“ЖУРНАЛ РАДИОЭЛЕКТРОНИКИ” N 5, 2013

оглавление

О ПОСТРОЕНИИ ТИПОВОЙ ИНТЕГРИРОВАННОЙ МИС ДЛЯ РАДИОЛОГИИ И ОБСЛУЖИВАНИЯ МЕДИЦИНСКИХ ПРЕДПРИЯТИЙ ДРУГИХ ТИПОВ, ОРГАНИЗАЦИИ ОБУЧЕНИЯ, ОБРАБОТКИ И ПРЕДСТАВЛЕНИЯ СТАТИСТИЧЕСКИХ ДАННЫХ

 

А. Р. Дабагов
ЗАО «Медицинские технологии ЛТД»

Получена 21 мая 2003 г.

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

Ключевые слова: радиология, информатизация медицинских комплексов, облачные структуры, центры обработки и хранения данных.

Abstract. On the basis of a fast progress in the development of new radiology systems for the needs of healthcare, and the development of new integrated medical information technologies some new developments in the field of integrated computerized medical systems (EMS) are considered.  Some directions in the development of EMS in the near future in connection with the rapid development of cloud technologies and capabilities that the last ones open for new systems of medical informatics are discussed.

Keywords: radiology, computerization of medical complexes, HIS, cloud structures, centers of data processing and storage.

 

1. Введение

В обзорной работе [1] отмечалось, что, несмотря на ряд впечатляющих успехов в области информатизации и компьютеризации медицинских технологий, ряд проблем всё ещё остается и, кроме того, появляются новые, связанные с разнородностью уже существующих систем, проблемами жизненного цикла (старением), стандартизацией, и др.

Имеющиеся заделы в области наукоёмких медицинских технологий позволили и в России приступить к выпуску новой цифровой медицинской техники и программно-аппаратных средств интеграции, позволяющих внести новое измерение не только в сам процесс радиологических исследований, но также и в работу медицинских учреждений в целом [2,3].

Прогресс в различных областях ИТ, появление новых аппаратно-программных платформ и инновационных технических решений (например, облачные технологии [4] и GRID [5], последние в известной степени могут дополнять друг друга) постоянное улучшение характеристик компонентов, развитие инфраструктуры, впечатляющее увеличение плотности интеграции компонент (закон Мура) позволяют на сегодня разрабатывать и применять принципиально новые архитектуры на основе комбинаций уже апробированных решений, способствуя тем самым созданию крупных региональных и межрегиональных систем, облегчению настройки среды как под конкретного клиента, так и удовлетворения иным требованиям, облегчению интеграции и, в общем случае, обеспечивают возможности строить более сложные системы и адаптировать их под различные задачи в более сжатые сроки и с достаточно высокой эффективностью. Эти новые подходы, вообще говоря, открывают для медицинской информатики принципиально новые возможности, заключающиеся как в значительно большем разнообразии архитектурных решений, более широком применении открытых технологий[1], более легкой встраиваемости уже апробированных программных кодов[2] и, по мере необходмости, дополнительных программных модулей, и т.д. В конечном счёте этими технологиями гораздо легче (и дешевле) охватить имеющиеся лечебно-профилактические учреждения (ЛПУ), обеспечив необходимую функциональность и интеграцию с другими лечебными учреждениями и иными органами, в том числе для научных целей. Дальнейшему расширению будет препятствовать имеющаяся на настоящее время несогласованность стандартов и приравниваемых к ним документов (а иногда и их отсутствие), а также некоторые важные технические вопросы, препятствующие обеспечению открытости (как например, impedance mismatch, model mismatch, architecture mismatch – последнее в основном касается форматов и методов хранения данных).

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

 

2. Шаги разработки

Информационные медицинские системы мы можем условно разделить на три типа:

1. Специализированные системы (например, радиологические)

2. Общебольничные системы.

