Інформація призначена тільки для фахівців сфери охорони здоров'я, осіб,
які мають вищу або середню спеціальну медичну освіту.

Підтвердіть, що Ви є фахівцем у сфері охорони здоров'я.

Газета «Новости медицины и фармации» Гастроэнтерология (429) 2012 (тематический номер)

Вернуться к номеру

Облачные технологии в медицине

Авторы: А.В. Семашко, Центр томографии, г. Днепропетровск

Рубрики: Гастроэнтерология

Разделы: Справочник специалиста

Версия для печати


Резюме

В статье описаны возможности оптимизации работы сетевой программы «Доктрина» и модуля «MultyDoctor» для упрощения введения данных и получения информации по пациенту как для врача, так и для среднего медицинского персонала.


Ключевые слова

информационные технологии, программа, модуль.

«Священникам о приходских людях и о духовных детях иметь записныя книги, кто, у кого в приходе, когда родился, и кто молитву давал, где который младенец крещен и кем, и кто восприемник и восприемница были, и от которых лет кто у кого исповедывался; аще кто, кем, где и при ком обручен; аще кто умреть, при смерти — онаго кто исповедовали приобщал, и кто тому, аще и отвне, свидетелем был»… Так начиналась статистика на территории царской России и в Украине. Так этот наказ выполняется в большинстве лечебных учреждений Украины сейчас.

В последнее десятилетие в медицине отмечается быстрое развитие информационных технологий (ИТ). Первые компьютерные программы относились к разряду статистических модулей и решали задачи простого обобщения цифровых данных практического здравоохранения или же статистического анализа для научных целей, например, программа Statistica американской компании StatSoft, российская «Медстатистика 3.2», украинский «МедСтат».

На следующем этапе появились различные модульные специальные продукты по отраслям медицины, так называемые автоматизированные рабочие места (АРМ). Наиболее популярные из них, прежде всего в силу коммерческой привлекательности, относятся к поликлинической и стоматологической практике. Отдельно стоят программные продукты графической обработки медицинских данных рентгеновских исследований (АРМ врача­рентгенолога, врача компьютерной, магнитно­резонансной томографии), а также средства управления соответствующими базами данных. Разработкой этих продуктов, как правило, занимаются ключевые производители медицинского профильного оборудования, обеспечивая себе «привязку» покупателя такого оборудования к бренду производителя. Несмотря на то, что в последнее время общепринятым стал протокол передачи графических данных DICOM 3, до сих пор существуют проблемы обмена данными, произведенными на диагностических машинах разных производителей. Необходимость интеграции данных, различных не только по формату, но и по сути (текстовая, цифровая, графическая информация), привела к появлению универсальных программных комплексов, объединяющих производственные лечебно­диагностические модули.

Особенностью этой работы на первом этапе стала разрозненность действий участников сферы здраво­охранения: в штат сотрудников каждого лечебного учреждения, как правило, входили программисты, которые выполняли заказ инициативного медицинского работника и моделировали такую медицинскую информационную систему под потребности и представления о ее функционале конкретного лечебного учреждения. Перед этими программами стояли такие задачи: сбор статистической информации о движении пациентов, их различных характеристиках, сбор и обработка информации о материально­технической базе медицинского учреждения, помощь в подготовке отчетной документации.

В практической работе врача большинство систем были мало применимы, за исключением персонализированных АРМ в пределах небольшого специализированного медицинского учреждения. При этом основной задачей разработчика прикладного медицинского программного продукта должно стать облегчение работы медицинского работника. Второй не менее важной задачей такой программы должна быть максимальная объективизация вводимых и обрабатываемых данных. Так, если попросить описать ход операции двух врачей, наблюдавших за ней или даже участвовавших в ней, мы получим в лучшем случае две разные версии. В худшем, если один из описывающих — оператор, мы можем увидеть значительное расхождение в описательной части, особенно в случаях нестандартной ситуации, в случае возникшего осложнения и его коррекции. В той же мере подобная картина возможна в любых эпизодах трактовки врачом результатов исследования, протоколов и пр. Третьей задачей разрабатываемых продуктов для медицины должна быть безусловная полезность программ в работе врача, на которую он должен потратить свое время.

