CC BY
75
ческое применение в области детального персонифицированного учета и контроля прямых материальных затрат ЛДП. Прецеденты позволяют справиться с большой мощностью потока событий ЛДП. Отдельного внимания заслуживает тот факт, что они являются носителями знаний, выражающихся в ассоциировании между собой АФ, входящих в прецедент. Контроль нового прецедента -это фактически подтверждение новых знаний компетентным аудитором с немедленной возможностью дальнейшего функционального использования подтвержденных знаний. На основании изложенного можно сделать вывод, что прецеденты вышли за границы отдельного частного механизма и претендуют занять отдельный уровень в архитектуре современной МИС.
Литература
1. Кадыров Ф.Н. Экономические методы оценки эффективности деятельности медицинских учреждений. М.: Издат. дом «Менеджер здравоохранения», 2007.
2. Мчедлидзе Т.Ш., Янченко В.М., Касумова М.К. Управление медицинским бизнесом: Система управления
стоматологической организацией. СПб.: ООО «МЕБИ издательство», 2007.
3. Калинин А.Н., Малых В.Л., Юсуфов Т.Ш. Управление материальными ресурсами ЛПУ в МИС. Аптека и диетпитание // Врач и информационные технологии. 2006. № 4. С. 87-90.
4. Гулиев Я.И., Малых В.Л., Юрченко С.Г. Контекстный анализ событий и синтез структуры медицинских знаний. Современные информационные и телемедицинские технологии для здравоохранения // А1ТТН'2008: матер. II меж-дунар. конф. Минск: Объединенный институт проблем информатики НАН Беларуси, 2008. С. 164-168.
5. Малых В.Л., Гулиев Я.И., Крылов А.И., Рюмина Е.В. Проблемы автоматизации учета прямых материальных затрат в медицине. Архитектура прецедентного материального учета // Аудит и финансовый анализ. 2009. № 2. С.465-471.
6. Назаренко Г.И., Полубенцева Е.И. Управление качеством медицинской помощи. М.: Медицина, 2000.
7. Гулиев Я.И., Малых В.Л. Архитектура НЬ-Х // Программные системы: теория и приложения: тр. Междунар. конф. / ИПС РАН, Переславль-Залесский; под ред. С.М. Абрамова. В 2 т. М.: Физматлит. 2004. Т. 2.С. 147-168.
8. Малых В.Л., Юрченко С.Г. Документальный уровень представления знаний в интегрированной медицинской информационной системе // Там же. С. 217-230.
РЕАЛИЗАЦИЯ ДОКУМЕНТОВ В МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ ИНТЕРИН
С.Г. Юрченко (ИПС им. А.К. Айламазяна РАН, г. Переславль-Залесский,
уигсЫ^Пепп. ш)
В статье приводятся основные требования к электронным медицинским документам. В качестве примера описывается их реализация в медицинской информационной системе Интерин.
Ключевые слова: электронный медицинский документ, медицинская информационная система, архитектура информационных систем.
В медицинских информационных системах (МИС) очень важна поддержка медицинских документов. Согласно ГОСТ Р 52636-2006, персональная медицинская запись (ПМЗ) может содержать описание проведенного осмотра или обследования (в том числе лабораторного или инструментального), консультации, назначения, выполненной операции или процедуры, обобщенного заключения о состоянии больного и т.д. Совокупность таких записей, выполненных традиционным способом в конкретном медицинском учреждении, составляет историю болезни, или амбулаторную карту пациента.
По сути весь лечебно-диагностический процесс находит свое отражение в документах, являющихся основным носителем медицинской информации о пациенте. В крупных медицинских учреждениях за год может заполняться до нескольких сотен тысяч документов. Поскольку подобные документы являются источником персональных и конфиденциальных данных, они должны отвечать следующим требованиям:
• неизменность и достоверность на протяжении всего периода хранения;
• регламентация прав доступа и конфиденциальность;
• персонифицируемость (возможность определить автора и происхождение записи в любой момент - аналог подписи на традиционном документе).
Счет различным типам документов идет на сотни, причем зачастую отсутствует общепринятый стандарт, регламентирующий содержание информации и порядок, в котором она должна включаться в документ. Один и тот же осмотр в разных больницах может выглядеть по-разному в зависимости от предпочтений специалистов, работающих в них. В процессе работы эти предпочтения могут меняться: например, врач решает добавить какое-то новое поле или изменить список возможных значений в существующем. Следует учитывать и различия между стационарными и поликлиническими учреждениями. Дополнительно могут существовать несколько вариантов визуального представления одного и того же документа, скажем, выписка из него, выдаваемая на руки пациенту, где указан адрес медицинского учреждения или иная контактная информация. В элек-
тронных версиях документов, в отличие от традиционных бумажных, могут подавляться незаполненные поля.
Так как МИС являются коллективными, то есть подразумевают одновременную работу большого количества пользователей, должно соблюдаться несколько условий. Во-первых, запрет на одновременное внесение изменений несколькими пользователями: пока один не закончит работу с документом, другие могут открывать его лишь для просмотра, но не для редактирования. Во-вторых, у одного документа может быть несколько авторов, поэтому соответствующим образом должна быть авторизована любая информация, вносимая в него, чтобы можно было узнать, кто менял те или иные данные. В-третьих, права доступа к документу могут быть ограничены, например, его смогут видеть лишь лечащий врач пациента и заведующий отделением, для остальных пользователей системы он будет недоступен.
Для соблюдения неизменности окончательно заполненного документа может использоваться электронная цифровая подпись. После этого автор теряет возможность исправлять, менять либо удалять его, такое право остается только за специальными сотрудниками, указанными в политике безопасности МИС.
Информация в том виде, в каком она хранится в документе, может отличаться от структуры данных, используемой в БД МИС, более того, не все данные могут быть жестко структурированы и находить свое отражение в таблицах БД. Часть из них хранится лишь в теле документа и извлекается из него в случае необходимости.
Представляется важной поддержка описания структуры документа с использованием соответствующей терминологии. В качестве примера можно привести стандарт CDA (Clinical Document Architecture), определяющий структуру данных клинического документа и процесс его машинной обработки. В стандарте подразумевается использование архетипов и медицинских терминов в описании структуры. Однако в отсутствие общепринятого соответствия русско- и англоязычных медицинских терминов адаптация западных стандартов затруднительна, а национальные стандарты подобного типа пока не приняты.
Учитывая большое количество документов и возможность изменения со временем их структуры, представляется необходимым наличие средств быстрого конструирования документов.
Исследовательским центром медицинской информатики ИПС РАН была разработана архитектура HL-X для поддержки документов. В работе [1] сформулирована концепция документа и определены различные требования (информационные, функциональные, терминологические) к нему. Автор статьи принимал самое непосредственное участие в реализации данной архитектуры.
Были выдвинуты следующие основные принципы реализации в МИС подсистемы поддержки медицинских документов.
Содержимое документа и его визуальное представление разделены. Используется трехуровневая архитектура: БД, содержимое документа (назовем его моделью данных), описание визуального представления (модель визуализации). Процесс их взаимодействия подчиняется следующим правилам: модель данных взаимодействует с БД МИС, модель визуализации - с моделью данных, взаимодействие визуальной модели напрямую с БД должно быть сведено к минимуму.
Структура БД МИС может отличаться от структуры данных в документах. Они должны быть независимыми друг от друга, структура таблиц БД не должна перестраиваться под структуру данных, содержащихся в документах, и наоборот.
Данные в документах могут быть слабо структурированными (анамнез жизни, данные осмотра) и сильно структурированными (диагноз, назначения, движение по отделениям). Для заполнения сильно структурированных данных может понадобиться вызов внешнего приложения либо заполнение отдельного документа. В таком случае используется следующая схема работы: вызывается внешняя форма либо другой документ, которые сохраняют информацию в БД, откуда она зачитывается в модель данных текущего документа.
Структура и внешний вид документов могут со временем меняться, отражая новые стандарты, личные предпочтения врачей, специфику медицинского учреждения. Должна поддерживаться историчность моделей документов.
Желательно обеспечить оптимизацию ввода данных пользователем. Если врач будет тратить много времени на заполнение документов, у него останется меньше времени на осмотр и лечение пациентов. В качестве одного из решений данной проблемы предлагается использовать заимствование в документах информации, уже содержащейся в МИС (например, личных данных пациента), содержимого других документов, шаблонов (заранее сформированных пользователями наборов данных).
Может потребоваться ввод в документы не только текстовой, но и графической информации, а также прикрепление внешних файлов (например данных с прибора).
Разработанная в рамках МИС Интерин архитектура электронного медицинского документа включает в себя формализованные описания структуры модели данных и модели визуализации документа, метаописание структуры БД, набор визуальных компонентов (для отображения информации в документе). Все модели и описания структуры хранятся в той же БД, к которой обращается и МИС.
Для визуализации документов на сервере приложений используются динамически генерируемые HTML-страницы.
Модели документов описываются на языке XML, чем обеспечиваются их гибкость (с дальнейшим расширением возможностей) и простота внесения изменений. Поддерживается историчность не только моделей, но и визуальных компонентов - это сохраняет неизменность внешнего представления документа с момента подписания.
Для запроса информации, необходимой в документах, из БД МИС используется набор так называемых объектов-запросов (query-объектов). Чтобы обеспечить дополнительную гибкость, возможно прямое указание в модели запросов на языке SQL.
Выгрузка информации из документа в БД МИС осуществляется на основе тезауруса, где хранится описание таблиц БД и связь полей таблицы с узлами модели данных документа.
Для поиска и отбора экземпляров документов с каждым из них связывается набор описывающих его атрибутов, таких как пациент, автор, дата создания и т.п.
Доступ к документам контролируется с использованием механизма пользователей СУБД, что позволяет осуществлять сквозную авторизацию, не запрашивая имя и пароль дважды, сначала при входе в МИС, а затем отдельно для доступа к документам.
Для того чтобы исключить одновременную правку документа двумя или более пользователями, при открытии документа на редактирование он помечается как заблокированный. В таком случае другой пользователь при попытке открыть тот же документ сможет увидеть его лишь в режиме просмотра, не имея возможности ничего в нем менять. Как только первый пользователь закроет документ, блокировка будет снята и документ станет свободным для редактирования.
При сохранении документ обретает статус черновика. Если же врач закончил ввод данных и не собирается больше ничего менять в документе, он выполняет команду его подписания. После этого редактирование документа становится невозможным, его можно открывать лишь для просмотра.
Документ в статусе черновика может быть удален, но запись о нем все равно остается; он становится недоступным в МИС, однако может быть при необходимости восстановлен (его статус изменен на черновик) администратором системы.
Каждому документу сопоставлен автор. В некоторых случаях требуется, чтобы документ содержал информацию, внесенную несколькими авторами, тогда в модели данных документа отражается, кто был последним, кто изменял значение того или иного поля.
Структура модели данных документа описывается на языке XML в соответствии с некоторыми правилами.
В качестве наименований узлов выбираются названия понятий, описывающих содержащиеся в них данные. Например, узел, где будет храниться диагноз, называется английским словом <DIAGNOSIS> либо транскрипцией <DIAGNOZ>. Это обеспечивает удобочитаемость модели в процессе разработки, легко понять, какое поле из визуального представления документа в какой узел модели данных попадет. Допускаются альтернативные названия вложенных узлов, например, <PATI-ENT_NAME /> либо <PATIENT><NAME /></PA-TIENT>, второй вариант предпочтительнее. Новая версия стандарта XML дает возможность использовать в качестве названия термины на русском языке, без перевода, в версии XML 1.0 можно было использовать лишь латинский алфавит.
Кроме того, есть несколько названий для служебных узлов, позволяющих обозначить разделы документа или иную техническую информацию.
Для обеспечения заимствования данных между узлами модели используются команды работы с контекстом. При обработке документа узел может поместить свое значение в динамически поддерживаемый ассоциативный массив, откуда другой узел это значение может забрать. Например, узел, содержащий дату создания документа, через этот массив может передать свое значение узлу с датой осмотра. Порядок обхода узлов соответствует некоторым заданным правилам, таким образом, каждому узлу при обходе может быть доступен свой контекст (набор именованных значений), отсюда было выбрано такое название для данного массива. Знание всех контекстов использования данных документа позволяет ставить задачу построения конструктора документов, обеспечивающего в процессе конструирования семантическую корректность модели [2]. Например, конструктор не позволит включить в документ данные о результатах лабораторных исследований вне контекста конкретного пациента и его медкарты, даты забора лабораторных материалов и т.п.
Специальные объекты-запросы (получающие данные из БД) помечаются особым образом, чтобы отделить их от узлов, служащих лишь для хранения данных. Запрос может выполняться однократно (при создании документа) либо при каждом обращении к документу.
Примеры объектов-запросов: информация о пациенте (Ф.И.О., дата рождения, домашний адрес и т.п.), диагноз, имя пользователя, список возможных типов диет.
Запрос может возвращать как одно, так и несколько значений, во втором случае узел такого объекта тиражируется нужное количество раз. Обычные узлы (не запросы) также могут быть помечены как множественные. Например, в пред-
операционной концепции есть поле «симультанная операция», а их может быть несколько. Для каждой выбранной операции данный узел и все вложенные в него узлы будут размножены. Если пользователь затем удалит какую-то из выбранных операций, соответствующее поддерево модели будет удалено.
Для того чтобы экземпляры документов можно было отбирать по заданным параметрам, специальный раздел модели отведен под подобные значения, такие как идентификатор пациента, ссылка на автора, дата создания документа и т.п. Они выгружаются в специальную таблицу БД, проиндексированную для ускорения поиска, чтобы не обращаться каждый раз к XML-модели документа.
Для ускорения заполнения документов врач может пользоваться шаблонами. Например, можно создать шаблоны для наиболее часто встречающихся нозологий (заболеваний) и затем выбирать нужный, сразу же получая заполненный документ, где ему останется лишь поменять несколько значений.
Шаблон - такая же модель данных, как и обычный документ, а потому в его качестве может использоваться другой экземпляр документа того же типа. Кроме того, добавлена возможность создания схем преобразования моделей из одного типа в другой, что позволяет заимствовать данные, например, из переводного эпикриза в выписной.
Шаблоны могут быть личными (то есть доступными лишь создавшему их) и доступными любому врачу отделения или всего медицинского учреждения.
Кроме того, можно создать так называемый шаблон по умолчанию: при создании каждого нового экземпляра документа данного типа в него будут сразу же заимствованы данные из такого шаблона. Таким образом, врач может создать некий типичный заполненный осмотр, в котором ему надо будет только изменить значения, отклонившиеся от нормы, что может многократно ускорить заполнение.
Визуальная модель документа представляет собой XML-документ, состоящий из узлов, соответствующих так называемым визуальным компонентам. Каждый компонент формирует тот или иной тип поля или набор полей. Они могут быть редактируемыми и нередактируемыми.
Примеры редактируемых компонентов: текстовое поле (однострочное либо многострочное), число, дата и время, выбор файла, переключатели (checkbox), выпадающий список, графическое изображение (с возможностью добавления пометок).
Примеры нередактируемых компонентов: заданный статичный текст, заголовок раздела документа, данные назначений.
Работа с документом осуществляется в двух режимах: редактирование и просмотр. Для облег-
чения поддержки оба режима описываются одной моделью. В зависимости от режима визуальные компоненты формируют различающийся html-код. Поля, в которые не вводились значения, в режиме просмотра обычно не отображаются. Это и более удобно для пользователя, и экономит место при печати бумажной копии документа.
Все компоненты являются гибконастраивае-мыми, имея набор заданных параметров. Например, можно указать, что поле даты осмотра не должно быть пустым, тогда, если пользователь удалит его значение, документ не даст ему продолжить работу, пока он не введет новое значение. Можно ограничить максимальную длину вводимого значения и т.п.
Так как предусмотреть все возможные варианты, которые могут понадобиться для описания визуального представления документа, невозможно, имеется компонент «фрагмент html-кода», в котором можно задать любой html-код, включая активные сценарии на JavaScript.
У большинства компонентов есть параметр, связывающий их с узлом модели данных. Это означает, что при открытии документа он будет брать оттуда значение, а при его изменении помещать новое значение обратно в тот же узел.
Существует возможность сформировать группу компонентов, которую можно растиражировать нужное количество раз, например, в осмотре стоматолога дать возможность врачу описать лечение нескольких зубов (количество изначально неизвестно: один зуб или несколько).
Некоторые поля можно пометить как обязательные для заполнения, иначе автор не сможет закончить работу с документом. Другие поля могут быть динамически изменяющимися: например, «индекс массы тела» может меняться в зависимости от введенных значений веса и роста пациента.
Существует возможность скрывать или показывать отдельные поля либо целые разделы в зависимости от выбранного значения. Это может понадобиться для более полного контроля над вводимыми данными, чтобы врач не мог, к примеру, выбрать «патологий нет» и после этого по ошибке ввести текст в поле описания патологий.
Для того чтобы дать возможность выгружать некоторые наборы полей из документа в БД МИС, но без необходимости писать каждый раз программный код, был разработан тезаурус. Он представляет собой описание соответствия между узлами модели данных документа и полями таблицы БД. На основе этого описания приложение автоматически составляет SQL-запрос на вставку, обновление либо удаление записи в таблице.
Все наборы узлов в модели данных, которым требуется такая возможность, помечаются особым образом, формируя объект для выгрузки. Так как некоторые поля таблицы могут оказаться обяза-
тельными для заполнения, можно указать набор узлов, который предварительно проверяется на отсутствие пустых значений, иначе данные выгружаться не будут.
Очевидно, что не все данные могут соответствовать таблицам, в каких-то случаях вместо этого требуется вызвать некую функцию с нужными параметрами и т.п. Такая возможность также доступна.
Разработанная подсистема удовлетворяет большинству поставленных условий, однако имеет несколько путей улучшения: использование электронной цифровой подписи, возможность выгрузки документов в форматы 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-а)
Д.В. Алимов (ИПС им. А.К. Айламазяна РАН, г. Переславль-Залесский, [email protected])
В статье исследуются проблемы автоматизации комплексных лечебно-профилактических учреждений на основе использования нескольких однотипных системных компонент. Обосновывается необходимость встраивания в архитектуру таких многокомпонентных систем специального механизма, обеспечивающего разделение и интеграцию данных между компонентами. Описываются апробированные технические решения по реализации механизма мно-гокомпонентности в МИС Интерин PROMIS.
Ключевые слова: многокомпонентность, интеграция данных, медицинские информационные системы, архитектура медицинских информационных систем.
Одним из важных свойств, которыми должна обладать интегрированная медицинская информационная система (МИС), является ее способность автоматизировать работу больших и очень больших лечебно-профилактических учреждений (ЛПУ), представляющих собой сложные комплексы с многократно повторяющимися структурными подразделениями. Для таких комплексных ЛПУ актуальны задачи получения данных о работе каждой структурной компоненты учреждения, которая сама может выступать как самостоятельное учреждение, а также задачи получения данных о работе всего комплекса (многокомпонентного учреждения в целом).
Одним из подходов к решению задачи объединения/разделения данных является интеграция различных МИС в единое целое. При интеграции встает вопрос о реализации логики обмена данными между различными МИС. Есть разнообразные пути интеграции информационных систем (ИС): разработка протоколов передачи данных, создание программных интерфейсов и пр. Но как бы тесно системы ни были интегрированы, при этом подходе они продолжают оставаться обособленными МИС со своей логикой работы, своими справочниками и 1Т-специалистами по обслуживанию каждой такой ИС.
Другой подход - это создание единой ИС комплексного ЛПУ, в которой подсистемы, ин-форматизирующие то или иное направление дея-
тельности учреждения, являются компонентами (возможно, множественными). В этом случае возможно объединение в ИС сразу нескольких однотипных компонент ЛПУ в единое целое. Это необходимо, например, при информатизации лечебного учреждения, имеющего в своем составе несколько стационаров. ИС, с одной стороны, должна разделять данные и хранить информацию о том, какие именно какой компоненте принадлежат, а с другой - каждый пользователь должен иметь возможность использовать данные всех подсистем (например, при статистической обработке информации). Системный механизм, позволяющий объединять в едином информационном пространстве компоненты как одного, так и нескольких типов, получил название механизма поддержки совместной работы МИС в мультипликативных (множественных) структурах ЛПУ.
От того, насколько удачно в ИС комплексного ЛПУ будет реализован механизм поддержки работы МИС в мультипликативных структурах, зависит эффективность работы всей системы.
В данной статье рассматриваются схема комплексного ЛПУ и один из методов реализации механизма работы в мультипликативных структурах, используемый в МИС Интерин PROMIS.
В общем случае комплексное ЛПУ может состоять из стационара, диагностического центра, поликлиники, реабилитационного центра и здравпункта. Причем каждая компонента может быть
