Статья ниже представляет собой мой вольный перевод сравнительного (довольно поверхностного) анализа стандартов HL7 и openEHR, опубликованного в электронном журнале Journal of Health Informatics 2010 Vol 5 под названием « Применение стандартов совместимости медицинских записей на практике Сама статья, что называется, любезно предоставлена одним из авторов, однако в силу давности публикации я воздержался от задавать кучу дополнительных вопросов.
Из всей статьи взяты только положительные и отрицательные стороны каждого из стандартов с точки зрения авторов, которые (авторы) являются приверженцами openEHR и как бы должны подвести читателей к мысли, что openEHR имеет явные преимущества перед HL7. Очевидно, столько людей, сколько и сравнений (можно посмотреть « Какими должны быть стандарты? » Адама Босворта), для меня приведенное ниже больше похоже на сравнение soft и green, т.к.
HL7 и openEHR преследуют разные цели, их разработка строилась на разных принципах, и если можно было усмотреть между ними какое-то соответствие, то это не означает, что они эквивалентны.
Однако такое сравнение имеет место, авторы сами разрабатывают стандарт (openEHR), поэтому их мнение должно быть интересно.
Мои редкие комментарии - в квадратных скобках, если что-то не совсем понятно, рекомендую.
обращаясь к первоисточнику, возможно, ваш перевод будет лучше.
Также в статье приведены положительные и отрицательные стороны CDA и CEN EN13606, на мой взгляд, эти сравнения не столь существенны, т.к.
относятся к их предкам-стандартам.
HL7v2 Положительные стороны: • Типы данных стандарта HL7v2 достаточно выразительны и позволяют передавать произвольно структурированные объекты.
В результате существующая инфраструктура на базе HL7v2 может использоваться для транспортировки различных семантически богатых данных.
[Это еще более верно в HL7v3, но там это не упоминается.
] • Сегменты, добавленные в более поздних версиях, в значительной степени избавили пользователя от необходимости определять дополнительные сегменты.
• Простота использования и широкое распространение способствуют дальнейшему использованию и относительно недорогому внедрению сторонними поставщиками.
[В сравнении не учитываются те, кто начинает с нуля.
] Отрицательные стороны: • Необязательность и двусмысленность в интерпретации сегментов сообщения препятствуют общей совместимости; для успешного обмена сообщениями необходима предварительная договоренность между контрагентами.
• Отсутствие явной семантики затрудняет обмен сообщениями.
Не существует иных средств описания смыслового содержания, кроме тех, которые строго прописаны в стандарте.
Невозможно установить связи между различными частями сообщения.
• Региональные реализации принесли ограниченный успех.
[И как это согласуется с их заявлениями о простоте использования и широком распространении?] • Проблемы с конфиденциальностью и правами доступа [структурами согласия], необходимыми для МК.
[ЭВ этих проблемах можно винить, например, SOAP, в теле которого передается сообщение HK7.] • Инструменты экспрессии HL7v2 недостаточны для кодирования сложных клинических исследований.
[Вопрос – Следует ли сообщать о сложных клинических исследованиях?] HL7v3 Положительные стороны: • Гибкая и богатая семантика позволяет выразить любую область здравоохранения.
• Стандарт решает многие трудности, возникающие на практике с медицинскими данными (например, недостаток информации, неточности, дублирование записей и т. д.).
• HL7 RIM предоставляет инструменты для описания медицинской реальности, хотя это оставлено на усмотрение рабочих групп, которые делают это с использованием терминологии или онтологии.
• Доступны различные инструменты разработки.
[Не совсем понятно, что именно подразумевается под инструментами разработки – инструментами моделирования, инструментами интеграции, инструментами для работы с XML.] • Может использоваться в аналитических системах принятия решений.
• «Большая часть работы в сфере здравоохранения (в США) основана на версии 3».
[Видимо, имеется в виду CDA и другие шаблоны документов.
] • HL7v3 не так уж сложен, если вы освоите его, и большинству реализаций не нужны все тонкости стандарта.
Динамическая модель не сложнее, чем в HL7v2. [Возможно, это не сложнее того, что может быть сложным в вызове-ответе, но чаще всего оно не соответствует напрямую HL7v2.] Отрицательные стороны: • Даже среди специалистов v3 нет уверенности в ее пригодности для заявленных целей.
• Переход на версию 3 для многих медицинских процессов, таких как оповещения, проверка лекарств и т. д., не дает явных преимуществ по сравнению с версией 2. Те.
возврат инвестиций недостаточно прозрачен.
[Опять же, а как насчет тех, кто начинает с нуля.
] • Первое нормативное издание вышло в 2005 году, но с тех пор стандарт постоянно обновляется.
[На самом деле это применимо к любому стандарту.
] • Структура сообщения v3 достаточно сложна и трудна для понимания, что требует достаточно длительного процесса обучения, что, в свою очередь, влияет на количество специалистов по этому стандарту.
• Неверно говорить, что отображение v2-v3 может автоматически выполняться механизмом интеграции, в то время как некоторые поля сообщения v2 легко сопоставляются с полями сообщения v3, сам процесс взаимодействия и его причины (триггерные события) в двух стандартах разные.
[В реальности всё ещё хуже, маппинг практически невозможно выполнить автоматически, триггерные события в сообщениях v2 и v3 разные.
] • Получить все артефакты из сообщения версии 3 гораздо сложнее, чем отправить их, поскольку извлечение смысла из сообщения версии 3 требует больше усилий.
[Это больше относится к CDA со сложными шаблонами разделов, чем к сообщениям.
Именно это, на мой взгляд, является одним из недостатков данного сравнения, поскольку.
авторы постоянно смешивают сообщения и документы.
] • RIM страдает от несоответствия между информационной моделью (объекты-сущности документа) и эталонной онтологией (объекты как описания сущностей).
[Объясните мне это по-русски!] • RIM путает акт с записью, а сами документы плохо структурированы.
Не существует ни иерархии документов, ни формальной модели для выражения отношений между документами, ни средств выражения данных в клиническом контексте.
[Причём здесь документы, и причём здесь отношения между шаблонами документов, унаследованными от CDA?] • Некоторые определения нелогичны, отсутствуют понятия «диагноз», «оценка» и «прогноз».
[Весь домен PRPA посвящен этому, там присутствуют все концепции.
] • Информация, содержащаяся в документах (CDA) и сообщениях, интерпретируется по-разному.
В то время как документ допускает фактическое утверждение (хотя и в описательной части), сообщение допускает только косвенное утверждение в классе Закона о наблюдении.
[Может быть потому, что это разные понятия.
CDA — это всего лишь один из доменов HL7v3 NE.] • v3 не подходит в качестве модели хранения информации для ММК, а сам стандарт не описывает никакой архитектурной модели (не считая EHR-S FM, которая описывает функции системы, а не архитектуру).
[Об этом я писал в предыдущей статье, поэтому повторяться не буду.
] • Информативность XML-сообщения версии 3 очень низкая (не более 5%), тогда как само сообщение достаточно велико.
• Сложность модели и ее взаимодействие с внешними словарями, такими как SNOMED CT, означают, что утверждение может быть выражено несколькими способами, но не существует уникального способа для получателя сообщения интерпретировать информацию одинаковым образом.
• Семантика информационного содержания сообщения смешивается с семантикой самого сообщения.
• Неясно, как можно запрашивать хранилище сообщений версии 3. [Может кто-нибудь объяснить, о чем здесь идет речь?] • Дизайн HL7v3 ближе к языку описания процессов, чем к языку описания документов.
Это создает зависимость между документами и процессами — содержимое документов ограничено требованиями процесса, связанными с ними.
[А давайте поговорим об ASTM CCR, его содержание не ограничивается процессом, в котором он используется? CCR является прародителем HL7 CCD. Или другие документы HITSP, которые были прототипами шаблонов документов CDA.] • Реализация сообщений требует много ресурсов.
Во всех системах, участвующих в коммуникациях, сообщения должны реализовываться одинаково.
[Очень странное заявление, если я общаюсь с кем-то на русском языке, то ожидаю, что мне ответят тоже по-русски, даже если это потребует от говорящего много времени на изучение.
] открытьEHR Положительные стороны: • Модель интуитивно понятна и легка для понимания врачей.
Архетипы, как правило, легко понять, обсудить и спроектировать.
Используемые термины легко соотносятся с историей болезни.
• Используемый подход заключается в записи наблюдений врачей и анализе этих записей.
• Модель полностью соответствует стандарту ISO/TS 13808. • Запросы могут отправляться сообщениями HL7v2. [Вероятно, их также можно было бы перенести в HL7v3 и сохранить в CDA.] • Поскольку семантика, специфичная для предметной области, содержится в декларативных архетипах и словарях, эталонная модель должна быть стабильной во времени.
• Архетипы можно конвертировать в CDA с помощью XSLT. Отрицательные стороны: • Используемому подходу не хватает семантической строгости и онтологии.
Модель шаблона не обеспечивает основу для семантической совместимости — для представления клинической семантики и отношений между понятиями требуется отдельная модель.
• Он не обеспечивает достаточной поддержки семантических отношений между архетипами.
Внутри архетипов семантика определяется автором данного архетипа.
• Стандарт еще не использовался для реализации средних и крупных систем.
• Стандарт практически не получил широкого распространения, несмотря на достаточное время существования.
[Эта статья была написана в 2010 году, с тех пор, вероятно, произошли некоторые изменения.
] • Спецификация стандарта нестабильна и постоянно меняется.
[Куда она пойдет.] • Создать взаимосвязанную и логически непересекающуюся модель довольно проблематично.
Чтобы избежать семантического дублирования и конфликтов для национальных репозиториев, могут потребоваться более сложные инструменты разработки, чем те, которые доступны в настоящее время.
• Поддержка со стороны разработчиков официальных стандартов, таких как SNOMET CT или ISO 13606, очень слаба.
Грубо говоря, HL7 и openEHR используют диаметрально противоположные подходы к одной и той же области.
Если HL7 действует как скульптор, он берет блок RIM и отсекает от него все ненужное, чтобы выразить некоторую медовую область, подразумевая, что если система способна работать в концепциях RIM, она сможет интерпретировать любое сообщение, построенное на основе усеченная модель RIM. В теории.
На практике все несколько сложнее.
Напротив, openEHR берет кубы архетипов, клонирует их неограниченное количество раз и пытается построить из них виртуальный EHR, подкрепленный информационной моделью.
Теги: #hl7 #CDA #CCD #ccr #openEHR #EN13606 #ИТ-стандарты #Разработка систем связи
-
Открытый Вебинар «Работа: Своя И Чужая»
19 Oct, 24 -
Всего Лишь Игра. Не Компьютер, Бумага
19 Oct, 24 -
Новый Симулятор Жизни Сисадмина От Intel
19 Oct, 24
