Current Build

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

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

HL7 v3 должен был стать следующим поколением стандартов обмена сообщениями HL7. В нём была введена Эталонная информационная модель (RIM), модель типов данных и ряд словарей наряду с формальной методология развития стандартов. Кроме того, он ввёл в использование "документы" в качестве альтернативы архитектуре обмена сообщениями для совместного использования медицинской информации (см. сравнение с CDA). Хотя формально стандарт охватывает и то, и другое, термин "v3" обычно используют для ссылки на именно на обмен сообщениями v3. Типы данных, лежащие в основе v3, были утверждены ИСО в качестве стандарта ISO 21090. HL7 RIM также была утверждена в качестве стандарта ИСО.

Обмен сообщениями v3 был использован в некотором количестве крупных проектов, в частности в области электронных медицинских карт, хотя и не получил такого распространения, как HL7 v2 . HL7 RIM и типы данных из ISO 21090 также использовались другими проектами организациями, разрабатывающими стандарты, которые не полностью использовали методологию HL7 v3. Многие комментарии и руководства, приведённые здесь, также применимы и к этим решениям.

Эталонная модель: Использование HL7 RIM - основа методологии HL7 v3, это важнейшая часть спецификации и проводного формата. Все элементы данных в экземплярах HL7 v3 выведены либо из RIM, либо из типов данных ИСО. В FHIR это справедливо для большинства элементов ресурсов и типов данных, но не для всех. Некоторые ресурсы (StructureDefinition, CapabilityStatement, ValueSet и др.) имеют дело с содержимым, находящимся вне области действия RIM. Также в некоторых случаях были внесены исправления в типы данных FHIR, которые ещё не поддержаны в модели типов данных HL7 v3. Ожидается, что эти изменения будут поддержаны в следующей версии модели типов данных v3. Основное отличие состоит в том, что формат сериализации FHIR достигается не за счёт установления соответствия с RIM. В результате получаются значительно более лаконичные и интуитивно понятные экземпляры. Можно реализовать FHIR, абсолютно не зная HL7 RIM.

Коды: v3 в значительной степени полагается на закодированные атрибуты при передаче смыслового значения экземпляров. Например classCode, moodCode, determinerCode. Разрешённые коды для этих атрибутов строго контролируются HL7. В FHIR также имеются атрибуты, возможные значения которых ограничены теми кодами, что определены в спецификации FHIR - те, что используют тип данных code. Впрочем, в основном это атрибуты, передающие рабочие значения - статус, тип контактных данных и т. п.

И FHIR, и v3 используют наборы значений для определения кодов, которые можно использовать в атрибутах в определённом контексте. Однако в FHIR набор значений ValueSet - это всего лишь один из типов ресурсов, что означает, что его можно пересылать как любой другой фрагмент данных. (То же самое верно и для StructureDefinition, CapabilityStatement и других ресурсов метауровня.)

Степень детализации и ссылки: модели HL7 v3 разбиты на 3 основных типа - обёртки, полезная нагрузка и общие типы элементов сообщений (CMET). Они комбинируются для определения содержимого, которое можно отправить по проводам за один раз. В некоторых случаях степень детализации каждой их этих моделей будет равняться степени детализации FHIR-ресурсов, но не всегда. Модели v3 подразделяются на основе ожидания их повторного использования. Модели FHIR подразделяются на основе автономности объектов, которые они представляют. В HL7 v3 многочисленные модели могут существовать для представления одной и той же существенной лежащей в основе медицинской информации конструкции. Например на уровне HL7 International есть 10 различных общих типов элементов сообщений для понятия "Пациент". Кроме того, некоторые модели из группы полезной нагрузки представляют пациента напрямую, без использования этих элементов. Дальнейшие вариации моделей v3 создаются филиалами HL7 и другими реализаторами v3. Каждый из этих различных элементов имеет свою собственную схему и может использовать различные имена элементов, различные уровни вложенности и различные ограничивающие условия. В FHIR же есть только один ресурс Patient. Для этого ресурса можно создать множество профилей, однако все они будут использовать одну и ту же схему и поддерживать один и тот же формат сериализации.

Проектирование через ограничивающие условия: Методология проектирования в v3 - это проектирование через ограничивающие условия. Идея в том, что в HL7 RIM представлены все данные, необходимые для любого вида медицинского взаимодействия. Все остальные модели данных просто отсекают от RIM лишнее, чтобы соответствовать требованиям определённой доменной области. Этот процесс начинается на международном уровне и дальше уточняется уже в отдельных странах, проектах и, наконец, конкретных реализациях. Чем ближе модели к реализаторам, тем они менее абстрактные. Поэтому модели v3 чрезвычайно широкие по своему охвату и возможностям и слегка абстрактные. Это необходимо для гарантии получения всех возможных вариантов реализации в области, покрываемой этой моделью, посредством ограничивающих условий. Также каждая модель имеет свою собственную схему и, в большинстве случаев, схемы с ограничивающими условиями не являются строго совместимыми со схемами ограничиваемой модели.

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

