Current Build

Переводит команда Health Samurai . Приглашаем поучаствовать в русификации стандарта FHIR: GitHub , Email.

FHIR Infrastructure Work GroupMaturity Level: N/ABallot Status: Informative

HL7 v2 был первым стандартом обмена информацией, разработанным HL7, и является одним из наиболее широко применяемых, известный в стационарном обслуживании по всему миру, хотя также применяется и в большом разнообразии других контекстов. HL7 v2 использует сообщения, составленные из пригодных к повторному употреблению сегментов для передачи информации, относящейся к здравоохранению, между отправляющей и получающей системами, а также вызов определенного поведения (перевод пациентов, лабораторные ордера и т. д.). Он также поддерживает одностороннюю передачу с помощью уведомлений, обеспечивает поддержку запросов и другие рабочие процессы.

Основанный на событиях: FHIR поддерживает парадигму обмена сообщениями на основе событий, аналогичную структуре обмена сообщениями в HL7 v2 (хотя в отличие от HL7 v2, FHIR поддерживает и другие парадигмы, включая документы, REST и другие модели обслуживания). См. ресурс Message Header.

Гранулярность (неравномерность): Структура HL7 v2, состоящая из "сегментов", предлагает повторно используемые порции данных, которые примерно соответствуют идее ресурсов FHIR. Тем не менее, сегменты HL7 v2 нельзя обрабатывать независимо друг от друга. Кроме того, не у всех сегментов есть характеристики независимой сущности, что присуще ресурсам FHIR. Из-за различий в области действия и подходе к расширяемости, сегменты и типы данных HL7 v2 часто загромождены элементами данных, которые не используются (и даже не распознаются) большинством реализаций.

Сегменты можно компоновать в повторяющиеся и/или необязательные коллекции, называемые "группами" для отражения полных бизнес-объектов здравоохранения. Например, компонент "Order" сообщения OMP (Pharmacy/Treatment Order Message) состоит из:

  • сегмента ORC, предназначенного для аспектов рабочего процесса ордера
  • сегмента RXO, предназначенного для аспектов ордера, связанных с аптеками
  • необязательных сегментов TQ1 и TQ2, описывающих распределение ордера по срокам
  • необязательных сегментов NTE, предназначенных для дополнительных заметок или отображения ордера
  • необязательных сегментов RXR, описывающих информацию о способе применения
  • и т.д.

Подход к степени детализации, используемый в HL7 v2, придаёт особое значение повторному использованию "шаблонов" информации. Например распределение по срокам и информация о способе применения будут бесполезны сами по себе, однако нужны во многих обстоятельствах. Из-за трехуровнего ограничения вложенности отдельные сегменты также требуются для структур данных, которые в противном случае имели бы слишком глубокую вложенность. У FHIR другой подход к повторному применению, направленный на объекты, которые можно поддерживать независимо. Ресурс MedicationRequest охватывает все аспекты приведенных выше сегментов, за исключением некоторых аспектов рабочего процесса ORC, которые регулируются ресурсом Task. Ресурс MedicationRequest сам по себе является комплексным, содержащим вложенные структуры для указаний по дозировке, инструкций по выдаче и т. п., которые не являются простыми типами данных.

Расширяемость: HL7 v2 предоставляет механизм расширений с помощью использования "Z-сегментов". Значение этих сегментов непрозрачно без предварительного ручного объяснения от отправителя. Предполагается, что расширения будут ограничены элементами данных, которые не влияют на смысл "стандартных" сегментов. С другой стороны, в FHIR Расширения могут появляться на любом уровне (включая типы данных). ModifierExtensions могут использоваться в обстоятельствах, когда расширение может менять смысл других элементов (например введение в запись индикатора отрицания). Наконец, значение расширений FHIR обнаруживается разрешением URI, который определяет расширение. Такой подход с URI также гарантирует, что расширения, созданные независимыми системами, не будут конфликтовать. (Что может быть проблемой для Z-сегментов.)

Межверсионная совместимость: HL7 version 2 имеет строгие процессы поддержки прямой и обратной совместимости. Содержимое может добавляться только в конец существующих полей, компонентов и т. п. Ожидается, что приложения будут игнорировать неожиданное содержимое или повторы. FHIR сулит аналогичные правила совместимости. Путь к элементу в FHIR-экземпляре остается неизменным в следующих версиях. Особые правила обработки "новых" элементов (игнорирование, проверка на наличие индикаторов "must understand" и т. п.) будут разработаны в течение периода STU.

