CC BY
29
тельными для заполнения, можно указать набор узлов, который предварительно проверяется на отсутствие пустых значений, иначе данные выгружаться не будут.
Очевидно, что не все данные могут соответствовать таблицам, в каких-то случаях вместо этого требуется вызвать некую функцию с нужными параметрами и т.п. Такая возможность также доступна.
Разработанная подсистема удовлетворяет большинству поставленных условий, однако имеет несколько путей улучшения: использование электронной цифровой подписи, возможность выгрузки документов в форматы PDF либо Microsoft
Word для управления печатью, а также добавление средств форматирования текста и проверки орфографии для всех либо некоторых полей.
Литература
1. Гулиев Я.И., Малых В.Л. Архитектура HL-X // Программные системы: теория и приложения: тр. Междунар. конф. / ИПС РАН, Переславль-Залесский; под ред. С.М. Абрамова. В 2 т. М.: Физматлит. 2004. Т. 2. С. 147-168.
2. Малых В.Л., Юрченко С.Г. Документальный уровень представления знаний в интегрированной медицинской информационной системе // Там же. С. 217-230.
3. Guliev Y.I., Malykh V.L., Yurchenko S.G. Conceptual models for representing information in healthcare information systems. Advanced Information and Telemedicine Technologies for Health (AITTH-2005). Minsk, 2005, vol 1, pp. 198-201.
ПОДДЕРЖКА МНОГОКОМПОНЕНТНОСТИ В МЕДИЦИНСКИХ ИНФОРМАЦИОННЫХ СИСТЕМАХ
(Работа поддержана грантом РФФИ 07-07-00290-а)
Д.В. Алимов (ИПС им. А.К. Айламазяна РАН, г. Переславль-Залесский, alimov@interin.ru)
В статье исследуются проблемы автоматизации комплексных лечебно-профилактических учреждений на основе использования нескольких однотипных системных компонент. Обосновывается необходимость встраивания в архитектуру таких многокомпонентных систем специального механизма, обеспечивающего разделение и интеграцию данных между компонентами. Описываются апробированные технические решения по реализации механизма мно-гокомпонентности в МИС Интерин PROMIS.
Ключевые слова: многокомпонентность, интеграция данных, медицинские информационные системы, архитектура медицинских информационных систем.
Одним из важных свойств, которыми должна обладать интегрированная медицинская информационная система (МИС), является ее способность автоматизировать работу больших и очень больших лечебно-профилактических учреждений (ЛПУ), представляющих собой сложные комплексы с многократно повторяющимися структурными подразделениями. Для таких комплексных ЛПУ актуальны задачи получения данных о работе каждой структурной компоненты учреждения, которая сама может выступать как самостоятельное учреждение, а также задачи получения данных о работе всего комплекса (многокомпонентного учреждения в целом).
Одним из подходов к решению задачи объединения/разделения данных является интеграция различных МИС в единое целое. При интеграции встает вопрос о реализации логики обмена данными между различными МИС. Есть разнообразные пути интеграции информационных систем (ИС): разработка протоколов передачи данных, создание программных интерфейсов и пр. Но как бы тесно системы ни были интегрированы, при этом подходе они продолжают оставаться обособленными МИС со своей логикой работы, своими справочниками и 1Т-специалистами по обслуживанию каждой такой ИС.
Другой подход - это создание единой ИС комплексного ЛПУ, в которой подсистемы, ин-форматизирующие то или иное направление дея-
тельности учреждения, являются компонентами (возможно, множественными). В этом случае возможно объединение в ИС сразу нескольких однотипных компонент ЛПУ в единое целое. Это необходимо, например, при информатизации лечебного учреждения, имеющего в своем составе несколько стационаров. ИС, с одной стороны, должна разделять данные и хранить информацию о том, какие именно какой компоненте принадлежат, а с другой - каждый пользователь должен иметь возможность использовать данные всех подсистем (например, при статистической обработке информации). Системный механизм, позволяющий объединять в едином информационном пространстве компоненты как одного, так и нескольких типов, получил название механизма поддержки совместной работы МИС в мультипликативных (множественных) структурах ЛПУ.
От того, насколько удачно в ИС комплексного ЛПУ будет реализован механизм поддержки работы МИС в мультипликативных структурах, зависит эффективность работы всей системы.
В данной статье рассматриваются схема комплексного ЛПУ и один из методов реализации механизма работы в мультипликативных структурах, используемый в МИС Интерин 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).
РАЗРАБОТКА ТЕМПОРАЛЬНОЙ МОДЕЛИ ДАННЫХ В МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ
А.Н. Базаркин (ИПС им. А.К. Айламазяна РАН, г. Переславль-Залесский, bugs@interin.ru)
В статье исследуются основные методы построения темпоральных моделей данных в реляционных СУБД. Приводится несколько критериев классификации методов их построения, а также обобщается опыт реализации одной из темпоральных моделей в интегрированной подсистеме МИС Интерин PROMIS.
Ключевые слова: темпоральность, историчность, темпоральная модель данных, темпоральные БД, здравоохранение, медицинские информационные системы, лечебно-профилактические учреждения.
В отличие от традиционных моделей данных, обеспечивающих хранение лишь мгновенного снимка объектов предметной области, темпоральные модели данных позволяют хранить информацию об эволюции объектов: для любого объекта, который был создан в момент времени Т1 и закончил свое существование в момент времени Т2, в БД будут сохранены все его состояния на временном интервале [Т1, Т2].
Под темпоральностью объекта следует понимать явную или неявную связь объекта с определенными датами или промежутками времени.
В самом широком смысле темпоральные данные -это данные, которые могут изменяться с течением времени.
На рынке коммерческих БД отсутствуют СУБД, обладающие полноценными темпоральными возможностями.
Для их реализации в рамках информационной системы (ИС) программистам, как правило, приходится разрабатывать специальные средства, расширяющие и дополняющие существующие реляционные модели. Весьма распространенной проблемой разработки таких приложений является