3. Интегрированные системы, позволяющие, помимо интегральной автоматизации всего ЛПУ, легко строить модульные конструкции (т. е. добавлять в случае необходимости дополнительные модули), интегрировать территориально системы информатизации различных ЛПУ в некоторый общий кластер, предоставлять физическим и юридическим лицам иные услуги (обработка данных, консультационную помощь, доступ к базам данных, проведение телеконференций, также оказывать ИТ-услуги отдельным пациентам (хранение и предоставление по запросу личных данных, услуги онлайн-мониторинга и др.)

 

 

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

·        достаточно большие объемы информации;

·        высокая скорость передачи больших массивов данных;

·        без потери качества изображений;

·        конфиденциальность.

 

Таким образом решались первоочередные задачи:

 

·        Повышение качества обследования пациентов,

·        Использование возможностей обработки изображения,

·        Увеличение эффективности работы врача,

а также

·        Повышение уровня организации работ в ЛПУ,

·        Увеличение пропускной способности отделений,

·        Автоматизация рабочего процесса.

Система первоначально включала в себя следующие модули:

·        АРМ регистратора

·        АРМ лаборанта

·        АРМ врача-диагноста

·        АРМ врача-клинициста

·        АРМ конференции

·        Центр обработки данных

·        Устройство печати медицинских диагностических изображений

·        Устройство записи и графического оформления CD и DVD дисков

Далее был добавлен телекоммуникационный модуль, включающий в себя систему «Телемед-МТ».

Система строилась на современном уровне и с применением современных стандартов и протоколов (HL7, DICOM 3 etc). Последнее позволяло последовательно интегрировать в систему другие блоки обработки и анализа информации, что в результате привело к созданию интегрированной медицинской ИТ-системы «ИнтегРис-МТ», ( рис. 2).

К ее основным преимуществам следует отнести следующие:

·        Модульная структура позволяет превратить отдельные АРМ, вне зависимости от их местонахождения, в полноценные телемедицинские терминалы;

·        Телекоммуникационный блок обеспечивает возможность работы как по выделенным каналам, так и через Интернет, со стационарными ЛПУ и мобильными рентгенодиагностическими кабинетами;

·        Специализированные технологии передачи медицинских изображений позволяют использовать каналы связи с ограниченной пропускной способностью;

·        Эргономичный интерфейс, позволяющий врачу в удаленном доступе просматривать полную информацию о пациенте, включая историю исследований и все ранее сделанные снимки;

·        При получении, обработке, передаче и хранении данных обеспечивается надёжная защита информации.

 

 

 

На основе проведенных разработок был реализован проект внедрения телемедицинской интегрированной радиологической информационной системы, показавший высокую эффективность и удобство работы для врачей и персонала клиник. Схема системы показана на рис. 3.

 

3. МИС и облачные технологии

Облачные технологии – хороший пример того, что «новое есть хорошо забытое старое». Так, нечто похожее разрабатывалось еще для машин серии IBM 360 и некоторых других. Недавний взрыв интереса к облачным технологиям и появление многочисленных аппаратно-программных средств, включение средств виртуализации в процессоры Intel и AMD объясняется, в основном, тем, что производительность серверов на базе х64 и х86 становится недопустимо низкой; так, для последних она находится в пределах 5–15% [6]. Последнее обстоятельство является особенно неприятным при построении больших серверных систем и центров обработки данных (ЦОД)[3] [7]. Облачные системы имеют и ряд других преимуществ, так, увеличивается скорость развертывания, в ряде случаев можно значительно улучшить показатели скорости и надежности работы с данными, и немаловажное значение имеет факт, что в облачных архитектурах в принципе можно использовать старые и хорошо зарекомендовавшие себя программы и модули, просто поставив нужные «гостевые» ОС и соединив их тем или иным образом с новыми конструируемыми приложениями, интерфейсами и т.д.

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

Ряд вопросов вызывают проблемы безопасности в облачных структурах, имеющих свою специфику. Однако, судя по огромному количеству публикаций в печати, над «облачными» проблемами, в том числе в области безопасности, работают ряд крупнейших фирм, некоммерческих организаций и отдельных энтузиастов-профессионалов. Следует, однако, подчеркнуть, что, по отзывам изготовителей, разработчиков и администраторов, обслуживание облачных структур требует более высокого профессионализма «команды»[4], что, однако, кратно компенсируется снижением затрат на использование «облаков» в замену традиционных IT-структур.

По мере развития технологии появилось определение облачных вычислений, которое было дано Национальным институтом стандартов и технологий (NIST). Оно состоит из пяти основных характеристик, трех моделей служб и четырех моделей развертывания [4,8]:

3.1. Основные характеристики

·        Самообслуживание по запросу, т.е. пользователь может (но не обязательно должен) готовить вычислительные ресурсы для сеанса работы.

·        Широкий доступ к сети. Пользователь должен иметь необходимый  доступ к сети с помошью стандартного утилитария, поддерживаемого сообществом Интернет.

·        Создание пулов ресурсов. Вычислительные ресурсы поставщика объединяются в пулы для обслуживания нескольких пользователей с помощью многоклиентской модели.

·        Способность к быстрой адаптации. Средства могут быстро и гибко подготавливаться к работе, в некоторых случаях автоматически, для быстрого масштабирования, а затем быстро освобождаться для свертывания.

·        Измеряемая служба. Облачные системы автоматически управляют использованием ресурсов и его оптимизацией с помощью средства измерения на некотором уровне абстракции, соответствующем типу службы[5].

 

3.2. Модели служб

·        Программное обеспечение как услуга (SaaS). Потребителю предоставляется возможность использовать приложения поставщика, выполняемые в облачной инфраструктуре.

·        Облачная платформа как услуга (PaaS). Возможность, предоставляемая  потребителю, развертывается в созданной им облачной инфраструктуре или приобретённых приложениях, созданных с помощью языков программирования и средств, поддерживаемых поставщиком. Потребитель не управляет базовой облачной инфраструктурой, включающей сеть, серверы, операционные системы и хранилище, но контролирует развёрнутые приложения и, возможно, параметры конфигурации среды размещения приложения.

·        Облачная инфраструктура как услуга (IaaS). Эта возможность, предоставляемая потребителю, предназначена для подготовки обработки данных, хранилища, сетей и других базовых компьютерных ресурсов; при этом потребитель может развёртывать и выполнять произвольно выбранное ПО, куда могут входить операционные системы и приложения. Потребитель не управляет базовой физической инфраструктурой облака, но может управлять операционными системами, хранилищем, развёрнутыми приложениями и, возможно, иметь ограниченный контроль над отдельными компонентами сети.

 

3.3. Модели развёртывания

·        Частное облако. Облачная инфраструктура предназначена только для одной организации. Она может управляться самой организацией или третьей стороной, а также может находиться внутри организации или вне ее.

·        Облако сообщества. Облачная инфраструктура совместно используется несколькими организациями и поддерживает определённое сообщество, которое имеет общие интересы (например, задачи, требования к безопасности, политику и необходимость соответствия требованиям). Она может управляться совместно или третьей стороной и находиться внутри сообщества или вне его.

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

·        Гибридное облако. Облачная инфраструктура состоит из двух и более облаков (частных, принадлежащих сообществу или общедоступных), которые остаются отдельными объектами, но связаны воедино стандартной или фирменной технологией, обеспечивающей переносимость данных и приложений (например, пакетная передача в облаке для балансировки нагрузки между облаками).

3.4. Классификация моделей

Для классификации различных моделей развертывания облачных вычислений используются два измерения: 1 - где выполняется служба: локально, в организации потребителя или центре данных поставщика услуг, и 2 – уровень доступа: общий или выделенный.

 

4. Характеристики стадии разработки проекта

На стадии пилотного проекта нами был разработан проект созданной нами интегрированной МИС в «облачном» варианте, обладающий всеми преимуществами облачных структур (скорость работы, быстрота развёртывания приложений, мобильность приложений и др)., позволяющий значительно расширить спектр предоставляемых потребителям услуг, за счёт передачи в облачную структуру части необходимого функционала информационно-технологического обеспечения медицинских учреждений, хранения и обработки данных, высокой скорости добавления и интеграции новых приложений, предоставления необходимых услуг «по запросу», а также за счёт быстрой настройки и конфигурации пула услуг. Разработанное решение также значительно повышает возможности увеличения мощности системы, ее переносимости и масштабируемости (как, впрочем, и отдельных ее компонент), легкости сопряжения с другими подобными системами.

4.1 Общие преимущества

·        Упрощение управления отделениями лучевой диагностики на уровне ЛПУ, группы ЛПУ, региона,

·        Обеспечение высокой степени надёжности хранения медицинских данных,

·        Увеличение круга специалистов, имеющих доступ к первичным радиологическим данным,

·        Предоставление доступа к диагностическим изображениям пациента независимо от того, в каком медицинском учреждении они получены,

·        Обеспечение круглосуточной доступности диагностических данных,

·        Обеспечение необходимой защиты медицинских персональных данных,

·        Обеспечение практически неограниченной масштабируемости,

·        Предоставление возможности проведения удаленной диагностики,

·        Обеспечение надежной идентификации врача и пациента в рамках системы.

4.2 Решение указанных в ЕГИСЗ первоочередных проблем

В Концепции создания ЕГИСЗ (Единой государственной системы в сфере здравоохранения) перечислены основные проблемы, тормозящие дальнейшее развитие системы здравоохранения, в их числе указываются:

·        Проблема сбора достоверной информации об объёмах проведённых радиологических исследований;

·        Проблема интеграции используемого медицинского оборудования с медицинскими информационными системами и внедрения цифровых систем для получения, диагностики и архивирования медицинских изображений и данных,

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

Для решения данных проблем разрабатывается система архивного хранения и предоставления доступа к медицинским изображениям, основанная на «облачных» технологиях. Опишем принцип работы системы:

4.3 Описание принципа работы

·        В ЛПУ устанавливается программное обеспечение, осуществляющее интеграцию с локальным сервером хранения медицинских изображений, или заменяющее данный сервер в случае, если он не установлен в ЛПУ[6]. Установленное программное обеспечение по стандартным протоколам (DICOM, HL7) принимает данные с диагностического оборудования ЛПУ и по настроенным политикам передачи данных передаёт их в дата-центр для долговременного хранения.

·        В дата-центре разворачивается программная инфраструктура по долговременному хранению диагностической информации и платформа для облачных сервисов.

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

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

·        Программное обеспечение, устанавливаемое в ЛПУ, поддерживает интеграцию с системами автоматизированной диагностики (CAD Computer-Aided Diagnostics) и с учётом возможности передачи в рамках системы снимков между ЛПУ обеспечивает использование функциональности CAD в ЛПУ, не имеющих подобных систем.

·        Передача данных между ЛПУ и дата-цетром осуществляется по защищённым протоколам передачи данных в соответствии с Федеральным законом от 27.07.2006 N 152-ФЗ «О персональных данных».

·        Система предоставляет для руководящих специалистов возможность сбора статистики о проведённых обследованиях. Формируемые системой отчёты позволяют оценить объём работы, выполняемой врачами и лаборантами. Так же система позволяет строить прогнозы уровня загруженности кабинетов на основе различных статистических моделей. Достоверность предоставляемых системой отчётов определяется автоматизированным способом их получения, а также тем, что к работе с системой допускаются только зарегистрированные в системе пользователи.

·        Интерфейс веб-доступа, по которому осуществляется взаимодействие врачей с дата-центром, позволяет осуществлять гибкую настройку под нужды и специфику каждого отдельного ЛПУ. Данная настройка может осуществляться сторонними организациями за счёт подключения ими модулей-расширений. Данные модули должны удовлетворять спецификации для модулей-расширений, которая будет публично доступна через веб-доступ. Также через веб-доступ будет предоставлена функция автоматической верификации модуля- расширения на предмет соответствия спецификации.

·        Система позволяет автоматизировать работу отделения лучевой диагностики, поскольку хранит и предоставляет по требованию всю входную и выходную информацию: направления на обследование, медицинские заключения и т.д.

·        Система обеспечивает сбор данных о потреблённых пользователем ресурсах и позволяет на основе выбранной пользователем политики рассчитывать стоимость потреблённых сервисов.

·        Пользователи взаимодействуют с системой через веб-интерфейс или браузер, за счёт чего обеспечивается кроссплатформенность предлагаемого решения. Кроме того, планируется тестирование работоспособности программного обеспечения на ведущих веб-браузерах.

·        Пользовательский интерфейс проектируется, среди прочего, в соответствии с Рекомендациями по разработке пользовательского интерфейса программ для Windows (Windows User Experience Interaction Guidelines) [http://msdn.microsoft.com/enus/ library/windows/desktop/aa511258.aspx].

·        Программное обеспечение разрабатывается в среде разработки Microsoft Visual Studio.

·        Система предоставляет возможность централизованного администрирования доступа пользователей к её ресурсам.

·        Система обеспечивает масштабируемость за счёт того, что выделяет вычислительные ресурсы только для подключенных к ней пользователей. В случае отключения пользователя от системы данные, с которыми работал пользователь, переносятся в долговременное хранилище.

·        Работа системы с базой данных осуществляется посредством языка SQL, без использования возможностей, специфичных для конкретной базы данных. За счёт этого обеспечивается возможность работы системы с произвольной базой данных и, как следствие, возможность подключения в случае необходимости дополнительных баз данных независимо от их типа.

·        Поскольку работа пользователя с системой осуществляется посредством веб-доступа по клиент-серверной модели, то обновление модулей системы можно проводить централизованно, без какого-либо участия пользователя.

·        В интерфейсе пользователя предусматривается механизм для формирования запросов в сервисную службу.
 

4.4 Достоинства конкретной модели

Выбор облачной модели для системы хранения медицинских данных определяет следующие её достоинства:

·        Упрощение сбора данных об объёмах работ выполняемых лечащими специалистами, а также о величине потока пациентов. Наличие достоверных данных о загруженности лечащих специалистов позволяет руководящему составу принимать взвешенные решения по управлению ЛПУ.

·        Простота получения всех данных пациента, включая данные об обследованиях в других ЛПУ.

·        Планирование затрат на хранение информации по мере увеличения её объёма и, как следствие, многократное уменьшение начальных вложений.

·        Круглосуточная доступность данных.

·        Простота сервисного обслуживания и обновления.

·        Значительное удешевление рабочего места клинициста, поскольку доступ к необходимой медицинской информации в рамках системы предоставляется посредством веб-доступа и не требует дорогостоящего медицинского программного обеспечения. При этом оплаты требуют только непосредственно потреблённые сервисы.

Разрабатываемое программное обеспечение использует многолетний опыт, полученный в результате автоматизации отделений лучевой диагностики. Гибкая архитектура системы позволяет создавать как системы хранения медицинских изображений для групп ЛПУ, так и региональные транзакционные системы.

Разрабатываемая система хорошо согласуется с принципами и установками Концепции создания ЕГИСЗ: «Для обеспечения долговременного хранения медицинских изображений могут создаваться централизованные цифровые архивы, обслуживающие несколько медицинских организаций. Создаваемые цифровые архивы и программное обеспечение, используемое в аппаратуре медицинской диагностики и лабораторных комплексах, должны интегрироваться с используемой данным учреждением здравоохранения медицинской информационной системой».

По результатам реализации проекта предполагается подача заявки в ФГУ ФИПС для регистрации разработанного программного продукта.

В настоящее время в медицинском диагностическом оборудовании идёт быстрый переход к цифровому способу получения и хранения диагностической информации. По инициативе и при поддержке правительства РФ в рамках Национального проекта «Здоровье», а также в рамках «Программы модернизации здравоохранения» была проведена масштабная замена морально устаревшего плёночного оборудования современными цифровыми аппаратами. Однако одного только наличия медицинской техники недостаточно для раскрытия всего потенциала, заложенного в цифровых технологиях. Можно выделить следующие основные причины, снижающие эффективность их применения. Во-первых, диагностическая информация доступна на данный момент лишь небольшому кругу профильных специалистов. Это связано в первую очередь с высокой стоимостью рабочего места врача-диагноста. Во-вторых, в настоящий момент диагностическая информация закреплена не за пациентом, а за ЛПУ, в которое он обращается, и, хотя информация циркулирует в пределах одного ЛПУ свободно, при обращении пациента в другое ЛПУ передать туда информацию бывает затруднительно. По той же причине проблематична и ее первичная обработка системами CDSS (системы поддержки клинических решений, как например, наша система SmartCAD [2].

4.5 Перспективы

В связи с чем, насущной необходимостью является объединение информационных систем отдельных ЛПУ с помощью «облачных» технологий с целью значительного повышения качества высокотехнологичных медицинских услуг за счёт объединения информационного пространства. Наличие современного цифрового оборудования, уже установленного в большом числе ЛПУ по всей стране в рамках «Программы модернизации здравоохранения», открывает потребности в централизованной системе доступа к медицинской информации. Интерес к разрабатываемой системе дополнительно будет обусловлен возможностью получения с "облачного" сервиса различной справочной информации, как то: методики диагностирования и лечения различных заболеваний, типичные диагностические картины, диагностические атласы и т. д. В перспективе, организуя связи между системами, объединяющими группы ЛПУ, возможно будет предоставлять централизованный доступ к медицинской информации уровня крупного города, региона и далее федерального, а также международного уровня.

4.6 Удовлетворение концепциям ЕГИСЗ

Ниже перечислены принципы Концепции создания ЕГИСЗ, которым удовлетворяет разрабатываемая система.

 

·        Система удовлетворяет принципу «однократный ввод и многократное использование первичной информации (полученной от медицинского (фармацевтического) работника, гражданина, должностного лица), в том числе для целей управления здравоохранением», поскольку обеспечивает обмен информацией между различными ЛПУ и за счёт этого ликвидирует её повторный ввод. Ввод информации в систему может осуществляться только зарегистрированными в системе медицинскими работниками.

·        Система удовлетворяет принципу «обеспечение совместимости (интероперабельности) медицинских информационных систем», в силу возможности интеграции с уже установленной в ЛПУ системой локального хранения медицинских изображений. После интеграции данные из локального архива ЛПУ становятся доступными из любого ЛПУ, подключенного к системе. Доступность данных регламентируется политикой безопасности, регламентируемой в системе.

·        Система удовлетворяет принципу «создание прикладных информационных систем по модели "программное обеспечение как услуга" (SaaS)», поскольку обеспечивает веб-доступ к основанному на облачной платформе архиву медицинских изображений и предоставляет потребителю возможность оплачивать только действительно потреблённые сервисы.

·        Система удовлетворяет принципу «централизованное управление разработкой, внедрением и сопровождением Системы на основании единой технологической политики с учетом отраслевых государственных, национальных и адаптированных к отечественным условиям международных стандартов в области медицинской информатики (включая стандарт HL7 и индустриальный стандарт DICOM для передачи радиологических изображений и другой медицинской информации)», поскольку в своей работе основывается на стандарте DICOM и имеет возможность интеграции с больничными информационными системами.

·        Система удовлетворяет принципу «предоставление Министерству здравоохранения и социального развития Российской Федерации или уполномоченной им организации организационной и технической возможности удаленного мониторинга работоспособности аппаратно-программных решений на уровне медицинской организации, а при необходимости и возможности удаленного управления аппаратно-программными решениями», поскольку информация о работе каждого ЛПУ доступна в центральном дата-цетре и может быть доступна соответствующим государственным органам после их регистрации в системе.

·        Система удовлетворяет принципу «принятие решения о модернизации используемых медицинских информационных систем и разработке новых компонентов Системы с учетом максимально возможного сохранения существующих программно-технических средств на основе анализа совокупной стоимости владения», поскольку позволяет осуществлять интеграцию с уже установленными в ЛПУ системами хранения медицинских изображений. Система также поддерживает конкуренцию среди производителей медицинских информационных систем, поскольку предоставляет возможность проводить настройку своей работы с помощью модулей-расширений, разрабатываемых сторонними организациями.

·        В зарубежной прессе периодически появляются статьи о системах, объединяющих большие сети коммерческих госпиталей в США, но в рамках отдельно взятой управляющей компании.

·        Система не имеет аналогов в РФ. У нас в стране существуют системы, которые позволяют просматривать и обмениваться медицинскими изображениями в рамках одного ЛПУ. Эти системы предназначены для накопления и обмена медицинскими данными внутри ЛПУ. Некоторые из этих систем предоставляют веб-доступ к хранящейся медицинской информации, но эти решения ограниченны рамками одного ЛПУ и ориентированы прежде всего на его локальных сотрудников. Логическое объединение медицинской информации является уникальной особенностью разрабатываемой системы.

4.7 Характеристики системы на первом этапе

На первом этапе, система должна иметь следующие характеристики:

·        Система должна обеспечивать не менее 16 одновременных подключений и одновременную работу не менее 200 пользователей.

·        Система должна обеспечивать загрузку обследований на пользовательские устройства со скоростью не менее 256 кбит/с, скорость обмена данными между ЛПУ не менее 1 Мбит/с.

·        Возможности системы должны позволять загрузку снимков исследований на пользовательские устройства в зависимости от типа исследования за время от 10 до 30 секунд.

·        Серверное оборудование комплектуется серверной группой из двух резервирующих друг друга серверов, а также дисковой системой с избыточным резервированием для максимальной надежности хранения данных.

Аппаратная часть системы, с учетом требований ее жизненного цикла, должна выполняться на широко распространённом серийном оборудовании. Вероятность безотказной работы – 0,998 (этот показатель может быть улучшен, но за счет существенного повышения стоимости проекта).

 

Заключение

1. Создана и апробирована ИТ-система автоматизации медицинских учреждений здравоохранения, расширяемая на региональном уровне. В системе интегрированы ряд сделаннных нами новых разработок в области радиологии. Система позволяет также интегрировать добавочные модули, необходимые для работы ЛПУ различного профиля, и, таким образом, представляет собой полноценную региональную МИС. Функционирование системы в Краснодарском крае РФ показало ее полную пригодность для решения поставленных ранее задач. Созданный продукт выводит региональную МИС на современный уровень, сокращает дефицит квалифицированного медицинского персонала, особенно в районных центрах; обеспечивает качество и скорость оказания медицинской помощи самого высокого уровня, сокращение заболеваемости и смертности населения.

2. Полный переход на «цифру» позволяет отказаться от традиционных методов рентгенологического исследования, Это обеспечивает ряд ощутимых преимуществ как для самих пациентов (снижение разовых доз облучения), так и для ЛПУ отсутствие традиционного фотопроцесса) и его персонала (повышение точности диагностики, облегчение поиска и хранения результатов обследований, систематизация результатов, обработка статистики, получение на ее основе новых данных для научного и статистического анализа, возможность получения данных «по запросу» в реальном времени, организация обучения персонала и многое другое.

3. Система также обеспечивает:

·        Сокращение перевозок пациентов для консультации.

·        Повышение пропускной способности ЛПУ.

·        Экономия площадей.

·        Автоматизацию медицинского обслуживания населения.

·        Повышение качества и улучшение организации лечебно-диагностического процесса.

Социальная значимость внедрения состоит в следующем:

·        Обеспечение диагностики для профилактики населения, выявления заболеваний на ранних этапах развития .

·        Повышение оперативности диагностики и лечения.

·        Повышение качества лечебно-диагностического процесса.

·        Доступность получения высококвалифицированной медицинской помощи для широких слоев населения.

 

4. Дальнейшее развитие системы на основе облачных технологий (реализация пилотного проекта) позволит обеспечить:

·        Удешевление стоимости владения, а в практическом плане – уменьшение стоимости обследований, повышение их точности;

·        Быстрое развертывание новых приложений, обслуживание учреждений здравоохранения в режиме «по запросу», предоставление медицинским предприятиям на различных условиях необходимых облачных сервисов с оплатой только фактического времени работы устройств, приложений и иных сервисов;

·        Быстрое реконфигурирование существующих и добавление новых сервисов;

·        Репликацию системы и/или ее частей, быстрое масштабирование системы;

·        Централизованнное обслуживание, настройку системы и/или отдельных ее частей (по конкретному договору с потребителем услуг);

·        Легкость поддержания жизненного цикла системы, перехода на новые аппаратно-программные платформы и технологии;

·        Повышение надежности и отказоустойчивости системы;

·        Подключение к системам других провайдеров.

В целом, для интегрированных медицинских систем облачные технологии открывают новый этап развития и большие перспективы в будущем. Кроме того, облачные технологии позволят, на наш взгляд, наилучшим образом обеспечить принципы «открытости» и решить ряд проблем, связанных как с вертикальной, так и горизонтальной интеграцией МИС в большие региональные системы электронного здравоохранения с возможностью их дальнейшего расширения и улучшения функциональности в будущем. В дальнейшем, степень интеграции систем может быть увеличена за счет включения их в системы GRID [5].

Литература

1. Дабагов, А. Р. Электронная медицина и проблемы построения интегрированных МИС. Биомедицинская радиоэлектроника, №5 2012 r., с. 40-49.

2. Дабагов, А. Р. Цифровая радиология и диагностика. Достижения и перспективы. Журнал Радиоэлектроники (Интернет-издание), №5 2009 r., стр. 1-18.. Москва: Издание ИРЭ РАН, http://jre.cplire.ru/jre/may09/2/text.pdf

3. Дабагов, А.Р. Современная цифровая радиология и диагностика в свете развития информационно-телекоммуникационных технологий. В сб.: 3-я Всероссийская конференция «Радиолокация и радиосвязь», с.

942-946, http://jre.cplire.ru/jre/library/3conference/conf3rd.pdf

4. Новости и возможности облака. http://technet.microsoft.com. [В Интернете] [Цитировано: 02. 03. 2013 г.] http://technet.microsoft.com/ru-ru/cloud/hh744751.aspx

5. Е. Е. Журавлев, В. Н. Корниенко, А. Я. Олейников , Т. Д. Широбокова. Модель открытой Грид-системы. Журнал Радиоэлектроники, № 12, 2012, с.1-19.

6. Черняк, Леонид. Ренессанс виртуализации - вдогонку за паровозом. Открытые системы. вып.2, 2007 r.
http://www.osp.ru/os/2007/02/4107980/

7. Черняк, Леонид. Виртуализация серверов стандартной архитектуры. Открытые системы. вып.3 2008 r.

http://www.osp.ru/os/2008/03/5015349/

8. Mell, Peter и Grance, Timothy. The NIST Definition of Cloud Computing. Gaithersburg, MD 20899-8930: US Dept. of Commerce, National Institute of Standards and Technology, Sept. 2011. http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf. Special Publication 800-145.



[1] Насколько большое значение при разработке облачных систем придается принципам открытости, видно из следующего примера. В 2001 году преподаватель Кембриджа и сотрудник лаборатории Ян Пратт дал старт проекту Xen (гипервизор, паравиртуализатор) и на все последующее время он стал его главным идеологом. Два университетских проекта VMware и Xen не похожи ни идеологически, ни технологически. В отличие от своих коллег из Стэнфорда, возглавляемых Розенблюмом, Пратт не пошел по пути немедленной коммерциализации, при создании своего предприятия, известного как компании XenSource, он отдал предпочтение подходам сообщества Open Source. Следуя принципам открытости, компания поддерживала сообщество разработчиков и продавала корпоративную версию продукта. Первая редакция Xen 1.0 была выпущена в 2003 году, за ней последовали 2.0, 3.0. В октябре 2007 года XenSource была куплена Citrix Systems и, как обычно в таких случаях, был произведен ребрендинг всей продуктовой линейки, XenExpress переименовали в XenServer Express Edition, встраиваемый гипервизор — в XenServer OEM Edition, XenServer — в XenServer Standard Edition и Enterprise — в XenServer Enterprise Edition. Несмотря на появление у проекта нового владельца консультативный совет, осуществляющий наблюдение за ним, Xen Project Advisory Board (Xen AB), продолжает существовать: в состав помимо Citrix входят

компании IBM, Intel, Hewlett-Packard, Novell, Red Hat и Sun Microsystems. Компания Citrix намеревается

сохранить открытость кодов Xen AB, а правила лицензирования регламентирует Xen AB. (Л.Черняк, Виртуализация серверов стандартной архитектуры).

[2] Написано один раз, работает везде (девиз платформы Java).

[3] Примерно ту же ситуацию мы будем иметь с большими центрами хранения данных (прим. авт.).

[4] Мы придерживаемся точно такого же мнения (авт.).

[5] Необходимы также различные аудиторские службы, фиксирующие различные события в системе (определяется концепцией функционирования системы и соответствующими документами, регламентирующими требуемый уровень  безопасности – концепцией, политикой и программой), а также службы аудита безопасности, фиксирующие определенные события безопасности и принимающие в автоматическом режиме конкретные меры и/или сообщающие об этом администратору на любое (по выбору) локальное устройство.

[6] Конкретно современные схемы и сети хранения данных (СХД) мы здесь не рассматриваем, поскольку это, вообще говоря, достаточно сложные системы, архитектура и состав которых определяется задачами, которые ставит разработчик (прим. авт.).