Current Build

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

2.6.0 Форматы представления ресурсов

FHIR Infrastructure Work GroupMaturity Level: 5Ballot Status: Normative

Normative Candidate Note: This page is candidate normative content for R4 in the Infrastructure Package. Once normative, it will lose it's Maturity Level, and breaking changes will no longer be made.

На этой странице задокументировано, каким образом описываются ресурсы. В реальности ресурсы могут быть представлены в следующих форматах: XML, JSON и Turtle. Дополнительно исследуются Форматы больших объемов данных. Другие форматы представления также допустимы, но не описаны в рамках данной спецификации (см. линк ниже).

Ресурсы описываются несколькими различными способами: The resources are described in several different ways:

  • иерархической таблицей, представляющей собой логическое представление содержимого
  • UML-диаграммой, содержащей графическое краткое изложение содержимого
  • с помощью XML-псевдосинтаксиса, дающего визуальное представление о том, как конечные экземпляры ресурса будут выглядеть в формате XML
  • с помощью JSON-псевдосинтаксиса, дающего визуальное представление о том, как конечные экземпляры ресурса будут выглядеть в формате JSON
  • a pseudo-Turtle syntax that provides a visual sense of what the end resource instances will look like in Turtle

В дополнение к этому наглядному синтаксису доступны и другие формы определений, включая W3C-схему и Schematron, а также StructureDefinition-синтаксис, определенный внутри. In addition to this descriptive syntax, other definitional forms are available, including W3C schema and Schematron, and the StructureDefinition syntax defined internally.

Логическое представление показывает ресурсы в виде дерева со следующими столбцами: The Logical View shows the resources as a tree structure with the following columns:

Столбец Содержимое
Имя Имя элемента в ресурсе (декларируется как имя XML-элемента либо имя JSON-свойства). Некоторые имена заканчиваются на [x] - значение этого обсуждается ниже. Дополнительно этот столбец содержит иконку, которая указывает на лежащий в основе тип содержимого. Описание иконок приводится ниже
Флаги Набор информации об элементе, которая влияет на его обработку. Описание флагов приводится ниже
Кард. число кардинальное число: нижняя и верхняя границы того, сколько раз элемент может появиться в ресурсе Cardinality: the lower and upper bounds on how many times this element is allowed to appear in the resource
Тип Тип элемента (связан гиперссылкой с определением этого типа). Отметьте, что тип элемента имеет одно из двух значений в зависимости от того, есть ли у этого элемента потомки. Если у элемента есть потомки, тогда это элемент анонимного типа, специализирующий данный тип. Если элемент не имеет потомков, тогда у этого элемента есть свойства и потомки, как указано в названном типе The type of the element (hyperlinked to the definition of the type). Note that the type of the element has one of two meanings, depending on whether the element has defined children. If the element has children, then the element has an anonymous type that specializes the given type. If the element has no children, then the element has properties and children as specified by the nominated type
Описание и ограничения Описание элемента и информация о применяемых к нему ограничениях. В частности, для кодированных элементов - информация о том, какие коды можно использовать A description of the element, and details about constraints that are applied to it. Particularly, for coded elements, information about which codes can be used. The description comes from ElementDefinition.short

Пример:

Name Flags Card. Type Description & Constraints
.. Resource Name Base Type Определение
... nameA Σ 1..1 TypeA Описание содержимого
... nameB[x] ?! Σ 0..1 Описание
должно содержать хотя бы значение
.... nameBType1 0..1 TypeB
.... nameBType2 I 0..1 typeC
... nameC 1..* Element Определение
.... nameD 1..1 TypeD Релевантные записи

Ключи к иконкам и флагам

  • .: Базовый элемент ресурса (см. Resources)
  • .: Элемент, являющийся частью ресурса и содержащий другие элементы, определенные в этом же ресурсе или профиле
  • .: Элемент, который может иметь один из нескольких типов (см. ниже)
  • .: Элемент типа данных, который описывает элемент, который имеет атрибут/свойство value. These are also known as primitive types. All primitive type names start with a lower case letter
  • .: Элемент типа данных, который описывает элемент, который содержит другие элементы. These are known as complex types. All complex type names defined in this specification start with an uppwer case letter
  • .: Элемент, который содержит ссылку на другой ресурс (см. references)
  • .: Этот элемент имеет такое же содержимое, что и другой элемент, описанный в этом ресурсе или профиле
  • .: Введение множества срезов (Introduction of a set of slices) (см. Slicing)
  • .: Расширение (см. Extensibility)
  • .: Составное расширение - с вложенными расширениями (см. Extensibility)
  • .: Расширение, имеющее элемент value и не содержащее вложенных расширений (см. Extensibility)
  • .: A complex modifier extension - one with nested extensions (see Extensibility)
  • .: A modifier extension that has a value and no nested extensions (see Extensibility)
  • .: Корневой элемент логического профиля
  • ?!: Это элемент-модификатор - см. Modifier Elements
  • S: Это элемент, который должен быть поддержан обязательно - см. Must-Support Elements
  • Σ: Это элемент, входящий в сокращенный вариант - см. Summary Searches
  • I: Этот элемент вводит ограничения или зависит от них - см. Constraints
  • NE: Этот элемент не может иметь расширений (только для некоторых элементов инфраструктуры)
  • TU: This element has a standards status of Trial Use (for discussion about mixing ballot status in a resource, see Mixed Normative content)
  • N: This element has a standards status of Normative
  • D: This element has a standards status of Draft

