This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
STU
3).
(v3.5.0:
R4
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
FHIR
Infrastructure
Work
Group
|
Maturity Level : 5 |
Ballot
Status
:
|
Normative Candidate Note: This page is candidate normative content for R4 in the Infrastructure Package . Once normative, it will lose it's Maturity Level, and breaking changes will no longer be made.
This page documents how the content of the resources are described. In actual exchange, resources can be represented in the following formats: XML , JSON and Turtle . Other representations are allowed, but are not described by this specification.
The resources are described in several different ways:
In addition to this descriptive syntax, other definitional forms are available, including W3C schema and Schematron, and the StructureDefinition syntax defined internally.
The Logical View shows the resources as a tree structure with the following columns:
| Column | Content |
| Name |
The
name
of
the
element
in
the
resource
(manifests
as
XML
element
name,
or
JSON
property
name.
Some
names
finish
with
[x]
-
the
meaning
of
this
is
discussed
below.
In
addition,
this
column
contains
an
icon
that
denotes
the
underlying
type
of
the
content.
The
icons
are
described
below
|
| Flags | A set of information about the element that impacts how implementers handle them. The flags are described below |
| Card. | Cardinality: the lower and upper bounds on how many times this element is allowed to appear in the resource |
| Type | The type of the element (hyperlinked to the definition of the type). Note that the type of the element has one of two meanings, depending on whether the element has defined children. If the element has children, then the element has an anonymous type that specializes the given type. If the element has no children, then the element has properties and children as specified by the nominated type |
| Description & Constraints |
A
description
of
the
element,
and
details
about
constraints
that
are
applied
to
it.
Particularly,
for
coded
elements,
information
about
which
codes
can
be
|
Here's an example:
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
|
Base Type | Definition | ||
|
Σ | 1..1 |
|
description of content |
|
?! Σ | 0..1 |
description
SHALL at least have a value |
|
|
0..1 |
|
||
|
I | 0..1 |
|
|
|
1..* | Element | Definition | |
|
1..1 |
|
Relevant Records |
Key to Type Icons and Flags
value
?!
:
This
element
is
a
modifying
element
-
see
Modifier
Elements
S
:
This
element
is
an
element
that
must
be
supported
-
see
Must-Support
Elements
Σ
:
This
element
is
an
element
that
is
part
of
the
summary
set
-
see
Summary
Searches
I
:
This
element
defines
or
is
affected
by
constraints
-
see
Constraints
NE
:
This
element
cannot
have
extensions
(some
infrastructural
elements
only)
Notes:
value
attribute/property
to
contain
the
actual
value
of
the
element
value
attribute/property
can
never
be
empty.
Either
it
is
absent,
or
it
is
present
with
at
least
one
character
of
non-whitespace
content
id
attribute
to
serve
as
the
target
of
an
internal
reference
.
The
id
attribute
is
not
shown
in
this
format.
Extensions
are
not
always
shown,
but
may
appear
except
where
the
flag
NE
appears
A
few
elements
have
a
choice
of
more
than
one
data
type
for
their
content.
All
such
elements
have
a
name
that
takes
the
form
nnn[x]
.
The
"nnn"
"nnn"
part
of
the
name
is
constant,
and
the
"[x]"
"[x]"
is
replaced
with
the
title-cased
name
of
the
type
that
is
actually
used.
The
table
view
shows
each
of
these
names
explicitly.
Elements that have a choice of data type cannot repeat - they must have a maximum cardinality of 1. When constructing an instance of an element with a choice of types, the authoring system must create a single element with a data type chosen from among the list of permitted data types.
Note: In object-orientated based implementations, this is naturally represented as a polymorphic property. However this is not necessary and the correct implementation varies according to the particular features of the language. In XML schema, these become an xs:choice of element.
The following elements have a choice of types:
The UML diagrams represent the same content as a series of classes that represent the elements of a resource.
The elements and the data types are hyperlinks to the formal definitions of the parts. The UML diagrams also show the vocabulary bindings. These are hyperlinks to the value set details.
Where
an
element
can
have
a
choice
of
data
types,
or
is
a
Reference
these
are
represented
by
showing
the
common
type
(
Reference
or
Type
),
and
then
showing
the
applicable
data
type
names
or
resource
types
in
a
stereotype,
separated
by
the
|
character.
Type
is
not
formally
otherwise
defined
by
this
specification,
but
is
a
super
type
of
all
the
data
types.
The actual order of the elements in XML cannot be determined from the diagram, nor whether a UML property becomes an element or an attribute in the XML representation.
Bindings to value sets are indicated by a stereotype on the element. The stereotype has 2 parts: the value set name, and a symbol that denotes the strength of the binding:
This specification defines the following ways to represent resources when they are exchanged:
Clients
and
servers
can
choose
what
syntax(s)
to
implement.
In
the
interests
of
interoperability,
servers
SHOULD
support
all
formats
(though
support
for
RDF
should
best
wait
until
it
is
more
fully
developed).
Systems
SHALL
declare
which
format(s)
they
support
in
their
Capability
Statement
.
If
a
server
receives
a
request
for
its
Capability
Statement
in
a
format
it
does
not
otherwise
support,
it
SHALL
return
a
.
Note:
415
406
Not
Acceptable
406
is
the
appropriate
response
when
the
Accept
header
requests
a
format
that
the
server
does
not
support,
and
415
Unsupported
Media
when
the
client
posts
a
format
that
is
not
supported
to
the
server.
Type.
Type
Clients and servers can choose what syntax(s) to implement. In the interests of interoperability, servers SHOULD support both the XML and JSON formats, which have the same functionality, for different technical stacks. The RDF format has quite different benefits - primarily around data analysis rather than exchange.
Unlike this rest of this page, the bulk use formats are draft until further experience is gained with their use. Their status will be reviewed in a future version of FHIR.
The XML and JSON formats are designed to support typical system process based data exchange uses. FHIR is also used to exchange large amounts of data- 1000s of records, or more (up to billions). The formats above can be used for this, but more suitable formats exist. This specification documents the following formats: