Current Build

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

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.

The FHIR specification describes a set of resources and several different frameworks for exchanging resources between different systems. Because of its general nature and wide applicability, the rules made in this specification are fairly loose. As a consequence, this specification allows that different applications might not be able to interoperate because of how they use optional features. Applications claiming conformance to this specification make the claim in respect of a specific exchange framework, and in regard to specific details about their usage of those frameworks and resource contents.

Applications claim conformance to one (or more) of the following exchange frameworks:

Для предоставления подробностей об особом применение этих фреймворков и содержимого ресурсов, FHIR предлагает слой соответствия, который разработчики, национальные/региональные программы и другие профилирующие организации типа IHE, могут использовать для предъявления вычислимого заявления о том, каким образом ресурсы и парадигмы обмена ресурсами используются для решения конкретных задач. Сам слой соответствия реализуется с помощью следующих ресурсов:

Value Set Определяет набор кодированных значений (см. "Using Codes" для более подробной информации)
StructureDefinition Вводит правила о способах использования ресурса (или типа) и его элементов данных в определенном контексте, включая определение того, каким образом будут использоваться расширения. Structure definition ссылается на наборы значений, используемые в кодированных элементах ресурса
CapabilityStatement Перечисление видов ресурсов и операций, предоставляемых и/или используемых приложением. Ресурс Capability Statement ссылается на профили для описания особенностей использования приложением ресурсов
Implementation Guide A single coherent collection of capability statements, profiles, extensions, value sets, and documentation describing a set of interoperable applications

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

FHIR is a closed specification. The specification defines what is possible and required for those portions of an API or exchange framework that wish to declare themselves as FHIR conformant, and that includes exchange resources that conform to the documented requirements of this specification. Systems may choose to support capabilities beyond those defined by FHIR (e.g. by adding additional end points/services with other names), but those portions of their interfaces that extend beyond what FHIR explicitly allows cannot be considered or described as "FHIR conformant".

Соответствие спецификации не дает никакой гарантии безопасности пациента или данных. Однако отказ от соответствия данной спецификации несет дополнительный риск двумя способами:

  • FHIR has been subject to a level of review and vetting unlikely to be received by any non-conformant variation; variations may result in introduction of undetected risks
  • FHIR-like solutions (based on FHIR, but not conformant) may set expectations by trading partners which are not met due to the non-conformance of the system and these un-met expectations may also result in risk

Systems can only claim FHIR Conformance for functionality described in the applicable CapabilityStatement.

This specification uses the conformance verbs SHALL, SHOULD, and MAY as defined in RFC 2119. Unlike RFC 2119, however, this specification allows that different applications might not be able to interoperate because of how they use optional features. In particular:

  1. SHALL: an absolute requirement for all implementations
  2. SHALL NOT: an absolute prohibition against inclusion for all implementations
  3. SHOULD/SHOULD NOT: A best practice or recommendation to be considered by implementers within the context of their particular implementation; there may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course
  4. MAY: This is truly optional language for an implementation; can be included or omitted as the implementer decides with no implications

The contents of a resource and the formats used to represent resources SHALL conform to the rules described in this specification, as defined in the narrative of the specification, and as controlled by the conformance properties defined below.

Data elements defined in resources and data types have 3 properties that are directly related to conformance: Cardinality, Is-Modifier, and Must-Support. These interact to place conformance requirements on implementations.

Частью определения каждого атрибута, описанного в FHIR, является кардинальное число - минимальное и максимальное количество необходимых вхождений. Это число определяет количество раз, которое этот атрибут может появиться в любом экземпляре ресурса данного типа. Данная спецификация вводит только следующие кардинальные множества: 0..1, 0..*, 1..1 и 1..*. Профили, описывающие частные случаи использования, могут использовать другие значения кардинального числа в пределах значения, определенного базовым ресурсом.

Обратите внимание, что когда присутствуют, элементы не могут быть пустыми - они ДОЛЖНЫ иметь атрибут value, элементы-потомки или расширения. Это означает, что назначение элементу минимального кардинального числа 1 не гарантирует присутствия допустимых данных; для гарантии, что требуемые данные будут присутствовать, необходимы определенные FHIRPath-ограничения.

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

