openEHR

openEHR — это открытая стандартная спецификация в области медицинской информатики , описывающая управление и хранение, извлечение и обмен данными о здоровье в электронных медицинских картах (EHR). В openEHR все данные о здоровье человека хранятся в «одноразовой», независимой от поставщика, ориентированной на человека EHR. Спецификации openEHR включают спецификацию EHR Extract [1], но в остальном не в первую очередь касаются обмена данными между системами EHR, поскольку это является фокусом других стандартов, таких как EN 13606 и HL7 .

Спецификации openEHR поддерживаются фондом openEHR Foundation, некоммерческим фондом, поддерживающим открытые исследования, разработку и внедрение EHR openEHR. Спецификации основаны на сочетании 15 лет европейских и австралийских исследований и разработок в области EHR и новых парадигм, включая то, что стало известно как методология архетипа [2] [3] для спецификации контента.

Спецификации openEHR [4] включают в себя информационные и сервисные модели для EHR, демографии, клинического рабочего процесса и архетипов . Они разработаны как основа для медико-юридически обоснованной, распределенной, версионной инфраструктуры EHR.

Архитектура

Блок-схема компонентов спецификации openEHR

Архитектура спецификаций openEHR в целом состоит из следующих ключевых элементов:

  • информационные модели (также известные как «эталонная модель»);
  • архетипический формализм;
  • переносимый язык запросов архетипов;
  • сервисные модели/API.

Использование первых двух позволяет разрабатывать «архетипы» и «шаблоны», которые являются формальными моделями клинического и связанного контента и составляют слой собственных фактических стандартов, гораздо более многочисленных, чем базовые спецификации, на которых они построены. Язык запросов позволяет строить запросы на основе архетипов, а не физических схем базы данных, тем самым отделяя запросы от физических деталей персистентности. Модели сервисов определяют доступ к ключевым внутренним сервисам, включая EHR Service и Demographics Service, в то время как растущий набор облегченных API на основе REST, основанных на путях архетипов, используется для доступа к приложениям.

Обзор архитектуры openEHR содержит краткое изложение архитектуры и подробные спецификации. [5]

Референтная модель

Центральной частью спецификаций openEHR является набор информационных моделей, известных в openEHR как «эталонные модели». [6] Модели составляют базовые информационные модели для систем openEHR и определяют инвариантную семантику модели электронной медицинской карты (EHR), выписки из EHR и демографической информации, а также поддерживают типы данных, структуры данных, идентификаторы и полезные шаблоны проектирования.

Некоторые из ключевых классов в компоненте EHR — это классы ENTRY, подтипы которых включают OBSERVATION, EVALUATION, INSTRUCTION, ACTION и ADMIN_ENTRY, а также Instruction State Machine — конечный автомат, определяющий стандартную модель жизненного цикла вмешательств, включая заказы на лекарства, хирургию и другие виды терапии.

Архетипы и многоуровневое моделирование

Ключевым нововведением в фреймворке openEHR является исключение всех спецификаций клинической информации из информационной модели (также известной как «эталонная модель») и предоставление вместо этого мощного средства выражения определений контента, который необходимо записывать врачам и пациентам, и который может быть напрямую использован во время выполнения системами, построенными на эталонной модели. Это оправдано необходимостью масштабируемого решения общей проблемы в здравоохранении с очень большим, растущим и постоянно меняющимся набором типов информации. [7]

Семантическая структура openEHR

Клиническое содержимое определяется в терминах двух типов артефактов, которые существуют вне информационной модели. Первый, известный как « архетипы », предоставляет место для формального определения повторно используемых точек данных и определений групп данных, т. е. элементов содержимого, которые будут повторно использоваться в многочисленных контекстах. Типичные примеры включают «системное измерение артериального давления» и «сывороточный натрий». Многие такие точки данных встречаются в логических группах, например, группа элементов данных для документирования аллергической реакции или аналиты в результатах теста функции печени. Некоторые архетипы содержат многочисленные точки данных, например 50, хотя более распространенное число составляет 10–20. Коллекция архетипов может пониматься как «библиотека» повторно используемых определений содержимого домена, при этом каждый архетип функционирует как «единица управления», содержимое которой совместно разрабатывается, рассматривается и публикуется.

Второй тип артефакта известен в openEHR как «шаблон» и используется для логического представления набора данных, специфичного для конкретного варианта использования, например, элементов данных, составляющих выписной эпикриз пациента или рентгенологический отчет. [8] Шаблон создается путем ссылки на соответствующие элементы из ряда архетипов. Шаблон может потребовать только одну или две точки или группы данных из каждого архетипа. С точки зрения технического представления шаблоны openEHR не могут нарушать семантику архетипов, из которых они созданы. Шаблоны почти всегда разрабатываются для локального использования разработчиками программного обеспечения и клиническими аналитиками. Шаблоны обычно определяются для экранных форм GUI , определений сообщений и определений документов и, как таковые, соответствуют «операционным» определениям контента.

