Сравнение FHIR с другими стандартами HL7
Организация Health Level Seven International занимается разработкой стандартов обмена медицинской информацией с 1987 года. За этот период организация выпустила несколько семейств стандартов, многие из которых используются для автоматизации обмена медицинскими данными и повышения качества оказания медицинской помощи. В данной статье HL7 FHIR сравнивается с другими стандартами от HL7.
Сходства и различия с HL7 v2
HL7 v2 – это первый стандарт обмена медицинской информацией, разработанный HL7, широко применяемый и известный по всему миру.
Обмен сообщениями: HL7 v2 использует составленные из сегментов сообщения для передачи информации между медицинскими информационными системами и вызова определённого поведения (перевод пациентов между отделениями, заказы на лабораторные исследования и т. п.). FHIR поддерживает обмен сообщениями на основе событий, аналогичный обмену сообщениями в HL7 v2 (хотя в отличие от HL7 v2, FHIR поддерживает и другие парадигмы обмена, включая документы, REST и другие модели обслуживания).
Степень детализации: Сегменты HL7 v2 примерно соответствуют идее ресурсов FHIR, однако их нельзя обрабатывать независимо друг от друга. У FHIR другой подход к повторному применению, по которому ресурсы являются независимыми сущностями.
Расширяемость: HL7 v2 предоставляет механизм расширений с помощью использования "Z-сегментов". Это нестандартные сегменты, названия которых начинаются на букву "Z", значение которых у каждого учреждения может быть своё. В FHIR расширения можно добавлять на любом уровне ресурса (включая типы данных). Расширения-модификаторы могут менять смысл элементов (например, превратить утвердительную запись в отрицательную). Расширения публикуются и идентифицируются по URI, что гарантирует, что расширения, созданные независимыми системами, не будут конфликтовать (что может быть проблемой для Z-сегментов).
Межверсионная совместимость: HL7 v2 поддерживает прямую и обратную совместимость версий. Новое содержимое может добавляться только в конец существующих полей, компонентов и т. п. Предполагается, что приложения будут игнорировать неизвестное им содержимое. FHIR сулит аналогичные правила совместимости. Путь к элементу в ресурсах FHIR остаётся неизменным в последующих версиях спецификации. Введены особые правила обработки новых элементов (игнорирование, проверка на наличие индикаторов "обязателен к поддержке" и т. п.).
Удобочитаемость для человека: Экземпляры HL7 v2 не предлагают людям удобочитаемые версии своего содержимого. Некоторые системы передают удобочитаемое для человека отображение всего или части полезной нагрузки сообщения в NTE-сегментах, однако это не является обязательным правилом. FHIR же требует предоставления человекочитаемого содержимого для каждого ресурса.
Обновление данных: Данными HL7 v2 обычно обмениваются в режиме "моментального снимка" – обновление передаётся отправкой полной копии экземпляра, заполненного новыми данными. Однако некоторые сегменты и сообщения в HL7 v2 поддерживают более сложный обмен, когда отправляются только изменённые данные, и специальные коды или особые значения указывают, какой тип изменения должен произойти (например, добавить этот адрес, удалить это имя). FHIR "из коробки" функционирует только в режиме "моментального снимка".
Гибкость: И HL7 v2, и FHIR обеспечивают одинаковую степень гибкости на уровне международного стандарта. Большинство элементов данных являются необязательными. Однако имеется и различия. HL7 v2 стремится включить много элементов, которые применяются только в очень ограниченных обстоятельствах, для которых FHIR применяет расширения. FHIR-ресурсы намного более ограничены в том, какие элементы включать в основную спецификацию – только те, которые использует большинство систем.
Профили: И HL7 v2, и FHIR предлагают официальные механизмы создания профилей и дают рекомендации по применению спецификации. Однако в HL7 v2 профили не используются широко, а в FHIR профили являются существенным компонентом методологии и встроены в инструментарий спецификации, что увеличивает вероятность их использования.
Сходства и различия с HL7 v3
HL7 v3 должен был стать следующим поколением стандартов обмена сообщениями HL7. В нём была введена Эталонная информационная модель (RIM), модель типов данных и ряд справочников наряду с формальной методологией развития стандартов. Кроме того, он ввёл в использование "документы" в качестве альтернативы архитектуре обмена сообщениями для совместного использования медицинской информации (см. сравнение с CDA). Хотя формально стандарт охватывает и то, и другое, термин "v3" обычно используют для ссылки на именно на обмен сообщениями HL7 v3. Типы данных, лежащие в основе HL7 v3, были утверждены ИСО в качестве стандарта ISO 21090. HL7 RIM также была утверждена в качестве стандарта ИСО.
Эталонная информационная модель (RIM): Использование HL7 RIM – основа методологии HL7 v3, это важнейшая часть спецификации и средство обеспечения совместимости. Все элементы данных в экземплярах HL7 v3 выведены либо из RIM, либо из типов данных ИСО. В FHIR это справедливо для большинства элементов ресурсов и типов данных, но не для всех. Некоторые ресурсы (StructureDefinition, Conformance, ValueSet и др.) находятся вне области действия RIM. Также в некоторых случаях были внесены исправления в типы данных FHIR, которые пока ещё не поддержаны в модели типов данных HL7 v3. Основное отличие состоит в том, что совместимость в FHIR достигается не за счёт установления соответствия с RIM, поэтому экземпляры в FHIR получаются значительно более лаконичными и интуитивно понятными. Можно реализовать FHIR, абсолютно не зная HL7 RIM.
Использование закодированных атрибутов: И FHIR, и v3 используют наборы допустимых значений, чтобы задавать коды, которые можно использовать в атрибутах. Однако в FHIR набор значений ValueSet – это тоже ресурс, что означает, что его можно пересылать как любой другой фрагмент данных.
Степень детализации моделей и ресурсов: Модели HL7 v3 подразделяются на 3 основных типа – обёртки, полезная нагрузка и общие типы элементов сообщений (CMET). В некоторых случаях степень детализации каждой их этих моделей будет равняться степени детализации FHIR-ресурсов, но не всегда. Модели HL7 v3 подразделяются на основе ожидания их повторного использования. Модели FHIR подразделяются на основе автономности объектов, которые они представляют. В HL7 v3 для одной и той же сущности может существовать несколько моделей, например, на уровне HL7 International есть 10 различных CMET для понятия "пациент". В дальнейшем филиалы HL7 и сами реализаторы создают вариации моделей HL7 v3. Каждая вариация имеет свою собственную схему и может использовать свои имена элементов, свои уровни вложенности и ограничивающие условия. В отличие от HL7 v3, в FHIR есть только один ресурс Patient. Для этого ресурса можно создавать множество профилей, однако все они будут использовать одну и ту же схему базового ресурса.
Методология проектирования: В HL7 RIM представлены все данные, необходимые для любого вида медицинского взаимодействия. Все остальные модели данных просто отсекают от RIM лишнее, чтобы соответствовать требованиям определённой доменной области. Этот процесс начинается на верхнем уровне и дальше уточняется в отдельных странах, проектах и, наконец, конкретных реализациях. Чем ближе модели к реализаторам, тем они менее абстрактные. Также каждая модель имеет свою собственную схему и, в большинстве случаев, схемы с ограничивающими условиями не являются строго совместимыми со схемами ограничиваемой модели. В FHIR используется другой подход. Ресурсы в FHIR не пытаются представить все элементы данных, какие только можно использовать в данной предметной области. Если приблизительно 80% систем, использующих ресурс, поддерживают этот элемент, тогда он входит в базовый ресурс. Для всех остальных элементов данных предполагается использование расширений. Профили используются, чтобы ограничить ресурсы и регламентировать использование подходящих расширений для сужения предметной области.
Вывод из контекста: Многие данные при передаче информации человек понимает из контекста. Например подразумевается, что если на титульной странице отчёта указан автор, то все утверждения в нём сделаны этим человеком. В методологии HL7 v3 есть три механизма, чтобы делать явным для компьютеров то, что люди обычно понимают интуитивно. В FHIR контекст отсутствует – всё задаётся явным образом. Если отчёт о пациенте содержит 100 данных наблюдений, относящихся к одному и тому же пациенту, то каждое наблюдение будет содержать ссылку на этого пациента. Одно из преимуществ такого подхода в том, что каждый ресурс можно безопасно использовать, не беспокоясь о контексте, в котором он был передан.
"Null flavors" – дополнительные коды, когда точное значение по какой-либо причине неизвестно: Для работы с такими случаями HL7 v3 ввёл понятие "null flavor" для большинства атрибутов и свойств типов данных в своих моделях. Примеры таких значений: "Неизвестно", "Не спросили", "Положительная бесконечность", "Ничтожное количество", "Замаскировано" (по причине безопасности или конфиденциальности, например), "Другое" и т. п. Эти "null flavors" могли появиться абсолютно в любом месте кроме элементов, помеченных как "обязательные". В FHIR тоже используются такие коды, но их использование регламентируется самой спецификацией, которая задаёт список допустимых значений "null flavors" для тех элементов, где предполагается, что они понадобятся большинству систем.
Сходства и различия с HL7 CDA
CDA (Архитектура клинического документа) – это наиболее широко используемый стандарт семейства HL7 v3. Он описывает стандартизированный заголовок, содержащий метаданные документа, и предоставляет возможность передавать клиническое содержимое, структурированное в разделы.
В FHIR можно создавать документы с помощью ресурса Composition или передавать традиционные документы CDA R2 с помощью ресурса DocumentReference и работать с CDA-документом, как с двоичным вложением.
Тип содержимого: CDA ограничен "клиническими" сценариями использования и теми документами, которые имеют отношение к пациентам. FHIR-документы не имеют ограничений на своё содержимое и могут быть не только о пациентах.
Подход к читаемости человеком: И CDA, и FHIR требуют наличия и вводят правила представления понятного удобочитаемого содержимого.
Модель содержимого: В CDA "содержимое" документа описывается с помощью сложной и абстрактной модели, основанной на проекте HL7 "Клинический отчёт". Она позволяет выражать почти любое клиническое понятие с любой степенью строгости и детализации, однако для этого требуется опыт моделирования RIM. Распространённые клинические понятия могут (что часто и происходит) моделироваться по-разному в различных ситуациях, и неочевидно, как представлять такие сущности, как аллергия, операция или кровяное давление "прямо из коробки", а для поддержки совместимости нужны шаблоны. В FHIR всё клиническое (и неклиническое) содержимое в сообщении обрабатывается с помощью ссылок на существующие определения ресурсов. Эти ресурсы чётко определяют, как представлять такие общие структуры, как аллергия и кровяное давление "прямо из коробки" и гарантируют, что имеется только один путь представления ключевого содержимого. Однако для совместного использования содержимого в стандарте уже должен быть определён соответствующий подходящий ресурс. Поэтому на первых стадиях разработки FHIR могла возникать необходимость в использовании универсального ресурса Basic, если подходящий стандартный ресурс ещё не был определён.
Шаблоны и профили: При интерпретации значения экземпляров CDA полагается на шаблоны. Хотя смысловое значение, теоретически, можно определить по атрибутам и кодам RIM, в действительности это часто оказывается небезопасным или недостаточным. В отличие от CDA, в FHIR смысл задаётся ресурсом. Профили можно использовать для определения расширений, однако они никогда не уточняют смысл основных элементов. При этом профили, использованные при создании конкретного экземпляра ресурса, можно объявлять в экземпляре с помощью тегов, однако такое объявление не обязательно.
Язык разметки: У CDA свой собственный XML-синтаксис для текстового содержимого, отчасти основывающийся на HTML. FHIR использует ограниченный набор XHTML, несколько более выразительный, чем разметка CDA. Преобразование из FHIR в CDA потребует принимать в расчёт эти ограничения (или, в качестве альтернативы, предоставлять полностью отображаемую версию документа).
Сводное сравнение FHIR с другими стандартами обмена сообщениями HL7
Сравним FHIR с другими стандартами HL7 по таким критериям, как опыт использования, расширяемость и семантика, простота реализации и интеграции, сложность стандарта и наличие его перевода на русский язык, и перспективность.
По опыту использования победителем является HL7 V2, поскольку он давно используется в США и других странах, однако в России мало систем, поддерживающих HL7 V2, что нивелирует это преимущество.
По расширяемости и семантике плюсы у HL7 V3 и FHIR, поскольку они имеют встроенные механизмы описания расширений и ограничений. У HL7 V2 серьёзный минус – костыльные решения в виде Z-сегментов и инициативы LRI (разработка руководства по реализации интерфейса лабораторных результатов, накладывающего дополнительные ограничения поверх стандарта HL7 V2 для обеспечения реального взаимодействия лабораторных информационных систем и МИС).
По простоте реализации и интеграции бесспорным лидером выступает FHIR, поскольку это одна из основных характеристик, заложенных в процесс разработки стандарта и вынесенных в само его название – "быстрые" (ресурсы), а также потому, что вместе со стандартом создан целый арсенал руководств по реализации, инструментов и библиотек, имеются эталонные реализации и тестовые сервера. Самым сложным в реализации оказывается HL7 V3.
По сложности стандарта и перевода, HL7 V3 – явный аутсайдер, поскольку является достаточно глубоким стеком стандартов, и его осмысленное использование требует серьёзной подготовки и обучения. FHIR и HL7 V2 – это отдельные, сравнительно небольшие спецификации, переведённые на русский язык.
Оценивая перспективность стандартов: на данный момент V2 более не разрабатывается, V3 разрабатывается очень долго, а FHIR – быстро, причём пытается сохранить основные успешные концепции HL7 V3, упрощая их по возможности, и активно пропагандируется самой HL7, поэтому является естественным выбором для реализации.
Таблица сравнения стандартов HL7
Заключение
Стандарту FHIR под силу решить все задачи, для решения которых использовались ранние стандарты от HL7 (HL7 v2, HL7 v3 и CDA). В большинстве случаев у FHIR есть дополнительные преимущества, особенно когда речь идет об обеспечении совместимости. Поэтому существует вероятность, что стандарт FHIR постепенно заменит собой некоторые или все стандарты подобного рода. Однако всё ещё неясно, насколько быстро произойдет массовый переход к FHIR. Вероятнее всего, что существующие в настоящий момент стандарты будут применяться параллельно друг с другом. Организация HL7 International приняла решение осуществлять сопровождение существующих стандартов столько времени, сколько потребуется сообществу.
См. также
Приложение: Связь между FHIR и другими стандартами HL7Сравнение с HL7 версии 2
Сравнение с HL7 версии 3
Сравнение с HL7 CDA
О команде:
Health Samurai – команда экспертов в области разработки веб-решений для здравоохранения, работают на рынках США, Европы, России уже более 8 лет.
Health Samurai, в рамках организации HL7 Россия, курируют направление HL7 FHIR: проводят обучение, консультируют и участвуют в реализации российских проектов по информатизации здравоохранения. Health Samurai являются активными участниками международного сообщества по развитию стандарта HL7 FHIR.
Продуктовая линейка Health Samurai:
- Fhirbase (Open Source) – хранилище для медицинских данных на базе HL7 FHIR
- Aidbox – облачная платформа для разработки веб-решений для здравоохранения
- HL7 Mapper – модуль интеграции, преобразования данных HL7 2.x в HL7 FHIR
Сайт: http://health-samurai.io
|
Авторы статьи:
Павлышина Александра 
Имеет 8 летний опыт работы в ИТ-отрасли. Участвовала в создании облачной сертифицированной медицинской информационной системы MedClient, которая внедрена в трёх клиниках в США. Является экспертом HL7 FHIR, занимается официальным переводом стандарта HL7 FHIR на русский язык. |
|
Рыжиков Николай 
Главный архитектор облачной системы aidbox. |
