FHIR CI-Build
FoundationThis is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions 
| Implementable Technology Specifications Work Group | Maturity Level: Normative | Standards Status: Normative |
The XML representation for a resource is described using this format:
<name xmlns="http://hl7.org/fhir" (attrA="value")><!-- from Resource: id, meta, implicitRules, and language --> <nameA><!--
1..1 type description of content --><nameA> <nameB[x]><!-- 0..1 type1|type1 description --></nameB[x]> <nameC> <!-- 1..* --> <nameD><!-- 1..1 type>Relevant elements --></nameD> </nameC> <name>
Using this format:
value attribute, extension URLs in the url attribute on an extension, and the id property on elements (but not on resources, where the resource id is an element). 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) denotes that an element defines or is affected by additional rules that control its presence and/or content)<?xml encoding="UTF-8" ?>) is optional but recommendedapplication/fhir xml.This page contains some JSON examples for the purposes of comparison between the two formats. The formats page has a comparison between the XML and JSON formats.
An element that has a maximum cardinality of >1 (e.g. x..* in the definitions) may occur more than once in the instance.
In XML, this is simply done by repeating the XML element multiple times.
So a CodeableConcept is represented in XML like this:
<code>
<coding>
<system value="http://snomed.info/sct"/>
<code value="104934005"/>
</coding>
<coding>
<system value="http://loinc.org"/>
<code value="2947-0"/>
</coding>
</code>
For comparison, In JSON, this is done by using an array type, also using the singular name:
{
"coding": [
{
"system" : "http://snomed.info/sct",
"code" : "104934005"
},
{
"system" : "http://loinc.org",
"code" : "2947-0"
}
]
}
FHIR elements with primitive datatypes are represented in by an XML element with a value attribute.
<code value="abc"/> <!-- code --> <date value="1972-11-30"/> <!-- dateTime --> <deceased value="false" /> <!-- boolean --> <count value="23" /> <!-- integer -->
For comparison, this is represented in JSON as
"code" : "abc", "date" : "1972-11-30", "deceased" : false, "count" : 23
If the value has an id attribute, or extensions, then these are represented as follows:
<birthDate id="314159" value="1970-03-30" >
<extension url="http://example.org/fhir/StructureDefinition/text">
<valueString value="Easter 1970"/>
</extension>
</birthDate>
The JSON representation is more complex:
"birthDate": "1970-03-30",
"_birthDate": {
"id": "314159",
"extension" : [ {
"url" : "http://example.org/fhir/StructureDefinition/text",
"valueString" : "Easter 1970"
}]
}
Complex datatypes (types that contain named elements of other types) are represented using an element that containing an element for each element in the datatype. Complex datatypes can have ids, which are represented as id attributes, in the same manner as described for primitives. For example:
<Patient xmlns="http://hl7.org/fhir">
<text>
<status value="generated" />
<div xmlns="http://www.w3.org/1999/xhtml"><p>...</p></div>
</text>
<name id="f2">
<use value="official" />
<given value="Karen" />
<family id="a2" value="Van" />
</name>
</Patient>
For comparison, this is represented in JSON as:
{
"resourceType" : "Patient",
"name" : [{
"id" : "f2",
"use" : "official" ,
"given" : [ "Karen" ],
"family" : "Van",
"_family" : {"id" : "a2"}
}],
"text" : {
"status" : "generated" ,
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>...</p></div>"
}
}
Things to note here are:
http://hl7.org/fhir namespace, except for the XHTML contentdiv element which is in the Narrative element text is represented
directly as xhtml, with a root <div> element in the xhtml namespaceThis specification provides schema definitions for all the resource and datatype content models it describes.
The base schema is called "fhir-base.xsd" and defines all 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 most of the constraints defined for the datatypes and resources, though some are only expressible and validatable using FHIRPath. 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.
Given the way extensions work, applications reading XML resources will never encounter unknown elements. However, once an application starts trading with other applications that conform to later versions of this specification, unknown XML elements may be encountered. Applications MAY choose to ignore unknown elements to foster forwards compatibility in this regard, but may also choose not to - which would be the normal behavior for schema generated applications.
In addition to the validation schema, this specification provides a set of schemas suitable for code generation. These schemas describe the same XML syntax, but apply less validation to create schemas that work better with code generation tooling.
Specifically, these schemas are generated without any xsd:choice elements,
for code generators that don't deal with choices well. Implementers that
use these schemas will need to enforce the correct usage of the
choice elements without schema
support.
Implementers making use of schema-driven code generation tooling need
to consider how to handle the decimal
datatype. The decimal datatype is defined to be precision aware - that
is, that implementers need to preserve the difference between "2.0" and
"2.00" - this is ubiquitously considered important in handling observed
data in healthcare. Both schemas map this datatype to a union of xsd:decimal and xsd:double, but
the base W3C schema decimal type is specified not to be precision aware. Schema
driven implementations vary as to how precision is handled. Implementers
will need to determine how their generated code handles decimals/doubles and
consider changing the type for decimal in their schema from xsd:decimal/double
to xsd:string. Specifically, implementers may wish to change:
<xs:simpleType name="decimal-primitive">
<xs:union memberTypes="xs:decimal xs:double"/>
</xs:simpleType>
to this:
<xs:simpleType name="decimal-primitive">
<xs:restriction base="xs:string">
<xs:pattern value="-?(0|[1-9][0-9]{0,17})(\.[0-9]{1,17})?([eE][ -]?[0-9]{1,9}})?"/>
</xs:restriction>
</xs:simpleType>
Note that most code generation frameworks ignore the pattern restriction.
Resources and/or Bundles may be digitally signed (see Bundle and Provenance).
This specification defines the following method for canonicalizing FHIR resources, when represented as XML. Each XML instance or fragment that is part of the collection being signed SHALL:
' instead of ")<?xml version="1.0" encoding="UTF-8"?> (http://www.w3.org/2006/12/xml-c14n11)
This canonicalization method is identified by the URI http://hl7.org/fhir/canonicalization/xml. The
following additional canonicalization URIs are also defined:
| http://hl7.org/fhir/canonicalization/xml#data | The narrative (Resource.text) is omitted prior to signing (note the deletion is at Resource.text, not Resource.text.div) |
| http://hl7.org/fhir/canonicalization/xml#static | In addition to narrative (Resource.text), the Resource.meta element is removed. This makes the signature robust as the content is moved from server to server, or workflow and access tags are added or removed. Note that workflow and security tags may contain information important to the handling of the resource, so meta elements should be protected from tampering by other means if unsigned. |
| http://hl7.org/fhir/canonicalization/xml#narrative | The method only retains the Resource.id and Narrative (Resource.text |
| http://hl7.org/fhir/canonicalization/xml#document | The signs everything in a Bundle, except for the Bundle.id and Bundle.metadata on the root Bundle (allows for a document to be copied from server to server) |
These canonicalization methods allow systems the flexibility to sign the various portions of the resource that matter for the workflow the signature serves. These canonicalization algorithms do not work for enveloped signatures. This will be researched and addressed in a future release. This specification may define additional canonicalizations in the future, and other specifications might also define additional canonicalization methods.
Implementation Note: 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 systems consider carefully the impact of any signature processes. The impact of signatures on Document bundles and their related processes is the most well understood use of digital signatures.
Note that following normalization procedures in XML can assign the same normalized text to resources with slightly different meanings, since leading whitespace matters in markdown text, and the XML representation serializes the markdown datatype using attributes.
FHIR ®© HL7.org 2011 . FHIR R6 hl7.fhir.core#6.0.0-ballot2 generated on Tue, Nov 5, 2024 16:41 0000.
Links: Search |
Version History |
Contents |
Glossary |
QA |
Compare to R5 |
|
Propose a change