Foundation
This
page
is
part
of
the
Continuous
Integration
Build
of
FHIR
Specification
(v4.0.1:
R4
-
Mixed
Normative
and
STU
)
in
it's
permanent
home
(it
will
always
(will
be
available
incorrect/inconsistent
at
this
URL).
The
current
version
which
supercedes
this
version
is
5.0.0
.
For
a
full
list
of
available
versions,
see
times).
See
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
|
Responsible
Owner:
FHIR
Infrastructure
Work
Group
|
Standards Status : Normative |
This page documents the way version change is handled in FHIR. FHIR is a standard, so the way version change is handled is a bit different from an application API. This page describes:
See also Managing FHIR Versions for additional implementer advice about dealing with versions.
FHIR is a standard. In order to be useful, standards need to evolve. At the same time, the evolution of standards needs to be predictable and manageable for the implementation community. This section describes how HL7 develops a standard so that implementers know what to expect as the standard evolves.
HL7 has five descriptive terms that describe the level of stability and implementation readiness associated with different aspects of the specification. They are as follows:
| Standard Level | Description |
|---|---|
|
|
This
.
It
|
| Trial Use |
This content has been well reviewed and is considered by the authors to be ready for use in production systems. It has been subjected to ballot and approved as an official standard. However, it has not yet seen widespread use in production across the full spectrum of environments it is intended to be used in. In some cases, there may be documented known issues that require implementation experience to determine appropriate resolutions for. Future versions of FHIR may make significant changes to Trial Use content that are not compatible with previously published content. |
|
|
This
Some resources with a standards status of 'draft' have an FMM (FHIR Maturity Model) level of 1 or 2 - this means that the committee responsible for them is ready for them to be |
| Informative | This portion of the specification is provided for implementer assistance and does not make rules that implementers are required to follow. Typical examples of this content in the FHIR specification are tables of contents, registries, examples, and implementer advice |
| Deprecated | This portion of the specification is outdated and may be withdrawn in a future version. Implementers who already support it should continue to do so for backward compatibility. Implementers should avoid adding new uses of this portion of the specification. The specification should include guidance on what implementers should use instead of the deprecated portion |
Standards status, when found in a specification under ballot or in a Continuous Integration (CI) build reflects the intended status of the artifact after balloting is complete and the final publication is released.
Some Normative artifacts contain a few parts labeled as 'Trial Use' even though the artifact itself is labeled 'Normative' :
While
HL7
prefers
to
avoid
this
outcome,
there
are
several
resources
where
the
overall
functionality
of
the
artifact
is
clearly
ready
to
be
labeled
as
'normative'
while
some
very
specific
parts
are
known
not
to
have
the
requisite
level
of
implementation
experience
as
the
rest
of
the
resource.
E.g.
Bundle.signature
e.g.,
Bundle.issues
.
Where
a
Normative
resource
contains
elements
marked
as
trial-use,
these
elements
are
clearly
marked
in
the
resource
definitions.
Implementers
should
be
aware
that
future
versions
of
the
FHIR
specification
may
change
these
parts
of
the
resources
(in
addition
to
the
other
changes
allowed
under
the
inter-version
compatibility
rules
.
).
While
HL7
will
carefully
consider
the
consequences
of
breaking
change
to
these
elements,
implementers
should
be
aware
that
reading/using
these
elements
has
the
potential
to
cause
breaking
change
to
their
applications
later.
Note
that
this
same
status
will
arise
as
a
matter
of
process
when
Notes:
The
content
of
this
release
has
been
subject
to
significant
review
through
ballot
and
other
HL7
processes
and
many
aspects
of
it
have
been
implemented
and
subjected
to
interoperability
testing
through
Connectathons
and
early
adoption.
However,
the
degree
of
testing
has
varied.
Some
resources
have
been
well
tested
in
a
variety
of
environments.
Others
have
received
relatively
little
real-world
exercise.
In
general,
the
infrastructure
should
be
considered
to
be
more
stable
than
the
resources
themselves.
In
some
cases,
there
are
issues
on
which
input
is
specifically
requested
during
the
Trial
Use
period
(see
the
Outstanding
outstanding
Issue
List
,
List,
and
known
issues
will
arise
after
publication
(refer
to
the
FHIR
Change
Request
tracker
for
details.)
Guidance
from
early
implementation
will
help
address
these
areas.
All
artifacts
in
this
specification
are
assigned
a
"Maturity
Level",
known
as
FMM
(after
the
well-known
CMM
grades).
The
FMM
level
can
be
used
by
implementers
to
judge
how
advanced
-
and
therefore
stable
-
an
artifact
is.
The
following
FMM
levels
are
defined:
|
|
the
|
| FMM 1 |
|
| FMM 2 |
|
| FMM 3 |
;
has
been
subject
to
a
round
of
formal
balloting;
has
at
least
10
distinct
implementer
comments
recorded
in
the
tracker
drawn
from
at
least
3
organizations
resulting
in
at
least
one
substantive
|
| FMM 4 |
),
and
implemented
in
multiple
prototype
projects.
As
well,
the
responsible
work
group
agrees
the
artifact
is
sufficiently
stable
to
require
implementer
consultation
for
subsequent
non-backward
compatible
|
| FMM 5 |
FMM4
+
the
artifact
has
been
published
in
two
formal
publication
release
cycles
|
|
|
FMM5
+
the
responsible
work
group
and
the
FHIR
management
group
agree
the
material
is
ready
to
lock
down
according
to
the
inter-version
change
rules
and
the
artifact
has
passed
HL7
normative
ballot.
This
is
|
Tested across scope means:
has
signed
off
on
the
list
of
"example
contexts"
defined
for
the
artifact
The
Maturity
level
is
strongly
related
to
stability;
the
higher
the
maturity
level,
the
more
controls
are
enforced
to
restrict
breaking
changes
to
the
resource.
For
further
information,
and
discussion,
see
The
table
above
represents
a
frozen
snapshot
of
the
maturity
levels
maintained
by
the
FHIR
Management
Group
on
the
FHIR
Confluence
page
.
Further
information
and
discussion
about
these
levels
can
be
found
there.
The
maturity
model
is
significantly
influenced
by
the
degree
and
type
of
implementation
activity
using
an
artifact.
For
this
reason,
we
encourage
implementers
to
register
their
implementations
.
A
detailed
analysis
of
the
basis
for
the
maturity
metrics
for
FHIR
artifacts
can
be
found
here
.
New
versions
of
FHIR
will
be
are
published
on
a
release
cycle
of
approximately
18-24
months.
This
frequency
in
an
ongoing
basis.
The
time
between
publications
is
based
on
the
timelines
necessary
to
consult
with
implementers,
to
develop
and
review
new
content,
as
well
as
to
undertake
the
formal
balloting
and
reconciliation
processes
required
for
ANSI-approved
standards.
This
release
cycle
also
ensures
an
opportunity
to
incorporate
implementer
feedback
from
earlier
versions
of
the
specification
into
subsequent
versions.
Limited-scope
releases
on
a
shorter
timeline
may
occur
occasionally
where
necessary
to
meet
implementer
needs.
Each
new
release
of
FHIR
is
assigned
a
unique
version
number.
The
FHIR
version
policy
is
based
on
Semantic
versioning
,
but
with
some
differences
due
to
the
fact
that
FHIR
is
a
specification,
not
a
software
API.
There is a single development version of FHIR. This undergoes cycles of development as managed by HL7. Each major cycle of development is concluded by a formal ballot (or more than one), and then a new specification is published. In version control terms, each published specification is a branch off the development trunk, which may then itself undergo further change as HL7 maintains the published specification (though such changes are usually minimal, limited to necessary technical corrections or security alerts).
Each
FHIR
version
is
identified
by
a
string
composed
from
4
parts:
publication.major.minor.revision.
major.minor.patch-label.
|
|
|
|
|
|
|
|
|
|
|
|
Additional notes:
The FHIR version is usually known implicitly, but can be specified/determined by one of three methods:
For further information, see Managing Multiple FHIR Versions .
The following kinds of changes may be made to the specification:
NOTE:
The
examples
provided
as
part
intent
of
this
specification
are
never
substantive.
While
every
effort
these
rules
is
made
to
ensure
that
FHIR
examples
applications
that
are
correct,
changes
conformant
to
the
examples
in
the
an
existing
specification
are
not
considered
substantive.
also
conformant
to
subsequent
versions.
In
practice,
there
are
many
subtle
issues
around
inter-version
change,
and
the
exact
rules
are
subject
to
further
clarification
based
on
feedback
from
implementers.
Content with a status of Draft or Trial Use can change - including Breaking Changes - from version to version, subject to the rules described by the Maturity Process . There are no rules for maintaining any sort of compatibility between versions for content with these statuses, though of course we will only make breaking changes based on feedback from the community.
Once an artifact achieves Normative status, specific rules come into play around inter-version compatibility. These rules have implication for both forward and backward compatibility and are intended to allow implementations to exercise FHIR interfaces and process the content of FHIR resources safely while exchanging data between systems using different versions of FHIR. These rules do not apply to non-normative content, including STU content within normative artifacts.
In rare circumstances, HL7 may approve changes that technically break content with a status of Normative where there is a high level of confidence that the change will not impact existing implementers. Such deviations from the declared rules will involve broad notification, extensive community consultation and reviews by multiple levels of HL7 governance processes.
Yes, this this is the second dragon in as many paragraphs. Inter-version compatibility is complicated...
The assertion around non-breaking change does NOT mean that the types of changes permitted here cannot cause existing systems to fail, even if they make allowances for the types of changes permitted. (Though those that make allowances will hopefully fail more gracefully.) Because the requirements of healthcare continue to evolve, the rules defined here allow for new content to be introduced - new codes, new elements, etc. Depending on the design of a receiving system, such new content may cause failure. A system that relies on schema validation will fail because of a new element. A system that relies on a select statement iterating through 'status' codes might fail or behave unexpectedly due to incorrect fall-through when a new status code is introduced. Systems designers are strongly encouraged to consider the types of changes permitted here and consider how these types of changes will impact their ability to safely function when dealing with newer versions of FHIR.
NOTE: The examples provided as part of this specification are never substantive. While every effort is made to ensure that FHIR examples are correct, changes to the examples in the specification are not considered substantive.
Forward compatibility means that content that is conformant in an old release will remain conformant with future versions. Once normative, FHIR's rules try to enforce forward compatibility. However, that doesn't guarantee that all old systems will interoperate with future systems.
Backward compatibility means that instances created against future versions of the specification will interoperate with older versions of the specification. This is not guaranteed by FHIR, though there are strategies systems can adhere to that will increase their chances of such interoperability. Specifically, when dealing with content from a system supporting an unknown normative version and wishing to maximize backwards compatibility, applications SHOULD:
However,
in
a
healthcare
context,
many
implementers
are
unwilling
to
consider
some
of
these
steps
because
of
concerns
about
clinical
risk
or
technical
limitations
in
their
software
(e.g.
(e.g.,
schema-based
processing).
.
| Category | Allowed changes |
|---|---|
| Resources | New artifacts resources may be introduced. Existing resources will not have their names changed |
| Artifacts (resources, profiles, code systems, etc.) |
New
artifacts
including
new
resources
and
|
| Elements |
New
optional
elements
and/or
content
|
| Cardinality |
Minimum
element
cardinalities
will
not
be
changed.
Upper
cardinality
may
change
from
1
to
*
only
in
circumstances
where
all
elements
except
for
the
first
repetition
can
be
safely
ignored.
Note
that
this
may
change
the
path
to
the
element
in
some
syntaxes
|
| Descriptions | Descriptive information about a resource - short labels, definitions, usage notes, aliases, examples, rationale, mappings, etc. may be updated or revised to provide additional clarity or guidance, but not in such a manner as to invalidate a reasonable interpretation of the previously documented use of an element. (This does not preclude fixing obvious errors.) |
| Value Sets and Code Systems |
The definition of any value set that is marked as immutable will never change. The expansions for immutable value sets may still change if no "stable date" is declared and the value set does not restrict code system and/or value set references to specific versions and the codes in the referenced code system(s) or value set(s) change. For non-immutable value sets:
For both immutable and non-immutable value sets, additional designations may be declared. Normative CodeSystems whose content is generated from a mix of normative and non-normative contents may break these rules. For example, the code system containing the list of all resources may have codes removed or renamed as non-normative resources are removed or renamed.
These
expectations
only
apply
to
Value
Sets
and
Code
Systems
maintained
as
part
of
the
FHIR
specification.
HL7
cannot
enforce
these
rules
on
terminology
artifacts
maintained
by
other
authorities
-
|
| Terminology Bindings |
|
|
|
Except
as
described
in
the
preceding
paragraph,
|
| Value Constraints |
The
allowed
list
of
|
| Flags | The Is Modifier and Is Summary flags will not be changed. |
| Slicing | Slicing rules and aggregation characteristics will not be changed. |
| Search Criteria | Search criteria may be added but not removed or renamed. Existing criteria will not have their type or path changed or have their description altered in any way that would invalidate the reasonable behavior of existing systems (except for correcting obvious errors). |
| Operations | New operations may be defined but operations will not be removed or renamed. Existing parameters will not be removed or renamed, nor may their type or lower cardinality be changed. Upper cardinality may be changed from 1 to *. (Systems should ignore unexpected repetitions.) Additional optional parameters may be introduced. Changes to operations that would violate the preceding constraints will be handled by defining new operations and, potentially, deprecating the old operations. |
| Restful interface | Existing endpoints will not be renamed or removed, nor have their expected behavior changed in a manner that would cause reasonable systems designed against prior versions to be non-interoperable. Additional endpoints and interactions may be introduced. |
| Profiles and extension definitions |
Profile
structure,
extension
definitions
and
search
criteria
definitions
will
not
be
removed
or
have
their
URIs
changed.
New
profile
structures,
extension
definitions
and
search
criteria
definitions
may
be
introduced.
Profiles
may
have
their
statuses
changed
to
"retired".
Profiles
referenced
by
data
elements
for
structures
or
|
| Capability Statements | Within the CapabilityStatements for defined FHIR Services or 'core' implementation guides, additional operations may be added. These additions might be optional (MAY/SHOULD) or mandatory (SHALL). Note that the introduction of mandatory operations would break forwards compatibility and will only occur with community consultation. |
| Implementation Guides |
Additional
artifacts
can
be
added,
and
artifacts
can
be
changed.
The
list
of
global
profiles
will
not
|
| References |
Where
one
conformance
resource
points
to
another
|
| Conformance Language |
SHALL
statements
cannot
be
broken
(though
they
can
be
clarified)
and
|
Once
content
is
normative,
there
is
a
process
for
removing
it
from
the
standard
by
marking
it
as
deprecated
or
withdrawn
(from
the
HTML
4.0
Standard
):
| Deprecated | Systems should continue to support the artifact/feature/concept, but are discouraged from making use of it |
| Withdrawn | Documented for historical purposes, no longer supported |
The
specification
will
provide
guidance
with
deprecated
materials
showing
how
to
avoid
using
them.
Deprecated
materials
are
eligible
to
be
balloted
to
be
withdrawn
two
years
after
their
deprecated
status
is
published.
The
computable
artifact
labels
(e.g.
(e.g.,
codes,
element
names,
urls,
etc.)
associated
with
withdrawn
materials
SHALL
not
be
used
in
future
versions
of
HL7
specifications.
Materials
marked
"deprecated"
may
have
that
marking
removed
as
part
of
a
subsequent
ballot
at
a
later
moment,
while
withdrawn
materials
SHALL
NOT.
The following artifacts are deprecated in this version of FHIR:
Additional
discussion
on
inter-versioning
issues
can
be
found
here:
https://confluence.hl7.org/display/FHIR/Interversion+Compatibility
.
Regardless
of
the
degree
of
prior
implementation,
all
aspects
of
the
FHIR
specification
are
potentially
subject
to
change
while
an
artifact
has
a
status
of
Draft
or
Trial
Use
.
These
changes
may
be
minor
(clarifications
of
definitions,
etc.)
or
major
(refactoring
of
resources,
changes
to
serialization
rules,
eliminating
or
adding
data
types,
datatypes,
etc.)
There
is
no
commitment
to
backward
or
forward
compatibility
during
the
trial
use
process
until
content
is
normative.
Changes
will
not
be
made
without
cause,
however
the
interests
of
long-term
implementability
will
generally
trump
the
impact
on
early
adopters
when
determining
what
changes
should
be
made.
This
balance
will
shift
more
towards
early
adopters
as
maturity
levels
increase.
I.e.
i.e.,
Impact
on
existing
implementations
will
be
weighted
more
highly
for
an
FMM-level
5
artifact
than
they
would
for
an
FMM-level
1
artifact.
Implementers who are willing to accept the risk of change (perhaps for the benefit of early implementation experience, first mover advantage and the ability to leverage FHIR's intrinsic benefits) are encouraged to implement those parts of FHIR that are early in the maturity cycle in real-world systems. However, those implementers should be aware that local adaptations may be necessary to meet real-world requirements. Furthermore, such implementers should architect their solutions to be tolerant of changes to the specification and, where necessary, to manage interoperability with systems that may be using different versions of the specification or different local adaptations.
During
the
Trial
Use
period,
requests
for
change
may
be
submitted
using
the
HL7
issue
tracker
which
can
be
found
here
.
Where
possible,
updates
to
the
"development"
version
of
the
specification
will
be
made
in
a
timely
fashion.
Implementers
should
be
aware
that
the
changes
are
not
considered
"official"
until
such
time
as
they
are
balloted
and
approved
as
part
of
a
subsequent
Trial
Use
or
Normative
publication.
Change
requests
might
be
fixes
to
allow
implementation,
clarifications
or
enhancements.
In
addition,
HL7
will
be
developing
and
introducing
additional
resources
and
profiles
as
part
of
the
FHIR
specification.
SDOs and regulatory bodies that are interested in making use of the FHIR specification should feel free to do so, but should consider and plan for the possibility that the specification will evolve and change prior to becoming Normative .
A
key
aspect
of
the
FHIR
specification
development
process
is
gaining
feedback
from
implementers
making
use
of
the
specification.
As
well,
the
process
is
conditional
on
real
world
real-world
implementation
in
order
to
move
through
the
maturity
cycle.
For
this
reason,
all
FHIR
implementers
are
encouraged
to
register
their
usage
here
,
which
captures
contact
and
other
information
that
will
allow
HL7
to
perform
appropriate
monitoring
of
FHIR
usage.
Survey
information
is
confidential
and
reported
in
aggregate
only.
One type of breaking change that can happen between trial-use versions is that elements that were previously mandatory might be removed or made optional. When converting data from future releases of FHIR, no data will be available for these elements. The '1' minimum cardinality can be satisfied by sending a data-absent-reason extension with a value of "not-applicable". Systems SHOULD always check not only for an element but a value for the element when writing their logic.
Many implementations need to convert resources from one FHIR version to another. Once resources become normative (once sufficiently mature and stable), converting resources forwards from past versions is not needed. Converting back to older versions presents a challenge, however, in that the newer version may add additional elements that are not present in the older version. In some cases, the elements are simply irrelevant since the requirements they represent are not in scope for older applications, but in other cases, it is necessary to represent the data in order to cater for round-tripping.
A more complex problem arises with resources that are not yet stable (early in the maturity process). If applications have implemented less stable resources, not only do they have the problem of new elements for new requirements, the specification may change in either compatible or incompatible ways, and it may be necessary to carry data elements from past versions forward in order to allow seamless round-tripping.
In
order
to
help
authors
and
implementers
with
address
this
problem,
any
element
defined
in
any
version
HL7
defines
a
set
of
FHIR
is
automatically
assigned
an
extension
URL
cross-version
packages
that
uniquely
identifies
the
define
extensions
for
every
element
and
can
that
is
present
in
all
other
major
versions
of
FHIR.
These
extensions
allow
data
from
other
versions
to
be
used
represented
in
the
relevant
FHIR
version.
The
extension
a
standard
way.
In
order
to
make
detection
of
these
extensions
easier,
they
are
defined
with
a
standard
URL
for
an
element
can
automatically
be
derived:
pattern:
http://hl7.org/fhir/[defining_version]/StructureDefinition/extension-[Path]
where
[version]
[defining_version]
is
taken
from
this
list:
|
FHIR
DSTU2
|
1.0 |
|
FHIR
R3
(STU3,
or
just
R3)
|
3.0 |
|
FHIR
R4
(mixed
STU/Normative)
| 4.0 |
|
FHIR
R4B
(only
STU
changes)
| 4.3 |
|
FHIR
R5
(this
version)
|
|
This table includes the formal milestone releases for DSTU2 and on, which are the only releases for which this process is defined. Older versions than that are not supported. Technical correction releases are not listed because they will never introduce or change elements. Ballot and interim releases are not supported for use in implementation environments
Note
that
this
not
every
element
will
have
an
extension
framework
from
a
given
FHIR
version.
Extensions
are
only
applies
back
defined
for
elements
that
do
not
have
a
way
of
representing
the
data
in
the
target
version
-
e.g.
elements
that
do
not
exist,
elements
with
types
that
do
not
exist,
or
elements
with
changes
that
prevent
direct
representation
(e.g.
maximum
cardinality
changes
from
1
to
DSTU2.
*
).
The
[Path]
is
actually
the
ElementDefinition.id
from
the
relevant
StructureDefinition
for
the
element.
This
leads
to
URLs
like
the
following:
http://hl7.org/fhir/4.0/StructureDefinition/extension-Bundle.signature
|
R4
Signature
Element
on
Bundle
|
http://hl7.org/fhir/3.0/StructureDefinition/extension-Patient.animal.species
|
STU3
Species
Element
on
Patient
|
http://hl7.org/fhir/1.0/StructureDefinition/extension-ValueSet.extensible
|
DSTU2
ValueSet.extensible
|
Implementers
should
Further
details
can
be
aware
of
found
in
the
following
issues
when
using
these
extensions:
individual
cross-version
definition
packages.
|
|
|
|
|
|
|
|
|
|
n/a |
|
|
|
|
|
|
|
|
n/a |
|
|
|
|
|
|
|
|
n/a |
|
|
|
|
|
|
|
|
n/a |
|
|
|
|
|
|
|
|
n/a |
|
|
|
|
|
|
|
|
n/a |
Note
for
balloters:
these
packages
that
some
guides
linked
above
will
not
exist
at
the
time
of
publication
(e.g.,
extensions
based-on
or
targeting
this
release).
The
links
will
be
created
when
R4
is
finalized.
Until
then,
these
correct
and
will
resolve
once
the
packages
are
broken
links.
available.
While
This
specification
is
the
result
of
fifteen
years
of
work
by
HL7,
its
standards,
government
and
implementation
partners,
along
with
the
wider
(huge)
FHIR
implementation
community.
This
is
the
first
full
normative
version
of
the
standard
-
none
of
the
content
in
this
mixed
Normative
specification
is
considered
trial-use.
The
FHIR
implementation
community
and
Trial
Use
release
implementation
base
is
occurring,
development
now
massive
and
the
pace
of
implementation
adoption
of
new
versions
is
slowing.
Note
that
for
this
release,
the
extensions
have
been
moved
out
into
a
separate
module
and
updated
versions
will
be
progressing
on
published
regularly.
See
the
Extension
Version
Policy
for
further
information.
Irrespective of the choice around publication speed and whether to publish partial new branch versions, HL7's general intent for the Release 6 is to move most of the resources in the Foundation, Base and Clinical layers (see the 'Category' tab in the Resources pages ) to full Normative status, along with a few other resources including e.g., Questionnaire.
Whatever
HL7
decides
to
do
with
regard
to
the
formal
status
of
the
resources,
the
next
release.
This
next
release
will
include
additional
clarifications,
resources,
profiles
and
quality
enhancements
over
the
current
release
based
on
implementation
experience
and
ongoing
development
work.
It
will
also
incorporate
fixes
for
issues
raised
with
the
FHIR
issue
tracker
.
It
may
might
be
useful
for
implementers
of
the
STU
this
release
to
review
the
candidate
current
release
(at
http://build.fhir.org
)
to
get
a
sense
of
what
changes
are
likely
coming
and
perhaps
to
find
more
robust
definitions
and
guidance
than
are
available
in
the
this
release.
Some
implementers
who
are
dependent
on
content
that
exists
in
a
draft
release
may
might
choose
to
implement
based
on
a
particular
snapshot
of
the
development
release,
though
in
doing
so,
they
will
limit
their
potential
communication
partners.
The
next
major
publication
of
FHIR
will
In
addition,
implementers
should
be
Release
5.
It
is
our
hope
release
5
will
include
more
Normative
content,
including
more
aware
that
most
of
the
core
patient
summary
clinical
content.
Other
content,
implementation
tooling
including
most
if
not
all
clinical
knowledge/reasoning,
care
planning,
and
financial
resources,
are
likely
to
remain
at
the
Trial
Use
level
as
they
are
those
provided
by
HL7
will
not
expected
to
meet
support
interim
versions
other
than
the
criteria
for
Normative.
latest
release.
More
information
on
plans
for
Release
5
can
be
found
on
the
HL7
product
director's
blog
.
(Subscribing
to
this
blog
is
a
good
way
to
keep
current
on
significant
events
in
FHIR
development,
including
ballot
and
publication
timelines.)
There
will
be
additional
releases
of
FHIR
with
a
frequency
of
somewhere
between
18
and
24
months
for
the
foreseeable
future.
These
releases
will
include
maintenance
on
Normative
content,
new
content
(e.g.
in
the
public
health,
financial
or
clinical
research
spaces),
revisions
to
trial
use
content
reflecting
implementer
feedback
and
increasing
maturity
on
Trial
Use
artifacts
and
the
migration
of
additional
content
to
normative
status.
As
well,
HL7
will
continue
to
focus
to
providing
additional
guidance
through
the
publication
of
implementation
guides
and
profiles
where
consensus
can
be
found
at
the
international
level.
timelines).
FHIR
®©
HL7.org
2011+.
FHIR
Release
4
(Technical
Correction
#1)
(v4.0.1)
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Fri,
Mon,
Nov
1,
2019
09:37+1100.
QA
Page
10,
2025
15:24+0000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
R3
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change