FHIR Release 3 (STU)

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

Implementable Technology Specifications Рабочая группаУровень зрелости: 5Статус голосования: Пробное использование

XML-представление ресурса имеет такой формат:

 <name xmlns="http://hl7.org/fhir" (attrA="value")>   doco
   <nameA><!-- ?? 1..1 type description of content  --><nameA>
   <nameB[x]><!-- 0..1 type1|type1 description  --></nameB>
   <nameC> <!--  1..* -->
     <nameD><!-- 1..1 type>Relevant elements  --></nameD>
   </nameC>
 <name>

Правила этого формата:

  • Для создания допустимого XML-экземпляра ресурса просто замените содержимое элементов и атрибутов допустимыми значениями в соответствии с кардинальным множеством, типовыми правилами и комментариями к каждому элементу
  • Имена ресурсов и элементов являются регистрозависимыми (тем не менее дубликаты, различающиеся только регистром, никогда не вводились)
  • Элементы должны всегда появляться в том порядке, в котором они описаны
  • Когда повторение элемента разрешено, элементы упорядочены, и техническая инфраструктура должна иметь возможность доступа к элементам в правильном порядке (см. также раздел Cardinality Rules с описанием элементов с кардинальным множеством > 1)
  • Некоторые свойства представлены в виде атрибутов: значения примитивных типов в атрибуте value, URL-адреса расширений в атрибуте url в расширениях, и свойство id в элементах (но не в ресурсах, где идентификатор ресурса - это элемент)
  • Любой из XML-элементов может иметь атрибут "id", служащий в качестве цели внутренней ссылки. Атрибут "id" не показывается в этом формате
  • FHIR-элементы всегда принадлежат пространству имен http://hl7.org/fhir . Обычно оно указывается в корневом элементе в качестве пространства имен по умолчанию. В FHIR-ресурсах может встретиться ещё только одно пространство имен - XHTML (XHTML встречается в большинстве ресурсов)
  • Инфраструктурные элементы, являющиеся общими для всех ресурсов, не приводятся в этом XML-представлении. Они должны появляться до любых других заданных элементов-потомков в следующем порядке:
  • FHIR-элементы не бывают пустыми. Если элемент присутствует в ресурсе, он ОБЯЗАН иметь либо атрибут value, либо элементы-потомки, определенные для его типа, либо 1 или больше расширений
  • Атрибуты не могут быть пустыми. Либо они отсутствуют, либо присутствуют с по крайней мере одним символом не пробельного содержимого
  • Реализаторы ДОЛЖНЫ обрезать начальные и конечные пробелы перед операцией записи и ДОЛЖНЫ обрезать начальные и конечные пробелы при чтении значений атрибутов
  • Иконка замочка (??) означает, что элемент вводит или зависит от дополнительных правил, которые регулируют его присутствие и/или содержимое
  • XML-комментарии, команды обработки и форматирования не являются частью содержимого ресурса
  • В FHIR-ресурсах не должно быть ссылок на DTD (из-за злоупотребления дыры в безопасности XXE )
  • XML-ресурсы должны обмениваться в кодировке UTF-8. Указание схемы кодирования символов с помощью команды обработки <?xml encoding="UTF-8" ?> не обязательно, но рекомендуется
  • Другие команды обработки НЕ ДОЛЖНЫ быть включены и НЕ ДОЛЖНЫ требоваться в целях правильного понимания и/или представления данных ресурса или его описательной части. Приложения МОГУТ сохранять команды обработки при оперировании ресурсами, но это не является обязательным
  • MIME-тип для этого формата - application/fhir+xml.

В спецификации есть XML-схемы для всех моделей содержимого, которые она описывает.

Базовая XML-схема называется "fhir-base.xsd", она описывает все типы данных и базовые инфраструктурные типы. Кроме того, есть схема для каждого ресурса и общая схема fhir-all.xsd, которая включает в себя схемы всех ресурсов. Для процессоров схем, которые не поддерживают циклические включения, есть единая схема, которая содержит в себе всё.

В дополнение к файлам w3c-схемы, данная спецификация также приводит Schematron-файлы, которые вводят в действие различные ограничения, определенные для типов данных и ресурсов. Они укомплектованы в файлы для каждого ресурса.

Обмениваемый XML ДОЛЖЕН быть проверен на соответствие w3c-схеме и Schematron, хотя соответствие схеме и Schematron не является достаточным условием, чтобы являться совместимым экземпляром: данная спецификация вводит несколько правил, которые не могут быть проверены никакими механизмами. Операционные системы могут использовать инструменты схемы для проверки валидации, но не обязаны это делать. Обмениваемое содержимое НЕ ДОЛЖНО задавать схему или даже просто содержать пространство имен экземпляра схемы в самом ресурсе.

