This page is part of the FHIR Specification (v3.5.0: R4 Ballot #2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2
FHIR Infrastructure Work Group | Maturity Level: 5 | Ballot 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.
This page documents how the content of the resources are described. In actual exchange, resources can be represented in the following formats: XML, JSON and Turtle. Other representations are allowed, but are not described by this specification.
The resources are described in several different ways:
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:
Column | Content |
Name | The name of the element in the resource (manifests as XML element name, or JSON property name. Some names finish with [x] - the meaning of this is discussed below. In addition, this column contains an icon that denotes the underlying type of the content. The icons are described below |
Flags | A set of information about the element that impacts how implementers handle them. The flags are described below |
Card. | Cardinality: the lower and upper bounds on how many times this element is allowed to appear in the resource |
Type | 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 |
Description & Constraints | 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 |
Here's an example:
Name | Flags | Card. | Type | Description & Constraints |
---|---|---|---|---|
Resource Name | Base Type | Definition | ||
nameA | Σ | 1..1 | TypeA | description of content |
nameB[x] | ?! Σ | 0..1 | description SHALL at least have a value |
|
nameBType1 | 0..1 | TypeB | ||
nameBType2 | I | 0..1 | typeC | |
nameC | 1..* | Element | Definition | |
nameD | 1..1 | TypeD | Relevant Records |
Key to Type Icons and Flags
value
attribute/property. These are also known as primitive types. All primitive type names start with a lower case letter?!
: This element is a modifying element - see Modifier ElementsS
: This element is an element that must be supported - see Must-Support ElementsΣ
: This element is an element that is part of the summary set - see Summary SearchesI
: This element defines or is affected by constraints - see ConstraintsNE
: This element cannot have extensions (some infrastructural elements only)Notes:
value
attribute/property to contain the actual value of the elementvalue
attribute/property can never be empty. Either it is absent, or it is present with at least one character of non-whitespace contentid
attribute to serve as the target of an internal reference. The id
attribute is not shown in this format. Extensions are not always shown, but may appear except where the flag NE
appears
A few elements have a choice of more than one data type for their content. All such elements have a name that
takes the form nnn[x]
. The "nnn" part of the name is constant, and the "[x]" is replaced with the title-cased
name of the type that is actually used. The table view shows each of these names explicitly.
Elements that have a choice of data type cannot repeat - they must have a maximum cardinality of 1. When constructing an instance of an element with a choice of types, the authoring system must create a single element with a data type chosen from among the list of permitted data types.
Note: In object-orientated based implementations, this is naturally represented as a polymorphic property. However this is not necessary and the correct implementation varies according to the particular features of the language. In XML schema, these become an xs:choice of element.
The following elements have a choice of types:
The UML diagrams represent the same content as a series of classes that represent the elements of a resource.
The elements and the data types are hyperlinks to the formal definitions of the parts. The UML diagrams also show the vocabulary bindings. These are hyperlinks to the value set details.
Where an element can have a choice of data types, or is a Reference these are
represented by showing the common type (Reference
or Type
), and then showing the applicable data type names or
resource types in a stereotype, separated by the |
character. Type
is not formally otherwise defined by
this specification, but is a super type of all the data types.
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:
Systems SHALL declare which format(s) they support in their Capability Statement.
If a server receives a request for its Capability Statement in
a format it does not otherwise support, it SHALL return a 406 Not Acceptable
. 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.
Clients and servers can choose what syntax(s) to implement. In the interests of interoperability, servers SHOULD support both the XML and JSON formats, which have the same functionality, for different technical stacks. The RDF format has quite different benefits - primarily around data analysis rather than exchange.
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: