CC BY
33
Медицинские информационные системы www.idmz.ru _
2016, № 6 ^
С. И. КОМАРОВ,
к.т.н., с.н.с. Исследовательского центра медицинской информатики Института программных систем им. А. К. Айламазяна РАН, e-mаil: [email protected] Д. В. АЛИМОВ,
с.н.с. Исследовательского центра медицинской информатики Института программных систем им. А. К. Айламазяна РАН, e-mail: [email protected]
ПРИМЕНЕНИЕ МЕХАНИЗМА МНОГОКОМПОНЕНТНОСТИ ПРИ ИНФОРМАТИЗАЦИИ КРУПНОГО ЛПУ С ФИЛИАЛАМИ
УДК 61:007
Комаров С. И., Алимов Д. В. Применение механизма многокомпонентности при информатизации крупного ЛПУ с филиалами (Институт программных систем им. А. К. Айламазяна РАН)
Аннотация. Статья посвящена анализу особенностей применения механизма поддержки мультипликативных структур МИС при информатизации крупных ЛПУ с филиалами. Статья будет полезна как архитекторам и разработчикам МИС, так и пользователям современных МИС.
Ключевые слова: медицинская информационная система, информатизация здравоохранения, филиалы лечебно-профилактических учреждений, механизм многокомпонентности.
UDC 61:007
Komarov S. I., Alimov D. V. Use of the multicomponent mechanism at informatization of the large hospital with branches (Ailamazyan Program Systems Institute of RAS)
Abstract. The Article is devoted to discuss the application of low-level multicomponent mechanism of HIS at the large hospital with branches informatization process.
Keywords: hospital information system, healthcare system informatization, hospital branches, multicomponent mechanism.
-Ф-
ВВЕДЕНИЕ
□ дним из основных инструментов управления крупным предприятием в настоящее время является информационная система масштаба предприятия, обеспечивающая актуальной информацией руководителей и сотрудников при принятии ими решений как стратегического, так и тактического плана.
_ В статье [3] нами были представлены результаты анализа функ-
ционирования крупных лечебно-профилактических учреждений (ЛПУ) и выделены некоторые особенности, которые следует учи-^^^^^^^^^^^^^^^^^^^ тывать при проектировании информационных систем таких ЛПУ.
Случаи, когда крупное ЛПУ имеет в своем составе филиальную сеть, либо в рамках некоторой организации объединена сеть близких по мощности ЛПУ, представляют отдельный интерес в рассмотрении, так как дополнительные ограничения могут накладываться
© С. И. Комаров, Д. В. Алимов, 2016 г.
и информационные
технологии
> индивидуальной политикой таких организаций во многих аспектах - и структурном, и в финансовом, и в организации потоков пациентов, и в организации бизнес-процессов, и т.д.
В данной статье мы хотели бы предложить результаты анализа задачи информатизации крупных ЛПУ с филиалами с использованием системных механизмов поддержки мультипликативных структур (многокомпонентности [1]).
ОСОБЕННОСТИ КРУПНЫХ ЛПУ С ФИЛИАЛАМИ
В предыдущей статье о применении механизмов многокомпонентности [3] мы рассматривали особенности крупных ЛПУ и выделили некоторые характерные признаки, присущие различным вариантам их организационных построений.
В случае ЛПУ с филиалами мы отмечали, что такие ЛПУ создаются на базе головного учреждения - либо многопрофильного, либо специализированного. Филиалы могут быть как отдельными юридическими лицами, так и в составе головного ЛПУ (обычно при близкой территориальной расположенности).
При информатизации группы ЛПУ требуется учитывать особенности бизнес-процессов
медицинских организаций, работающих в нашей системе здравоохранения [4], а также ландшафт в виде:
• меняющейся нормативно-справочной информации федерального, регионального, ведомственного уровней;
• уточнения требований к составу и функциям прикладного программного обеспечения соответствующего уровня ЕГИСЗ, ведомства;
• меняющимся требованиям к составу и способам информационного обмена между участниками информационного взаимодействия в рамках ЕГИСЗ, ведомства;
• меняющимся требованиям к внутренним информационным обменам в рамках группы ЛПУ.
К основным особенностям, требующим учета при построении медицинской информационной системы для случая крупного ЛПУ с филиалами, мы относим следующие:
1. Филиалы могут быть зарегистрированы как отдельные юридические лица, однако в системе должна присутствовать возможность отслеживать и использовать в информационном обмене их принадлежность к головному ЛПУ.
2. Среди отдельных линейных, расположенных удаленно филиалов могут встречаться
[Стационар Ф1|
Рис. 1. Пример структуры ЛПУ с филиалами (уровень компонент МИС)
как состоящие из только одной компоненты (часто это ЛПУ амбулаторного типа - Поликлиника, Диагностический центр и т.п.), так и комплексные (Рис. 1). Центральное ЛПУ является крупным либо комплексным многопрофильным лечебным учреждением, либо специализированным.
3. Особое внимание уделяется процедуре оформления пациентов, направляемых из филиалов в Центр (отслеживается полнота, корректность, своевременность оформления документации; оценивается своевременность и соответствие стандартам медицинских мероприятий на всех уровнях сети).
4. В целях обеспечения преемственности и корректного продолжения лечения требуется оперативная доступность исходных данных о пациенте.
5. Переводы пациентов в другое ЛПУ оформляются выпиской и сопровождаются всей необходимой медицинской документацией. Возможны запросы на предоставление дополнительных данных, анализ соответствия информации о проведенных лечебно-диагностических мероприятиях в исходящем и в принимающем ЛПУ (совпадение диагнозов, оценка качества медицинской помощи на предыдущем этапе и т.д.).
6. Возможно консультирование, проведение диагностических и лечебных мероприятий пациентам в головном/других ЛПУ сети/внешних ЛПУ с предоставлением всей необходимой информации медицинской карты пациента.
7. Нормативно-справочная информация обычно распространяется централизованно, от головного ЛПУ в филиалы (например, утвержденные справочники услуг, прейскуранты, плановые показатели, типовые формы и т.д.).
8. Сбор статистических данных осуществляется раздельно по каждому филиалу. В головном учреждении необходимо анализировать также и обобщенную статистику по всей сети, иметь возможность формировать регламентированную отчетность с учетом данных из филиалов.
2016, № 6
9. Договорная работа по обслуживанию пациентов ведется от имени юридического лица. Реестры оказанных услуг формируются, как правило, раздельно. В центр передается итоговая (в соответствии с регламентированной периодичностью) информация о финансовой работе каждого филиала.
10. Материальное снабжение осуществляется через центральные склады каждого юридического лица (возможны централизованные закупки с передачей на склады филиалов).
ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ К МИС КРУПНОГО ЛПУ С ФИЛИАЛАМИ
В статье [5] нами были рассмотрены особенности доступа к данным на рабочем месте пользователя в работе многокомпонентных ЛПУ различных типов. Обобщая рассмотренные варианты для случая крупного ЛПУ с филиалами, мы делаем вывод о том, что медицинская информационная система такого ЛПУ должна обладать дополнительными возможностями по отношению к МИС отдельного ЛПУ, такими как:
• поддержка актуального состояния системных справочников в соответствии с принадлежностью головному ЛПУ/филиалам;
• поддержка механизмов распространения нормативно-справочной информации в головном ЛПУ и филиалах;
• поддержка механизмов интеграции со сторонними информационными системами с учетом существующей информационной инфраструктуры, территориальной разнесенности и уровня иерархии в сети ЛПУ;
• поддержка ведения учетной и отчетной информации и документации как по отдельным территориальным подразделениям (филиалам), так и по всему ЛПУ в целом;
• поддержка ведения единой медицинской карты пациента, включающей данные медицинских карт каждого из ЛПУ сети, обслужившего данного пациента;
>
и информационные
технологии
• обеспечение автоматизированной фильтрации данных на рабочем месте пользователя в соответствии с принадлежностью его к конкретному филиалу/головному подразделению;
• обеспечение возможности доступа к информации других филиалов/подразделений в пределах полномочий пользователя;
• обеспечение возможностей агрегирования информации (с учетом требований различных вариантов группировки по организационно-структурному признаку) с нужной степенью детализации для нужд управленческого учета.
ВАРИАНТЫ
АРХИТЕКТУРНЫХ РЕШЕНИЙ
В общем случае можно рассматривать три основных варианта архитектурных решений при построении информационной системы поддержки деятельности крупных ЛПУ с филиалами.
1. Децентрализованный вариант. Для каждого ЛПУ, включая головное и филиалы, устанавливается отдельный экземпляр МИС.
2. Централизованный вариант. Устанавливается один экземпляр МИС для всех ЛПУ.
3. Смешанный вариант. Часть ЛПУ объединяется по некоторым критериям и использует один экземпляр МИС.
С точки зрения использования вычислительных мощностей возможны следующие решения: • Использование централизованных серверных мощностей центра обработки данных
Рис. 3. Централизованный вариант
ш
ф 1
Рис. 2. Децентрализованный вариант
Ф 1
Рис. 4. Смешанный вариант
2016, № 6
Рис. 5. МИС в ЦОД
Рис. 6. МИС в ЦОД и локально
(ЦОД) для размещения МИС (Рис. 5, а также МИС 1 и МИС 2 на Рис. 6).
• Использование локальных серверных мощностей для размещения МИС (Рис. 2, а также МИС 3 на Рис. 6).
Остановимся на некоторых особенностях приведенных архитектурных решений, накладывающих определенные ограничения на требования к программному обеспечению (базовому и специализированному), компьютерной технике и параметрам сети.
Первый и третий варианты потребуют реализации механизмов обмена/синхронизации данных в целях поддержки решения задач обеспечения прозрачности данных, приведенных нами выше. При размещении серверных групп локально: а) потребуются отдельные серверные мощности для каждого ЛПУ (или отдельных ЛПУ из 3 варианта), б) потребуется базовое программное обеспечение, средства СУБД и специализированное программное обеспечение для каждой группы серверов в каждом ЛПУ, в) обслуживания будут требовать все серверные группы в каждом ЛПУ. При этом необхо-
димо отметить, что надежность такого решения в децентрализованном варианте повышается за счет снижения зависимости от каналов связи между ЛПУ, что немаловажно при выборе решения с учетом критичности фактора оперативной доступности программного обеспечения АРМ в повседневной работе персонала.
Второй и третий вариант (в части ЛПУ, использующих одну МИС) потребуют реализации серьезных механизмов разграничения прав и полномочий доступа к данным «своих» ЛПУ и «своих» пациентов. Базовое и специализированное программное обеспечение потребуется только для централизованной серверной группы. Обслуживания будут требовать только централизованные серверные мощности. Однако, доступность МИС на рабочем месте пользователя будет зависеть не только от работоспособности серверной группы и средств ЛВС ЛПУ, но и от стабильности и пропускной способности каналов связи между ЛПУ и централизованной серверной группой. Требования к централизованной серверной группе будут значительно выше, чем к каждой из децентрализованных.
>
и информационные
технологии
Отдельным вопросом является сравнительная оценка стоимости владения информационной системой в вариантах различных архитектурных решений. В рамках данной статьи эта задача рассматриваться не будет, мы лишь немного коснемся этой проблемы.
1. Децентрализованный вариант
Как мы уже отметили, в децентрализованном случае каждое ЛПУ, включая головное и все филиалы, оснащается своим экземпляром МИС. Данные каждого ЛПУ хранятся раздельно в различных экземплярах баз данных (БД). Все справочники, данные о пациентах, данные об организациях, настройки пользователей и т.п. - локализованы. Как следствие, возникают задачи обмена данными по различным направлениям - статистике, экономике лечения, медицинскому документообороту, нормативно-справочной информации (НСИ) и т.д., в том числе и задачи синхронизации.
Существует большое количество решений для обмена/синхронизации данных в информационных системах. Это и файлообменные операции, и репликации баз данных, и шины данных со стандартизованными интерфейсами, и специализированные программные продукты типа интеграционных платформ, и т.д., каждое из которых имеет свою сферу применимости.
Не останавливаясь детально на анализе плюсов и минусов каждого подхода, хотим отметить, что эти разные технологии в применении к задаче построения медицинской информационной системы, хранящей большой объем разнотипной информации, могут создать дополнительные трудности (к сожалению, не всегда «лежащие на поверхности» и явно представляемые разработчиками/поставщиками информационных систем своим заказчикам) при выборе правильного варианта решения по информатизации. Отметим хотя бы несколько из них.
• Файлообменные операции критичны к изменениям структур данных, настройкам
базового и специализированного программного обеспечения.
• Репликация баз данных требует обмена большими объемами данных, трудоемка в настройке и требовательна к каналам связи.
• Интеграционные платформы в силу своей универсальности являются избыточными с точки зрения функциональности и достаточно сложными с архитектурной точки зрения. Существенное (про грамотном проектировании и реализации) упрощение дальнейшего развития опирается на серьезные интеллектуальные и финансовые вложения в начале проекта интеграции, что не всегда под силу конкретному учреждению. Кроме того, интеграционная платформа является отдельным, отнюдь не самым дешевым, продуктом, который необходимо обслуживать наряду с интегрируемыми.
• Практически при любом примененном решении в процессе эксплуатации потребуется квалифицированный персонал (в собственном штате либо в привлеченной организации), обладающий достаточными знаниями в предметной области и имеющий соответствующие технические навыки для разрешения конфликтов при обмене данными. Такие требования также повышают стоимость владения МИС. Ситуация в нашем здравоохранении такова, что лечебные учреждения не могут позволить себе иметь в штате достаточное количество высококвалифицированного технического персонала. Финансовые возможности крупного ЛПУ с широкой филиальной сетью заметно больше рядового ЛПУ, но и там предпочтение при информатизации отдается решениям с меньшей стоимостью владения.
2. Централизованный вариант
В централизованном случае предполагаем, что все ЛПУ работают с одним экземпляром МИС. Данные хранятся в единой БД. Справочники, данные о пациентах, пользователях и т.п. централизованы.
С архитектурной точки зрения интересны варианты работы с данными - в зависимости от того, где установлено клиентское программное обеспечение:
• «Толстый» клиент в филиале. Формы работают на клиентских рабочих местах.
• Веб-клиент. Промежуточный вариант, т.к. формы работают в браузере в филиале, а обрабатываются на веб-сервере, рядом с БД МИС.
• Терминальный доступ. Формы работают на сервере терминалов, который находится в центральном узле.
При использовании архитектуры с единым хранилищем данных не возникает задач синхронизации баз данных каждого ЛПУ. Однако возникают другие вопросы, которые, на наш взгляд, должны быть решены на этапе проектирования системы в целом.
Так, при совместной работе нескольких организаций в одной Системе возникает задача разграничения доступа к данным внутри Базы данных. Очевидно, что данная задача должна решаться на уровне сервера, а не на клиентских рабочих местах. Разработчики СУБД предлагают свои решения уровня Системы управления базами данных. Например, компания Oracle для контроля доступа к данным предлагает Oracle Virtual private database [6] -решение, позволяющее использовать политики безопасности на уровне строк и столбцов. После соответствующей настройки объектов базы данных политики безопасности применяются автоматически в зависимости от прав и полномочий пользователя на доступ к данным.
Также требуется решить ряд технических задач, влияющих на общую отказоустойчивость системы. При распределенной работе пользователей с Системой в режиме online наименее контролируемым участком является канал связи между пользовательским рабочим местом и серверным пулом. В связи с этим требуется обеспечить стабильный канал с достаточной пропускной способностью для
2016, № 6
обеспечения бесперебойной и комфортной работы пользователей. Кроме того, организация резервных каналов связи с достаточной пропускной способностью становится также одной из первоочередных задач обеспечения отказоустойчивости информационной системы крупного ЛПУ с филиалами. С учетом параметров сетевых каналов, используемых для связи между ЛПУ, должно приниматься решение по вариантам использования «толстого» или «тонкого» клиента.
3. Смешанный вариант
В смешанном варианте некоторые ЛПУ работают в едином экземпляре МИС, некоторые - в отдельных.
Данные хранятся для части ЛПУ в разных БД, для части - в одной, соответственно и справочники, данные о пациентах, пользователях и т.п. для ряда ЛПУ централизованы, для других - локализованы.
Например, если головное ЛПУ и один из его филиалов расположены недалеко друг от друга и имеют устойчивые и достаточные каналы связи друг с другом, то разумно было бы работать в рамках единой МИС. Если же филиал расположен далеко, и каналы связи неустойчивы, можно предложить выделять работу этого филиала в отдельный экземпляр МИС. Аналогично для группы филиалов - при условии географической близости и достаточности каналов связи можно организовать работу в них в едином экземпляре МИС.
Легко убедиться, что при этом остаются актуальными как задачи для централизованного варианта, так и задачи для децентрализованного в соответствующих случаях применения.
ТЕХНОЛОГИЧЕСКИЕ РЕШЕНИЯ, ИСПОЛЬЗУЕМЫЕ В МИС «ИНТЕРИН PROMIS»
При проектировании конфигурации МИС «Интерин PROMIS» (ООО «Интерин технологии») для крупных ЛПУ группой компаний «Ин-
>
» и информационные
технологии
шКЁ
>терин» были проанализированы и опробованы различные технологические решения.
В результате исследований и экспериментов пришли к выводу, что одним из возможных вариантов является синтезированное решение: Одна МИС для крупного ЛПУ с филиалами, с авторским решением для разграничения доступа к данным на уровне Базы данных. В сущности это централизованный вариант, позволяющий за счет использования возможностей авторских механизмов разграничения доступа и основанных на них интерфейсных решениях предоставлять пользователю синтезированную среду, создающую для некоторого множества задач децентрализованный вариант с доступом только к своим данным, для другого - централизованный вариант с доступом ко всем данным, для третьего - доступ к определенным подмножествам всего множества данных.
Важным условием работоспособности такого решения является стабильность и достаточная пропускная способность каналов связи между информатизируемыми учреждениями. Соединение удаленных клиентских рабочих мест с серверным пулом рекомендуется осуществлять с использованием защищенных туннелей Virtual private network. По размещению клиентского программного обеспечения возможны все варианты работы в зависимости от требований к набору функций конкретного автоматизированного рабочего места, возможностей каналов связи и требований к базовому программному обеспечению.
Также важным условием является работоспособность (в общем смысле - и надежность применяемых технологических решений, и удобство интерфейса, и полнота обеспечиваемых функций и рабочих мест, и возможности адаптации к меняющимся требованиям, и т.п.) применяемой информационной системы. На протяжении длительного времени МИС «Интерин PROMIS» успешно используется в ряде крупных многопрофильных ЛПУ, входящих в число лидеров как по качеству оказыва-
емой медицинской помощи, так и по количеству обслуживаемых пациентов и работающих в МИС сотрудников. Полный спектр подсистем и автоматизированных рабочих мест персонала как лечебно-диагностических, так и вспомогательных и обслуживающих подразделений, качество реализации системы, надежность и высокая степень ее проработанности обеспечивают требуемое качество информатизации каждого конкретного ЛПУ. Большие объемы обрабатываемой информации в действующих информационных системах, свойства масштабируемости, запас по мощности и конкретные реализованные проекты подтверждают, что примененные технологические решения могут применяться при информатизации нескольких лечебных учреждений.
Для разграничения доступа к данным в МИС «Интерин PROMIS» используется механизм многокомпонентности [1,2] - общесистемный механизм низкого уровня, имеющий доступ к данным всех подсистем и модулей информационной системы, который обеспечивает разметку данных по принадлежности к тому или иному множеству подразделений лечебного учреждения и предоставляет возможность динамического управления доступом пользователей к данным. Механизм многокомпонент-ности позволяет размечать ключевые сущности Медицинской информационной системы, такие как: Подразделение лечебного учреждения, Медицинская карта, Прейскурант и т.д., набором меток типа «Компонента», «Область видимости».
В работе [3] был представлен опыт информатизации двух различных крупных ЛПУ, тесно сотрудничавших друг с другом в лечебно-диагностическом процессе и использовавших один экземпляр МИС. В целях поддержки такого варианта работы механизм многоком-понентности был расширен сущностью «Территория» и возможностями комбинирования меток «Компонента», «Область видимости» с меткой «Территория».
Медицинские информационные системы www.idmz.ru _
2016, № 6 ^
Задача информатизации крупного ЛПУ с филиалами требует дальнейшего расширения функциональных возможностей механизма в направлении обеспечения множественной регистрации данных в МИС уровня ЛПУ. К таким задачам относятся задачи регистрации и корректного использования в системе данных о юридическом лице (таких как полное и краткое юридические наименования, коды по классификаторам, адреса, контактные телефоны, и т.д.), финансово-экономических данных (данные финансовых организаций, обслуживающих счета Лечебного учреждения; дополнительные данные о руководстве (включая главного врача, главного бухгалтера, заместителей по направлениям работы)).
Для описания данных юридического лица была введена сущность «Учреждение», расширяющая выразительные способности сущности «Территория». Данная сущность обладает набором атрибутов для хранения данных, а также содержит описание набора Компонент, входящих в структуру данного лечебно-профилактического учреждения. Так как отношения между сущностями МИС («Учреждение», «Компонента» и другие сущности системного хранилища данных) выражаются в виде связанного ациклического графа, ме-
дицинская информационная система поддерживает однозначное определение принадлежности данных каждому учреждению.
ЗАКЛЮЧЕНИЕ
Крупные ЛПУ с филиалами обладают рядом особенностей, накладывающих дополнительные требования и ограничения в задаче комплексной информатизации таких учреждений. К ним относятся требования к задачам информационного обмена, требования к инфраструктуре информационной системы, требования к используемой информационной системе и ряд других требований и ограничений. Важным с точки зрения адекватной реализации проекта информатизации и дальнейшей поддержки жизненного цикла информационной системы является выбор архитектурных решений для создаваемого аппаратно-программного комплекса. Описанный в статье подход к расширению выразительных возможностей системного механизма многокомпонентное™ позволяет использовать (с учетом вариантов удовлетворения других ограничений и требований) медицинскую информационную систему с поддержкой многокомпонентности, такую как «Интерин PROMIS», при решении задачи информатизации крупных ЛПУ с филиалами.
ЛИТЕРАТУРА
1. Назаренко Г. И., Замиро Т. Н, Михеев А. Е, Гулиев Я. И., Хаткевич М. И. Проблемы создания медицинских информационных систем. Поддержка мультипликативных структур ЛПУ в МИС // Врач и информационные технологии. - 2007. - № 4. - С. 48-50.
2. Алимов Д. В. Поддержка многокомпонентности в медицинских информационных системах // Программные продукты и системы. - 2009. - № 2. - С. 31-34.
3. Комаров С. И., Алимов Д. В. Особенности применения механизма многокомпонентности при информатизации крупных ЛПУ// Врач и информационные технологии. - 2014. -№ 5. - С. 29-36
4. Гулиев Я. И., Белышев Д. В., Михеев А. Е. Моделирование бизнес-процессов медицинской организации: классификация процессов// Врач и информационные технологии. - 2015. -№ 4. - С. 6-13
5. Комаров С. И., Алимов Д. В. Мультипликативные структуры крупных ЛПУ// Врач и информационные технологии. - 2015. - № 4. - С. 23-32
6. Oracle Virtual private database http://docs.oracle.com/cd/B28359_01/network.111/ b28531/vpd.htm
