ФорумИз всей статьи взяты только положительные и отрицательные стороны каждого из стандартов с точки зрения авторов, которые (авторы) являются адептами openEHR и, как бы, должны подвести читателей к мысли, что openEHR имеет явные преимущества по сравнению с HL7.
Очевидно, что сколько людей столько и сравнений (можно глянуть «Какими должны быть стандарты» от Адам Босворт), для меня ниже приведённое больше похоже на сравнение мягкого и зелёного, т.к. HL7 и openEHR преследуют разные цели, их развитие строилось на разных принципах, и, если удалось углядеть какое-то соответствие между ними, то это вовсе не означает, что они равнозначны. Тем не менее, данное сравнение имеет место быть, авторы сами занимаются разработкой стандарта (openEHR), поэтому их мнение должно быть интересным. Мои редкие комментарии в квадратных скобках. Если что-то не совсем понятно, рекомендую обращаться к первоисточнику, возможно ваш перевод будет лучше. Также, статья содержит положительные и отрицательные стороны CDA и CEN EN13606, на мой взгляд эти сравнения не столь существенные, т.к. ссылаются на свои стандарты-предки.
HL7v2
Положительные стороны:
• Типы данных стандарта HL7v2 достаточно выразительны и позволяют пересылать произвольно структурированные объекты. В результате, существующая, основанная на HL7v2, инфраструктура может быть использована для передачи различных, семантически богатых, данных. [Это даже в бОльшей степени относится к HL7v3, однако там это не упоминается.]
• Сегменты, добавленные в более поздних версиях, в основном позволили избежать необходимости определять дополнительные сегменты пользователем.
• Простота использования и широкое распространение способствует дальнейшему использованию и сравнительно недорогой реализации сторонними вендорами. [Сравнение не учитывает тех, кто начинает с чистого листа.]
Отрицательные стороны:
• Опциональность и неоднозначность в толковании сегментов сообщения тормозит всеобщую совместимость, для успешного обмена сообщениями необходима предварительная договоренность между контрагентами.
• Отсутствие явной семантики усложняет обмен сообщениями. Отсутствуют средства описания смыслового контента кроме того, что жёстко прописан в стандарте. Невозможно установить отношения между разными частями сообщения.
• Региональные реализации достигли ограниченного успеха. [И как это согласуется с их же утверждением про простоту использования и широкое распространение?]
• Проблемы с конфиденциальностью и правами доступа [consent structures], необходимые для ЭМК. [Эти проблемы могут быть взвалены например на SOAP в теле которого передаётся HK7 сообщение.]
• Средства выражения HL7v2 недостаточны для кодирования сложных клинических исследований. [Вопрос – нужно ли передавать сообщения со сложными клиническими исследованиями?]
HL7v3
Положительные стороны:
• Гибкая и богатая семантика позволяет выразить любую область здравоохранения.
• Стандарт решает многие трудности, возникающие на практике с мед данными (такие как отсутствие информации, неточности, дублирование записей и т.д.)
• В HL7 RIM предусмотрены средства для описаний мед реальности, хотя и отданы на откуп рабочим группам, которые делают это с помощью терминологии или онтологии.
• Существуют разнообразные средства разработки. [Не совсем понятно, что именно понимается под средствами разработки – средства моделирования, средства интеграции, средства работы с XML.]
• Может использоваться в аналитических системах принятия решений.
• «Большая часть работы в области медицинской помощи (в США), основана в v3.» [Видимо имеется ввиду CDA и прочие шаблоны документов.]
• HL7v3 не настолько сложный, если в нём один раз разобраться и большинству реализаций не нужны все тонкости стандарта. Динамическая модель не сложнее аналогичной в HL7v2. [Может и не сложнее, что может быть сложного в запрос-ответ, но чаще всего она не соответствует напрямую HL7v2.]
Отрицательные стороны:
• Даже среди специалистов v3 нет уверенности в его пригодности заявленным целям.
• Переход на v3 для многих мед процессов, таких как оповещения, проверка лекарств и прочее, не даёт явных преимуществ по сравнению с v2. Т.е. окупаемость инвестиций не достаточно прозрачна. [Опять же, как насчёт тех, кто начинает с чистого листа.]
• Первое нормативное издание было в 2005, однако с тех пор стандарт находится в постоянном обновлении. [Вообще-то это относится к любому стандарту.]
• Структура v3 сообщения достаточно сложная и трудная для понимания, что требует достаточно долгого процесс обучения, что, в свою очередь, отражается на количестве специалистов по данному стандарту.
• Неверно утверждать, что v2-v3 маппинг может автоматически произведён integration engine, в то время как некоторые поля v2 сообщения легко сопоставить полям v3 сообщения, сам процесс взаимодействия и его причины (trigger events) в двух стандартах различны. [В реальности всё ещё хуже, маппинг практически невозможно произвести автоматизировано, trigger events в v2 и v3 сообщениях различны.]
• Гораздо труднее получить все артефакты из сообщения v3, чем их отправить, т.к. для вычленения смысла из сообщения v3 требуется больше усилий. [Это в бОльшей степени относится к CDA со сложными шаблонами секций, чем к сообщениям. В этом как раз один из недостатков этого сравнения, на мой взгляд, т.к. авторы постоянно перемешивают messaging и documents.]
• RIM страдает несоответствием между Информационной Моделью (объекты-документ-сущности) и Ссылочной Онтологией (объекты как описание сущности). [Объясните мне это на русском!]
• RIM путает акт с записью, а сами документы едва ли структурированы. Нет иерархии документов, отсутствует формальная модель для выражения отношений между документами, и нет каких-либо средств чтобы выразить данные в клиническом контексте. [Причём тут документы, причём тут отношения между шаблонами документов наследованными от CDA?]
• Некоторые определения нелогичны, отсутствуют такие понятия как «диагноз», «оценка» и «прогноз». [Весь PRPA домен только этому и посвящен, все понятия там присутствуют.]
• Информация содержащаяся в документах (CDA) и в сообщениях трактуется по-разному. В то время как в документе позволяется делать фактическое утверждение (хотя и в секции narrative), в сообщении возможно только косвенное утверждение в классе Observation Act. [Может быть потому, что это разные понятия. CDA всего лишь один из доменов HL7v3 NE.]
• v3 не подходит как модель для хранения информации для ЭМК, и в самом стандарте не описано какой-либо архитектурной модели (не считая EHR-S FM, которая описывает функции системы, а не архитектуру). [Про это я писал в прошлой статье, поэтому не буду повторяться.]
• Информационная наполненность v3 XML сообщения очень низкая (не более 5%), в то время как само сообщение достаточно большое.
• Сложность модели и её взаимодействие с внешними словарями, такими как SNOMED CT, означает, что выразить утверждение можно множественным способом, в тоже время для получателя сообщение не существует уникального способа интерпретировать информацию таким же способом.
• Семантика информационного содержания сообщения смешиваются с семантикой самого сообщения.
• Непонятно, как можно было бы запросить репозиторий v3 сообщений. [Может кто-то объяснит, о чём они здесь?]
• Дизайн HL7v3 ближе к языку описания процессов, чем к описанию документов. Это создаёт зависимость между документами и процессами – содержание документов ограничивается связанными с ними требованиями процесса. [А давайте поговорим об ASTM CCR, его содержание не ограничивается процессом, в котором он используется? CCR является прародителем HL7 CCD. Или прочие документы HITSP которые явились прототипами для шаблонов документов CDA .]
• Реализация сообщений требуют много ресурсов. Во всех системах участвующих в коммуникациях сообщения должны быть реализованы одинаковым образом. [Очень странное утверждение, если я общаюсь с кем-то на русском языке, то ожидаю, что отвечать мне тоже будут на русском, даже если это потребует от говорящего много времени для изучения.]
openEHR
Положительные стороны:
• Модель является интуитивно понятной и простой для понимания врачей. Архетипы, как правило, легки для понимания, обсуждения и проектирования. Используемые термины легко соотносятся с клинической записью.
• Используемый подход предназначен для записи наблюдений врача и запросов этих записей.
• Модель полностью соответствует стандарту ISO / TS 13808.
• Запросы могут быть переданы сообщениями HL7v2. [Вероятно они также могут быть переданы HL7v3 и сохранены в CDA.]
• Поскольку предметно-ориентированная семантика в декларативных архетипах и словарях, эталонная модель должна быть стабильной в течении долгого времени.
• Архетипы могут быть преобразованы в CDA используя XSLT.
Отрицательные стороны:
• Используемому подходу не хватает смысловой строгости, он также не содержит онтологии. Эталонная модель не обеспечивает основу для семантической совместимости – требуется отдельная модель для представления клинической семантики и связей между концепциями.
• Он не обеспечивает достаточную поддержку для семантических связей между архетипами. Внутри архетипов семантика определяется автором данного архетипа.
• Стандарт пока что не использовался для реализации средних и крупных систем.
• Стандарт практически не распространён, несмотря на достаточное время существования. [Статья написана в 2010, с тех пор, вероятно, произошли какие-то изменения.]
• Спецификация стандарта не стабильна и постоянно подвергается изменениям. [Куда же она денется.]
• Достаточно проблематично создать взаимосвязанную и логически не пересекающуюся модель. Чтобы избежать семантического дублирования и конфликтов для национальных репозитариев, могут понадобиться более изощрённые средства разработки, чем те, что существуют на данный момент.
• Поддержка со стороны официальных разработчиков стандартов, таких как SNOMET CT или ISO 13606, весьма слабая.
Грубо говоря, HL7 и openEHR используют диаметрально противоположные подходы к одной и той же области. Если HL7 действует как скульптор, берёт глыбу RIM и отсекает от неё все лишнее, чтобы выразить какую-то мед область, подразумевая, что если система в состоянии оперировать понятиями RIM, то сможет интерпретировать любое сообщение построенное на усечённой модели RIM. В теории. На практике всё несколько сложнее.
В противоположность этому, openEHR берёт кубики архетипов, клонирует их
неограниченное количество раз и пытается из них построить виртуальную
EHR подпирая это информационной моделью.