Как предполагается использовать openEHR?
Я занимаюсь исследованием электронных медицинских карт (EHR). Похоже, что OpenEHR достаточно распространен и ценится в этой области, поскольку он широко принят. Однако я не могу найти, как это используется. Я имею в виду, я могу видеть все определения для архетипов, и как эти определения пишутся в ADL или XML. Но как только я получу архетип, который является определением определенной модели данных, как мне это использовать? Есть ли другой тип представления, может быть, также в ADL или XML? Есть ли примеры реальных медицинских записей для пациента? Я часами искал пример медицинской карты Джона Доу с информацией, такой как пол, возраст, артериальное давление и т. Д., Но все примеры, которые я могу найти, касаются определений этих терминов.
Если кто-то может поставить меня на правильный путь, я был бы признателен. Заранее спасибо!
8 ответов
Спецификация openEHR описывает, как написать систему, основанную на этом двухуровневом подходе... ряд компаний по всему миру в настоящее время используют архитектуру в качестве основы для своих систем. Ваше разочарование не ново, так как это сложный шаг. Но в результате системы могут совместно использовать медицинские записи с последующим обнаружением формального значения. Модели могут быть написаны на любом языке, добавляя языки по мере того, как вы идете.... нет языкового первенства.
Я предлагаю вам подписаться на техническую рассылку openehr.org и задать тот же вопрос.
Приветствия Сэм Херд Фонд OpenEHR
После того, как у вас будет набор архетипов, определяющих вашу клиническую историю (структура, ограничения, терминология), я бы порекомендовал создать ваши операционные шаблоны (OPT) с помощью Ocean Template Designer. Это большой XML со всей семантикой архетипов, на которую ссылаются, в одном файле (прост в обращении).
После этого вы должны сделать несколько вариантов дизайна:
- База данных технологии
Вы можете выбрать реляционную, объектную или документную технологию. Я предпочитаю сочетание реляционной и некоторой поддержки XML. Большинство реляционных СУБД сегодня поддерживают XML как собственный тип данных.
- Модель данных
Существуют две экстремальные модели: а) сопоставить RM 1-1 с моделью БД, б) использовать подход ключ / значение. Для требований, которым необходимо запрашивать иерархию, а) лучше, но у вас будет много объединений в реляционных СУБД. Для запросов, основанных на простых данных, б) лучше, но вам нужно иметь некоторую логику, если вы хотите построить иерархию обратно из наборов k/v.
Почему я упомянул иерархию? Как вы могли заметить, информационная модель openEHR имеет древовидную структуру, поэтому по умолчанию является иерархической, и это потому, что клиническая информация имеет иерархическую природу.
В EHRServer я создавал структурированные индексы в реляционной СУБД. Этот подход находится в середине а) и б). Я также использую инструменты ORM ( http://grails.org/doc/latest/guide/GORM.html) для автоматического отображения экземпляров объектов в таблицах.
Одним из ключевых аспектов модели данных является сохранение ссылки на архетип, который определяет каждую точку данных, что может быть сделано в самой БД или с использованием метаданных для сопоставления путей архетипа с таблицей / столбцом.
- Определение пользовательского интерфейса
Вы можете создать свой пользовательский интерфейс вручную или сгенерировать его из архетипов + шаблонов. В любом случае вам понадобятся метаданные, чтобы связать поля пользовательского интерфейса с полями архетипов. Для этого я использую поле id и archetypeId + path.
Это помогает мне связать входные данные от врачей в Информационную модель openEHR, и с правильными метаданными это можно сделать общим способом.
Если вы не знаете об идентификаторах и путях архетипов, прочитайте: http://openehr.org/releases/1.0.2/architecture/am/archetype_principles.pdf
Я бы также порекомендовал обзор архитектуры: http://openehr.org/releases/1.0.2/architecture/overview.pdf
- Бизнес логика
Привязка данных к вашей модели данных является частью бизнес-логики, которая также проверяет эти данные. Для проверки я использую ограничения, которые появляются в архетипах и рабочих шаблонах. Если у вас есть путь архетипа Id +, вы можете получить ограничение из архетипа, а затем оценить это ограничение по отношению к входным данным.
- Интеграция предыдущих компонентов
Склейте все вещи вместе, и вы получите: UI <-> logic <-> DB
Надеюсь, это поможет.
Добро пожаловать в мир openEHR:)
Вам также может пригодиться просмотр примеров с открытым исходным кодом - мы внедрили приложение для составления отчетов об эндоскопии с использованием openEHR от персистентности до автоматического графического интерфейса. Приложение.Net winforms в этом случае использует MVC, поэтому я полагаю, что не составит труда использовать веб-интерфейс или мобильный интерфейс. На данный момент вы не найдете в openEHR средства для моделирования "пользовательского интерфейса" вместе с данными - поэтому мы использовали функцию "взломать" и использовать аннотации для создания некоторых "директив GUI", которые встроены в клинические модели.
Посмотрите: http://gastros.codeplex.com/
Также написал пару "статей" по реализации openEHR, если вам нравятся такие вещи;)
Atalag K, Ян HY, Tempero E, Уоррен JR. Оценка возможности сопровождения программного обеспечения с помощью openEHR - сравнение архитектур. Международный журнал медицинской информатики
Atalag K, Ян HY, Tempero E, Уоррен Дж. Модельно-ориентированная разработка систем клинической информации с использованием openEHR. Стад Здоровье Технол Информ. 2011;169:849-53.
Аталаг К, Ян Ху. От моделей доменов openEHR до продвинутых пользовательских интерфейсов: пример внедрения в эндоскопии. Веллингтон; 2010. Доступно по адресу: http://www.hinz.org.nz/uploads/file/2010conference/P17_Atalag.pdf
Удачи! Последнее замечание - HL7, как отметили некоторые другие, предназначено для "вне систем" или для обмена медицинской информацией - некоторые пытались использовать RIM для создания приложений. Для этой цели существует openEHR - так что это спецификации для построения систем EHR. Появляющийся стандарт FHIR от HL7 имеет сходство с точки зрения определения моделей клинических данных - я также рекомендую следить за этим пространством: мы надеемся, что некоторая конвергенция произойдет в недалеком будущем, надеюсь;)
Вы также можете посмотреть на
dev.ehrscape.com, который основан на базовом бэкэнде openEHR и
посмотрите на вызов композиции GET
Вы увидите пример данных JSONified openEHR. Это упрощенная версия "канонических" данных openEHR, но она помогает дать представление о структуре в целом.
Другие примеры на http://www.medvision360.com/medcloud/?lang=en, аналогично модели данных на основе openEHR
Вот фрагмент жизненных показателей в формате JSON...
{
"ctx":{
"language":"en",
"territory":"GB",
"composer_name":"Sr. Kristen George"
},
"nursing_vital_signs_observations":{
"vital_signs":[
{
"respirations":[
{
"any_event":[
{
"rate":[
{
"|magnitude":16,
"|unit":"/min"
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
},
{
"blood_pressure":[
{
"any_event":[
{
"systolic":[
{
"|magnitude":123,
"|unit":"mm[Hg]"
}
],
"diastolic":[
{
"|magnitude":102,
"|unit":"mm[Hg]"
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
},
{
"pulse":[
{
"any_event":[
{
"heart_rate":[
{
"|magnitude":93,
"|unit":"/min"
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
},
{
"indirect_oximetry":[
{
"any_event":[
{
"spo2":[
{
"|numerator":94,
"|denominator":100
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
}
],
"context":[
{
"setting":[
{
"|code":"233",
"|value":"secondary nursing care",
"|terminology":"openehr"
}
],
"start_time":[
"2014-05-22T15:18:07.339+01:00"
]
}
]
}
}
Вы можете найти некоторую помощь, посмотрев эту работу на GitHub https://github.com/ppazos?tab=repositories большая часть которой основана на концепциях openEHR.
В мире многоуровневого моделирования знаний в здравоохранении существует также MLHIM. MLHIM вырос из опыта работы с openEHR и основан непосредственно на стандартах XML. www.mlhim.org и https://github.com/mlhim
Записи компилируются и передаются в XML другим поставщикам или организациям. HL7 используется для отправки сообщений, таких как лабораторные заказы, в / из поставщиков лаборатории с определенными OBR и OBX.
Я не уверен, что вы собираетесь делать со своими исследованиями - если вы создаете свое собственное приложение / сайт, то я бы предложил синюю кнопку плюс. Это инициатива ONC, и js проанализирует большинство документов CCDA (XML-документ с информацией о пациенте из EHR). Посмотрите библиотеку на GitHub - https://github.com/blue-button/bluebutton.js
Самое главное, исследовать фон (Закон HITECH) и знать проблемы (совместимость EHR). Перейдите на сайт HHS.gov и просмотрите информацию там. Кроме того, вам понадобится кто-то, кто знает медицинскую терминологию и коды (ICD, CPT, SNOMED и т. Д.), А также клинический консультант, потому что у вас могут быть все данные в мире, но если вы их не отображаете в правильном или значимом смысле, это по сути бесполезно.
Упрощенный ответ на ваш вопрос:
- Модель данных: используйте любую платформу, которая придерживается спецификаций openEHr.
- Ограничения данных: используйте архетипы: могут быть определены в ADL или XML
- Экземпляр записи openEHR: XML
- База данных: любая
Вот запись openEHR для глюкозы в крови с клиническими данными, закодированными с использованием LOINC:
<namespace>EHR</namespace>
<type>COMPOSITION</type>
</contribution>
<commit_audit>
<system_id>10aec661-5458-4ff6-8e63-c2265537196d </system_id>
<committer xsi:type="PARTY_IDENTIFIED">
<name>guest</name>
</committer>
<time_committed>
<value>2008-05-22T10:34:28</value>
</time_committed>
<change_type>
<value>creation</value>
<defining_code>
<terminology_id>
<value>openehr</value>
</terminology_id>
<code_string>249</code_string>
</defining_code>
</change_type>
</commit_audit>
<uid>
<value>c7ff23f4-6ad2-4ff9-bedf-fb60be37666e::10aec661-5458-4ff6-8e63-c2265537196d::1
</value>
</uid>
<data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="COMPOSITION" xmlns="http://schemas.openehr.org/v1" archetype_node_id="openEHR-EHR-COMPOSITION.report.v1">
<name>
<value>Blood glucose report</value>
</name>
<archetype_details>
<archetype_id>
<value>openEHR-EHR-COMPOSITION.report.v1</value>
</archetype_id>
<template_id>
<value>blood_glucose</value>
</template_id>
<rm_version>1.0.1</rm_version>
</archetype_details>
<language>
<terminology_id>
<value>ISO_639-1</value>
</terminology_id>
<code_string>en</code_string>
</language>
<territory>
<terminology_id>
<value>ISO_3166-1</value>
</terminology_id>
<code_string>AU</code_string>
</territory>
<category>
<value>event</value>
<defining_code>
<terminology_id>
<value>openehr</value>
</terminology_id>
<code_string>433</code_string>
</defining_code>
</category>
<composer xsi:type="PARTY_IDENTIFIED">
<name>Some Labs, at some place</name>
</composer>
<context>
<start_time>
<value>2012-02-26T11:44:17+1000</value>
</start_time>
<setting>
<value>other care</value>
<defining_code>
<terminology_id>
<value>openehr</value>
</terminology_id>
<code_string>238</code_string>
</defining_code>
</setting>
<other_context xsi:type="ITEM_TREE" archetype_node_id="at0001">
<name>
<value>other context</value>
</name>
</other_context>
</context>
<content xsi:type="SECTION" archetype_node_id="openEHR-EHR-SECTION.diagnostic_reports.v1">
<name>
<value>Blood Glucose</value>
</name>
<items xsi:type="OBSERVATION" archetype_node_id="openEHR-EHR-OBSERVATION.lab_test-blood_glucose.v1">
<name>
<value>Blood glucose</value>
</name>
<language>
<terminology_id>
<value>ISO_639-1</value>
</terminology_id>
<code_string>en</code_string>
</language>
<encoding>
<terminology_id>
<value>IANA_character-sets</value>
</terminology_id>
<code_string>UTF-8</code_string>
</encoding>
<archetype_details>
<archetype_id>
<value>openEHR-EHR-OBSERVATION.lab_test-blood_glucose.v1</value>
</archetype_id>
<template_id>
<value>Blood glucose</value>
</template_id>
<rm_version>1.0.1</rm_version>
</archetype_details>
<subject xsi:type="PARTY_IDENTIFIED">
<externalRef xsi:type="PARTY_PROXY">
<id >
<value>1.2.4.5.6.12.1</value>
<root >
<value>1.2.4.5.6.12.1</value>
</root>
</id>
<namespace>DEMOGRAPHIC</namespace>
<type>PERSON</type>
</externalRef>
<name>Patient Name</name>
<identifiers xsi:type="DV_IDENTIFIER">
<issuer>Some issuer id</issuer>
<assigner>Some Assignee</assigner>
<id>B5404149</id>
<type>null</type>
</identifiers>
</subject>
<protocol xsi:type="ITEM_TREE" archetype_node_id="at0033">
<name>
<value>Tree</value>
</name>
<items xsi:type="CLUSTER" archetype_node_id="at0039">
<name>
<value>Specimen details</value>
</name>
<items xsi:type="ELEMENT" archetype_node_id="at0040">
<name>
<value>DateTime received</value>
</name>
<value xsi:type="DV_DATE_TIME">
<value>2006-11-22T18:57:01</value>
</value>
</items>
<items xsi:type="ELEMENT" archetype_node_id="at0041">
<name>
<value>DateTime processed</value>
</name>
<value xsi:type="DV_DATE_TIME">
<value>2006-11-22T18:57:01</value>
</value>
</items>
</items>
</protocol>
<data archetype_node_id="at0001">
<name>
<value>data</value>
</name>
<origin>
<value>2006-11-22T18:57:01</value>
</origin>
<events xsi:type="POINT_EVENT" archetype_node_id="at0002">
<name>
<value>Any event</value>
</name>
<time>
<value>2006-11-22T18:57:01</value>
</time>
<data xsi:type="ITEM_TREE" archetype_node_id="at0003">
<name>
<value>Tree</value>
</name>
<items xsi:type="ELEMENT" archetype_node_id="at0005">
<name xsi:type="DV_CODED_TEXT">
<value>Glucose 1h^Post Meal</value>
<defining_code>
<terminology_id>
<value>LN</value>
</terminology_id>
<code_string>10449-7</code_string>
</defining_code>
</name>
<value xsi:type="DV_TEXT">
<value>Blood Glucose</value>
</value>
</items>
<items xsi:type="ELEMENT" archetype_node_id="at0004">
<name>
<value>Blood glucose</value>
</name>
<value xsi:type="DV_QUANTITY">
<magnitude>100</magnitude>
<units>mmol/l</units>
<precision>0</precision>
</value>
</items>
</data>
</events>
</data>
</items>
</content>
</data>
<lifecycle_state>
<value>completed</value>
<defining_code>
<terminology_id>
<value>openehr</value>
</terminology_id>
<code_string>532</code_string>
</defining_code>
</lifecycle_state>
Если вас интересует комбинация REST+openEHR (или другие подходы EHR, основанные на архетипах, такие как CIMI или ISO 13606), вам может быть интересен подход, описанный в http://www.biomedcentral.com/1472-6947/13/57 соответствующий открытый исходный код на Java доступен по адресу https://github.com/LiU-IMT/EEE
Более поздние обсуждения, касающиеся определения / стандартизации API openEHR REST, можно найти по адресу https://openehr.atlassian.net/wiki/display/spec/openEHR+REST+APIs
Наличие стандартизированного REST API для openEHR позволит приложениям конечных пользователей подключаться к бэкэндам openEHR от нескольких разных поставщиков / проектов, поэтому вам не нужно тратить так много времени на хранение и запросы.