Foundation
This page is part of the FHIR Specification (v1.6.0:
STU
3 Ballot 4). 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
|
|
|
|
All extensions used in resources require a formal published definition which can be used by application developers, or the applications themselves, to help integrate extensions into the healthcare process they support.
Every extension in a resource refers directly to its definition, which is made available as a
StructureDefinition
.
A
resource
can
be
. A resource can be
profiled
to
specify
where
particular
extensions
are
used.
Whenever
resources
containing
extensions
are
exchanged,
the
definitions
of
the
extensions
SHALL
be
available
to
all
the
parties
that
share
the
resources.
Each
extension
contains
a
URI
that
references
the
source
of
the
definitions
as
a
to specify where particular extensions are used.
Whenever resources containing extensions are exchanged, the definitions of the extensions SHALL be available to all the parties that share the resources. Each extension contains a URI that references the source of the definitions as a
StructureDefinition
.
The
source
SHOULD
be
a
literal
reference,
such
as
an
http:
url
that
refers
to
an
end-point
that
responds
with
the
contents
of
the
definitions
-
preferably
a
FHIR
RESTful
server
supporting
the
Resources
Profile,
or
a
logical
reference
(e.g.
using
a
urn:)
-
for
instance,
to
a
national
published
standard.
Extensions
may
be
defined
by
any
project
or
jurisdiction,
up
to
and
including
international
standards
organizations
such
as
HL7
itself.
Before
defining
a
new
extension,
attempt
to
reuse
existing
extensions
defined
in
one
of
the
shared
registries
described
below
.
As
well,
some
concepts
may
be
appropriate
to
adding
as
part
of
the
core
specification.
. The source SHOULD be a literal reference, such as an http: url that refers to an end-point that responds with the contents of the definitions - preferably a
FHIR RESTful server
supporting the Resources Profile, or a logical reference (e.g. using a urn:) - for instance, to a national published standard. Extensions may be defined by any project or jurisdiction, up to and including international standards organizations such as HL7 itself.
Before defining a new extension, attempt to reuse existing extensions defined in one of the shared registries described below . As well, some concepts may be appropriate to adding as part of the core specification.
Elements are included as part of FHIR resources and data types principally on the basis of current world-wide usage patterns. Policy is that if a significant majority of systems throughout the world that would use a resource or data type would use an element, then that element will be included as part of the resource/data type. If not, it will be left to an extension. This holds even if the element is very common or even mandatory in one or two specific jurisdictions.
Proposals
suggesting
a
new
core
element
can
be
raised
by
anyone.
(Free
registration
is
required.)
However,
given
the
suggesting a new core element can be raised by anyone. (Free registration is required.) However, given the
timelines
for
new
FHIR
releases
as
well
as
the
uncertainties
associated
with
vetting
the
specification
through
a
ballot
process,
it
may
still
be
necessary
to
define
extensions
even
for
elements
that
are
likely
to
be
supported
as
part
of
the
core
specification
in
a
future
release.
for new FHIR releases as well as the uncertainties associated with vetting the specification through a ballot process, it may still be necessary to define extensions even for elements that are likely to be supported as part of the core specification in a future release.
Extensions are always defined against some particular context - the type of element that they may be used to extend. The following are possible contexts for an extension:
| Code |
|
|
Examples |
|---|---|---|---|
|
resource
| A particular element (including the root) in a single resource | The element path for that element, using the standard dotted notation |
Condition
Condition.code |
|
datatype
| A particular element (including the root) in a particular data type | The data type name for primitive types or the element path for complex data types. These extensions can be used anywhere the data type is used |
Address.part.value
string |
|
mapping
| A particular context in one of the mapped reference models | The name of the reference model followed by the mapping path. The details of the path depend on the named mapping | RIM: Act[moodCode="EVN"] |
|
extension
| Another extension | The profile URI of the extension followed by the extension code |
http://myextensions.org/someExtension
|
Note: For type 'resource' and 'datatype', if the context is an element that can have multiple types, then use the [x] qualified name (e.g. Observation.value[x]) if the extension works on all choice types, or otherwise an enumeration of explicitly named elements if not (e.g. Observation.valueQuantity)
In addition, the extension definition might apply additional constraints with regards to particular element values of the target that make its use appropriate. Extensions SHALL only be used on a target for which they are defined.
The cardinality constraints asserted by the extension definition itself apply to any contexts where the extension is used.
.
HL7
extension
definitions
may
be
balloted
alongside
resource
content
as
part
of
the
FHIR
specification
or
may
be
published
as
part
of
separate
specifications.
When
HL7
publishes
extension
definitions
as
part
of
the
FHIR
specification,
these
extensions
SHALL
be
used
for
this
data
whenever
the
data
is
represented
in
instances.
Applications
SHOULD
use
other
HL7-defined
extensions
published
to
represent
equivalent
data
in
the
interest
of
maximum
interoperability.
To
minimize
complexity
for
implementers,
HL7
will
not
elevate
widely
adopted
extensions
(defined
by
HL7
or
other
organizations)
to
be
content
defined
in
a
core
resource
in
future
versions
of
the
resource
unless
there
is
widespread
endorsement
of
such
a
migration
from
the
implementer
community.
This
policy
ensures
that
widespread
adoption
of
an
extension
does
not
result
in
a
forced
migration
to
a
core
element.
Extensions
labeled
as
draft
may
be
moved
in
either
direction,
but
after
extensions
are
finalised
as
normative
they
won't
be
moved.
In
some
cases,
an
HL7
work
group
or
other
body
may
publish
a
Minimum Cardinality
If the Extension minimum cardinality is 0, then the extension is optional anywhere it appears. A
profile
whose
sole
purpose
is
to
define
extensions
expected
to
be
needed
by
implementers
in
a
particular
context;
e.g.
extensions
needed
to
map
a
particular
set
of
HL7
v2
that defines the use of an extension may make the minimum cardinality any number up to maximum cardinality of the extension itself. Example: Example:
Patient birthplace
.
If the Extension minimum cardinality is > 1, then the extension must have a minimum cardinality of at least the minimum cardinality in any profile that defines the use of an extension. The the minimum cardinality may be any number up to maximum cardinality of the extension. Even with a minimum cardinality >0, the extension is only required to be present in instances if the inatances explicitly or implicitly conform to a profile that defines the use of the extension. Example: Conformance Expection .
segments
or
a
HL7
v3
Maximum Cardinality
model.
Implementations
are
encouraged
to
share
their
extensions
with
HL7
and
register
them
with
the
HL7
extension
registry.
The
domain
committees
will
work
to
elevate
the
extensions
into
HL7
published
extensions
or,
if
adopted
by
a
broad
enough
portion
of
the
implementer
community,
into
the
base
resource
structure
itself.
To
avoid
interoperability
issues,
extensions
SHALL
NOT
change
their
definition
once
published.
(Small
clarifications
to
descriptions
that
do
not
affect
interoperability
are
permitted.)
Rather
than
modifying
an
existing
extension,
a
new
extension
should
be
introduced.
Revisions
to
an
extension
may
extend
the
set
of
contexts
in
which
the
extension
apply
but
may
not
remove
or
constrain
any
context
previously
listed
©
HL7.org
2011+.
FHIR
DSTU2
(v1.0.2-7202)
generated
on
Sat,
Oct
24,
2015
07:44+1100.
Links:
Search
If the Extension maximum cardinality is 1, then the extension is only allowed once on any element on which it appears. A profile that defines the use of an extension can only make the maximum cardinality 1 (or zero if the minimum cardinality is 0, and the profile constrains another profile that allows the extension). Example: Mother's Maiden Name .
If the Extension maximum cardinality is >1, then the extension is allowed up to the specified number of times on any element on which it appears. A profile that defines the use of an extension may make the maximum cardinality any value up to the specified maximum. Example: Patient Disability .
An extension is a wrapper for url and a value or other extensions. As such, some of the properties of the extension are defined on the extension itself, while others are defined on the Extension.value. This list provides guidance for the correct usage:
As well as defining the base element structure for resources, HL7 also publishes extensions, including as part of this specification . HL7 publishes such data definitions as extensions rather than as part of the base resource structure in order to keep the base resource structure simple and concise, and to allow implementers not to engage with an entire world's worth of functionality up front. Note that HL7 does not generally define "modifier" extensions - if HL7 publishes an element that modifies the meaning of other elements, it will mostly be part of the resource content itself, since everyone has to understand the extension anyway.
Before extensions can be used in instances, their definition SHALL be published. HL7 maintains two extension registries:
Users are encouraged to register their extensions in the second registry, though this is not required. All that is required is that the extension is published in a context that is available for users of the extension. So, for example, if a particular extension is only used within a single institution, the definition of the extension can be placed on the institution's intranet. However since, by their nature, resources tend to travel well, it's always better to use the HL7 or other publicly accessible extension registries.
The HL7 FHIR registry can be found at
http://hl7.org/fhir/registry
.
HL7 extension definitions may be balloted alongside resource content as part of the FHIR specification or may be published as part of separate specifications. When HL7 publishes extension definitions as part of the FHIR specification, these extensions SHALL be used for this data whenever the data is represented in instances. Applications SHOULD use other HL7-defined extensions published to represent equivalent data in the interest of maximum interoperability.
To minimize complexity for implementers, HL7 will not elevate widely adopted extensions (defined by HL7 or other organizations) to be content defined in a core resource in future versions of the resource unless there is widespread endorsement of such a migration from the implementer community. This policy ensures that widespread adoption of an extension does not result in a forced migration to a core element. Extensions labeled as draft may be moved in either direction, but after extensions are finalised as normative they won't be moved.
In some cases, an HL7 work group or other body may publish a profile whose sole purpose is to define extensions expected to be needed by implementers in a particular context; e.g. extensions needed to map a particular set of
HL7 v2
segments or a
HL7 v3
model.
Implementations are encouraged to share their extensions with HL7 and register them with the HL7 extension registry. The domain committees will work to elevate the extensions into HL7 published extensions or, if adopted by a broad enough portion of the implementer community, into the base resource structure itself.
To avoid interoperability issues, extensions SHALL NOT change their definition once published. (Small clarifications to descriptions that do not affect interoperability are permitted.) Rather than modifying an existing extension, a new extension should be introduced. Revisions to an extension may extend the set of contexts in which the extension apply but may not remove or constrain any context previously listed
© HL7.org 2011+. FHIR STU3 Ballot (v1.6.0-9663) generated on Thu, Aug 11, 2016 17:07+1000.
QA Page
Links:
Search
|
Version History
|
Table of Contents
|
Compare to DSTU2
| 
|
Propose a change