Удобочитаемость для человека: In general, экземпляры HL7 v2 не предлагают людям удобочитаемые версии обмениваемого содержимого. В то время как некоторые системы могут применять NTE-сегменты для передачи человекочитаемого отображения всего или части полезной нагрузки сообщения, правила, когда и при каких условиях это происходит, зависят от конкретного сайта. FHIR требует предоставления человекочитаемого содержимого для каждого ресурса.

Механизм обновления : Данными HL7 v2 обычно обмениваются в режиме "снапшота" - обновления передаются отправкой полной копии экземпляра, заполненного новыми данными. Однако некоторые сегменты и сообщения в HL7 v2 поддерживают более сложный обмен, когда только измененные данные отправляются и коды или особые значения указывают, какой тип изменений должен произойти (например добавить этот адрес, удалить это имя). FHIR "из коробки" функционирует только в режиме "снапшота". Хотя для введения эквивалентного HL7 v2 поведения и возможно применение ModifierExtensions, это привело бы к возникновению проблем совместимости и затруднило бы использование ресурсов вне парадигмы обмена сообщениями.

Необязательность элементов и профили: И HL7 v2, и FHIR обеспечивают одинаковую степень гибкости на уровне международного стандарта. Большинство элементов данных являются необязательными. Однако имеется и два различия. FHIR-ресурсы намного более ограничены в терминах того, какие элементы включены в основную спецификацию - только те элементы, которые будут поддерживать большинство систем. HL7 v2 стремится включить много элементов, которые применяются только в очень ограниченных обстоятельствах, для которых FHIR применяет расширения. И HL7 v2, и FHIR предлагают формальные механизмы для определения профилей, давая рекомендации по применению спецификации. Однако механизм HL7 v2 не широко используется. FHIR-профили образуют существенный компонент методологии и встроены в инструментарий, что увеличивает вероятность их использования.

Установление соответствия (мэппинг) : Одна из самых больших проблем с совместимостью HL7 v2 - это различия в реализациях. Даже когда идентичные сценарии обрабатываются в аналогичных бизнес-средах, поддерживаемые элементы данных могут различаться и даже место, где данные элемент данных расположение в экземпляре может меняться. В итоге задание непротиворечивых правил мэппинга между HL7 v2 и FHIR на международном или даже на региональном уровне не является реалистичным. Предлагаемые FHIR мэппинги дают начальную точку для рассмотрения, однако мэппинги потребуется выполнять для каждой реализации.

