Implementable
Technology
Specifications
![]() |
Maturity
Level
:
|
|
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><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)
<?xml
encoding="UTF-8"
?>
application/fhir+xml
.
This specification provides schema definitions for all the resource and data type 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
various
constraints
defined
for
the
datatypes
and
resources.
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
more
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
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
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
decimals/doubles
and
consider
changing
the
type
for
decimal
in
the
their
schema
from
to
xsd:decimal
xsd:decimal/double
xsd:string
.
Specifically,
implementers
may
wish
to
change
change:
<xs:simpleType name="decimal-primitive"><xs:restriction base="xs:decimal"> <xs:pattern value="-?([0]|([1-9][0-9]*))(\.[0-9]+)?"/> </xs:restriction><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-9]+)?"/><xs:pattern value="-?(0|[1-9][0-9]*)(\.[0-9]+)?([eE][+-]?[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.
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:
'
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
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
|
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.