Обоснование двух слоев моделей над информационной моделью заключается в том, что если определения наборов данных состоят из предопределенных точек данных из библиотеки таких определений, то все записанные данные (т. е. экземпляры шаблонов) в конечном итоге будут просто экземплярами стандартных определений контента. Это обеспечивает основу для работы стандартизированных запросов. Без уровня архетипа «библиотеки» каждый набор данных (т. е. фрагмент операционного контента) определяется уникально, и стандартный подход к запросам затруднен.

Соответственно, openEHR определяет метод запросов на основе архетипов, известный как AQL (Archetype Querying Language). [9]

В частности, openEHR использовался для моделирования плана совместного ухода. Архетипы были разработаны для размещения концепций плана совместного ухода. [10]

Хотя отдельные медицинские записи могут существенно различаться по содержанию, основная информация в экземплярах данных openEHR всегда соответствует архетипам. Это работает путем создания архетипов, которые выражают клиническую информацию таким образом, что ее можно многократно использовать, а в некоторых случаях даже универсально. [11]

Архетипический формализм

Архетипы openEHR выражены в "Archetype Definition Language", общедоступной спецификации openEHR. Доступны две версии: ADL 1.4, [12] и ADL 2, [13] новый релиз с улучшенной поддержкой специализации, переопределения и аннотаций, среди прочих улучшений. [14] Релиз 1.4 ADL и его аналог "объектной модели" Archetype Object Model (AOM) являются основой для стандарта CEN и ISO "Archetype Definition Language" ( стандарт ISO 13606-2 ). [15]

Шаблоны исторически разрабатывались в простом, фактически разработанном в отрасли формате XML, известном как «.oet», по расширению файла. [16] ADL 2 определяет способ бесшовного выражения шаблонов с архетипами, используя расширения языка ADL. [17]

Обеспечение качества архетипов

Были определены различные принципы разработки архетипов. [18] Например, набор архетипов openEHR должен быть качественно управляемым, чтобы соответствовать ряду аксиом, таких как взаимоисключаемость. Архетипами можно управлять независимо от реализаций программного обеспечения и инфраструктуры, в руках групп клиницистов, чтобы гарантировать, что они соответствуют реальным потребностям на местах. Архетипы разработаны для того, чтобы позволить спецификации клинических знаний развиваться и развиваться с течением времени. Проблемы внедрения информационных проектов, выраженных в openEHR, сосредоточены на том, в какой степени фактические системные ограничения гармонируют с информационным проектом. [ необходима ссылка ]

В области электронных медицинских карт существует ряд существующих информационных моделей с перекрытиями в их области применения, которыми трудно управлять, например, между HL7 V3 и SNOMED CT . Подход openEHR сталкивается с проблемами гармонизации, если не используется изолированно. [19]

Международное сотрудничество

Следуя подходу openEHR, использование общих и управляемых архетипов в глобальном масштабе обеспечит возможность последовательного манипулирования и просмотра данных о состоянии здоровья openEHR независимо от технического, организационного и культурного контекста. Этот подход также означает, что фактические модели данных, используемые любым EHR, являются гибкими, учитывая, что могут быть определены новые архетипы для удовлетворения будущих потребностей в ведении клинических записей. Недавно работа в Австралии продемонстрировала, как архетипы и шаблоны могут использоваться для упрощения использования устаревших данных о состоянии здоровья и сообщений в системе медицинских записей openEHR, а также для вывода стандартизированных сообщений и документов CDA.

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

Фреймворк openEHR соответствует Стандарту передачи электронных медицинских карт (ISO 13606), а модель архетипических объектов 2 (AOM2) была официально принята техническим комитетом ISO TC 215 в качестве проекта спецификации для редакции ISO 13606:2 2017 года.

Международное усыновление

Архетипы openEHR используются Национальным управлением по переходу на электронное здравоохранение Австралии, Информационным центром здравоохранения и социального обеспечения Национальной службы здравоохранения Великобритании (HSCIC), норвежской организацией Nasjonal IKT и Министерством здравоохранения Словении.

openEHR был выбран в качестве основы для стандартизированной EHR в Бразилии. [20]

Его начинают использовать в коммерческих решениях по всему миру, в том числе в решениях, разработанных отраслевыми партнерами openEHR.

Менеджер по клиническим знаниям (CKM)