Распространение мобильных и облачных технологий, аналитики больших данных изменило сами подходы к ведению бизнеса, и тому есть множество примеров. Скажем, GE (General Electric) применяет облачную систему для управления автоматизированными электросетями (smart grid). Развитие сервиса и возможностей работы, передачи данных по Интернету и локальным сетям отразилось и на тренде разработок программ для медицины. По словам старшего вице­президента и главного аналитика компании IDC Фрэнка Дженса (Frank Gens), мир ИТ переходит на третью платформу, ключевыми элементами которой являются мобильные смарт­устройства, облачные вычисления, социальные сети и аналитика больших данных (big data). В результате конкурентной борьбы на этих четырех направлениях и рождаются сегодня основные тренды. Клиника Джона Хопкинса (Johns Hopkins Hospital) совместно с корпорацией Harris на облачной платформе создает и предоставляет сервисы медицинской визуализации. Указанные компании являются лидерами в своих отраслях.

Моделируемая нами идеальная программа для прикладных задач в медицине должна упростить бумажную работу врача. Она должна быть максимально простой, даже понятной на уровне интуиции, рассчитанной на «ленивого» медика, которому некогда осваивать мануал к программе. И главное — такая программа должна быть полезной для принятия решения.

В связи с этим наиболее удачным был бы комплекс, содержащий модуль введения объективных данных и модуль работы с такими данными, максимально копирующие обычную коммуникативную технику работы врача, какими являются речь, видео, графические инструменты, математические интерпретации данных, введенных самим врачом, а лучше в автоматическом режиме — как результат работы самой системы, что минимизирует влияние человеческого фактора и появление случайной ошибки.

Скромную попытку приблизиться к задекларированным принципам мы попытались реализовать в узкопрофильной сетевой программе «Доктрина» (авторы — А.В. Семашко и К.Б. Корчминский) и модуле MultyDoctor (авторы — А.В. Семашко, С. Ватилик), основанном на технологиях облачных сервисов, связав их в единый технологический процесс.

Система «Доктрина» реализована на программном языке Delphi, использует структуру баз данных Firebird. Программа (в дальнейшем — ПК «Доктрина») работает на частном медицинском диагностическом предприятии «Центр томографии» г. Днепропетровска с апреля 2011 года, прошла этапы инсталляции, наладки и в данный момент является стержнем технологического процесса. ПК «Доктрина» содержит несколько связанных рабочих модулей.

Модуль администратора со стандартным набором введения данных пациента показан на рис. 1.

 Мы попытались максимально упростить работу администратора, избавив его от ручного введения стандартных полей по адресу и месту работы пациента, направившего врача. В распоряжении администратора имеется модуль, связывающий диагнозы и возможные варианты исследований, что также облегчает поиск необходимого исследования. В данный модуль интегрирована программа записи пациента на исследование по телефону и через сайт Центра томографии (www.tomograph.dp.ua). Программа без участия какого­либо сотрудника напомнит пациенту sms­сообщением за два часа о запланированном исследовании. Точно таким же образом, без участия персонала Центра томографии, ПК «Доктрина» сообщит пациенту о готовности его результатов исследования, как только врач компьютерного томографа сформирует пакет с описанием исследования, рентгеновской пленкой и записанным CD­диском. В результате внедрения этого модуля нам удалось отказаться от постоянного ведения администратором­регистратором двух журналов: журнала предварительной записи на исследование и журнала учета выданных результатов исследований. Следует отметить, что работник рецепции, он же кассир, имеет в своем распоряжении интегрированный модуль (рис. 2) расчета показателей цены, скидки, факта оплаты, отсрочки платежа, напоминания об истечении времени рассрочки и пр.

Процедура оформления рассрочки платежа также максимально технически упрощена и занимает значительно меньше времени, чем при оформлении вручную. При этом исключен фактор персональной ошибки, т.к. расписка формируется и отпечатывается полностью автоматически. Интегрированный модуль sms­рассылок в фоновом режиме напомнит пациенту о необходимости доплаты за исследование за некоторое время до истечения срока. По итогу рабочего дня ПК «Доктрина» автоматически в запланированное время сформирует финансовый и краткий статистический отчет и отправит в фоновом режиме данные ответственным сотрудникам Центра томографии в виде sms­сообщений.

