Программные продукты и системы

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

Одним из подходов к решению задачи объединения/разделения данных является интеграция различных МИС в единое целое. При интеграции встает вопрос о реализации логики обмена данными между различными МИС. Есть разнообразные пути интеграции информационных систем (ИС): разработка протоколов передачи данных, создание программных интерфейсов и пр. Но как бы тесно системы ни были интегрированы, при этом подходе они продолжают оставаться обособленными МИС со своей логикой работы, своими справочниками и IT-специалистами по обслуживанию каждой такой ИС.

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

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

В данной статье рассматриваются схема комплексного ЛПУ и один из методов реализации механизма работы в мультипликативных структурах, используемый в МИС Интерин PROMIS.

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

Схема обобщенного комплексного ЛПУ представлена на рисунке 1.

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

Требования к механизму поддержки совместной работы МИС

Корпоративная медицинская система комплексного ЛПУ характеризуется следующими параметрами: наличие модулей для информатизации каждой компоненты, единое хранилище медицинских карт, единые справочники медицинского персонала и подразделений комплексно- го ЛПУ.

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

Если в систему входят компоненты стационар и поликлиника, медицинские карты пациентов стационара можно выделить по типу карты (в стационаре тип медкарты – история болезни). Но если в общем хранилище размещаются, например, медицинские карты двух стационаров, разделение по типу медкарты использовать нельзя.

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

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

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

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

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

Принципы реализации механизма поддержки многокомпонентности

Реализация описанной бизнес-логики в клиентских модулях нецелесообразна, так как усложняет клиентские модули и требует существенной доработки большого количества уже реализованных подсистем. Таким образом, для удовлетворения выдвигаемых требований при разработке корпоративной интегрированной МИС возможны два подхода, реализуемые на уровне СУБД: 1) создание динамических представлений и работа с таблицами данных через эти представления; 2) использование технологии виртуальных БД.

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

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

Второй метод основан на том, что SQL-запро­сы пользователей (любое обращение к данным – insert, update, delete, select) к таблицам БД автоматически модифицируются с помощью соответствующих правил защиты, накладываемых посредством динамически вычисляемой декларации where. Такая декларация вырабатывается специальной функцией, реализующей правила защиты; это могут быть любой предикат, выражение или некая формула, возвращаемая функцией. В СУБД Oracle 8i имела место такая особенность работы модуля вычисления правила: система кэшировала значения, получившиеся в результате вызова функции, реализующей правила защиты данных, и впоследствии могла выдавать сохраненный результат вместо очередного вызова функции. В СУБД Oracle 9i данная особенность работы базового ПО устранена, и вызов функции-правила происходит каждый раз при обращении к защищенному объекту.

К недостаткам подобного решения можно отнести то, что такая функциональность доступна только в СУБД класса Enterpise Edition, стоимость лицензии которой заметно выше стандартной.

Реализация механизма поддержки многокомпонентности в МИС Интерин PROMIS

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

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

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

Данное ограничение на действие «содержат» может быть записано в следующей форме:

СОДЕРЖИТ=<ОБЛАСТЬ ВИДИМОСТИ, КОМПОНЕНТА>

Для хранения пользовательских настроек был реализован контекст приложения, в котором в виде пар {КЛЮЧ, ЗНАЧЕНИЕ} хранятся настройки для каждого пользователя. Для удобства работы с хранимыми значениями используется программный интерфейс доступа к переменным контекста. Функция извлечения значения переменной контекста вызывается из различных хранимых процедур, пакетов и клиентских модулей, поэтому возникла задача ускорения работы данной функции.

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

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

В результате анализа структуры МИС принято решение о необходимости разметки лишь ограниченного набора таблиц, а не всех объектов ее БД. Разметке подверглись единые справочники системы: единое хранилище медицинских карт и единый справочник подразделений комплексного ЛПУ.

При создании записи в указанных справочниках ИС автоматически записывает значение переменной контекста пользователя «компонента» в соответствующий атрибут справочника.

На клиентском уровне были реализованы редактор компонент и областей видимости, пользовательская форма настройки переменных контекста и редактор контекста многокомпонентности, используемый администратором МИС.

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

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

Возможности механизма поддержки многокомпонентности

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

Имеется контекст механизма многокомпонентности. Для каждого пользователя хранится набор переменных, используемых механизмом поддержки многокомпонентности. Каждая переменная хранится в двух экземплярах: значение, проставленное администратором, и значение, заданное пользователем в процессе работы. Благодаря этому у администратора всегда есть возможность восстановить значение любой переменной контекста.

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

Имеется редактор переменных контекстов пользователей. У администратора есть возможность управления контекстом пользователей.

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

Литература

1.   Гулиев Я.И., Комаров С.И. Интегрированная распределенная информационная система крупного лечебно-диагностического учреждения // Стратегии здоровья: информационные технологии и интеллектуальное обеспечение медицины-97: тез. докл. IV междунар. форума. М., 1997.

2.   Никитина Галина. Механизм виртуальных частных баз данных в СУБД Oracle. URL: http://www.oracle.com/ru/ora­mag/octnov2002/easy_vpd.html (дата обращения: 01.12.2008).

3.   The Virtual Private Database in Oracle9iR2. Understanding Oracle9i Security for Service Providers. An Oracle Technical White Paper. January 2002.

4.   Сайт Исследовательского центра медицинской информатики Института программных систем РАН. URL: http://www.interin.ru (дата обращения: 01.12.2008).

5.   Сайт корпорации Oracle, разработчика СУБД Oracle. URL: http://www.oracle.com (дата обращения: 01.12.2008).