openEHR - это открытая стандартная спецификация в области информатики здоровья, которая описывает управление и хранение, поиск и обмен данными о здоровье в электронных медицинских картах (EHR). В openEHR все данные о здоровье человека хранятся в «одной жизни», независимой от поставщика, ориентированной на человека EHR. Спецификации openEHR включают спецификацию EHR Extract [1], но в остальном они не связаны в первую очередь с обменом данными между EHR-системами, так как это находится в центре внимания других стандартов, таких как EN 13606 и HL7 .
Спецификации openEHR поддерживаются openEHR Foundation, некоммерческим фондом, поддерживающим открытые исследования, разработку и внедрение ЭУЗ openEHR. Спецификации основаны на сочетании 15-летних европейских и австралийских исследований и разработок в области электронных медицинских записей и новых парадигм, включая то, что стало известно как методология архетипов [2] [3] для спецификации содержания.
Спецификации openEHR [4] включают модели информации и услуг для EHR, демографии, клинического рабочего процесса и архетипов . Они предназначены для того, чтобы стать основой надежной с медицинской точки зрения, распределенной, версионной инфраструктуры ЭУЗ.
Архитектура
Архитектура спецификаций openEHR в целом состоит из следующих ключевых элементов:
- информационные модели (также известные как «эталонная модель»);
- формализм архетипа;
- переносимый язык запросов архетипов;
- сервисные модели / API.
Использование первых двух позволяет разрабатывать `` архетипы '' и `` шаблоны '', которые являются формальными моделями клинического и связанного с ними контента и представляют собой слой де-факто собственных стандартов, гораздо более многочисленных, чем базовые спецификации, на основе которых они построены. Язык запросов позволяет строить запросы на основе архетипов, а не физических схем базы данных, тем самым отделяя запросы от деталей физического сохранения. Модели сервисов определяют доступ к ключевым внутренним сервисам, включая сервис EHR и демографический сервис, в то время как для доступа к приложениям используется растущий набор облегченных API-интерфейсов на основе REST, основанных на путях архетипа.
Обзор архитектуры openEHR предоставляет краткое изложение архитектуры и подробные спецификации. [5]
Эталонная модель
Центральной частью спецификаций openEHR является набор информационных моделей, известных в openEHR как «эталонные модели». [6] Модели составляют базовые информационные модели для систем openEHR и определяют инвариантную семантику электронной медицинской записи (EHR), EHR Extract и демографической модели, а также поддерживают типы данных, структуры данных, идентификаторы и полезные шаблоны проектирования. .
Некоторыми из ключевых классов в компоненте 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 ).
Шаблоны исторически разрабатывались в простом, де-факто промышленно разработанном формате XML, известном как «.oet» после расширения файла. [15] ADL 2 определяет способ бесшовного выражения шаблонов с помощью архетипов с использованием расширений языка ADL. [16]
Гарантия качества архетипов
Были определены различные принципы развития архетипов. [17] Например, набор архетипов openEHR требует управления качеством, чтобы соответствовать ряду аксиом, таких как взаимоисключающие. Архетипами можно управлять независимо от программных реализаций и инфраструктуры в руках клинических групп, чтобы гарантировать, что они удовлетворяют реальным потребностям на местах. Архетипы разработаны, чтобы позволить спецификации клинических знаний развиваться и развиваться с течением времени. Проблемы в реализации информационных дизайнов, выраженные в openEHR, связаны с тем, насколько фактические системные ограничения согласуются с информационным дизайном. [ необходима цитата ]
В области электронных медицинских карт существует ряд существующих информационных моделей с частично совпадающими областями применения, которыми сложно управлять, например, между HL7 V3 и SNOMED CT . Подход openEHR сталкивается с проблемами гармонизации, если не используется изолированно. [18]
Международное сотрудничество
Следуя подходу openEHR, использование общих и управляемых архетипов в глобальном масштабе обеспечит возможность последовательного манипулирования и просмотра данными openEHR, независимо от технического, организационного и культурного контекста. Этот подход также означает, что фактические модели данных, используемые любой EHR, являются гибкими, учитывая, что могут быть определены новые архетипы для удовлетворения будущих потребностей ведения клинических записей. Недавно работа в Австралии продемонстрировала, как архетипы и шаблоны могут использоваться для облегчения использования устаревших медицинских записей и данных сообщений в системе медицинских записей openEHR, а также для вывода стандартизированных сообщений и документов CDA.
Перспектива получения соглашения по дизайну и формам управления на международном уровне остается спекулятивным, с влияниями в пределах от разнообразных медико-правовых условий для культурных изменений, технических изменений , таких как степень , в которой ссылка клиническая терминология должна быть неотъемлемой .
Структура openEHR соответствует стандарту обмена электронными медицинскими картами ( ISO 13606 ), а объектная модель архетипа 2 (AOM2) была официально принята ISO TC 215 в качестве проекта спецификации для версии ISO 13606: 2 от 2017 года.
Международное усыновление
Архетипы openEHR используются Национальным переходным органом электронного здравоохранения Австралии, Информационным центром здравоохранения и социального обеспечения Национальной службы здравоохранения Великобритании (HSCIC), норвежской организацией Nasjonal IKT и Министерством здравоохранения Словении.
openEHR был выбран в качестве основы для стандартизированной EHR в Бразилии. [19]
Он начинает использоваться в коммерческих решениях по всему миру, в том числе в тех, которые производятся отраслевыми партнерами openEHR.
Менеджер клинических знаний (CKM)
Одним из результатов подхода к моделированию openEHR является открытая разработка архетипов, шаблонов и подмножеств терминологии для представления данных о здоровье. Из-за открытого характера openEHR эти структуры общедоступны для использования и внедрения в информационных системах здравоохранения. Пользователи сообщества могут делиться, обсуждать и утверждать эти структуры в совместном репозитории, известном как Clinical Knowledge Manager (CKM). Некоторые в настоящее время используют openEHR CKM:
- Менеджер клинических знаний openEHR
- Менеджер клинических знаний NEHTA
- Менеджер по клиническим знаниям в Великобритании
- Норвежский национальный менеджер по клиническим знаниям в области ИКТ
- Менеджер по клиническим знаниям Министерства здравоохранения Словении
Смотрите также
- Архетип (информатика)
- Европейский институт медицинских записей
- Электронная передача данных о состоянии здоровья ( ISO / CEN EN 13606 - EHRcom)
- Уровень здоровья 7
- Архитектура службы информатики здравоохранения (HISA)
- HIPAA
- ProRec
- СНОМЕД КТ
Рекомендации
- ^ Технические характеристики Редакционный комитет. «openEHR EHR Extract IM» . Фонд openEHR . Фонд openEHR . Дата обращения 3 ноября 2015 .
- ^ Бил Т. (2002). «Архетипы: модели предметной области на основе ограничений для перспективных информационных систем» (PDF) . Материалы 11-го семинара OOPSLA по поведенческой семантике . (PDF)
- ^ С. Херд и Т. Бил. (ред.) (2007). «Обзор архитектуры openEHR» (PDF) . Фонд openEHR . Проверено 9 апреля 2013 года .CS1 maint: дополнительный текст: список авторов ( ссылка ) (PDF)
- ^ Программа спецификаций openEHR. «Спецификации openEHR» . Фонд openEHR . Дата обращения 3 ноября 2015 .
- ^ Программа спецификаций openEHR. «Обзор архитектуры openEHR» . Фонд openEHR . Фонд openEHR . Дата обращения 3 ноября 2015 .
- ^ Программа спецификаций openEHR. «Эталонная модель openEHR» . Фонд openEHR . Дата обращения 3 ноября 2015 .
- ^ Программа спецификаций openEHR. «Обзор технологии архетипа» . Фонд openEHR . Фонд openEHR . Дата обращения 3 ноября 2015 .
- ^ «Что такое openEHR» . Фонд openEHR . Проверено 9 апреля 2013 года .
- ^ «Архетипический язык запросов (AQL)» . Фонд openEHR . Проверено 9 апреля 2013 года .
- ^ Хэгглунд М., Чен Р., Кох С. (2011). «Моделирование общих планов ухода с использованием CONTsys и openEHR для поддержки совместного ухода за пожилыми людьми на дому» . Журнал Американской ассоциации медицинской информатики . 18 (1): 66–9. DOI : 10.1136 / jamia.2009.000216 . PMC 3005865 . PMID 21106993 .
- ^ «Клиническая стандартизация» . Фонд openEHR. Архивировано из оригинального 19 декабря 2013 года . Проверено 9 апреля 2013 года .
- ^ Бил, Т; Слышал, S, ред. (12 декабря 2008 г.), Язык определения архетипов 1.4 , openEHR Foundation.
- ^ Программа спецификаций openEHR (3 ноября 2015 г.), Язык определения архетипов 2 , openEHR Foundation
- ^ «Технические характеристики ADL / AOM 2» . Фонд openEHR . Дата обращения 3 ноября 2015 .
- ^ "Шаблон" .oet "XSD" . Фонд openEHR . Проверено 9 апреля 2013 года .
- ^ Программа спецификаций openEHR. «Спецификация языка определения архетипа (ADL2)» . Фонд openEHR . Фонд openEHR . Дата обращения 3 ноября 2015 .
- ^ С. Херд и Т. Бил. (ред.) (2005). «Определения и принципы архетипа» (PDF) . Фонд openEHR . Проверено 9 апреля 2013 года .CS1 maint: дополнительный текст: список авторов ( ссылка ) (PDF)
- ^ Мин Л., Тиан Кью, Лу Х, Дуань Х. (август 2018 г.). «Моделирование EHR с подходом openEHR: предварительное исследование в Китае» . BMC Медицинская информатика и принятие решений . 18 (1): 75. DOI : 10,1186 / s12911-018-0650-6 . PMC 6116359 . PMID 30157838 .
- ^ "Ministério da Saúde" . bvsms.saude.gov.br . Проверено 30 апреля 2020 .
Внешние ссылки
- сайт фонда openEHR
- спецификации openEHR
- Официальный документ openEHR 2015