Context conduction: При передаче медицинской информации между людьми, многие данные вытекают из контекста. Например, если у отчёта есть автор, указанный на титульной странице, обычно подразумевается, что все утверждения в этом отчёте сделаны этим человеком. Такие умозаключения становятся проблематичными, когда возникает необходимость анализировать данные с помощью компьютеров, будь то запрос, поддержка принятия решений или другой анализ. К настоящему времени методология HL7 v3 обеспечивает три различных механизма, позволяющих задавать в моделях данных, как контекст должен распространяться на модели, делая явным для компьютеров то, что люди обычно понимают интуитивно. FHIR избрал другой путь. В FHIR контекст отсутствует - всё задаётся явным образом. Если отчёт о пациенте содержит 100 данных наблюдений, относящихся к одному и тому же пациенту, то каждое наблюдение будет содержать ссылку на этого пациента. Однако это относительно безболезненно, поскольку это всего лишь ссылки - идентификатор и, возможно, коротенькое значение для отображения. Одним из преимуществ такого подхода является то, что каждый ресурс может быть безопасно использован и рассмотрен без беспокойства о контексте, в котором он был передан. Значение каждого экземпляра ресурса полностью самодостаточно.

Null flavors: В здравоохранении часто бывает, что данные неизвестны, недоступны, имеют исключительное значение или каким-то ещё образом выпадают из границ "нормальных" значений. Для работы с такими случаями v3 ввёл понятие "null flavor" для почти каждого атрибута и свойства типа данных в своих моделях. Эти закодированные null flavors можно пересылать вместо или в дополнение к данным, которые обычно заполняются для атрибута, связи или свойства типа данных. Примерами могут быть такие понятия, как "Неизвестно", "Не спросили", "Положительная бесконечность", "Ничтожное количество", "Замаскировано" (по причине безопасности или конфиденциальности, например), "Другое" и т. п. Если только элемент не был явно помечен как "обязательный", что означает, что для него не разрешены null flavors - эти null flavors могли появиться в любом месте.

FHIR подходит к этой проблеме по-другому. Null flavors вводятся только в основной спецификации в обстоятельствах, где предполагается, что они понадобятся большинству систем. Там, где это необходимо, flavors ограничены теми значениями, которые подходят данному элементу.

Использование отображения на RIM: Многие элементы ресурсов и свойства типов данных содержат мэппинги с RIM. Эти мэппинги служат для двух целей. Они помогают определить семантику FHIR в терминах эталонных моделей HL7, помогая убедиться, что Рабочие группы, которые определяют элементы данных, имеют хорошее и непротиворечивое понимание смыслового значения каждого элемента. Также они предоставляют руководства для реализаторов спецификаций v3, которые, возможно, ищут способ перейти с или установить соответствия между v3 и FHIR. Однако для последней цели важно понимать некоторые ограничения, наложенные на мэппинги с RIM. RIM - это язык, который позволяет передавать одно "понятие" несколькими различными способами с разной степенью детализации и выразительности. Так вполне возможно, что элемент RIM соответствует основному FHIR-элементу, даже хотя его RIM-представление несколько отличается о описанного в этом мэппинге. Кроме того, не все модели v3 придерживаются наилучших практик моделирования, поэтому некоторые элементы данных, которые могут появляться в мэппинге с FHIR-элементами, могут не соответствовать, если информация не была хорошо представлена. Поэтому мэппинги с RIM следует принимать за руководство, а не абсолют, и устанавливать соответствия следует в контексте спецификации v3, с которой выполняется мэппинг. (Также см. Абстрактные модели ниже.)

Расширения в v3: Хотя основой методологии v3 является "проектирование через ограничивающие условия", в ней предусмотрено использование расширений - либо во внешнем пространстве имён, либо помеченных специальным атрибутом. Во время преобразования из v3 и FHIR придётся учитывать использование подобных расшрений. Как правило, для большинства расширений v3 можно установить соответствие с расширениями FHIR, поскольку принцип v3 "проектируй через ограничения" предполагает, что всё, что считается "основой" в FHIR, уже было частью базовой спецификации v3.

Абстрактные модели:Как было замечено выше, большинство моделей v3, созданных на уровне HL7 International, полностью абстрактные. В результате этого модели можно использовать для выражения самых разнообразных понятий, часто в широком разнообразии различных способов. Это сильно усложняет определение соответствия между теми спецификациями и FHIR (или любой другой спецификацией). Для практической совместимости v3 <-> FHIR мэппинги необходимо создавать на уровне спецификаций обмена сообщениями, руководств по реализации и/или шаблоной, которые являются более конкретными и ближе к уровню реализации. Например отображение всей CDA на FHIR было бы невозможно, учитывая выразительные возможности в правой стороне модели CDA. Однако отображение шаблонов Консолидированной CDA (CCDA) на FHIR вполне возможно.

Использование контекста: Как было упомянуто выше, модели HL7 v3 полагаются на контекст - управляемый явным или неявным образом. Выполняя преобразование в FHIR, этот контекст придётся передавать в каждый ресурс.

Режим обновления: Для экземпляров HL7 v3 обновления обычно обрабатываются в режиме моментального снимка, похожено на подход в FHIR - если какая-то информация меняется, отправляется вся запись, включая изменённые элементы данных. Однако методология v3 не поддерживает введение свойства "updateMode", которое позволило бы отправлять только изменения для всего или части экземпляра. Каждое повторение элемента помечается свойством updateMode для указания, что с этим элементом необходимо сделать: добавить, удалить, обновить и т. п. Другие значения свойства updateMode дают дополнительный контроль над обновлениями. Как и для V2 выше, реализаторам потребуется сгенерировать полный снимок каждого ресурса or consider using the Patch Operation instead.

Дополнительные соображения: Большинство соображений по реализации соответствия между FHIR и HL7 v2 , также верны и для v3. В частности: Расширения, Независимые и вложенные ресурсы, Идентификация ресурсов, Объединение ссылок и ресурсов и Генерация человекочитаемого содержимого.