Модуль медицинской сестры — оператора компьютерного томографа наиболее прост и изначально задумывался именно таким, ибо на этого сотрудника возложена функция непосредственного выполнения исследования, начиная с предварительной доврачебной оценки возможности его исполнения, работы по укладке пациента в машинном зале, коммуникации с ним в процессе исследования и заканчивая подготовкой полученных данных в виде, удобном для врача­специалиста. Из этого модуля медицинская сестра автоматически получает информацию от ПК «Доктрина» о важных данных по пациенту, наличию у него в данный момент при себе данных других методов исследования. Модуль медицинской сестры позволяет ей программно изменять очередность пациентов, ожидающих исследования, если того требует клиническая ситуация, выбирая их из списка­плана, сформированного администратором. Более чем в 99 % случаев медицинской сестре приходится использовать в этом модуле только кнопки «Начать исследование» и «Завершить исследование», под которыми «зашито» много автоматизированных функций ПК «Доктрина»: синхронизация работы программного комплекса самого КТ и ПК «Док­трина», формирование папки исследования, которая будет в последующем автоматически наполнена протоколом­описанием исследования, конвертированными снимками исследования, уникальным шифром исследования для использования в работе облачного сервиса MultyDoctor. Тут же программа автоматически выполняет перевод ФИО пациента с русского на английский, что облегчает введение этих данных в компьютерную систему КТ. Медицинского работнику на этом этапе потенциально даны возможности удалить исследование из заказа, если на данном этапе выявлены факторы, препятствующие его выполнению. Точно так же возможно изменить вид исследования, выбрать (изменить) вид контрастного препарата, добавить к исследуемой зоне любую другую или убрать дополнительное исследование. Все эти решения медицинского работника (врача или опытной медицинской сестры) тут же отражаются в автоматическом режиме на рабочем модуле администратора, меняя виды исследования, цены и пр.

В результате использования этого модуля мы исключили из работы медицинской сестры два журнала — учета выполненных исследований и учета дозы облучения. Как и в предыдущем модуле, ПК «Доктрина» формирует эти данные автоматически и использует их далее в отчетах, которые также формируются автоматически в заданные временные промежутки. Несмотря на очевидную простоту работы на данном рабочем месте, именно на этом этапе ПК «Доктрина» формирует автоматизированный алгоритм последующих действий: автоматически присваивает папке с данными пациента уникальное имя и привязывает это исследование к конкретному врачу. Следует отметить, что вход в систему любого сотрудника персонифицирован через авторизацию путем введения пароля. Как и во всех других программах, эти меры связаны с необходимостью контроля присутствия персонала в сети. Кроме этого, персонификация в ПК «Доктрина» используется для контроля выполненного сотрудником объема работ, что автоматически применяется для расчета его заработной платы.

Таким образом, модуль медицинской сестры воплотил в себе три постулата «идеальной» программы: богатый функционал модуля «зашит» всего лишь под двумя кнопками; упростил ее работу, избавив от ведения бумажного учета и последующей статистики; дал оператору КТ дополнительную необходимую информацию о состоянии здоровья пациента, о его предыдущих посещениях Центра томографии, позволил управлять очередностью исследований и их составом, не сходя с места — средства помощи в принятии решения; несомненная польза на данном этапе — автоматизированное формирование последующего алгоритма работы так называемого «робота», о функциях которого будет сказано ниже и от надежности работы которого зависят все последующие процессы.

