CC BY
73
УДК 004.42;004.75
СОЗДАНИЕ РЕГИОНАЛЬНОЙ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ С ПРИМЕНЕНИЕМ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ НА БАЗЕ АРХИТЕКТУРЫ REST
А.С. Семенов, А.А. Пономарев Томский политехнический университет E-mail: [email protected]
Рассмотрена ситуация на рынке медицинских информационных систем в России, законодательные предпосылки по развитию в данной сфере в виде концепции создания единой государственной информационной системы в сфере здравоохранения. Выделена задача построения региональной информационной системы. На основе проведенного анализа подходов и зарубежного опыта, предложен способ реализации регионального сегмента государственной системы в виде регионального медицинского портала на базе архитектуры REST. В качестве примера практической реализации рассмотрен разработанный модуль «Электронная регистратура».
Ключевые слова:
Медицинская информационная система, облачные вычисления, веб-сервисы, архитектура REST.
Key words:
Medical information system, cloud computing, web services, REST architecture.
Введение
Одним из приоритетных национальных проектов является проект «Здоровье», предусматривающий информатизацию в сфере здравоохранения, в том числе внедрение в работу лечебно-профилактических учреждений (ЛПУ) медицинских информационных систем (МИС). Рынок МИС в данный момент очень широк и насчитывает порядка 700 разработок [1].
Информационные системы в здравоохранении проектируются и разрабатываются децентрализовано в условиях отсутствия единой методологии, а потому не позволяют рассматривать и анализировать деятельность системы здравоохранения в целом [2].
Несовершенство отечественной законодательной и нормативной базы является основным фактором, сдерживающим создание единого информационного пространства здравоохранения. На данный момент отсутствуют необходимые федеральные стандарты, регламентирующие правила обмена информацией между системами. В «Концепции создания единой государственной информационной системы в сфере здравоохранения» от 24 апреля 2011 г., разработанной Министерством здравоохранения и социального развития Российской Федерации, определены цели, принципы, общая архитектура, основные этапы создания информационной системы в сфере здравоохранения, механизм управления и ресурсного обеспечения ее создания и сопровождения, а также ожидаемый социально-экономический эффект [2]. Описанные в концепции принципы включают:
Семенов Андрей Сергеевич,
аспирант кафедры автоматики и компьютерных систем
Института кибернетики ТПУ. E-mail: andreysemenov@ sibmail.com
Область научных интересов: медицинские информаци-онные системы, стандарты интеграции и обмена медицинскими данными, облачные вычисления. Пономарев Алексей Анатольевич, канд. техн. наук, доцент кафедры автоматики и компьютерных систем
Института кибернетики ТПУ. E-mail: [email protected] Область научных интересов: разработка распределенных информационных систем,
онтологий, применение
стандартов BPEL, системы промышленной безопасности.
• обеспечение совместимости (интероперабельности) медицинских информационных систем;
• создание прикладных информационных систем по модели «программное обеспечение как услуга» (Software as a Service, SaaS).
Согласно концепции, ядром единой государственной информационной системы (ЕГИС) является федеральный центр обработки данных (ЦОД), включающий в себя основные транзакционные, управленческие и справочные системы. Одним из компонентов ЕГИС являются региональные прикладные системы, включающие в себя:
• медицинские информационные системы;
• системы выдачи и обслуживания льготных рецептов, а также рецептов на контролируемые лекарственные средства;
• системы удаленного мониторинга состояния здоровья пациентов;
• системы архивного хранения и предоставления доступа к медицинским изображениям.
Региональная МИС автоматизирует основные бизнес-процессы ЛПУ и предоставляет следующие основные сервисы:
• вывод расписания специалистов;
• запись пациента на приём;
• создание записи в электронной медицинской карте пациента;
• направление пациента на обследование.
Региональный сегмент ЕГИС
Концепция [2] устанавливает лишь общие положения построения регионального сегмента системы, без уточнения способов реализации. В данной статье рассматривается решение по построению этого сегмента.
При определении архитектуры регионального сегмента системы необходимо учитывать следующие факторы:
• стоимость разработки и поддержки;
• сложность внедрения;
• удовлетворение требованиям концепции [2];
• удовлетворение требованиям к МИС согласно документу [3];
• особенности региона.
В работе [4] изложен зарубежный опыт построения медицинских систем регионального и федерального уровня. Исходя из этого опыта, выделяется три модели данных, используемых при построении таких систем:
• централизованная;
• распределенная;
• гибридная.
Основное преимущество централизованной модели данных - максимальная простота, полный набор информации из всех подсистем, простота поддержки, а также более эффективная и рентабельная реализация требований безопасности и устойчивости системы по сравнению с распределенной моделью. Основной проблемой этого подхода являются высокие требования к производительности и масштабируемости для большого количества систем. Тем не менее, практика показывает, что подход может быть эффективно применен и на широком уровне, как в национальной системе National Health Service (Великобритания) [4].
В распределенной модели заполненные данные сохраняются не в одном центральном хранилище, а в распределенных подсистемах. Для получения полного набора информации необходимо собрать элементы из различных источников в единственную «виртуальную запись». Такой подход является более экономичным с точки зрения производительности и экономии трафика, но более сложным и дорогим в реализации. Усугубляет сложность реализации распределенной модели данных разнородность и разнообразие российских МИС.
Гибридная модель является самой гибкой и комбинирует оба подхода. Однако она, так же как и распределенная модель, предполагает объединение разрозненных МИС различных медицинских учреждений с помощью единой шины данных, что влечет за собой ряд трудностей при поддержке и модификации системы.
В таблице 1 представлен сравнительный анализ двух подходов: с использованием шины данных и с единым центральным хранилищем данных.
Таблица 1. Сравнительный анализ подходов к интеграции МИС
Критерий Разрозненные МИС, объединенные шиной данных Единый региональный медицинский портал
Модель данных Распределенная или гибридная Централизованная
Стоимость разработки Зависит от количества участников Зависит от количества участников
Стоимость поддержки Зависит от количества участников Не зависит от количества участников, работы ведутся централизованно
Удовлетворение требованиям [3], в т.ч. по защите персональных данных согласно 152 ФЗ Каждое ЛПУ самостоятельно ведет работу по удовлетворению требованиям Централизованная реализация требований
Возможность модификации Затруднена, в силу наличия множества разнородных систем Простая модификация, так как система одна
В результате анализа была выбрана централизованная модель хранения данных. На рис. 1 представлена общая схема предлагаемого решения, заключающегося в создании единого регионального медицинского портала. Портал включает в себя набор необходимых и обозначенных в требованиях [3] веб-сервисов для обеспечения полного функционала регионального сегмента ЕГИС. Таким образом, при таком подходе весь цикл работы МИС проходит в режиме облачных вычислений.
Рис. 1. Общая схема централизованного решения
Данные однократно экспортируются в базу данных портала из существующих информационных систем ЛПУ. В качестве средства экспорта может использоваться продукт Microsoft BizTalk, предоставляющий возможность интеграции данных из различных источников, а также службы интеграции (Integration Services), входящие в СУБД Microsoft SQL Server [5].
Используемые технологии
В качестве базы для реализации концепции облачных вычислений выбрана архитектура REST (Representational State Transfer). Согласно документу [6] американского федерального комитета по стандартизации в сфере здравоохранения Health Information Technology,
архитектура REST входит в список рекомендованных технологий для разработки медицинских информационных систем.
Сервисы, построенные на базе архитектуры REST, имеют ряд преимуществ по сравнению с SOAP (Simple Object Access Protocol):
• простота реализации;
• доступ к сервису REST посредством любого браузера;
• не требуется XML парсинг, требуется меньше трафика;
• результаты работы сервиса представлены в человекочитаемом виде [7].
Создание REST сервисов включает следующие шаги: [7]
1. определение ресурса, подлежащего публикации;
2. проектирование URI ресурса;
3. определение взаимосвязей ресурсов;
4. определение доступных представлений;
5. определение доступных методов для каждого ресурса с описанием эффекта;
6. перечисление возможных ответов (коды HTTP и результаты);
7. документация каждого ресурса;
8. открытие сервисов.
В качестве инструмента для реализации архитектуры REST в проекте используются службы WCF Data Services. Это компонент платформы .NET Framework для создания служб, использующих протокол Open Data Protocol (OData) для передачи и получения данных через интернет с помощью семантики REST. Службы OData предоставляют данные в качестве ресурсов, доступ к которым осуществляется с помощью URI. Доступ и изменение данных производится с помощью стандартных команд HTTP GET, PUT, POST и DELETE. В службах OData используются соглашения связи сущностей модели Entity Data Model для предоставления ресурсов в виде наборов сущностей, связанных с помощью сопоставлений.
На рис. 2 представлена общая архитектура системы, используемые инструменты и технологии.
Рис. 2. Общая архитектура системы
Практическая реализация
В качестве примера практической реализации рассматривается разработанный модуль «Электронная регистратура», представляющий собой готовую систему, включающую в себя возможности просмотра расписания врачей и удаленной записи пациентов на приём к врачу.
Автоматизации процесса записи пациентов на приём к врачу является первым очевидным шагом в информатизации медицины. Данный шаг относительно прост в реализации
и способен принести существенный рост эффективности медицинского учреждения, в частности, достоверное снижение очередей в ЛПУ [8].
В табл. 2 в качестве примера представлен ряд сервисов, входящих в разработанный модуль.
Таблица 2. Пример сервисов, входящих в модуль «Электронная регистратура»
Сервис URI Команды Права доступа
Список сотрудников http://medums.ru/service/Staff GET
Добавить расписание http ://medums.ru/service/T imetab le POST Администратор ЛПУ
Записаться на приём http ://medums.ru/service/T imetab leEvent POST Авторизованный пользователь
В качестве входных параметров в сервисы передаются соответствующие контексту данные, такие как идентификатор сотрудника, учреждения, пациента, дата и время приёма.
На рис. 3 показан пример XML-документа, возвращаемого по запросу URI http: //medums. ru/service/Staff(85).
xmlns: d= "http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns: m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
scheme="http¡//schemas.microsoft.com/ado/2007/08/dataseruices/scheme" />
Рис. 3. Результат работы веб-сервиса
На рис. 4 представлен фрагмент модели Entity Data Model, используемой в модуле.
Рис. 4. Фрагмент модели данных Entity Data Model
На рис. 5 приведен пример интерфейса разработанного модуля.
т
Выбор врача
Для того, чтобы просмотреть расписание работы конкретного специалиста, выберите его из списка.
Кабинет Врач
Терапевты
205 терапевт - Бетенекова Н В
317 терапевт - Лядункина М В
205 терапевт - Дискж О А
204 терапевт Рычкова Марина Викторовна Кабинет
204 терапевт -Мазеина Юлия Юрьевна
н Узкие специалисты
отоларинголог - Лисовая С Ф
эндокринолог - Грачева Е Н
врач КФД - Скрябина Наталья Федоровна
врач УЗИ - Казакова Марина Генриховна
Инфекционист - Старкова Елена Петровна
Выбранная дата 04.03.2011 Выбранное время: 8:15
Запись на приём
Врач: Терапевт - Росс И. А.
Выбрав время приема, Вы можете оставить описание симптомов болезни или жалоб в поле «Комментарий для врача». Для записи на приём нажмите на кнопку «Подтвердить».
Комментарий [ пример: боль в животе для врача: |
текущая неделя
Подтвердить
28.02.2011 Пн 01.03.2011 Вт 02.03.2011 Ср 03.03.2011 Чт 04.03.2011 Пт 05.03.2011 Сб 06.03.2011 Вс
8:00
8:15 8:15-8:30
8:30
8:45
9:00
9:15
9:30
9:45
10:00
10:15
Рис. 5. Интерфейс электронной регистратуры
Выводы
Рассмотрено решение по реализации регионального компонента единой государственной медицинской информационной системы на основе архитектуры REST. Описанный подход позволит медицинскому учреждению в короткие сроки и с минимальными затратами провести автоматизацию процесса записи пациентов на приём, с возможностью гибкого обмена данными с другими системами, в том числе с региональным и федеральным центрами обработки данных.
СПИСОК ЛИТЕРАТУРЫ
1. Эльянов М. М. Медицинские информационные технологии. - М.: CapitalPress, 2011. - 320 с.
2. Приказ Минздравсоцразвития Российской Федерации №364 от 28 апреля 2011 // Министерство
здравоохранения и социального развития РФ. 2011. URL:
http://www.minzdravsoc.ru/docs/mzsr/informatics/21 (дата обращения: 25.08.2011).
3. Методические указания. Требования к МИС, передаваемым в фонд алгоритмов и программ
Министерства здравоохранения и социального развития Российской Федерации, применяемым в Государственной информационной системе персонифицированного учета в здравоохранении Российской Федерации // Министерство здравоохранения и социального развития РФ. 2010. URL: http://www.minzdravsoc.ru/docs/mzsr/informatics/16 (дата
обращения: 25.08.2011).
4. Knowledge Driven Health - Microsoft. Connected Health Framework Architecture and Design
Blueprint. Part 3 // Microsoft Corporation. 2009. URL:
http://download.microsoft.com/documents/australia/health/Whitepaper_Connected_Health_Frame work_03_Technical.pdf (дата обращения: 17.09.2011).
5. Фам Ван Тап, Пономарев А.А. Технологии Microsoft для решения задач интеграции данных здравоохранения // Молодежь и современные информационные технологии: сборник трудов VIII Всерос. научно-практ. конф. студентов, аспирантов и молодых ученых. -Томск, 2010. - Т. 2. - С. 114-115.
6. Summary of 2011 Privacy and Security Standards, Guidance and Certification Criteria
Recommendations // Healthcare Information Technology Standards. 2011. URL: http://publicaa.ansi.org/sites/apdl/hitspadmin/Matrices/HITSP_09_N_450_2011.pdf (дата
обращения: 21.09.2011).
7. Oliva L.F. Design and development of a REST-based Web service platform for applications integration: Master thesis. - Barcelona, Spain, 2010. - 124 p.
8. Гусев А.В. Обзор решений «Электронная регистратура» // Врач и информационные технологии. - 2010. - № 6. - С. 4-15.
Поступила 13.10.2011 г.