Учитывая то, как работают расширения, приложения, читающие XML-ресурсы, никогда не встретят неизвестные элементы. Однако как только приложение начнёт работать с другими приложениями, которые соответствуют последним версиям данной спецификации, могут начать встречаться неизвестные XML-элементы. Приложения МОГУТ выбирать, игнорировать неизвестные элементы, чтобы благоприятствовать будущей совместимости в этом отношении, однако могут также выбрать не делать этого - что будет нормальным поведением для приложений, сгенерированных из схемы. Приложения объявляют свою модель поведения относительно неизвестных элементов с помощью элемента CapabilityStatement.acceptUnknown.

Кроме схемы для валидации, в спецификации есть набор схем для кодогенерации. Эти схемы описывают тот же самый синтаксис XML, однако накладывают менее строгие правила валидации для создания схем, которые работают с большим количеством средств кодогенерации.

В частности, эти схемы генерируются без элементов xsd:choice для кодогенераторов, которые не работают с ними. Реализаторам, которые используют эти схемы, нужно будет следить за корректным использованием элементов с выбором типа данных без помощи схемы.

Реализаторам, использующим инструменты кодогенерации на основе схем, нужно будет подумать, как они будут обрабатывать тип данных decimal. Десятичный тип данных определён для сохранения значений с некоторой точностью - то есть это то, что нужно реализаторам, чтобы сохранить разницу между значениями "2.0" и "2.00" - это повсеместно считается важным при работе с данными наблюдений в здравоохранении. Обе схемы мапят этот тип данных на xsd:decimal, однако базовая W3C-схема для десятичного типа не предназначена для указания точности. Реализации на основе схем различаются по работе с точностью. Реализаторам нужно будет определить, как их сгененированный код обрабатывает десятичные числа и рассмотреть изменение этого типа на десятичный в схеме с xsd:decimal на xsd:string. В особенности, реализаторам может понадобиться заменить:

  <xs:simpleType name="decimal-primitive">
    <xs:restriction base="xs:decimal">
      <xs:pattern value="-?([0]|([1-9][0-9]*))(\.[0-9]+)?"/>
    </xs:restriction>
  </xs:simpleType>

на:

  <xs:simpleType name="decimal-primitive">
    <xs:restriction base="xs:string">
      <xs:pattern value="-?([0]|([1-9][0-9]*))(\.[0-9]+)?"/>
    </xs:restriction>
  </xs:simpleType>

В качестве альтернативы, если поддержан, реализаторы могут выбрать использование precisionDecimal из фрейвморка XSD 1.1.

Отметьте, что большинство фрейвморков кодогенерации игнорируют ограничение по шаблону.

Ресурсы и/или бандлы можно подписывать электронной цифровой подписью (см. Bundle и Provenance).

Спецификация задаёт следующий метод канонизации FHIR-ресурсов, представленных в формате XML:

  • Отсутствие пробелов кроме одиночных пробелов в значениях атрибутов и в XHTML в Нарративе
  • Использовать дефолтные пространства имён для FHIR и XHTML
  • Не включать элементы, имеющие дефолтное значение, если дефолтное значение определено
  • Не включать никакие комментарии
  • Всегда использовать кодировку UNICODE для всех XML-сущностей (например &#39; вместо &quot;)
  • Включать инструкцию обработки XML <?xml version="1.0" encoding="UTF-8"?>
  • Использовать каноничный метод XML Canonical XML 1.1 (http://www.w3.org/2006/12/xml-c14n11)

Этот метод канонизации идентифицируется по URL-адресу http://hl7.org/fhir/canonicalization/xml. Также заданы следующие дополнительные URL-адреса канонизации:

http://hl7.org/fhir/canonicalization/xml#data Нарратив (Resource.text) убран до подписания (отметьте, что удалить нужно Resource.text, а не Resource.text.div)
http://hl7.org/fhir/canonicalization/xml#static Кроме нарратива (Resource.text) также нужно удалить элемент Resource.meta. Это сделает подпись более надёжной при перемещении контента с сервера на сервер или добавлении и удалении тегов доступа и рабочего процесса.
http://hl7.org/fhir/canonicalization/xml#narrative В этом методе остаётся только Resource.id и нарратив (Resource.text)
http://hl7.org/fhir/canonicalization/xml#document Здесь подписывается всё в бандле кроме Bundle.id и Bundle.metadata корневого бандла (позволяет копировать документ с сервера на сервер)

Эти методы канонизации дают системам гибкость в подписании различных частей ресурса, которые имеют значение для рабочего процесса, в котором используется подпись.

Примечание: вследствие подписания документа URL-адреса, идентификаторы и внутренние ссылки замораживаются и не могут быть изменены. Это может быть желаемым следствием, однако оно нарушает возможность взаимодействия между закрытыми экосистемами, где часто происходит re-identification. По этой причине рекомендуется, чтобы системы тщательно рассматривали каждый процесс подписания. Влияние подписей на бандлы-документы и их связанные процессы - это лучше всего понятое использование электронных цифровых подписей.