2nd DSTU Draft For Comment

This page is part of the FHIR Specification (v0.4.0: DSTU 2 Draft). 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

1.19.0 Resource Formats

This page documents how the content of the resources are described. In actual exchange, resources can be represented in the following formats: XML and JSON.

1.19.0.1 Resource Definition

The resources are described in several different ways:

  • a hierarchical table that presents a logical view of the content
  • a UML diagram that summarizes the content graphically
  • a pseudo-XML syntax that provides a visual sense of what the end resource instances will look like in XML
  • a pseudo-JSON syntax that provides a visual sense of what the end resource instances will look like in JSON

In addition to this descriptive syntax, other definitional forms are available, including W3C schema and Schematron, and the Profile syntax defined internally.

1.19.0.1.1 Logical table

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

Here's an example:

Name Flags Card. Type Description & Constraints
.. Resource Name Base Type Definition
... nameA Σ 1..1 type description of content
... nameB[x] M Σ 0..1 description
SHALL at least have a value
.... nameBType1 0..1 type1
.... nameBType2 I 0..1 type2
... nameC 1..* Element Definition
.... nameD 1..1 type Relevant Records

Key to Type Icons and Flags

  • .: The base element for a resource (see Resources)
  • .: The base element for a Bundle (see Bundles)
  • .: An element that is part of the resource and has elements within it defined in the same resource or profile
  • .: An element which can have one of a several different types (see below)
  • .: A data type which describes an element that has a value attribute/property
  • .: A data type which describes an element that has other elements
  • .: A element that contains a reference to another resource (see references)
  • .: This element has the same content as another element defined within this resource or profile
  • .: Introduction of a set of slices (see Slicing)
  • .: An extension (see Extensibility)
  • .: A complex extension - one with nested extensions (see Extensibility)
  • .: An extension that has a value and no nested extensions (see Extensibility)
  • .: The root of a logical profile
  • M: This element is a modifying element - see Modifier Elements
  • S: 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 Searches
  • I: This element defines or as affected by invariants - see Invariants
  • NE: This element cannot have extensions (some infrastructural elements only)

Notes:

  • Resource and Element names are case-sensitive (though duplicates that differ only in case are never defined)
  • Any elements that have a primitive type will have a "value" attribute/property to contain the actual value of the element
  • This "value" attribute/property can never be empty. Either it is absent, or it is present with at least one character of non-whitespace content
  • Elements are assigned a cardinality that specifies how many times the element may or must appear.
  • Unless elements have children defined directly (as nameC does above) they are assigned one or more types. Most of the types are defined in the data types. All the type names are hyperlinked to the source definition
  • Element reuse: Some data types that have children have the same set of children as some other element defined in the resource. In that case, the type of that element has a "see [name]" where [name] is the name of the element that has the defined children
  • When a logical element can have more than one type, its name 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 shows each of these names explicitly.
  • Each element name is also a hyperlink to the formal definition of the element in the data dictionary that underlies the exchange formats.
  • Any of the elements may have an id 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
  • FHIR elements can never be empty. If an element is present in the resource, it SHALL have either a value, child elements as defined for its type, or 1 or more extensions
  • Infrastructural elements that are common to all resources are not shown in the logical representation. These are described in the common base classes Resource, and DomainResource

1.19.0.1.2 UML

The UML diagrams represent the same content as a series of classes that represent the elements of a resource.

Name attrA : string 0..1 nameA : type 1..1 nameB[x] : type1 | type2 0..1 NameC nameD : type 1..* nameC 0..1

Where an element can have a choice of data types, these are represented by listing the type names separated by the "|" character. The elements and types are links to the formal definitions of the parts. The UML diagrams also show the bindings, and these are hyperlinks to the value set details.

These UML diagrams are intended to communicate the contents of the resource to a human, and are not suitable for code generation using standard UML code generation tools (see the eCore reference implementation for UML related code generation).

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.

1.19.0.1.3 Wire Format Representations

This specification defines these ways to represent resources when they are exchanged:

Clients and servers can choose whether to implement in XML or JSON. In the interests of interoperability, Servers SHOULD support both formats. Systems SHALL declare which format(s) they support in their Conformance Statement. If a server receives a request for it's conformance statement in a format it does not otherwise support, it SHALL return a 415 Unsupported Media Type.