This page is part of the FHIR Specification v6.0.0-ballot1: Release 6 Ballot (1st Draft) (see Ballot Notes). The current version is 5.0.0. For a full list of available versions, see the Directory of published versions
FHIR Infrastructure Work Group | Maturity Level: N/A | Standards Status: Informative |
This profile defines a large number of extensions that reflect capabilities of the ISO 21090 data types specification that were not included as part of the FHIR core data types specification. (These capabilities were excluded because it was determined that they represented "edge case" capabilities that the majority of existing implementations did not support.
At the present time, this profile is incomplete. It only contains extensions reflecting capabilities that have been explicitly identified as "useful" in the context of FHIR. The set of extensions in this profile will continue to grow over time until eventually all capabilities of the ISO 21090 specification are reflected.
For ease of reading, the extensions have been organized based on the underlying data type in the ISO specification. The applicable FHIR data type(s) are also identified.
NOTE: FHIR uses a different architecture than HL7 v3, so some capabilities might not make sense in the FHIR context or may need to be used in a different manner. Where necessary, guidance is included in this profile on any differences in usage.
These extensions may apply to any of the FHIR data types (complex or primitive). It can also appear on any resource element.
This extension allows exceptional values to be conveyed, as well as for data to be flagged as "missing" for some reason.
In v3, null flavors were often required for data types when particular components were missing. In the FHIR core specification, there is never an
automatic requirement to send a null flavor, though profiles may introduce such a requirement. As well, the need for null flavors is often made
explicit in the specification by adding relevant null flavors to the value set for coded elements or by introducing a "choice" of data type such that
either a normal value or a coded special value can be specified. For example, a resouce might have a quantity[x]
element with a type of
Quantity | code
where the value set is limited to TRC, QS or UNK. In this way, only those null flavors that are relevant to the context are
included.
Where null flavors are not supported as part of the core specification, extensions can be defined that expose only those null flavors that are relevant. This approach is preferred over referencing the full null flavor specification. (Note that the null flavor code system can be referenced in any value sets.)
These extensions apply to the HumanName data type.
EN-use
and indicates the representation form of the name (this has specific use in east Asian countries)
This extension applies to HumanName parts - e.g. family
and given
:
Note, however, that subsequent implementer experience has led to a new set of extensions being defined for most of the human name issues (see own-name, own-prefix, partner-name, partner-prefix, fathers-family and mothers-family), and these should be used in preference to the ISO 21090 extensions, which are defined only for backwards compatibility.
These extensions provide support for the probability distributions for the Quantity data type. There are two properties:
These extensions provide support for various additional properties of the Address data type. There are kinds of properties:
Address.use
propertyThese additional elements of Address will be ignored by applications that do not support them, so any information in them should also be duplicated in the Address.line to which they are attached.