openEHR — это открытая стандартная спецификация в области медицинской информатики , которая описывает управление, хранение, поиск и обмен медицинскими данными в электронных медицинских записях (EHR). В openEHR все данные о здоровье человека хранятся в «одной жизни», независимой от поставщика и ориентированной на человека ЭМК. Спецификации openEHR включают спецификацию извлечения EHR [1] , но в остальном они не касаются в первую очередь обмена данными между системами EHR, поскольку это находится в центре внимания других стандартов, таких как EN 13606 и HL7 .
Спецификации openEHR поддерживаются openEHR Foundation, некоммерческим фондом, поддерживающим открытые исследования, разработку и внедрение openEHR EHR. Спецификации основаны на сочетании 15-летних европейских и австралийских исследований и разработок в области ЭМК и новых парадигм, включая то, что стало известно как методология архетипов [2] [3] для спецификации содержания.
Спецификации openEHR [4] включают информационные и сервисные модели для EHR, демографические данные, клинический рабочий процесс и архетипы . Они призваны стать основой медико-юридической обоснованной, распределенной, версионной инфраструктуры EHR.
Архитектура спецификаций openEHR в целом состоит из следующих ключевых элементов:
Использование первых двух позволяет развивать «архетипы» и «шаблоны», которые являются формальными моделями клинического и связанного с ними содержания и представляют собой уровень собственных стандартов де-факто , гораздо более многочисленных, чем базовые спецификации, на которых они основаны. построены. Язык запросов позволяет строить запросы на основе архетипов, а не физических схем базы данных, тем самым отделяя запросы от деталей физического постоянства. Модели обслуживания определяют доступ к ключевым серверным службам, включая службу EHR и службу демографии, в то время как для доступа к приложениям используется растущий набор облегченных API-интерфейсов на основе REST, основанных на путях архетипов.
Обзор архитектуры openEHR содержит краткое описание архитектуры и подробные спецификации. [5]
Центральной частью спецификаций openEHR является набор информационных моделей, известных в openEHR как «эталонные модели». [6] Модели составляют базовые информационные модели для систем openEHR и определяют инвариантную семантику модели электронной медицинской карты (EHR), экстракта EHR и демографической модели, а также поддерживают типы данных, структуры данных, идентификаторы и полезные шаблоны проектирования. .
Некоторые из ключевых классов компонента EHR — это классы ENTRY, подтипы которых включают НАБЛЮДЕНИЕ, ОЦЕНКА, ИНСТРУКЦИЯ, ДЕЙСТВИЕ и ADMIN_ENTRY, а также конечный автомат инструкций — конечный автомат, определяющий стандартную модель жизненного цикла вмешательств, включая медикаментозное лечение. заказы, операции и другие методы лечения.
Ключевым нововведением в структуре openEHR является исключение всех спецификаций клинической информации из информационной модели (также известной как «эталонная модель») и вместо этого предоставление мощных средств выражения определений содержания, которые врачи и пациенты должны записывать, что может непосредственно использоваться во время выполнения системами, построенными на эталонной модели. Это оправдано необходимостью масштабного решения общей проблемы здравоохранения, связанной с очень большим, растущим и постоянно меняющимся набором типов информации. [7]
Клиническое содержание определяется с точки зрения двух типов артефактов, существующих вне информационной модели. Первый, известный как « архетипы », обеспечивает место для формального определения повторно используемых определений точек данных и групп данных, то есть элементов контента, которые будут повторно использоваться в многочисленных контекстах. Типичные примеры включают «измерение системного артериального давления» и «натрий в сыворотке». Многие такие точки данных объединены в логические группы, например, группа элементов данных для документирования аллергической реакции или аналиты в результатах функционального теста печени. Некоторые архетипы содержат множество точек данных, например 50, хотя чаще всего их число составляет 10–20. Коллекцию архетипов можно понимать как «библиотеку» повторно используемых определений контента предметной области, где каждый архетип функционирует как «единица управления», содержимое которой совместно разрабатывается, проверяется и публикуется.
Второй тип артефакта известен в openEHR как «шаблон» и используется для логического представления набора данных для конкретного случая использования, например элементов данных, составляющих сводку выписки пациента или отчет о радиологии. [8] Шаблон создается путем ссылки на соответствующие элементы из ряда архетипов. Для шаблона может потребоваться только одна или две точки данных или группы из каждого архетипа. С точки зрения технического представления шаблоны openEHR не могут нарушать семантику архетипов, из которых они построены. Шаблоны почти всегда разрабатываются для локального использования разработчиками программного обеспечения и клиническими аналитиками. Шаблоны обычно определяются для экранных форм графического пользовательского интерфейса , определений сообщений и определений документов и, как таковые, соответствуют «оперативным» определениям контента.
Оправдание двух уровней моделей над информационной моделью заключается в том, что если определения наборов данных состоят из заранее определенных точек данных из библиотеки таких определений, то все записанные данные (т. е. экземпляры шаблонов) в конечном итоге будут просто экземплярами стандартные определения контента. Это обеспечивает основу для работы стандартизированных запросов. Без уровня «библиотеки» архетипа каждый набор данных (т. е. часть оперативного контента) определяется однозначно, и стандартный подход к запросам затруднителен.
Соответственно, openEHR определяет метод запросов на основе архетипов, известный как AQL (язык запросов архетипов). [9]
Примечательно, что openEHR использовался для моделирования плана совместного ухода. Архетипы были разработаны с учетом концепций совместного плана ухода. [10]
Хотя отдельные медицинские записи могут сильно различаться по содержанию, основная информация в экземплярах данных openEHR всегда соответствует архетипам. Это работает путем создания архетипов, которые выражают клиническую информацию таким образом, который можно многократно использовать, а в некоторых случаях даже универсальный. [11]
Архетипы openEHR выражены в «Языке определения архетипов», общедоступной спецификации openEHR. Доступны две версии: ADL 1.4, [12] и ADL 2, [13] новая версия с лучшей поддержкой специализации, переопределения и аннотаций, а также других улучшений. [14] Версия 1.4 ADL и ее аналог «объектной модели» Archetype Object Model (AOM) являются основой для стандартов CEN и ISO «Язык определения архетипов» ( стандарт ISO 13606-2 ). [15]
Шаблоны исторически разрабатывались в простом, де-факто разработанном в отрасли формате XML, известном как «.oet» по расширению файла. [16] ADL 2 определяет способ беспрепятственного выражения шаблонов с помощью архетипов, используя расширения языка ADL. [17]
Выявлены различные принципы развития архетипов. [18] Например, набор архетипов openEHR должен быть качественно управляемым, чтобы соответствовать ряду аксиом, таких как взаимоисключаемость. Архетипами можно управлять независимо от программных реализаций и инфраструктуры, в руках групп клиницистов, чтобы гарантировать, что они отвечают реальным потребностям на местах. Архетипы созданы для того, чтобы позволить спецификации клинических знаний развиваться и развиваться с течением времени. Проблемы в реализации информационного дизайна, выраженные в центре openEHR, касаются того, в какой степени фактические ограничения системы гармонируют с информационным дизайном. [ нужна цитата ]
В области электронных медицинских карт существует ряд существующих информационных моделей с дублирующими сферами применения, которыми трудно управлять, например, между HL7 V3 и SNOMED CT . Подход openEHR сталкивается с проблемами гармонизации, если не используется изолированно. [19]
Следуя подходу openEHR, использование общих и управляемых архетипов во всем мире обеспечит возможность последовательного манипулирования и просмотра данных о здоровье openEHR, независимо от технического, организационного и культурного контекста. Этот подход также означает, что фактические модели данных, используемые в любой ЭМК, являются гибкими, поскольку могут быть определены новые архетипы для удовлетворения будущих потребностей ведения клинических записей. Недавно работа в Австралии продемонстрировала, как можно использовать архетипы и шаблоны для облегчения использования устаревших медицинских записей и данных сообщений в системе медицинских записей openEHR, а также вывода стандартизированных сообщений и документов CDA.
Перспектива достижения соглашения по дизайну и формам управления на международном уровне остается спекулятивной, причем влияние варьируется от различных медико-правовых сред до культурных различий и технических различий, таких как степень, в которой справочная клиническая терминология должна быть неотъемлемой. .
Структура openEHR соответствует стандарту связи электронных медицинских карт (ISO 13606), а объектная модель архетипа 2 (AOM2) была официально принята ISO TC 215 в качестве проекта спецификации для версии ISO 13606:2 2017 года.
Архетипы openEHR используются Национальным органом по переходу к электронному здравоохранению Австралии, Информационным центром здравоохранения и социального обеспечения Национальной службы здравоохранения Великобритании (HSCIC), норвежской организацией Nasjonal IKT и Министерством здравоохранения Словении.
openEHR был выбран в качестве основы для стандартизированных EHR в Бразилии. [20]
Он начинает использоваться в коммерческих решениях по всему миру, в том числе в тех, которые производятся отраслевыми партнерами openEHR.
Одним из результатов подхода к моделированию openEHR является открытая разработка архетипов, шаблонов и подмножеств терминологии для представления данных о состоянии здоровья. Благодаря открытому характеру openEHR, эти структуры общедоступны для использования и внедрения в информационные системы здравоохранения. Пользователи сообщества могут делиться, обсуждать и утверждать эти структуры в совместном репозитории, известном как Менеджер клинических знаний (CKM). Некоторые в настоящее время используют CKM openEHR: