This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version. For a full list of available versions, see the Directory of published versions . Page versions: R5R4BR4R3R2
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
. Page versions: R5 R4B R4 R3 R2
|
Propose a change