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

Размещено на http://www.allbest.ru/

УДК 002.53:004.65

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

Б. А. Кобринский

В.А. Кутуков

Б. А. Кобринский

д.м.н., профессор, руководитель Медицинского центра новых информационных технологий ФГБУ «МНИИ педиатрии и детской хирургии» Минздравсоцразвития РФ,

профессор кафедры «Биологическая и медицинская информатика и кибернетика» ГБОУ ВПО «Российский национальный исследовательский медицинский университет им. Н.И. Пирогова» Минздравсоцразвития РФ

E-mail: bakob@pedklin.ru

В.А. Кутуков

к.т.н., генеральный директор, ЗАО Stack Soft, руководитель ITU-T Focus Group on Cloud Computing

E-mail: kva@stacksoft.ru

идентификация электронный медицинский карта

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

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

From the perspective of designing and developing a health information system Russia considered two alternative architectures based on cloud technologies - centralized and distributed. Positive and negative aspects of both options are presented, on the basis of that found more promising implementation of a distributed architecture. The basic requirements for the design of identity management systems, access and build electronic medical records standards are formulated.

Key words: cloudy technologies, information medical systems architecture, electronic healthcare record.

Principles of construction and open issues cloud technology implementations in healthcare: The architecture of information system

B.A.Kobrinskiy, V.A.Kutukov

Abstract

Basic principles laying the information systems in healthcare: ensuring interoperability, the creation of applied information systems to model SaaS, legacy systems modernization and development of new components to the maximum possible preservation of the existing software and hardware.

To create a health information system use technology of "cloud computing» is the most appropriated.

The main advantage of using cloud computing technologies is a significant increase in the efficiency of automated processes and reduced costs of creating, supporting and developing information systems. We can distinguish two ways of building architecture - centralized and distributed. The implementation of a distributed architecture is more promising and reasonable. Its main advantages are: 1) a significant reduction in requirements for the reliability of the connection of medical institutions to access network bandwidth and stability bandwidth loop through to the core system, 2) preservation of health facility when disconnected from the network, 3) the ability to use embedded earlier local health information systems, 4) the ability to connect to a centralized system of private medical institutions, and 5) the maintenance of competition between medical information systems, thereby improving their quality.

