CC BY
92
ВраЧ ЕЗВВ Электронные истории болезни
^ и информационные
технологии
В.В. ШПУРИК,
к.т.н., научный сотрудник Института проблем регистрации информации НАН Украины, vadimov@i.ua
ПАРАДИГМА АРХЕТИПА В УПРАВЛЕНИИ, ХРАНЕНИИ И ОБМЕНЕ ЭЛЕКТРОННЫМИ ИСТОРИЯМИ БОЛЕЗНИ
УДК 61:007
Шпурик В.В. Парадигма архетипа в управлении, хранении и обмене электронными историями болезни
(Институт проблем регистрации информации НАН Украины)
Аннотация: В области Электронных историй болезни существует некоторое количество информационных моделей. В статье анализируется подход, использующий «язык определения архетипов», стандартизированный Европейской комиссией по стандартизации и Международной организацией по стандартизации, выраженный в синтаксисе ADL или его XML-эквиваленте для создания архетипов; многократно используемых формальных моделей, построенных на концепции доменов. Архетипы используются в openEHR, чтобы смоделировать такие медицинские данные, как «кровяное давление» или «медицинский рецепт».
Ключевые слова: информационные системыы, медицинские информационные системы, электронные медицинские картыI, ЭМК, архетип, внедрение информационных систем.
UDC 61:007
Shpuryk Vadym V. Using archetype paradigm in the management, storage, retrieval and exchange of health data in electronic case-records (Institute for information recording, NAS Ukraine)
Abstract: In the field of Electronic health records there are a number of existing information models. In this paper, the author attempt to analyze the approach uses the CEN- and ISO-standardised «archetype definition language» expressed in ADL syntax or its XML equivalent to build archetypes; these are reusable, formal models of domain concepts. Archetypes are used in openEHR to model clinical concepts such as «blood pressure» or «medical pre-scription».
Keywords: information systems, healthcare information systems, electronic healthcare record, EHR, archetype, information system deployment.
I
I
Люди, организации и программные системы взаимосвязаны между собой. Создавая программный продукт, разработчик уже по условию задачи предполагает его взаимодействие с другими системами, что обусловливает наличие «диалогового» элемента с использованием определенного понятийного аппарата, основывающегося на знаниях о предметной области. Способ выражения знаний даже об одних и тех же вещах и на одном и том же языке может быть столь различным, что это приводит к непониманию между людьми даже при разговоре об одном и том же предмете. Непонимание становится еще более значительным в случае обмена информацией между организациями и программами. Возможности взаимодействия программных моделей, созданных в различных организациях, а также возможности повторного использования и распространения этих моделей весьма ограничены. Это в свою очередь приводит к повторным усилиям по созданию программных моделей, мало отличающихся от уже созданных. Решение данной проблемы видится в устране-
© В.В. Шпурик, 2011 г.
40 ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ ■
Электронные истории болезни
нии или сведении к минимуму концептуальной и терминологической путаницы и установлении однозначного понимания языка, используемого для формирования требований и спецификаций сложных систем. Такой язык должен прежде всего служить средством коммуникации между людьми, имеющими различный взгляд на одни и те же вещи, взаимодействия между программными системами путем трансляции в него и из него, инструментальной поддержки для повторного использования благодаря формальной спецификации, унификации представления различных моделей, автоматизации проверки корректности, пере-водимости различных методов моделирования в унифицированное представление.
Все вышесказанное в полной мере относится и к области обработки медицинской информации. Совместные усилия двух организаций University College London из Великобритании и австралийской Ocean Informatics Pty Ltd привели к созданию некоммерческой организации openEHR, главной целью создания которой объявлена разработка открытой переносимой платформы, основным элементом которой является клинически эффективная и переносимая электронная история болезни (ЭИБ). Решение этой задачи предполагает исследование клинических требований и создание спецификаций в форме модульных информационных, сервисных и клинических информационных моделей.
Такая платформа должна удовлетворять следующие требования:
— возможность записывать любую клиническую информацию, включая комплексные результаты лабораторных исследований, привязанных к временной оси, а также изображения, диагнозы, листы назначений и т.п.;
— поддержка архетипов и шаблонов для всех клинических систем, расширяемых экспертами в направлении определения контента, семантики и пользовательского интерфейса независимо от программного обеспечения;
www.idmz.ru
гол i, 14» г
■■■■
РЧН
— интеграция с терминологическими системами:
SNOMED-CT (систематизированная медицинская номенклатура клинических терминов) для обеспечения возможности логического вывода и поддержки принятия решений, основывающихся на ЭИБ;
LOINC (система кодирования для лабораторных исследований) для обеспечения возможности обмена и прослеживаемости результатов лабораторных исследований;
ICDx(MI^) и ICPC (классификатор видов помощи) для обеспечения надежного прохождения всех стадий оказания врачебной помощи;
— интеграция с системами передачи сообщений, в частности, HL7, EDIFACT и с другими приложениями, посредством API;
— создание компонентной, адаптивной архитектуры, которая выдержит проверку временем и позволит работать с записями более чем столетней давности.
Результатом проводимых исследований должен стать открытый стандарт управления, хранения и обмена ЭИБ.
Для того, чтобы получить «семантически правильно определенную ЭИБ» («semantically well defined EHR content»), необходимо как минимум формализовать ЭИБ-структуру и однозначно определить связи между терминологическими системами.
Анализ подхода к решению задачи построения семантически правильно определенной ЭИБ, основанный на понятии архетипа
В области информатики архетип — это формализованная и многократно используемая модель некоторого понятия предметной области. В контексте данной работы понятие архетипа конкретизировано: архетип — это вычислимое выражение модели предметной области в форме структурированных ограничивающих утверждений, основывающихся на
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■ ■ ■■■ ■ !5 ■■ ■ ■ ■■■ ■■ ■■ ■ ■ ■ ■■■ ■■ ■ ■ ■ ■ ■ ■ ■■ ■■ ■ ■
ВраЧ ЕЗВВ Электронные истории болезни
^ и информационные
технологии
Рис. 1. Представление медицинской информации через архетипы
эталонной информационной модели. Все архетипы выражаются с помощью одного и того же формализма. В общем случае архетипы могут быть определены для многократного и широкого использования, при этом они могут быть доопределены (уточнены) для конкретного узкоцелевого применения. Архетипы могут быть адаптированы к любому естественному языку и терминологии.
Шаблон — это комплексная структура, представляющая собой определенный набор архетипов для целей локального использования (рис. 1). Шаблоны могут накладывать дополнительные ограничения на объединяемые ими архетипы, например, устанавливать значения по умолчанию. Другими словами, шаблоны представляют собой форму модели с ограничивающими утверждениями, которая непосредственно используется для того, чтобы внести в процесс создания данных ограничения локального контекста для удовлетворения определенных требований, а также для проверки данных, получаемых из внешних источников.
Так как архетипы являются моделями в широком смысле этого понятия и имеют обширные композиционные возможности, задача шаблонов состоит в формировании
множества архетипов для некоторой конкретизированной цели. Шаблоны могут использоваться для управления процессом связывания архетипов между собой, уменьшения тавтологий, ограничения излишнего терминологического разнообразия.
Подход openEHR выделяет ряд формальных определений моделей, включающий эталонную модель (RM), состоящую из первичных информационных моделей (IM), архетип-модели (AM), в свою очередь включающей язык определения архетипов (ADL), объектную модель архетипа (AOM) и сервисную модель (SM), которая определяет интерфейсы к основным программным службам в медицинских информационных системах. Более детально с этим вопросом можно ознакомиться в документах на сайте организации (http://www.openehr.org/).
В openEHR все детали медицинской информации находятся вне пределов эталонной модели. Наряду с этим, существуют средства, позволяющие врачам и пациентам выразить и зарегистрировать определенные сведения из предметной области таким образом, чтобы эти сведения могли быть поняты и обработаны. Согласно этому подходу, стабильная эталонная информационная модель представляет
42 ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ ■
Электронные истории болезни
собой первый уровень моделирования, в то время как формальные определения клинических понятий в форме архетипов и их шаблонов составляют второй уровень. Такое двухуровневое разделение сокращает зависимость созданной системы и данных от изменяющихся понятий предметной области.
Жесткое кодирование предположений об окружающем мире на языке программирования приводит к тому, что эти предположения не только сложно найти и осмыслить, но даже сложно изменить, особенно непрограммисту. Поэтому двухуровневая модель построения программной системы предполагает разделение на информационную и когнитологичес-кую составляющие, взаимоотношения между которыми описываются на модельном и реализационном уровнях: когнитологическая
модель представляется в виде множества абстрактных архетипов, описанных на языке определения архетипов ADL (рис. V), реализацией которой являются конкретизированные архетипы и шаблоны; семантические ограничения, определенные архетип-моделью, накладываются на информационную модель, формальная реализация которой (данные) ограничивается набором шаблонов.
Другими словами, данные — есть реализация эталонной информационной модели, например, концепции ЭИБ. Архетипы являются реализацией архетип-модели, которая в свою очередь есть обобщенный формализм для выражения всех архетипов. Архетип-модель формально связана с информационной моделью таким образом, что ее семантика является теми ограничениями, которые налагаются на типы объектов информационной модели. Архетип-модель может включать лингвистические элементы, позволяющие выражать взаимоотношения между различными элементами. Данные создаются и модифицируются при помощи архетипов, архетипы ограничивают конфигурацию реализации данных для обеспечения их корректности в рамках архетипа. Для иллюстрации проведем
www.idmz.ru
гол i, 14» г
■■■■
РЧН
аналогию, в которой под «реализацией» можно представить себе процесс лимфопоэ-за, в результате которого из стволовой кроветворной клетки образуется лимфоцит. В данном примере о стволовой кроветворной клетке можно говорить как об «архетипе», из которого также можно получить и фагоцит или гранулоцит в результате «реализации архетип-модели», то есть миэлопоэза.
Язык определения архетипов ADL (Archetype Definition Language) — это формальный язык для описания архетипов, который можно отнести к языкам описания знаний и который представляет собой формальный, абстрактный синтаксис для описания ограничений на некотором домене сущностей, данные которого описываются информационной моделью, выраженной, например, на UML/OCL.
ADL является формальным языком для описания архетипов, которые представляют собой основывающиеся на ограничениях модели предметной области. Подробно концепция архетипов изложена в [1,2]. Объектная Модель Архетипов (ОМА) openEHR [3] описывает определенную семантическую модель архетипов в виде объектной модели. Для описания накладываемых на данные как на реализацию некоторой информационной модели (например, представленную в виде UML) ограничений ADL-архетипы используют три вида синтаксических конструкций: dADL — для описания данных, cADL — для описания ограничений и FOPL — для представления логики предикатов первого порядка. ADL может описывать архетипы для любой предметной области, где существует формальная объектная модель, описывающая реализацию данных.
При использовании архетипов в определенном контексте они компонуются в комплексные ограничивающие структуры посредством шаблонов с заданными локальными или экспертными ограничениями. Формализм шаблонов есть, по сути, dADL. Архетипы могут специализироваться (уточняться) путем наследования свойств родительского архетипа, тем
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ 43 ■
ВраЧ ЕЗВВ Электронные истории болезни
^ и информационные
технологии
Рис. 2. Структура ADL-архетипа
44
Электронные истории болезни
самым используя одну из парадигм объектно ориентированного подхода. Синтаксически ADL-архетип представляет собой dADL-документ, содержащий секцию определения выражений на cADL.
Одна из важнейших задач архетипов — это соединение информационных структур и формальной терминологии. Нейтральность по отношению к языку дает возможность перевода архетипов на другие языки. Архетипы также обладают свойством адресации отдельных элементов, присущим языку запросов к элементам XML-документа Xpath.
Общая структура ADL-архетипа приведена на рис. 2. В качестве примера в этой структуре показаны элементы архетипа «blood__pressure» (кровяное давление). Основные
структурные компоненты выделены для наглядности жирным шрифтом. Ограничения, накладываемые на размер статьи, не позволяют здесь во всех подробностях рассмотреть структуру ADL-архетипа.
Так, в разделе «description» (описание) опущены данные об авторе, ключевые слова и элементы описания на других языках. В разделе «definition» (определение) оставлены только элементы, описывающие единицы измерения кровяного давления (mm Hg), допустимые пределы изменения величин (magnitude) и точность (precision).
Отдельный интерес представляет раздел «ontology» (онтология), в котором представлены знания о рассматриваемой предметной области. Онтологии непременно сопутствует некоторая концепция этой области интересов, которая выражается посредством определения базовых объектов и отношений между ними. Определение этих объектов и отношений между ними называют концептуализацией. Онтология является явным представлением некоторой концептуализации и может иметь несколько форм представления: неформальную на каком-либо естественном языке; полуформальную на каком-либо структурированном подмножестве естественного
www.idmz.ru
гол i, 14» г
■■■■
РЧН
языка; слабоформализованную на каком-либо языке из области искусственного интеллекта с формальным синтаксисом; формализованную на каком-либо языке из области искусственного интеллекта с формальным синтаксисом, семантикой, значимым и полным механизмом вывода. В большинстве случаев все усилия в данном направлении ограничиваются полуформальным представлением. На рис. 2 показаны определения (term_definitions) систолического и диастолического давлений. Показать определения понятий, связанных только с понятием «кровяное давление», в рамках данного рассмотрения не представляется возможным в силу того, что реальный ADL-архетип «blood_pressure» содержит их в количестве нескольких десятков. Таким образом, анализ знаний в предметной области возможен, когда имеется декларативная спецификация терминов. Формальный анализ терминов чрезвычайно ценен как при попытке повторного использования существующих онтологий, так и при их расширении [4].
И последнее, SNOMED-CT состоит из более чем миллиона медицинских концепций. Например, идентификатор «22298006» означает острый инфаркт миокарда (myocardial infarction). В разделе term_binding (рис. 2) описана связь рассматриваемых понятий систолического и диастолического давлений со систематизированной номенклатурой SNOMED-CT [5].
ВЫВОДЫ
Детальное исследование показало, что рассматриваемый в данной статье архетипподход к созданию ЭИБ действительно воплощает в себе большинство декларируемых разработчиками openEHR возможностей, но, наряду с этим, следует отметить, что имеющееся на данном этапе количество архетипов явно недостаточно для решения задачи получения «семантически правильно определенной ЭИБ», о которой шла речь в начале данной статьи. Так, например, поиск
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ 45 ■
ВраЧ ЕЗВВ Электронные истории болезни
^ и информационные
технологии
архетипов «sepsis» (сепсис) и «systemic inflammatory response syndrome (SIRS)» (синдром системного воспалительного ответа) средствами Менеджера клинических знаний (Clinical Knowledge Manager) не увенчался успехом по причине отсутствия таких архетипов. Это говорит о том, что создание и совершенствование формальной системы должно сопровождаться не менее интенсивным созданием контента. Именно эта задача возлагается на специалистов предметной области.
Повышение надежности систем моделирования следует связывать с возможностью и удобством полуформального и формального анализов декларативного описания на языке онтологии. При этом, говоря о формальном анализе, следует учитывать, что описание допускает формальный вывод (доказательство) наличия тех или иных свойств среды. Наличие базы знаний (архетипы и шаблоны) и относительно универсального интерпретатора делает принципиально возможным создание экспертных систем для новых приложений.
ЛИТЕРАТУРА
1. Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. OOPSLA 2002 workshop on behavioural semantics. URL http://www.open-ehr.org/publications/archetypes/archetypes_beale_oopsla_2002.pdf (Дата обращения: 05.11.2010).
2. Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. URL http://www.openehr.org/publications/archetypes/arche-types_beale_web_2000.pdf (Дата обращения: 05.11.2010).
3. Heard S, Beale T, FreriksG., Rossi-MoriA, PishevO. Templates and Archetypes: how do we know what we are talking about? HL7 internal paper, 2003. URL http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/arche-types/archetype_model/REV_HIST.html (Дата обращения: 05.11.2010).
4. McGuinness D.L., Fikes R., Rice J and Wilder S. (2000). An Environment for Merging and Testing Large Ontologies. Principles of Knowledge Representation andRea-soning: Proceedings of the Seventh International Conference (KR2000). A.G. Cohn, F. Giunchiglia and B. Selman, editors. San Francisco, CA, MorganKaufmann Publishers.
5. Ryan A., (2006). Towards semantic interoperability in healthcare: ontology mapping from SNOMED-CT to HL7 version 3. ACM International Conference Proceeding Series; Vol. 238, Australia Pages: 69-74.
46 ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ ■
