FHIR
Release
3
(STU)
CI-Build
This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
STU
3).
The
current
version
which
supercedes
this
version
is
5.0.0
.
For
a
full
list
Continuous
Integration
Build
of
available
versions,
see
FHIR
(will
be
incorrect/inconsistent
at
times).
See
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
R2
|
Responsible
Owner:
Implementable
Technology
Specifications
Work
Group
|
|
The XML representation for a resource is described using this format:
<<name xmlns="http://hl7.org/fhir" (attrA="value") resourceDefinition="{canonical}"><!-- 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:
Foundation
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
)
denotes
that
an
element
defines
or
is
affected
by
additional
rules
that
control
its
presence
and/or
content
)
<?xml
encoding="UTF-8"
encoding="UTF-8"
?>
application/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 .
When
additional
resources
are
represented
in
XML,
the
base
document
name
is
the
name
of
the
resource
as
allocated
by
HL7,
the
namespace
is
the
normal
FHIR
namespace,
and
an
additional
attribute
is
present,
resourceDefinition
.
The
resourceDefinition
value
contains
a
canonical
reference
to
the
definition
of
the
resource
and
always
includes
the
version
explicitly,
e.g.,
<ViewDefinition xmlns="http://hl7.org/fhir" resourceDefinition="http://hl7.org/fhir/uv/sql-on-fhir/StructureDefinition/ViewDefinition|2.0.0-pre"> <id value="a-valid-id"/> // etc <ViewDefinition>
The
resourceDefinition
attribute
is
a
feature
of
the
XML
format,
and
is
not
defined
anywhere
in
the
structural
definitions
of
FHIR
(in
the
same
way
that
the
base
name
is
not).
The
resourceDefinition
attribute
is
not
present
if
the
resource
is
one
defined
in
this
specification.
Also, see note about the schema and additional resources below.
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
content
div
element
which
is
in
the
Narrative
element
text
is
represented
directly
as
xhtml,
with
a
root
<div>
element
in
the
xhtml
namespace
This 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.
The base schema only describes the resources defined in this specification; additional resources are not included in the schema. If enough implementers identify a need for this, HL7 may choose to provide a tool that stitches a new schema for a given set of additional resources.
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.
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
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.
datatype.
The
decimal
data
type
datatype
is
defined
to
be
precision
aware
-
that
is,
that
implementers
need
to
preserve
the
difference
between
"2.0"
"2.0"
and
"2.00"
"2.00"
-
this
is
ubiquitously
considered
important
in
handling
observed
data
in
healthcare.
Both
schemas
map
this
data
type
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
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: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-9]+)?"/><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>
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.
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
See
Signatures
and
their
related
processes
is
the
most
well
understood
use
of
digital
signatures.
for
details.
FHIR
®©
HL7.org
2011+.
FHIR
Release
3
(STU;
v3.0.2-11200)
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Thurs,
Oct
24,
2019
11:53+1100.
QA
Page
Fri,
Nov
21,
2025
00:03+0000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
DSTU2
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change