Примечания:

  • Имена ресурсов и элементов чувствительны к регистру (хотя дубликаты, различающиеся только регистром, ни разу не вводились)
  • Любые элементы примитивного типа будут иметь атрибут/свойство value, содержащий фактическое значение элемента
  • Атрибут/свойство value" никогда не может быть пустым. Либо он отсутствует, либо присутствует и содержит по крайней мере один непробельный символ
  • У элементов есть кардинальное число, указывающее, сколько раз этот элемент может или должен появиться.
  • Если только у элементов нет непосредственно заданных потомков (как у nameC выше), им назначается один или несколько типов (см. раздел Типы данных). Имена всех типов сделаны гиперссылками и ведут на свои определения
  • Повторное использование элементов: некоторые типы данных, имеющие потомков, содержат такой же набор потомков, как и некоторый другой элемент, определенный в этом ресурсе. В этом случае тип этого элемента содержит указание "см. [name]", где [name] - это имя элемента, у которого определены элементы-потомки.
  • Каждое имя элемента также сделано гиперссылкой и ведет на подробное описание этого элемента в словаре данных, лежащем в основе форматов обмена.
  • Любые элементы могут иметь атрибут id, используемый в качестве цели внутренней ссылки. В этом формате атрибут id не показывается. Расширения показываются не всегда, но могут быть везде, где нет флага NE
  • FHIR-элементы никогда не могут быть пустыми. Если элемент присутствует в ресурсе, он ДОЛЖЕН иметь либо значение (value), либо элементы-потомки, соответствующие его типу, либо 1 или более расширений
  • В логическом представлении не показаны инфраструктурные элементы, являющиеся общими для всех ресурсов. Они описываются в общих базовых классах Resource и DomainResource

В некоторых элементах указывается несколько типов данных для их содержимого на выбор. У всех подобных элементов имя имеет вид nnn[x]. Часть имени вида "nnn" является константой, а "[x]" заменяется на название типа с большой буквы, который будет фактически использоваться. В таблице приводятся все эти имена.

Элементы с типом данных на выбор не могут повторяться, они должны иметь максимальное кардинальное число равным 1. При создании экземпляра элемента с выбором типа, система разработки должна создать один элемент с тем типом данных, который был выбран из списка разрешенных типов данных.

Примечание: в объектно-ориентированных реализациях этот выбор, как правило, отображается в виде полиморфного свойства. Однако это не обязательно, и корректные реализации варьируются в соответствии с конкретными особенностями языка. В XML-схеме это обозначается как xs:choice элемента.

The following elements have a choice of types:

На UML-диаграммах изображена та же самая информация в виде классов, представляющих элементы ресурса. The UML diagrams represent the same content as a series of classes that represent the elements of a resource.

NameA Documentationelement : [type] [0..*] DocumentationnameB : CodeableConcept [0..1] « Value Set Description (Strength=Preferred)Value Set Name? » NameC Documentationvalue[x] : Type [0..1] « Type1|Type2|Type3 » Docuementationreference : Reference [0..1] « Resource1|Resource2 » DocumentationnameC [0..1]

Элементы и типы данных на странице оформлены в виде ссылок на свои формальные определения. UML-диаграммы показывают ещё и привязки к справочникам. Они оформлены в виде ссылок на описания наборов значений.

Элементы, у которых есть выбор типа данных или которые являюется ссылками, обозначаются общим типом (Reference или Type), затем идет перечисление имён соответствующих типов, разделенных символом |. Type формально не определяется где-то ещё в спецификации, а является базовым типом всех типов данных.

Из диаграммы невозможно определить фактический порядок XML-элементов и то, будет ли UML-свойство элементом или атрибутом в XML-представлении. The actual order of the elements in XML cannot be determined from the diagram, nor whether a UML property becomes an element or an attribute in the XML representation.

Bindings to value sets are indicated by a stereotype on the element. The stereotype has 2 parts: the value set name, and a symbol that denotes the strength of the binding:

В спецификации определены следующие типы представления ресурсов для их обмена: This specification defines the following ways to represent resources when they are exchanged:

Системы ДОЛЖНЫ объявлять, какой формат(ы) они поддерживают в своих Capability Statement. Если сервер получает запрос на свое заявление о возможностях в формате, который он не поддерживает, он ДОЛЖЕН вернуть ошибку 406 Not Acceptable. 4 Note: 406 is the appropriate response when the Accept header requests a format that the server does not support, and 415 Unsupported Media Type when the client posts a format that is not supported to the server.

Клиенты и серверы могут выбирать, какой синтаксис реализовывать. В интересах совместимости серверам СЛЕДУЕТ поддерживать оба формата XML и JSON, имеющие одинаковую функциональность в разных технических стеках. Формат RDF имеет другие преимущества, в основном связанные с анализом данных, а не обменом.

Unlike this rest of this page, the bulk use formats are draft until further experience is gained with their use. Their status will be reviewed in a future version of FHIR.

The XML and JSON formats are designed to support typical system process based data exchange uses. FHIR is also used to exchange large amounts of data- 1000s of records, or more (up to billions). The formats above can be used for this, but more suitable formats exist. This specification documents the following formats:

  • ND-Json (New line delimited JSON)
  • Google Protobuf (under consideration)
  • Apache Parquet/Avro (bulk data formats under consideration)