This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions

ISO 21090 Data Type Extensions

FHIR Infrastructure Work GroupMaturity Level: N/AStandards Status: Informative

Scope and Usage

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.

Any (ANY)

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.)

Entity Name (EN)

These extensions apply to the HumanName data type.

  • EN-use - allows a more refined statement of the intended use of a particular name
  • EN-representation - is for a subset of 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:

  • EN-qualifier - allows distinguishing initials, middle names, call-me names and other types of names

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.

Parametric Probability Distribution of a Physical Quantity (PPD<PQ>)

These extensions provide support for the probability distributions for the Quantity data type. There are two properties:

  • uncertainty - Indicates the standard deviation associated with the extended quantity.
  • uncertaintyType - Identifies the probability distribution associated with the uncertainty of the extended quantity.

Address (AD)

These extensions provide support for various additional properties of the Address data type. There are kinds of properties:

These 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.