Расширения:Хотя некоторые HL7 v2 элементы хорошо ложатся на основные элементы FHIR, большой процент элементов - нет. Если HL7 v2-элемент не поддержан ядром, потребуется расширение для совместного использования информации. При проявлении заинтересованности HL7 может опубликовать и поддерживать расширения для HL7 v2-элементов, которые не поддержаны ядром спецификации FHIR. Перед созданием локальных расширений следует проверить реестр расширений FHIR . Если позволяет время, следует связаться с ответственной рабочей группой HL7 с запросом на определение дополнительных расширений HL7 v2, если требуемые отсутствуют. Если времени нет, приложения могут задавать свои собственные расширения, но должны иметь план миграции для если/когда HL7 определит их позже. Для Z-сегментов URIs должны быть определены, чтобы различаться для системы/среды, которая задала этот Z-сегмент (например http://acme.org/fhir/extensions/consent), не на основе имени самого Z-сегмента (при условии, что могут существовать Z-сегменты с одинаковыми именами, но разными значениями) (например http://hl7.org/ZAC).

Идентификация ресурсов:Сообщения HL7 v2 будут часто ссылаться на объекты, на которые уже давались ссылки в предыдущих сообщениях. При конвертации сообщений в FHIR, эти ссылки будет необходимо направить на тот же URI ресурса. При условии, что не все объекты сообщений HL7 v2 имеют идентификаторы в сообщении, это может быть проблематично. В FHIR имеется подход для решения этой проблемы - транзакции. Однако пока еще не решен вопрос разветвлений использования этого подхода в среде обмена сообщениями. Реализаторам потребуется исследовать свои собственные стратегии в рамках ранней адаптации.

Объединение ссылок и ресурсов : Сообщения HL7 v2 могут успешно ссылаться на один и тот же "объект" множество раз. Например сообщение, содержащее медицинскую историю болезни пациента, вероятно, будет многократно ссылаться на одних и тех же медицинских работников и клиники/больницы. При этом в некоторых случаях данные, сохранённые для данного объекта, могут быть одинаковыми для всех случаев применения, в других случаях информация может варьироваться. Например система-отправитель может передавать архивные номера телефонов из старых записей и текущие номера телефонов для более новых записей. В качестве альтернативы, структура сообщерия может позволять выражать различное количество деталей в различных частях сообщения или приложение-отправитель может просто быть запрограммировано передавать различное количество деталей в различных частях сообщения (например ередача номера телефона для заказывающего мед. работника, но не для вводящего данные мед. работника). При конвертации в FHIR-ресурсы, все ссылки на один и тот же "объект" будут, как правило, иметь одинаковый идентификатор ресурса и упоминаться в экземпляре только один раз - с полным набором необходимой/доступной информации. Это создаёт две проблемы:

  1. Как программа-конвертор узнает, когда две части сообщения ссылаются на один и тот же объект? Если некоторые ссылки могут иметь уникальные идентификаторы или имена, которых достаточно для подтверждения, что это один и тот же объект, другие могут их не иметь - хотя может быть достаточно и некоторой другой комбинации атрибутов. Реализаторам потребуется задать особые правила преобразования
  2. Если присутствуют несколько версий данных, какие данные следует использовать - или следует отправлять несколько версий с различными архивными идентификаторами? (И если последнее, каким должен быть порядок версий? Если порядок версий можно определить по данным в сообщении (например предположить, что в более ранних датах заказа хранится более старая демографическая информация), можно указать эти даты в элементе updated для указания относительного упорядочивания. Если порядок невозможно определить, будет трудно объединить данные в один ресурс или представить его в помощью нескольких ресурсов.

Идентифицированные и вложенные ресурсы: Для каждого сообщения HL7 v2 будет установлено соответствие с несколькими экземплярами ресурсов - часто десятками или даже сотнями экземпляров ресурсов. Чтобы продолжить следовать парадигме обмена сообщениями HL7 v2, все данные ресурсов будут, как правило, передаваться по проводам в составе FHIR-сообщения, а не с помощью ссылки, что характерно для RESTful реализации. Однако FHIR предлагает два способа передачи ресурсов в виде связки (бандла): их можно отправлять либо как полностью идентифицированные ресурсы (записи в бандле со своими собственными идентификаторами, которые могут участвовать в независимых транзакциях), либо их можно отправлять в виде вложенных ресурсов, что означает, что они идентифицируются только относительно другого ресурса, и их нельзя извлекать или другим образом ими манипулировать самими по себе. В процессе преобразования HL7 v2 в FHIR потребуется определить, какие элементы данных имеются или должны присутствовать для полной идентификации ресурса. В некоторых случаях это будет определяться во время мэппинга. В других случаях это будет зависеть от контекста использования конкретного экземпляра. Например поле XCN, содержащее только имя (|^Смит^Джон|), содержит недостаточно информации, чтобы отличить этого врача от любого другого Джона Смита, и поэтому должно быть вложенным ресурсом, тогда как поле XCN со значением |12345^Смит^Джон| содержит достаточно информации, хотя процесс преобразования потребует осознать область действия этого идентификатора и связанные с ним процессы управления.

Генерация человекочитаемого содержимого: FHIR требует, чтобы каждый ресурс содержал человекочитаемую описательную часть, которая содержит всю информацию, значимую для принятия решения человеком. При конвертации из HL7 v2, разработчики (вероятно по указанию врачей) потребуется определить, какая информация из сообещния должна отображаться и каким образом генерировать это содержимое.

Отсутствие информации и режимы обновления:В HL7 v2 коды "действия" могут определить, определённые сегменты содержать информацию для добавления, обновления или удаления. ПОля могут быть заполнены "нулями" (две последовательных двойных кавычки без других символов) для обозначения поля, подлежащего удалению. Опущенный элемент или повторение интерпретируются, как правило, как "оставить существующие данные неизменёнными". Это противоположно FHIR-подходу, требующему присутствия всех данных в виде снапшота. Системам потребуется либо логика для генерации полного снимка каждого ресурса или consider using the Patch Operation instead.