Для элементов, имеющих кардинальное число > 1, порядок их появления может иметь значение. Если только в определении элемента (в данной спецификации или в расширении) не определено значение порядка явно (с помощью ElementDefinition.orderMeaning, значение порядка не определено, и реализаторам разрешается менять порядок элементов. Обратите внимание, что не возможно установить значение порядка элементов в профиле с помощью StructureDefinition. Когда описание значения порядка отсутствует, реализации, которым требуется выбрать один элемент из списка элементов для некоторого использования, ДОЛЖНЫ делать это, основываясь на семантике содержимого этого элемента, который повторяется. Профили и руководства по реализации часто вводят правила относительно этого процесса выбора.

Clients should not depend on servers maintaining ordering of elements, unless the retrieved resource conforms to a profile which mandates maintenance of ordering. If a server cannot maintain ordering, it must strip off known profile tags which require maintenance of ordering, and strip off unknown profiles (since they might require maintenance of ordering).

Is-Modifier - это булево свойство, которое назначается, когда элемент определен либо в рамках базового содержимого ресурса в данной спецификации, либо при определении расширений.

An element is a modifier if and only if it cannot be safely ignored because its value, or its meaning if missing, may cause the interpretation of the containing element or one of its descendants to no longer conform to the stated definition for the element. Typical examples of elements that are labeled "Is-Modifier" are elements such as "status", "active", "refuted", or "certainty" that invert or negate the meaning of the resource (or element) that contains them.

Modifier is not an indication of the degree of importance for a particular piece of information or whether the element ought to be ignored when the resource is used for common use-cases. It is expected that if you ignore an element you may miss an important piece of computable meaning.

For example, consider Observation:

  • Observation.status allows the entered-in-error code, which indicates that no actual Observation occurred at all. The definition of Observation indicates that it is a measurement that has been made - and doesn't allow for the possibility of a measurement that wasn't made. As a result, if the status element were ignored and an Observation were interpreted at face value based on its definition, a system or user would infer that an Observation had occurred, which would be false
  • If an application ignores the Observation.subject element, it wouldn't know who or what was observed, which would make the remaining information largely useless for most usage. However, any system that ignores the subject would not have a false understanding of the Observation as it's defined. The system would understand what type of observation was made, when and what was found, just not who it was about
  • Even something as critical as Observation.code is not a modifier element. While the Observation would have little utility without the code, the understanding when ignoring the element that “some” Observation had been made on the specified subject at the specified date and time would still be true when the element was reintroduced. The only exception would be if a value expressed in the Observation.code element could somehow convey that the Observation had not occurred or otherwise cause the instance to diverge from the defined meaning of Observation when ignoring the element

The definition of is-modifier has a corollary: any element that meets the requirement that it could cause the interpretation of the containing element or its descendants to diverge from their definition SHALL explicitly declare how such divergence could occur and must be marked as a modifier element. Any element not marked is-modifier and without that explanation SHALL NOT be used by an implementer in such a manner as to make the element behave as a modifier. For example, using a special "name" on a patient to indicate that the subject isn’t a real patient, but is instead an artificial structure used for non-patient tests would be non-conformant with FHIR because Patient.name is not a modifier element

Whether an element is a modifier cannot be changed when element usage is described in a constraining Structure Definition. When an element is labeled as Is-Modifier, the documentation must be clear about why it is a modifier.

A typical example of a modifier element is one that negates the element that contains it. For instance, in the following fragment of a resource definition:

NameFlagsCard.TypeDescription & Constraintsdoco
.. AllergyIntoleranceDomainResourceAllergy or Intolerance (generally: Risk of Adverse reaction to a substance)
... onsetΣ0..1dateTimeDate(/time) when manifestations showed
... patientΣ1..1Reference(Patient)Who the sensitivity is for
... verificationStatus?! Σ0..1CodeableConceptunconfirmed | confirmed | refuted | entered-in-error
AllergyIntoleranceVerificationStatus (Required)
... criticalityΣ0..1codeCRITL | CRITH | CRITU
AllergyIntoleranceCriticality (Required)

The definition of an AllergyIntolerance is that it contains information about "Risk of harmful or undesirable, physiological response which is unique to an individual and associated with exposure to a substance". If the value of the 'verificationStatus' element is set to entered-in-error, the entire resource does not actually contain valid information about any risk of exposure, and it is not safe for applications to ignore this element. As a consequence, it is labeled as 'is modifier = true'. In this tabular representation of the resource, this shows as the flag '?!'. The JSON and XML representations of a resource definition have their own representation of 'is modifier = true' status, and it is defined directly in a ElementDefinition.

If a narrative summary is present, and the status is generated, Is-Modifier elements SHALL be represented in the narrative summary of the resource. If Narrative is present with some other status Is-modifier elements SHOULD be represented.

Если значение элемента-модификатора в экземпляре не ясно или подразумевается из контекста, такой ресурс может быть неверно интерпретирован. Везде, где это возможно, элементы, помеченные как "Is-Modifier = true", имеют кардинальное число 1, для того чтобы внести определенность в их обработку. Тем не менее, иногда это не возможно - большая часть существующих данных недостаточно хорошо описана. Реализации, создающие ресурсы, ДОЛЖНЫ гарантировать обеспечение подходящих значений элементам с флагом isModifier.

Реализации, обрабатывающие данные в ресурсах, ДОЛЖНЫ понимать влияние этого элемента при использовании этих данных. От реализаций не требуется "поддерживать" этот элемент сколь-нибудь существенным образом - они могут достигнуть этого понимания отклонением экземпляров, которые содержат значения, которые они не поддерживают (к примеру, приложение может отказаться принимать результаты обследований со значением надежности не "ok"). В качестве альтернативы гарантия того, что реализации такие значения никогда не встретятся, может обеспечиваться средой ее разработки. Однако независимо от этого приложениям СЛЕДУЕТ всегда проверять это значение.

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

Каждый элемент в базовом ресурсе имеет флаг Is-Modifier со значением "истина" или "ложь". Значение этого флага не может быть изменено профилями этого ресурса в обоих направлениях. Когда в StructureDefinition описывается расширение, оно помечается флагом Is-Modifier, и он не может быть изменен в других профилях. Обратите внимание, что расширения с is-Modifier = true представляются по-другому в экземплярах ресурса ("modifierExtension" вместо "extension"), и имеются дополнительные правила их обработки.

Most status elements are marked as modifiers because of the presence of the entered-in-error status. Other modifiers are defined:

Отметка на элементе "Обязателен к поддержке" означает, что реализации, создающие или использующие ресурсы, ДОЛЖНЫ предоставлять "поддержку" этого элемента некоторым значимым способом. Поскольку базовая спецификация FHIR должна быть независимой от какого бы то ни было контекста конкретной реализации, в рамках базовой спецификации нет элементов с флагом "Обязателен к поддержке". Этот флаг предназначен для использования в профилях, имеющих определённый контекст реализации.

По этой причине спецификация сама никогда не помечает элементы как must-support. Это делается в StructureDefinitions, где профиль помечает элемент как mustSupport=true. Когда профиль делает это, он ДОЛЖЕН также точно прояснить, какая именно "поддержка" требуется, так как это может включать ожидания того, что система должна хранить, отображать, обеспечивать ввод данных, включать в логику поддержки принятия решений, передавать другим потребителям данных и т.п.

Обратите внимание, что элемент со свойством IsModifier не обязательно является "ключевым" элементом (например одним из важных элементов в использовании ресурса) и не становится автоматически mustSupport - однако обе эти вещи более вероятны для элементов-модификаторов, чем для других элементов.

All elements may have constraints attached to them (also known as 'invariants'). Constraints defined on an element have the following properties:

KeyIdentifies the constraint uniquely amongst all the constraints in the context - typically, this is used to refer to the constraint in an error message
RequirementsAn explanation of why the constraint has been applied - what harmful conditions are being avoided
SeverityThe severity of the invariant - see below
Human DescriptionA human description of the rule intended to be shown as the explanation for a message when the constraint is not met
ExpressionA FHIRPath expression that must evaluate to true when run on the element
XPathAn XPath expression that must evaluate to true when run on the element in the XML representation

Many constraints are defined in the base specification. In addition, additional constraints may be defined in profiles that apply to resources. Systems are not required to evaluate the constraints, just as they are not required to check for conformance, or schema validity. However, systems SHOULD always ensure that all resources are valid against all applicable constraints.

Constraints have a severity level:

Error (rule) A rule that all resources must conform to. Validators should report it as an error if the rule is violated, and applications processing the content can reject it as an invalid resource
Warning Report this as a warning that there may be a problem with the resource, but it is considered valid and can be processed normally
Guideline A warning marked with an extension (http://hl7.org/fhir/StructureDefinition/elementdefinition-bestpractice) that indicates that it should be a treated as an error if the implementation context asks a validator to enforce best practice rules. See Best Practices for a full list

Elements can also be explicitly associated with constraints defined elsewhere. This is a notification to implementers that the element is affected by the constraint. It has no meaning when the constraints are evaluated.

Profiles may define additional constraints that apply to an element, but they cannot alter or remove constraints that are already applied.

In addition to the conformance metadata, each element has other metadata properties defined in the ElementDefinition:

Данная спецификация содержит множество примеров. Несмотря на то, что были приложены все усилия для обеспечения полного соответствия примеров спецификации, если примеры противоречат спецификации, то корректной и нормативной считается спецификация, а не примеры. Это же правило относится и к эталонным реализациям.

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