This page is part of the FHIR Specification (v0.0.82: DSTU 1). 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.12.5.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.12.5.0.1 Resource Definition

The resources are described in two different ways: a UML diagram that summarizes the content, and a pseudo-XML syntax that provides a visual sense of what the end resource instances will look like in XML. Note that although the description of the resources is based on their XML representation, other representations such as JSON are equally valid.

1.12.5.0.1.1 XML

The XML syntax uses the following notation:

 <Name xmlns="http://hl7.org/fhir" (attrA="value")> 
   <nameA><!-- 1..1 type description of content  --><nameA>
   <nameB[x]><!-- 0..1 type1|type2 description  --></nameB>
   <nameC> <!--  1..* -->
     <nameD><!-- 1..1 type>Relevant records  --></nameD>
   </nameC>
 <name>

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 to contain the actual value of the element
• Elements are assigned a cardinality that specifies how many times the element may or must appear. If the cardinality is shown in Pink then there is an additional condition that impacts on the allowed cardinality. This is available as a mouse-over text, or in the formal definitions
• Unless elements have children defined directly (as nameC does above) they are assigned one or more types. All of the types are defined in the data types except for "Resource" and "Narrative" that are documented below. The type names are hyperlinked
• 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 reference to [path] where [path] is 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. In XML, for example this would like:

    <name>
      <nameBType1>
       ... contents for type1 ...
      </nameBType1>
    </name>
  

  The types that are allowed on this element are listed with a "|" used to separate them. When one of the types is Resource([X]), the type name in the element name is simply "Resource".
• Each element name in the pseudo-syntax is also a hyperlink to the formal definition of the element in the data dictionary that underlies the exchange formats.
• If the element name is underlined, then applications are required to support and/or understand it
• 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
• FHIR elements are never empty. If an element is present in the resource, it SHALL have either a value attribute, child elements as defined for its type, or 1 or more extensions
• Attributes can never be empty. Either they are absent, or they are present with at least one character of non-whitespace content
• In addition to this descriptive syntax, other definitional forms are available, including W3C schema and Schematron

1.12.5.0.1.2 UML

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

Where an element can have a choice of data types, these are represented in the choice using the same syntax as the xml syntax described above. Due to way UML works, the actual order of the elements cannot be determined from the diagram, nor is it visible whether a property is an element or an attribute. 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 details of the binding.

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.