|Implementable Technology Specifications Work Group||Maturity Level: 5||Ballot Status: Trial Use|
The XML representation for a resource is described using this format:
<name xmlns="http://hl7.org/fhir" (attrA="value")> <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:
valueattribute, extension URLs in the
urlattribute on an extension, and the
idproperty on elements (but not on resources, where the resource id is an element)
<?xml encoding="UTF-8" ?>processing instruction is optional but recommended
This specification provides schema definitions for all the 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 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.
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. Applications declare their unknown elements behavior using CapabilityStatement.acceptUnknown.
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 with more code generation tooling.
Specifically, these schemas are generated without any
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
Implementers making use of schema driven code generation tooling need
to consider how to handle the decimal
data type. The decimal data type 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 data type to
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 and
consider changing the type for decimal in the schema from
xsd:string. Specifically, implementers may wish to change
<xs:simpleType name="decimal-primitive"> <xs:restriction base="xs:decimal"> <xs:pattern value="-?(|([1-9][0-9]*))(\.[0-9]+)?"/> </xs:restriction> </xs:simpleType>
<xs:simpleType name="decimal-primitive"> <xs:restriction base="xs:string"> <xs:pattern value="-?(|([1-9][0-9]*))(\.[0-9]+)?"/> </xs:restriction> </xs:simpleType>
Alternatively, if supported, implementers may wish to use the precisionDecimal from the XSD 1.1 framework.
Note that most code generation frameworks ignore the pattern restriction.
This specification defines the following method for canonicalizing FHIR resources, when represented as xml:
<?xml version="1.0" encoding="UTF-8"?>
This canonicalization method is identified by the URL
following additional canonicalization URLS are also defined:
|http://hl7.org/fhir/canonicalization/xml#data||The narrative (
|http://hl7.org/fhir/canonicalization/xml#static||In addition to narrative (Resource.text), the
|http://hl7.org/fhir/canonicalization/xml#narrative||The method only retains the
|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 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.
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.