Модуль врача КТ представляет из себя нечто, похожее на базу данных, и примитивный, но достаточно функциональный текстовый редактор. Используя процедуру персонификации, в одно и то же время или по установленному графику с «сырыми» данными могут работать сразу несколько врачей. Это зависит от количества рабочих графических станций обработки изображений КТ и количества рабочих модулей программы «Доктрина». Физически исследование КТ выполняется опытной медицинской сестрой для дальнейшего описания разными врачами. Заказ на конкретного врача производится на этапе работы администратора и может быть корректирован также на модуле медицинской сестры. Сам же врач может приступать к описанию исследования как сразу после его исполнения, так и гораздо позже. Авторизуясь, врач фильтрует на свое рабочее место только те исследования, которые предназначены именно ему, и не видит чужих исследований. Авторизуясь, врач идентифицирует себя в системе MultyDoctor, о чем будет сказано далее. Модуль врача КТ обязательно сообщит своему врачу, что он задерживает описание исследования, отослав эту информацию автоматически врачу в виде sms, если тот забыл или задерживается. Опция контроля допустимой временной задержки описания исследования, как правило, не более 3 часов для планового исследования, автоматически генерируется программой по истечении указанного времени. В случае срочного исследования врач будет уведомлен об этом сразу. Такая же функция автоматически применяется в случае, когда врач описал и распечатал протокол исследования, но по каким­либо причинам задерживает распечатывание рентгеновской пленки. Временной интервал для этого случая составляет не более 30 мин. Этот механизм ПК «Доктрина» автоматически забирает на себя некоторые функции менеджмента со стороны директора или ответственного менеджера. В работе этой опции имеют место нюансы, которые учитывают разные рабочие ситуации и которые не относятся к теме данной статьи, так как отражают все те же признаки «идеальной» программы, но применительно к работе директора или менеджера, модули которых не будут здесь нами освещаться. Кроме этого, модуль врача КТ позволяет врачу не тратить время на оформление протокола исследования, введение паспортных данных пациента, названия исследования, суммарной дозы облучения, параметров исследования и пр. Модуль тут же укажет врачу на то, были ли ранее этому больному выполнены исследования в Центре томографии, извлечет и будет держать на видном месте ранние протоколы и снимки в цифровом варианте. Их не нужно искать по базе данных вручную, чтобы сравнить снимки или описания. Более того, возможно использовать старый протокол по этому пациенту в виде шаблона для написания нового, если в нем, например, у онкологического больного надо изменить лишь цифровые данные очагов поражения. В данном модуле врач под рукой имеет свои шаблоны по различным зонам исследования, которые он может на свое усмотрение изменять, добавлять или удалять, также врачу тут же доступны шаблоны его коллег, авторизованные ранее в системе. Чужие шаблоны врач может применить для описания своего пациента, сохранить понравившийся шаблон под своим именем, но не может изменить или удалить чужой шаблон. Закончив описание исследования путем клика по кнопке «Готово», врач переходит с текстом протокола исследования в полном его дизайнерском фирменном оформлении в редактор MSWord, где воочию может увидеть законченный вариант, где уже будет автоматически встроена его подпись и ФИО, а также «шапка» предприятия (Центр томографии), данные о больном и все данные о структуре исследования. Именно отсюда производится распечатывание текста протокола. При этом врач уже не утружден сохранением протокола исследования, так как на этом этапе модуль доктора КТ уже автоматически произвел сохранение, привязав протокол к персональной базе данных доктора, к базе данных пациента и к папке конкретного исследования с уникальным кодом. Именно в тот момент, когда врач нажал кнопку «Готово», под управлением «робота» начинают осуществляться действия, которые стали основой функционирования системы MultyDoctor. Эти действия происходят в автоматическом фоновом режиме и не заметны для персонала Центра томографии. Таким образом, в модуле доктора КТ нами также реализованы, возможно, не в полном объеме, принципы «идеальной» медицинской программы. Была радикально упрощена работа врача с базой данных пациентов, по оформлению протокола исследования за счет как готовых шаблонов, так и «сшивания» данных по больному, введенных на предыдущих этапах, врач избавлен от риска потери исследования или забот по его сохранению в своей папке. Очевидная полезность программы заключена в автоматизированной помощи врачу в применении предыдущих исследований по этому больному, есть возможность тут же их сравнить. Несомненная польза заключена также в обмене опытом между врачами Центра томографии путем использования шаблонов своих коллег, а также в «персональном менеджере», который автоматически контролирует и корректирует режим работы врача. После нескольких дней работы с программой практически все врачи отметили больший комфорт работы по данному протоколу, чему ярким подтверждением было их активное участие в доработке функционала данного модуля. В результате такого сотрудничества работа с модулем врача КТ значительно упростилась, в некоторых местах автоматизировалась. На наш взгляд, дизайн рабочего места имеет большое значение для обеспечения комфорта в работе с программой. Первоначально неудачно выбранный дизайн инструментов программы негативно сказывался на ее функционале и в кратчайшие сроки нами изменялся.

Считаем необходимым описать еще задачу и ее решение в модуле врача КТ, заключенные в логической схеме функционирования «робота». Проблема заключалась в том, что пациент получал на руки пакет с исследованиями, которые ничего не говорили направляющему доктору о логике работы врача Центра томографии: протокол с описанием исследования, пленку формата А3 с двенадцатью черно­белыми картинками и CD с полным набором «сырых» картинок. На практике врач КТ, описывая исследование, оперирует не двенадцатью картинками, отобранными им для рентгеновской пленки, а гораздо большим количеством, доходящим до 50 и более, на которых видны особенности патологического процесса. На этих снимках врач для себя оставляет графические отметки, указатели и пр. Таким образом, врач­заказчик исследования лишен возможности проследить ход мысли врача КТ, а найти эти утерянные картинки в общем массиве на CD практически невозможно. Редко врач­заказчик про­сматривает весь массив картинок на CD, особенно если он работает в ограниченном временном режиме. Мы столкнулись с тем, что исследование попадает врачу­заказчику от пациента в лучшем случае на следующий день. А может и вовсе не попасть, даже быть утерянным. Часто результаты выполненного исследования нужны врачу­заказчику срочно. Все эти проблемы мы решили, обязав «робота» по клику «Готово» активизировать следующие функции в режиме on­line:

