This
page
is
part
of
the
FHIR
Specification
(v5.0.0:
R5
-
STU
v6.0.0-ballot1:
Release
6
Ballot
(1st
Draft)
(see
Ballot
Notes
).
This
is
the
The
current
published
version
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
R2
This
page
provides
mappings
for
Element
Definition
(see
Mappings
to
Other
Standards
for
further
information
&
status).
Many
other
standard
frameworks
define
frameworks
for
defining
"data
elements".
These
overlap
to
some
degree
with
the
ElementDefinition
type.
This
page
provides
general
mappings
between
ElementDefinition
and
the
other
frameworks.
One
important
consideration
with
regard
to
other
Element
definition
frameworks
is
the
scope
of
the
definition.
Many
of
these
definition
frameworks
use
the
term
"Data
Element"
to
refer
to
a
data
item
that
is
collected
and
stored
with
provenance,
such
as
when
it
was
collected,
who
recorded
it,
etc.
In
this
specification,
that's
an
Observation
,
and
the
definition
of
this
kind
of
data
element
is
an
ObservationDefinition
,
or
a
StructureDefinition
that
contains
several
different
atomic
data
items.
An
ElementDefinition
in
this
specification
is
a
narrower
notion,
solely
around
the
characteristics
of
a
single
element,
its
definition,
and
its
value
domain
.
Other
frameworks
-
especially
ISO
11179
-
are
used
in
both
ways,
sometimes
with
no
formal
differentiation
between
them.
For
this
reason,
the
mappings
on
this
page
are
very
provisional,
and
are
provided
with
the
intent
of
helping
implementers
understand
the
possible
relationships.
Mappings
to
the
LOINC
master
table
which
defines
observations
-
this
may
be
relevant
when
the
element
describes
an
observable
piece
of
data.
This
is
particularly
relevant
in
profiles
of
observation,
and
also
related
to
ObservationDefinition
Mappings
to
ISO
11179
which
details
how
the
ElementDefinition
class
relates
to
the
ISO
11179
framework.
Note
that
the
principle
differences
are
that
FHIR
does
not
differentiate
between
a
Data
Element
and
a
Data
Element
Value,
and
the
FHIR
specification
is
heavily
type
dependent.
Also,
the
FHIR
specification
includes
constraints
and
other
concerns
that
are
outside
the
scope
of
ISO
11179
(Designatable_Item).designation.sign
acceptability!=preferred
or
context
is
other
than
default
min
Minimum
size
of
data
element
values?
max
Maximum
size
of
data
element
values?
base
n/a
path
n/a
min
n/a
max
n/a
contentReference
type
.domain.data+Q14type
code
.domain.data+Q14type
profile
n/a
targetProfile
n/a
aggregation
n/a
versioning
defaultValue[x]
meaningWhenMissing
orderMeaning
fixed[x]
N/A
(only
relevant
when
constraining,
which
11179
doesn't
do)
pattern[x]
example
label
value[x]
.example
minValue[x]
maxValue[x]
maxLength
.domain.maximum_character_quantity
condition
constraint
??
key
requirements
severity
suppress
human
expression
source
mustHaveValue
valueAlternatives
mustSupport
??
isModifier
??
isModifierReason
isSummary
??
binding
.domain
strength
description
.domain.description
valueSet
points
to
explicit
list
or
expression
that
evaluates
to
list
of
(Enumerated_Value_Domain).member
additional
purpose
valueSet
documentation
shortDoco
usage
any
mapping
Registered_item).document_reference[document_type=mapping]
Also,
.meaning
linkage
to
Data_Element_Concept
is
done
as
a
mapping
to
a
reference
model.
(Data_Element_Concepts
are
all
defined
in
some
sort
of
reference
model,
be
that
Object_Class
and
Property
or
some
other
mechanism)
identity
language
map
ObjectClass,
Property
(this
is
one
possible
data
model
that
can
be
mapped
to
-
the
uri
would
identify
the
data
model
mappingSpecification.mappingScript
Foundation
|
Propose
a
change