This page is part of the FHIR Specification (v1.4.0:
STU
3 Ballot 3). The current version which supercedes this version is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
. For a full list of available versions, see the
Directory of published versions 
.
Page
versions:
. Page versions:
R5
R4B
R4
R3
R2
|
|
|
|
| This page and the RDF forms are joinlty maintained by the HL7 FHIR project and the
W3C Semantic Web Health Care and Life Sciences Interest Group |
FHIR resources can be represented as an
RDF graph
How
to
exchange
RDF
using
the
RESTful
API
serialised in the
Turtle format
Note:
this
page
uses
turtle
for
clarify
and
readability,
but
there
is
no
requirement
or
expectation
that
turtle
should
be
used
in
preference
to
other
syntaxes.
Note
that
production
turtle
instances
would
not
be
laid
out
so
clearly
either.
Implementer
Note:
The
FHIR
RDF
format
is
defined
to
assist
the
process
of
bridging
between
operational
data
exchange
and
formal
knowledge
processing
systems.
While
the
RDF
form
offers
a
fully
functional
representation
of
FHIR
resources,
it
has
very
different
operational
characteristics
from
the
. The RDF format is defined to assist the process of bridging between operational data exchange and formal knowledge processing systems. While the RDF form offers a fully functional representation of FHIR resources, it has different operational characteristics to the
JSON
and
and
XML
,
and
would
be
implemented
for
different
reasons.
Systems
focused
on
operational
exchange
of
data
would
not
generally
use
RDF.
1.18.3.1
RDF
Representation
of
FHIR
The
FHIR
RDF
definitions
are
defined
for
the
following
purposes:
Providing
the
class
definitions
to
support
RDF
based
representation
of
resource
instances
Supporting
knowledge
based
analysis
of
the
FHIR
specification
itself
Providing
knowledge
of
use
at
run-time
for
converting
between
FHIR
and
other
content
models
Supporting
reasoning
across
the
information/terminology
model
boundary
The
RDF
definitions
are
published
as
a
series
of
turtle
files
RIM
and
FHIR
.
1.18.3.1.1
RDF
Class
Definitions
The
backbone
of
the
RDF
definitions
are
a
formal
definition
of
the
FHIR
resources
as
RDF
classes.
Each
data
type,
resource,
or
element
within
a
resource
is
defined
as
rdf:Class
with
a
series
of
rdf:Property
items.
Each
property
has
a
rdfs:range
the
specifies
the
value
domain
for
the
property.
In
most
cases,
the
conversion
from
the
base
resource
definitions
is
straightforward.
Constraints
are
represented
in
two
ways
-
as
OWL
statements,
and
as
SHACL
predicates.
Implementers
wishing
to
enforce
constraints
can
use
tools
from
either
language,
or
process
the
knowledge
represented
in
these
constraints
in
any
other
way
they
see
fit.
1.18.3.1.2
Enumerated
Codes
FHIR
elements
that
have
a
code
data
type
with
a
Required
binding
to
an
extensional
ValueSet
are
bound
directly
to
the
concepts
defined
in
the
code
system.
The
RDF
defines
the
value
set,
an
associated
code
system,
and
an
RDF
class
for
the
code
system.
Each
code
in
the
code
system
is
defined
as
a
singleton
class
where
the
class
elucidates
the
definition
and
relationships
of
the
concept,
and
the
single
instance
is
used
to
refer
to
the
concept.
1.18.3.1.3
The
Ontological
RIM
THe
RDF
definitions
for
the
resources
and
classes
are
also
mapped
to
an
ontological
representation
of
the
v3
RIM,
which
is
also
distributed
as
part
of
this
specification
(
turtle
and
RDF/XML
).
The
resources
and
type
definitions
refer
to
both
classes
and
code
systems
defined
as
part
of
the
RIM.
The
references
to
the
classes
defined
in
the
RIM
are
generally
only
of
interest
from
a
RIM
perspective;
they
do
not
define
semantics
that
are
necessary
to
understand
the
FHIR
resources
directly.
The
Ontological
RIM
is
a
variant
of
the
v3
RIM
optimised
for
its
use
as
an
ontology
supporting
FHIR
and
other
reasonsing
uses.
It
has
the
following
variations
from
the
classical
HL7
v3
RIM:
II.root
and
CD.codeSystem
are
changed
to
xs:anyUri
so
that
they
can
accomodate
RDF
concepts
as
well
as
pure
OIDs
and
UUIDs
The
structure
of
the
CD
data
type
has
been
re-organised
to
support
validation
logic
more
effectively
Only
the
base
structural
classes
are
included
(yet?)
More:
mixins?
associations?
nullFlavor
on
associations?
representations, and would be implemented for different reasons. Systems focused on operational exchange of data would not generally use choose to use RDF.
This page describes:
A FHIR resource is represented by a series of RDF triples. The Turtle representation for a resource is described using this format:
Turtle Template [ a fhir:Observation; fhir:nodeRole fhir:treeRoot; # from Resource: id; meta; implicitRules; and language # from DomainResource: text; contained; extension; and modifierExtension fhir:Obervation.identifier [ Identifier ]; # 0..* Unique Id for this particular observation fhir:Obervation.status [ fhir:value "<code>" ]; # R! registered | preliminary | final | amended + fhir:Obervation.code [ CodeableConcept ]; # 1..1 R! Type of observation (code / type) fhir:Obervation.subject [ fhir:reference [ Patient|Group|Device|Location ] ]; # 0..1 Who and/or what this is about fhir:Obervation.encounter [ fhir:reference [ Encounter ] ]; # 0..1 Healthcare event during which this observation is made # effective[x]: 0..1 Clinically relevant time/time-period for observation. One of these 2: fhir:Obervation.effectiveDateTime [ fhir:value "<dateTime>" ]; fhir:Obervation.effectivePeriod [ Period ]; ]
Note: this is a placeholder for when the proper format is defined .
Using this format:
text/turtle
.
Each resource is represented as a set of RDF triples represented using the Turtle syntax. When a resource has a persistent identity (e.g. it can be found at a particular URL - usually a FHIR RESTful server), then that URL is it's identity. Resources with no persistent identity (e.g. bundles from search results) have the the identity is "_".
Some resources can contain other resources. Given that the relationships can appear in any order, it cannot be assumed that the first encountered element represents the resource of interest that is being represented by the set of turtle statements. The focal resource - where to start when parsing - is the resource with the relationship
fhir:nodeRole
to
fhir:treeRoot
. if there is more than node in a set of turtle statements, it cannot be determined how to parse them as a single resource.
Elements that can repeat are represented by a relationship
fhir:index [n]
where [n] is a zero-based integer offset (ie.g the first element has an index of 0). Lists are never sparse; it is an error if there are missing items in the repeat sequence.
Primitive elements - elements with a primitive type - are represented as regular nodes so that the elements extensions can be represented. The actual value of the primitive type is represented using the fhir:value predicate:
fhir:index "[value]"^^xs:type
The value is always a literal string that contains the value, followed by a schema type as specified for the primitive type . The schema type is required, but may be omitted when the defalut value of xs:string is correct. Note that the correct schema type for a date/dateTime must be determined by inspecting the value of the date for precision.
The fhir:value property can never be empty. Either the relationship is absent, or it is present with at least one character of content. XHTML is represented as an escaped xs:string.
A Reference element is representing using the same rules as above:
fhir:Observation.subjectReference [
fhir:Reference.reference [ fhir:value "Patient/example" ];
fhir:Reference.display [ fhir:value "Example Patient" ];
];
This allows faithful round tripping of the resource between the Turtle format and the JSON and XML formats. But it's very useful for an RDF processor to be able to link to the target of the reference directly. This can be done using the fhir:reference property:
fhir:Observation.subjectReference [
fhir:reference <http://hl7.org/fhir/Patient/example>;
fhir:Reference.reference [ fhir:value "Patient/example" ]
];
The fhir:reference relationship can be added automatically as part of generating the resource representation, or it can be injected by a post-processor that knows how to convert the raw references into RDF-suitable references.
The same logic applies to the
Coding
and
its
container
and
CodeableConcept
represent
references
from
a
resource
to
a
separate
knowledge
container.
The
definitions
of
the
Coding
data
type
are
constained
by
operational
considerations
around
incomplete
knowledge,
longitudinal
version
issues,
use
across
multiple
contexts,
etc.,
so
a
mapping
process
is
required
to
match
the
information
that
constitutes
the
Coding
reference
to
the
target
RDF
concept
on
which
reasoning
will
be
based.
For
instance,
a
reference
to
a
LOINC
code
in
a
JSON
resource
instance
takes
this
form:
{
"resourceType" : "Observation",
"code" : {
"coding" : {
"system" : [ fhir:uri.value "http://loinc.org"],
"code" : [ fhir:code.value "54411-4"],
"display" : [ fhir:string.value "Rh immune globulin given Qualitative"]
},
"text" : "Rh immune globulin"
}
}
As
an
example,
in
the
local
LOINC
RDF
representation,
the
URI
for
that
LOINC
code
is
http://loinc.org/owl/54411-4.
(Note
that
for
many
terminologies,
including
LOINC,
there
is
no
standard
RDF
representation
and
multiple
forms
with
different
addressing
schemes
are
available.
Where
standard
representations
exist,
implementers
SHOULD
use
the
same
addressing
scheme.)
There
is
no
algorithmic
conversion
between
the
system/code
and
the
equivalent
RDF
concept;
instead,
a
mapping
table
or
process
of
some
kind
must
be
maintained.
These
mapping
tables
have
variable
complexity.
In
the
worst
case
-
codes
that
have
the
form
of
an
expression
-
considerable
syntactic
and
semantic
logic
is
required
to
perform
the
mapping.
For
this
reason,
the
reconciliation
process
is
often
performed
as
a
preprocessing
step
prior
to
using
the
RDF
for
reasoning.
Once
the
reconciliation
process
is
complete,
the
resolved
concepts
are
stated
as
rdf:type
assertions
on
the
concept:
@prefix loinc: <http://loinc.org/owl#> .
:resource a fhir:Observation;
data types. These are represented directly in turtle by serialising their properties as specified above:
fhir:Observation.code [a loinc:54411-4;fhir:CodeableConcept.coding [ fhir:index 0; fhir:Coding.system [ fhir:value "http://loinc.org" ]; fhir:Coding.code [ fhir:value "29463-7" ]; fhir:Coding.display [ fhir:value "Body Weight" ] ]; fhir:CodeableConcept.coding [fhir:Coding.system [ fhir:uri.value <http://loinc.org>] ; fhir:Coding.code [ fhir:code.value "54411-4" ]; fhir:Coding.display [ fhir:string.value "Rh immune globulin given Qualitative"]; ]; fhir:CodeableConcept.text [ fhir:string.value "Rh immune globulin" ]; ]. Typically, these type assertions are only used in the RDF form, but they can be carried as a normal FHIR extension in both the XML and JSON forms: { "resourceType" : "Observation", "code" : { "extension" : { "url" : "http://hl7.org/fhir/StructureDefinition/rdftype", "valueUri" : "http://loinc.org/owl/54411-4" }, "coding" : { "system" : "http://loinc.org", "code" : "54411-4", "display" : "Rh immune globulin given Qualitative" }, "text" : "Rh immune globulin" } } Implementers should note that these type assertions often reference local ontologies, and the correct URI may be scope dependent or may vary on a different lifecycle due to the coding information itself, and so it is usually not appropriate to persist these references. These type assertions may be made against either CodeableConcept or Coding data types; when the FHIR resource property has a type of CodeableConcept they should be made at this level rather than on the Coding.fhir:index 1; fhir:Coding.system [ fhir:value "http://snomed.info/sct" ]; fhir:Coding.code [ fhir:value "27113001" ]; fhir:Coding.display [ fhir:value "Body weight" ] ] ];
For reasoners using the RDF, it's very useful to make the implicit concept references in these Coding and CodeableConcept explicit using rdfs:type assertions:
fhir:Observation.code [
a loinc:29463-7;
a sct:27113001;
fhir:CodeableConcept.coding [
fhir:index 0;
a loinc:29463-7;
fhir:Coding.system [ fhir:value "http://loinc.org" ];
fhir:Coding.code [ fhir:value "29463-7" ];
fhir:Coding.display [ fhir:value "Body Weight" ]
];
fhir:CodeableConcept.coding [
fhir:index 2;
a sct:27113001;
fhir:Coding.system [ fhir:value "http://snomed.info/sct" ];
fhir:Coding.code [ fhir:value "27113001" ];
fhir:Coding.display [ fhir:value "Body weight" ]
]
];
These type assertions can be make by any agent that knows how to convert from the code system to the correct ontological representation of that. Note that a few code systems have standard ontological representations, but many don't. Again, these assertions can be made by the serialiser, or injected by a post-processor.
FHIR uses ShEx for representing the turtle schema. Todo: actually generate the ShEx schema.
In addition to the basic representation of FHIR resources in turtle format, a Turtle representation of the FHIR infrastructure and definitions is also published, for the following purposes:
The RDF definitions are published as a series of turtle files: RIM and FHIR . Note: these are out of sync with the serialization above; this will be fixed in the lead up to the Montreal connectathon.
TODO
© HL7.org 2011+. FHIR STU3 Candidate (v1.4.0-8139) generated on Thu, Mar 31, 2016 08:10+1100.
QA Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Compare
to
DSTU1
|
Version History
|
Table of Contents
|
Compare to DSTU2
|
|
|
Propose
a
change
|
Propose a change