— «робот» по ранее сгенерированному автоматическому ключу и специальным меткам находит весь массив «сырых» картинок, с которыми работал врач Центра томографии, а специальный конвертер преобразует их в формат меньшего размера, но очень хорошего качества и копирует эти файлы в отдельную папку, имеющую уникальный код привязки к ФИО пациента и конкретному исследованию. Таким образом, мы получили тот усредненный объем графической информации, который реально отображает исследовательскую работу врача КТ;

— «робот» помещает в эту папку готовый протокол с описанием исследования, подписью врача и его ФИО, таким образом сформировав полноценный объем информации для пересылки;

— «робот» информирует администратора на его модуле об окончании исследования и помещает данное исследование в группу законченных;

— «робот», используя базу данных по пациентам и врачам, применив номера их мобильных телефонов, автоматически отсылает sms­сообщения: пациенту — с текстом о том, что описание исследования закончено и он уже может его получить; врачу — с текстом о том, что его пациенту (ФИО пациента) выполнено исследование и врач может получить результаты этого исследования немедленно, войдя на сайт Центра томографии и введя в специальное поле уникальный код, указанный в данном sms. При этом «робот» будет определенное количество раз пытаться отправить эти сообщения в ситуациях проблемы с мобильной связью, пока не достигнет положительного результата.

С момента удачной отсылки sms врачу­заказчику начинается работа модуля MultyDoctor, который на сегодня является уникальным для отечественного здравоохранения и аналогов которому мы не нашли в зарубежных программных комплексах. Это область реализации особых инструментов облачных сервисов, которые стали доступны только в недавнем времени благодаря улучшению в работе протоколов передачи данных в Интернете. Функционал сервиса MultyDoctor нацелен на объективизацию введения и оценку медицинской информации. Главное окно сервиса MultyDoctor показано на рис. 3.

В разработке сервиса MultyDoctor мы начали движение в этом направлении и не претендуем на исключительность способа решения этой сложнейшей задачи. Тем не менее практические врачи­заказчики уже позитивно оценили работу данного сервиса. Мы с благодарностью принимаем их критические замечания по улучшению работы нашего облачного сервиса MultyDoctor.

Во­первых, в соответствии с требованиями защиты персональной информации мы не можем в свободном режиме позволить ознакомиться с функционалом сервиса MultyDoctor, так как в эту систему врач может попасть, только воспользовавшись присланным ему уникальным sms­кодом, который в случайном порядке генерируется «роботом» и становится известен только доктору­заказчику исследования и системному администратору Центра томографии. Применительно к работе ПК «Доктрина» на выделенном сервере автоматически формируется база данных «врач — пациент», куда выгружается папка с усредненными данными и протоколом исследования. Врач­заказчик имеет возможность прочитать и распечатать протокол со своего компьютера, прямо из окна сервиса MultyDoctor, выбрав для этого из массива снимков именно те, которые, на его взгляд, являются наиболее информативными, и поместить отпечатанный лист в карту пациента. В этом сервисе реализованы инструменты коммуникации врача­заказчика исследования и врача Центра томографии, который описывал это исследование. Если в конкретный момент времени врач Центра томографии находится за работой со своим персонифицированным модулем врача КТ, он «виден» на сервисе MultyDoctor как доктор, с которым возможно непосредственное общение. Чтобы врач­заказчик имел возможность задать вопрос типа «что это такое?», ему доступны средства графического выделения подозрительного места на снимке путем его обведения. Находясь в чате с врачом­заказчиком, врач Центра томографии тут же видит это графическое действие и точно понимает, о каком проблемном месте идет речь, таким образом, общение докторов становится максимально предметным. Кроме того, врач­заказчик исследования, скажем так — держатель кодового ключа доступа к результатам исследования, может пригласить к обсуждению этих снимков­картинок любое количество коллег, последовательно вводя в особую форму номер мобильного телефона врача, которого он желает временно подключить к обсуждению данного исследования. Форма приглашения к on­lineконференции представлена на рис. 4.