Одним из результатов подхода к моделированию openEHR является открытая разработка архетипов, шаблонов и подмножеств терминологии для представления данных о здоровье. Благодаря открытой природе openEHR эти структуры общедоступны для использования и внедрения в информационных системах здравоохранения. Пользователи сообщества могут делиться, обсуждать и утверждать эти структуры в совместном репозитории, известном как Clinical Knowledge Manager (CKM). Некоторые используемые в настоящее время CKM openEHR:

  • Менеджер клинических знаний openEHR
  • Менеджер по клиническим знаниям NEHTA
  • Менеджер по клиническим знаниям в Великобритании
  • Норвежский национальный менеджер по клиническим знаниям в области ИКТ
  • Менеджер по клиническим знаниям Министерства здравоохранения Словении

Смотрите также

Ссылки

  1. ^ Редакционный комитет спецификаций. "openEHR EHR Extract IM". openEHR Foundation . Получено 14 апреля 2023 г.
  2. ^ Бил Т. (2002). "Архетипы: модели предметной области на основе ограничений для перспективных информационных систем" (PDF) . Труды 11-го семинара OOPSLA по поведенческой семантике .(PDF-файл)
  3. ^ Heard, S.; Beale, T., ред. (2007). "Обзор архитектуры openEHR" (PDF) . openEHR Foundation . Получено 9 апреля 2013 г. .(PDF-файл)
  4. ^ Программа спецификаций openEHR. "Спецификации openEHR". Фонд openEHR . Получено 3 ноября 2015 г.
  5. ^ Программа спецификации openEHR. "Обзор архитектуры openEHR". OpenEHR Foundation . Получено 3 ноября 2015 г.
  6. ^ Программа спецификации openEHR. "Эталонная модель openEHR". OpenEHR Foundation . Получено 14 апреля 2023 г.
  7. ^ Программа спецификации openEHR. "Обзор технологии архетипа". OpenEHR Foundation . Получено 3 ноября 2015 г.
  8. ^ "Что такое openEHR". OpenEHR Foundation . Получено 9 апреля 2013 г.
  9. ^ "Archetype Query Language (AQL)". OpenEHR Foundation . Получено 9 апреля 2013 г.
  10. ^ Hägglund M, Chen R, Koch S (2011). «Моделирование совместных планов ухода с использованием CONTsys и openEHR для поддержки совместного ухода на дому за пожилыми людьми». Журнал Американской ассоциации медицинской информатики . 18 (1): 66– 9. doi :10.1136/jamia.2009.000216. PMC 3005865. PMID  21106993 . 
  11. ^ "Клиническая стандартизация". OpenEHR Foundation. Архивировано из оригинала 19 декабря 2013 года . Получено 9 апреля 2013 года .
  12. ^ Бил, Т.; Херд, С., ред. (12 декабря 2008 г.), Archetype Definition Language 1.4, openEHR Foundation.
  13. ^ Программа спецификации openEHR (3 ноября 2015 г.), Archetype Definition Language 2, OpenEHR Foundation
  14. ^ "Спецификации ADL/AOM 2". OpenEHR Foundation . Получено 3 ноября 2015 г.
  15. ^ Крышин Дж., Цивонюк К., Смолик В.Т., Ванта Д., Врублевски П., Мидура М. (2022). «Производительность информационной системы больницы на основе openEHR». Международный журнал медицинской информатики . 162 : 104757. doi : 10.1016/j.ijmedinf.2022.104757 . PMID  35395475. S2CID  247899113.
  16. ^ "Шаблон ".oet" XSD". OpenEHR Foundation . Получено 9 апреля 2013 г.
  17. ^ Программа спецификации openEHR. "Спецификация языка определения архетипов (ADL2)". OpenEHR Foundation . Получено 3 ноября 2015 г.
  18. ^ Heard, S.; Beale, T., ред. (2005). "Определения и принципы архетипов" (PDF) . openEHR Foundation . Получено 9 апреля 2013 г. .(PDF-файл)
  19. ^ Мин Л, Тянь Цюй, Лу Сюй, Дуань Х (август 2018 г.). «Моделирование EHR с использованием подхода openEHR: исследовательское исследование в Китае». BMC Medical Informatics and Decision Making . 18 (1): 75. doi : 10.1186/s12911-018-0650-6 . PMC 6116359. PMID  30157838 . 
  20. ^ "Министерство да Сауде". bvsms.saude.gov.br . Проверено 30 апреля 2020 г.
  • веб-сайт Фонда openEHR
  • спецификации openEHR
  • Белая книга openEHR 2015
Взято с "https://en.wikipedia.org/w/index.php?title=OpenEHR&oldid=1259588657"