DSTU2 Ballot Source

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

1.17.1 XML Representation of Resources

The XML representation for a resource is described using this format: 

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

Using this format:

  • To build a valid XML instance of a resource, simply replace the contents of the elements and attributes with valid content as described by the cardinality, type rules and content description found in the comment in each element
  • Resource and Element names are case-sensitive (though duplicates that differ only in case are never defined)
  • Elements must always appear in the order documented
  • A few properties are represented as attributes: primitive values in the "value" attribute, extension URLs in the "url" attribute on an extension, and the "id" property
  • Any of the XML 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 always in the namespace http://hl7.org/fhir. This is usually specified as the default namespace on the root element. The only other namespace that occurs in FHIR resources is the XHTML namespace (XHTML is found in most resources)
  • Infrastructural elements that are common to all resources are not shown in the xml representation. These must appear prior to any other defined child elements in the following order:
  • 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
  • The lock icon (??) denotes that an element defines or is affected by additional rules that control its presence and/or content
  • XML comments, processing instructions and formatting are not part of the contents of a resource
  • XML resources SHALL be exchanged using UTF-8 encoding. Specifying the character encoding using a <?xml encoding="UTF-8" ?> processing instruction is optional but recommended
  • Other processing Instructions SHOULD not be included, except and SHALL not be required in order to properly understand and/or present the data or narrative of the resource. Applications MAY preserve these when handling resources, but are not required to do so
  • The MIME-type for this format is application/xml+fhir.

1.17.1.1 XML Schema and Schematron

This specification provides schema definitions for all of the content models it describes.

The base schema is called "fhir-base.xsd" and defines all of the datatypes and base infrastructure types. In addition, there is a schema for each resource and a common schema fhir-all.xsd that includes all the resource schemas. For schema processors that do not like circular includes, there is a single schema that contains everything.

In addition to the w3c schema files, this specification also provides Schematron files that enforce the various constraints defined for the datatypes and resources. These are packaged as files for each resource.

XML that is exchanged SHALL be valid against the w3c schema and Schematron, though being valid against the schema and Schematron is not sufficient to be a conformant instance: this specification makes several rules that cannot be checked by either mechanism. Operational systems may choose to use schema tools to check validation, but are not required to do so. Exchanged content SHALL not specify the schema or even contain the schema instance namespace in the resource itself.

1.17.1.2 Digital Signatures

Resources and/or Bundles may be digitally signed (ref to be provided). One consequence of signing the document is that URLs, identifiers and internal references are frozen and cannot be changed. This might be a desired feature, but it may also cripple interoperability between closed ecosystems where re-identification frequently occurs. For this reason, it is recommended that only Document Bundles are signed and then only when all the related resources are found in the bundle.

todo: canonical XML