Приглашенные врачи получают на свои мобильные телефоны sms­просьбу принять участие в обсуждении клинического случая и временный, действующий не более одних суток, код доступа в систему MultyDoctor именно в данный раздел по конкретному пациенту. Функционал MultyDoctor для приглашенных врачей тот же, что и для держателя кодового ключа, те же графические инструменты выделения и стирания, тот же протокол обмена текстовой информацией. После закрытия сеанса консультаций эти элементы графики не сохраняются, оставляя базу данных в неизменном виде. Отдельную картинку или файл с текстовым протоколом держатель кодового ключа может отослать на электронную почту одному или нескольким участникам такой конференции прямо из сервиса MultyDoctor.

Облачный сервис MultyDoctor предоставляет врачу­заказчику исследования довольно большой дополнительный функционал для работы с базой данных других своих пациентов. Здесь он имеет полную историю по всем своим пациентам, которые прошли исследование в Центре томографии. С этой базой данных врач может работать в любом месте, где ему доступен вход в Интернет. Большой объем функционала этого сервиса относится к средствам коммуникации врача­потребителя с управлением Центра томографии. Фактически сервис MultyDoctor для потребителя не выглядит как какая­то особенная программа. Ей не нужно обучаться, ее не нужно инсталлировать на свой компьютер, она не засоряет память ПК и не угрожает ему какими­либо действиями с системным реестром. В этом, на наш взгляд, еще одна черта «идеальной» медицинской программы, реализованной инструментами облачного сервиса, — программа не должны выглядеть или быть для пользователя программой в привычном представлении. На базе развития функционалов и коммуникации между ПК «Доктрина» и облачным сервисом MultyDoctor нами продолжается разработка других инструментов управления и анализа различных визуальных и цифровых типов медицинской информации, в чем мы видим настоящие перспективы улучшения качества обслуживания пациентов и возможный прогресс в развитии информационных медицинских систем.

В заключение несколько слов о безопасности системы в целом и о причинах, тормозящих продвижение таких программ в медицине. Самым серьезным препятствием в переходе к «облакам» являются культурные и ментальные особенности работы системы здравоохранения. Если одной фразой определить функциональную нагрузку облачного сервиса в медицинской практике, то она, по нашему мнению, звучит так: «система аутсорсинга в медицине». Предприятия этой системы не имеют опыта аутсорсинга в своей деятельности, а тем более с базами данных. При этом облачный сервис, облачная аналитика в медицине — прекрасная технология, позволяющая совершить серьезный прорыв, резкий скачок вперед в реформировании управления медицинским предприятием, экономя большие ресурсы, финансовые и кадровые. Прежде всего потому, что «облако» — это сама по себе огромная база ресурсов, причем достаточно недорогих. Второй, не менее важный вопрос: сможет ли провайдер внешнего облака обеспечить достаточный уровень безопасности данных? На этот вопрос весомо ответил все тот же аналитик компании IDC Фрэнк Дженс: «Зерно правды в том, что сервис­провайдеры являются очень крупными мишенями и злоумышленникам легко в них попасть. Но, с другой стороны, именно потому, что они крупные, у них и ресурсов для обеспечения безопасности больше, чем у какой­нибудь средней компании. И миф как раз состоит в том, что ваши данные будут в большей безопасности, если останутся внутри компании. Ведь если вы не являетесь крупной корпорацией, то сколько можете позволить себе потратить на безопасность своего Центра обработки данных? Наверное, не много. У вас просто не хватит ресурсов справиться с целенаправленной кибер­атакой. Поэтому для небольшой компании переход к поставщику облачных сервисов станет скорее укреплением ее безопасности».


Список литературы

1. Гимадеев Ш.М., Латыпов А.И., Радченко О.Р., Радченко С.В. «Облачные» вычисления в решении задач классификации на примере мужского бесплодия: новый источник медицинских данных // Вестник современной клинической медицины. — 2011. — Т. 4, № 3. — С. 64­71.

2. Гусев А.В. Перспективы облачных вычислений и информатизация учреждений здравоохранения // Врач и информационные технологии. — 2011. — № 2. — С. 6­17.

3. Оленева И.В. Современное состояние проблемы внедрения электронных медицинских карт в единой государственной информационной системе // Медицинский алфавит. — 2011. — Т. 4, № 20. — С. 8­10.

4. Gillam Lee. Cloud Computing: Principles, Systems and Applications / Nick Antonopoulos, Lee Gillam. — L.: Springer, 2010. — 379 p.

5. Mell Peter and Grance, Timothy. The NIST Definition of Cloud Computing. Recommendations of the National Institute of Standards and Technology // NIST. — 20 October 2011.

6. SoCC ’10: Proceedings of the 1st ACM symposium on Cloud computing / Hellerstein Joseph M. — N.Y.: ACM, 2010.


Вернуться к номеру