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-комментарии, команды обработки и форматирования не являются частью содержимого ресурса
  • There SHALL be no DTD references in FHIR resources (because of XXE security exploit )
  • 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.

In addition to the validation schema, this specification provides a set of schemas suitable for code generation. These schemas describe the same XML syntax, but apply less validation to create schemas that work with more code generation tooling.

Specifically, these schemas are generated without any xsd:choice elements, for code generators that don't deal with choices well. Implementers that use these schemas will need to enforce the correct usage of the choice elements without schema support.

Implementers making use of schema driven code generation tooling need to consider how to handle the decimal data type. The decimal data type is defined to be precision aware - that is, that implementers need to preserve the difference between "2.0" and "2.00" - this is ubiquitously considered important in handling observed data in healthcare. Both schemas map this data type to xsd:decimal, but the base W3C schema decimal type is specified not to be precision aware. Schema driven implementations vary as to how precision is handled. Implementers will need to determine how their generated code handles decimals and consider changing the type for decimal in the schema from xsd:decimal to xsd:string. Specifically, implementers may wish to change

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

to this:

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

Alternatively, if supported, implementers may wish to use the precisionDecimal from the XSD 1.1 framework.

Note that most code generation frameworks ignore the pattern restriction.

Resources and/or Bundles may be digitally signed (see Bundle and Provenance).

This specification defines the following method for canonicalizing FHIR resources, when represented as xml:

  • No whitespace other than single spaces in attribute values and in the XHTML in the Narrative
  • Use default namespaces for the FHIR and XHTML namespaces
  • Omit all elements that have a default value, if a default value is defined
  • Omit all comments
  • Always use the unicode character representation for any XML entities (e.g. &#39; instead of &quot;)
  • Include the XML processing instruction <?xml version="1.0" encoding="UTF-8"?>
  • Using the XML canonical method Canonical XML 1.1 (http://www.w3.org/2006/12/xml-c14n11)

This canonicalization method is identified by the URL http://hl7.org/fhir/canonicalization/xml. The following additional canonicalization URLS are also defined:

http://hl7.org/fhir/canonicalization/xml#data The narrative (Resource.text) is omitted prior to signing (note the deletion is at Resource.text, not Resource.text.div)
http://hl7.org/fhir/canonicalization/xml#static In addition to narrative (Resource.text), the Resource.meta element is removed. This makes the signature robust as the content is moved from server to server, or workflow and access tags are added or removed
http://hl7.org/fhir/canonicalization/xml#narrative The method only retains the Resource.id and Narrative (Resource.text
http://hl7.org/fhir/canonicalization/xml#document The signs everything in a Bundle, except for the Bundle.id and Bundle.metadata on the root Bundle (allows for a document to copied from server to server)

These canonicalization methods allow systems the flexibility to sign the various portions of the resource that matter for the workflow the signature serves.

Note: One consequence of signing the document is that URLs, identifiers and internal references are frozen and cannot be changed. This might be a desired feature, but it may also cripple interoperability between closed ecosystems where re-identification frequently occurs. For this reason, it is recommended that systems consider carefully the impact of any signature processes. The impact of signatures on Document bundles and their related processes is the most well understood use of digital signatures.