Transition to the new principles of meta-system must be based on the introduction of a single electronic medical record that is generated based on multimodular structure that takes into account the needs of different users. For that should the following problems should be solved: 1) development of personal identity management system of electronic health records (issuing new IDs and keeping current, archive identifiers, issuing temporary IDs, changing device information to be authentic), 2) development of concepts and standards for the construction of maps (single module architecture for all types of medical facilities: obligatory modules - the vital data, diagnoses, treatment information, the provision of services, and others, subsidiary - information, with limited time, general use, for example, to provide emergency, satellite - additional information for the specialized registers; person-centred data integration at the federal level or in regional segment; the all-Russian classifiers of a questionnaire and medical units; information exchange based on open or agreed protocols and formats, and convert charts from databases of different institutional systems, the formation of integrated electronic health records on the basis of association approved fixed-ins), 3) develop a system to control access to electronic medical records (keeping on the federal level, references to maps that are stored at the regional level authentication and authorization of health care worker before going to map the patient; authorized access to keys and / or modules in the cards depending on the position and functional responsibilities; modular exchange to accelerate its transmission / reception, i.e. decrease the load on the channels of communication, a request to the regional data centers to view / receive / transfer of medical data on the link in the federal sector, compulsory registration of patients' rights to view his medical records by other physician).

Введение

Среди принципов создания информационной системы в здравоохранении (ИСЗ), перечисленных в концепции создания ИСЗ, которые существенно влияют на архитектуру системы можно выделить следующие [1]:

• обеспечение интероперабельности различных медицинских информационных систем (МИС);

• создание прикладных информационных систем по модели «программное обеспечение как услуга» - Software as a Service (SaaS);

• принятие решения о модернизации унаследованных и разработке новых компонентов ИСЗ с учетом максимально возможного сохранения существующих программно-технических средств на основе анализа совокупной стоимости владения.

При создании ИСЗ наиболее целесообразно использовать технологии так называемых «облачных вычислений» (cloud computing), которые бурно развиваются в настоящее время и широко используются для реализации сложных территориально распределенных информационных систем [2].

Облачные вычисления определяются следующим образом: «Облачные вычисления (cloud computing)» - модель предоставления сервиса (услуги), при которой пользователь имеет возможность получить повсеместный, удобный доступ, по требованию, к пулу разделяемых, конфигурируемых ресурсов (например сетей, серверов, памяти, приложений и т.д.), которые могут быть быстро предоставлены пользователю и с минимальными для него усилиями по взаимодействию с сервис-провайдерами в процессе получения доступа к ресурсам (ITU-T Focus Group on Cloud Computing).

Главным преимуществом использования технологий облачных вычислений является существенное повышение эффективности автоматизируемых процессов и сокращение затрат на создание, поддержку и развитие информационных систем, IT-инфраструктуры за счет [3]:

· централизации IT ресурсов;

· виртуализации IT ресурсов;

· динамического управления IT ресурсами;

· повсеместного доступа к IT ресурсам;

· автоматизации IT процессов;

· упрощения IT услуг;

· стандартизации IT инфраструктуры.

Основываясь на подходах, предлагаемых технологиями облачных вычислений, можно выделить два возможных варианта построения архитектуры ИСЗ, которые назовем Централизованная и Распределенная архитектура.

Централизованная архитектура

В централизованной архитектуре (рис. 1) практически все компоненты прикладных информационных систем размещаются в централизованном ядре системы. Ядро системы строится на основе нескольких технологических площадок объединенных соответствующей телекоммуникационной инфраструктурой. Технологическая площадка это или отдельный собственный центр обработки данных (ЦОД), или арендуемое в ЦОДе одного из операторов место - определенное количество стоек, на которых располагается серверное и коммуникационное оборудование. Для обеспечения надежности функционирования ИСЗ необходимо не менее двух территориально разнесенных технологических площадок.

Рис. 1. Централизованная архитектура ИСЗ

Централизованная архитектура предполагает, что доступ и работа с прикладным программным обеспечением из лечебно-профилактических учреждений (ЛПУ) осуществляется по модели SaaS. Для работы с прикладным программным обеспечение в этом случае необходим только браузер. В ЛПУ строится локальная вычислительная сеть (ЛВС), к которой подключаются автоматизированные рабочие места (АРМ) различных специалистов, а также медицинское диагностическое и другое оборудование. Локальная сеть через соответствующее коммуникационное оборудование подключается к сети доступа (интернет) для работы с ядром ИСЗ. Данные с медицинского оборудования загружаются в централизованное хранилище ядра, также через сеть доступа. Необходимо отметить, что в этой архитектуре хранения данных в ЛПУ не осуществляется обработка медицинских данных, за исключением компьютеризированного медицинского оборудования, в котором такое хранение предусмотрено производителем медицинской техники.

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

Основные преимущества централизованной архитектуры ИСЗ

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

· Возможность организации единого мониторинга всей системы.

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

· Доступность всего необходимого объема медицинской информации о пациенте консультирующим дистанционно врачам (консультантам) и врачам-экспертам системы ОМС.

· Защита систем хранения данных (СХД) в одном месте.

Основные проблемы централизованной архитектуры ИСЗ

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

· Достаточно высокие требования к полосе пропускания и стабильности полосы пропускания сквозного канала между ЛПУ и ядром системы. Для достаточно комфортной работы сотрудников ЛПУ с числом рабочих мест 10 - 20 скорость подключения должна быть на уровне 10 Мбит/с и полоса сквозного канала от АРМ до централизованного приложения не менее 256 Кбит/с. Но проблема в том, что сегодня невозможно гарантировать требуемый уровень предоставления услуг для сквозного канала, поскольку трафик по пути от АРМ до приложения проходит, как правило, через сети нескольких операторов. Каждый из операторов может гарантировать SLA (Service Level Agreement - соглашение об уровне предоставления услуги) только в пределах своей сети.

· Использование систем поддержки принятия решений (СППР) и информационно-справочных систем в многопользовательском on-line режиме будет еще более повышать требования к каналам связи.

· Организация криптозащиты передаваемых данных.

· Трудности (часто фактическая невозможность) использования уже внедренных локальных МИС.

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

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

· Фактически зависимость от одного производителя (группы производителей для разных компонент) при реализации единой прикладной системы в централизованном ядре.

Распределенная архитектура

В распределенной архитектуре (рис. 2), также как и в централизованной, компоненты прикладных информационных систем размещаются в централизованном ядре системы. Однако при этом в ЛПУ сохраняются (продолжают функционировать) локальные МИС, возможно без реализации некоторых функций, например, без архивного хранилища электронных медицинских карт выбывших пациентов, без хранения медицинских изображений (особенно большого объема, типа МРТ и др.), резервного копирования текущей информации (состоящих на постоянном учете или госпитализированных больных) и т.д. Локальные МИС в этой архитектуре выполняют функции своего рода промежуточного накопителя (как бы кэш-памяти) между централизованным ядром и локальными АРМ. База данных локальной МИС - это своего рода репликация части централизованной базы. На локальные МИС можно и нужно также возложить вспомогательные функции, не требующие централизации, например, обеспечение работы с системами поддержки принятия врачебных решений. Обмен данным между локальной МИС и централизованным ядром может осуществляться по запросу или по расписанию.

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

Рис. 2. Распределенная архитектура ИСЗ

Основные преимущества распределенной архитектуры ИСЗ

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

· Возможность использования внедренных ранее локальных МИС, в том числе интегрированных с радиологическими (PACS) и лабораторными системами, включающими автоанализаторы, обмен с которыми из «облака» практически невозможен.

· Возможность подключение к централизованной системе частных ЛПУ, в том числе с определением объема сведений хранимых в централизованной системе.

· Поддержание конкуренции между производителями МИС и тем самым повышение качества систем.

Преимущества централизованной архитектуры

· Возможность организации единого мониторинга всей системы.

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

· Доступность всего объема медицинской информации о пациенте всем консультирующим дистанционно врачам (консультантам).

К проблемам распределенной архитектуры можно отнести несколько большие затраты на оборудование, устанавливаемое в ЛПУ и его обслуживание, а также затраты на сопровождение локальных МИС. Однако, за счет снижения затрат на каналы связи, эти затраты могут оказаться не столь велики (если вообще будут).

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

Электронные медицинские карты

Важнейшие задачи при реализации ИСЗ с распределенной архитектурой

(для централизованной архитектуры эти задачи не менее важны)

· Разработка системы управления персональной идентификацией электронных медицинских карт (ЭМК) [4].

· Разработка концепции и стандартов построения электронных медицинских карт.

· Разработка системы управления доступом к электронным медицинским картам.

Система управления персональной идентификацией (ПИД) электронных медицинских карт, реализованная на федеральном уровне, должна обеспечивать:

· выдачу новых идентификаторов (на основе персональных универсальных электронных идентифицирующих карт);

· ведение текущих идентификаторов (хранение ПИДов и присоединенных к ним данных, включая точную дату рождения до минут, место рождения, включая данные по ОКАТО и название мед. учреждения, место проживания, смены фамилий и имени, ф.и.о. матери или обоих родителей и т.д.), что обеспечит единую точку доступа к информации о состоянии здоровья пациента через постоянный идентификатор ЭМК;

· архив идентификаторов (умершие, покинувшие страну);

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

· прием всей изменяющейся анкетной информации, которая подлежит хранению совместно с присвоенным при рождении ПИДом.

Разработка концепции и стандартов построения электронных медицинских карт должна предусматривать [5]:

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

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

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

· Организация информационного обмена на основе открытых или согласованных протоколов и форматов.

· Конвертацию ЭМК из баз данных различных учрежденческих МИС при их объединении на региональном или федеральном уровне.

· Формирование интегрированных ЭМК на основе объединения по утвержденным фиксированным модулям (для постоянной и временной интеграции).

Разработка системы управления доступом к электронным медицинским картам предполагает:

· Ведение на федеральном уровне ссылок на ЭМК, хранящиеся в ЦОДах регионального уровня.

· Аутентификацию и авторизация медицинского работника перед обращением к ЭМК пациента.

· Санкционированный доступ по разделам и / или модулям ЭМК в зависимости от занимаемой должности и выполняемых на данный момент функциональных обязанностей (дежурный врач и др.). Помодульный обмен информацией позволит ускорить ее передачу / получение и уменьшит нагрузку на каналы связи.

· Запрос к ЦОДам региональных сегментов ИСЗ для просмотра / получения / пересылки медицинских данных по ссылке в федеральном сегменте.

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

Заключение

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

ЛИТЕРАТУРА

1. http://www.medwork.ru/content/kontseptsiya-sozdaniya-informatsionnoi-sistemy-v-zdravookhranenii-na-period-do-2020-goda

2. Metzler J. Cloud Computing: A Reality Check & Guide to Risk Mitigation. December 2009, www.webtorials.com

3. Metzler J. A Guide for Understanding Cloud Computing. November 2009, www.webtorials.com

4. Кобринский Б.А. Перспективы и пути интеграции информационных медицинских систем // Врач и информационные технологии. - 2009. - №4. - C.4-11.

5. Кобринский Б.А. Этапы и перспективы интеграции информационных систем клинических данных // Информационно-измерительные и управляющие системы. - 2010. - Т.8, №12. - С.12-17.

Сведения об авторах:

Кобринский Борис Аркадьевич

Д.м.н., проф., акад. РАЕН

Рук. Медицинского центра новых информационных технологий ФГБУ «МНИИ педиатрии и детской хирургии» Минздравсоцразвития РФ и профессор кафедры «Биологическая и медицинская информатика и кибернетика» ГБОУ ВПО «Российский национальный исследовательский медицинский университет им. Н.И.Пирогова» Минздравсоцразвития РФ

Адрес: 125412, г. Москва, Талдомская ул., д.2,

Тел.: (495) 483-71-92

E-mail: bakob@ pedklin.ru

Кутуков Виктор Александрович

К.т.н.

Генеральный директор, ЗАО «Стек Софт», руководитель ITU-T Focus Group on Cloud Computing

Адрес: 127299, г. Москва, ул. Б. Академическая, д.5а

Тел.: (495) 980-60-05 доб.2400

E-mail: kva@stacksoft.ru

Размещено на Allbest.ru