Foundation
FHIR
Infrastructure
Work
Group
|
Maturity
Level
:
|
|
|
This
page
standard.
See
the
Infrastructure
Package
|
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
four
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
|
For
all
content
marked
with
one
of
the
The |
|
| 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
|
| Informative |
This
portion
of
the
specification
is
provided
for
implementer
|
| Deprecated |
This
|
Some
Normative
artifacts
contain
a
few
parts
labeled
as
'Trial
Use'
even
though
the
top
artifact
itself
is
labeled
'Normative'
:
While
HL7
prefers
to
avoid
this
outcome,
there
are
several
resources
where
the
overall
functionality
of
the
page)
is
Draft
.
For
Release
4,
some
content
artifact
is
planned
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
.
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 new elements are introduced into normative resources in future versions - they will undergo a period of trial use as appropriate.
Note: it is also possible that some resources in the future will be labeled as 'trial use', but contain some elements labeled as 'normative'. There is no resource like this in this specification, though all Trial Use resources contain normative content from Resource and DomainResource , and the Data types .
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
Issue
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
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:
| Draft (0) |
the
resource
or
profile
(artifact)
has
been
published
on
the
current
build.
This
level
is
synonymous
with
Draft
|
| FMM 1 |
PLUS
the
artifact
produces
no
warnings
during
the
build
process
and
the
responsible
WG
has
indicated
that
they
consider
the
artifact
substantially
complete
and
ready
for
implementation.
For
resources,
profiles
and
implementation
guides,
the
FHIR
Management
Group
has
approved
the
underlying
resource/profile/IG
|
| FMM 2 |
PLUS
the
artifact
has
been
tested
and
successfully
|
| FMM 3 |
PLUS
+
the
artifact
has
been
verified
by
the
work
group
as
meeting
the
|
| FMM 4 |
PLUS
the
artifact
has
been
tested
across
its
scope
(see
below),
published
in
a
formal
publication
(e.g.
Trial-Use
),
and
implemented
in
multiple
prototype
projects.
As
well,
the
responsible
work
group
agrees
the
|
| FMM 5 |
the
artifact
has
been
published
in
two
formal
publication
release
cycles
at
FMM1+
(i.e.
|
|
Normative
| the artifact is now considered stable |
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
FHIR
Wiki
Confluence
page
.
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
published
on
a
release
cycle
of
approximately
18-24
months.
This
frequency
is
based
on
the
timelines
necessary
to
consult
with
implementers,
to
develop
and
develop,
review
new
content
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
desires.
needs.
Each
new
release
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.
| publication |
|
| major |
|
| minor |
|
| revision |
|
Additional notes:
)
-
does
not
conform
to
this
version
policy,
in
that
the
version
is
not
updated
as
changes
are
made.
To
indicate
this,
the
revision
is
always
"cb"
e.g.
3.1.cb
immediately
after
the
publication
of
Release
3
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 intent of these rules is to ensure that applications that are conformant to an existing specification are 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.
The following kinds of changes may be made to the specification:
Note
that
the
following
are,
by
definition,
considered
non-breaking
changes,
even
though
some
implementations
(including
the
reference
implementations)
might
not
be
able
to
handle
some
consequences
of
these
changes
without
error:
Creation
of
new
resources
Adding
new
optional
elements
in
an
existing
resource
Defining
new
data
types
Adding
new
API
operations
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.
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 we will only make breaking changes based on feedback from the community.
Once
an
artifact
achieves
Normative
status,
the
Backward
compatible
behavior
specific
rules
will
apply.
come
into
play
around
inter-version
compatibility.
These
rules
ensure
that
have
implication
for
both
forward
and
backward
compatibility
and
are
intended
to
allow
implementations
may
to
exercise
FHIR
interfaces
and
process
the
content
of
FHIR
resources
safely
while
exchanging
data
between
applications
systems
using
different
versions
of
FHIR.
There
Forward
compatibility
means
that
content
that
is
no
explicit
version
marker
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
content
specification
will
interoperate
with
older
versions
of
FHIR
resource
instances.
Instead,
the
version
supported
by
a
given
system
specification.
This
is
declared
using
the
conformance
framework
.
The
resources
CapabilityStatement
and
StructureDefinition
have
properties
for
declaring
the
FHIR
specification
version,
and
these
may
be
used
not
guaranteed
by
FHIR,
though
there
are
strategies
systems
can
adhere
to
determine
which
version
that
will
increase
their
chances
of
FHIR
such
interoperability.
Specifically,
when
dealing
with
content
from
a
system
supporting
an
implementation
is
using
to
aid
in
validation
unknown
normative
version
and
integration.
2.7.0.4.2
Forward
compatible
behavior
In
a
typical
scenario,
mixed
versions
may
need
wishing
to
exist,
so
maximize
backwards
compatibility,
applications
SHOULD
ignore
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. schema-based processing).
| Category | Allowed changes |
|---|---|
|
|
|
| Artifacts (resources, profiles, code systems, etc.) | New artifacts including new resources and data types may be introduced. Existing artifacts will not have any computable identifiers (e.g. resource names) changed. Artifacts may be deprecated |
| Elements |
New
optional
elements
and/or
content
(e.g.
XML
attributes,
etc.)
may
be
introduced
at
any
location
in
|
| 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.
|
| 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 - e.g. UCUM unit codes, ISO language codes, etc. |
| Terminology Bindings |
|
| Data Types |
Except
as
described
in
the
preceding
paragraph,
Data
types
will
not
be
removed
or
changed
except
as
allowed
above
for
elements.
New
data
types
may
be
introduced.
Types
declared
on
existing
elements
will
not
be
removed
or
string
may
be
changed
to
markdown
.
Additional
data
types
may
be
added
to
elements
which
are
already
expressed
as
a
choice
of
data
types
only
if
those
elements
are
optional
(minimum
cardinality
=
0).
|
| Value Constraints | The allowed list of Data types will not be added, removed or changed. Invariants, regular expressions, fixed values and patterns will not be added, removed or changed. |
| 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
|
| Operations |
New
operations
may
be
defined
but
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 data types may be replaced with a reference to a distinct profile that is "compatible" with the previously referenced profile according to these forward and backward compatibility rules. |
| 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 change |
| References | Where one conformance resource points to another (e.g. CapabilityStatement to profile, profile to profiles, profile to value set, etc.), the reference may change to point to a newer version of the conformance resource or to a distinct conformance resource so long as the content of the newly referenced resource adheres to the compatibility rules with respect to the previously referenced version. |
NOTE: In rare circumstances, HL7 may approve changes that technically break one of the above rules in situations where there is a high level of confidence that the change will not impact existing implementers. Such deviations from these declared rules will involve broad notification, extensive community consultation and reviews by multiple levels of HL7 governance processes.
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. 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:
http://wiki.hl7.org/index.php?title=FHIR_interversion_compatibility
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,
etc.)
There
is
no
commitment
to
backward
or
forward
compatibility
during
the
STU
process.
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.
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.
The
most
common
strategy
for
handling
change
between
versions
of
FHIR
is
to
use
different
end-points
for
different
versions.
e.g.
http://acme.com/fhir/r2
and
http://acme.com/fhir/r3,
though
other
approaches
are
possible.
During
the
Trial
Use
period,
requests
for
change
may
be
submitted
using
the
HL7
gForge
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
objective
aspect
of
the
Trial
Use
FHIR
specification
development
process
is
gaining
feedback
from
implementers
making
use
of
the
specification.
As
well,
HL7
has
a
need
to
monitor
which
portions
of
FHIR
are
being
implemented
in
what
sorts
of
environments
so
as
to
make
an
informed
decision
on
when
the
specification
process
is
ready
to
proceed
conditional
on
real
world
implementation
in
order
to
Normative
status.
move
through
the
maturity
cycle.
For
this
reason,
all
FHIR
implementers
are
encouraged
to
register
their
usage
here
.
This
survey
will
capture
,
which
captures
contact
and
other
information
that
will
allow
the
FMG
HL7
to
perform
appropriate
monitoring
of
FHIR
STU
usage.
Survey
information
will
be
kept
is
confidential
unless
and
reported
in
aggregate
only.
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
participant
authorizes
inclusion
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
their
project
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
implementers
with
this
problem,
any
element
defined
in
any
version
of
FHIR
is
automatically
assigned
an
HL7-maintained
wiki
page
extension
URL
that
uniquely
identifies
the
element
and
can
be
used
in
the
relevant
FHIR
version.
The
extension
URL
for
an
element
can
automatically
be
derived:
http://hl7.org/fhir/[version]/StructureDefinition/extension-[Path]
where [version] is taken from this list:
This
technique
can
be
used
with
all
versions
of
early
implementers.
Confidential
submissions
will
FHIR,
including
R2
and
R3:
|
FHIR
DSTU2
| 1.0 |
|
FHIR
R3
(STU3,
or
just
R3)
| 3.0 |
|
FHIR
R4
(this
version)
| 4.0 |
Note that this extension framework only applies back 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
be
reported
aware
of
the
following
issues
when
using
these
extensions:
Bundle.entry.resource
,
DomainResource.contained
,
etc)
This table shows the mapping between primitive data types across versions:
| R4 | R3 | DSTU2 |
| base64Binary | base64Binary | base64Binary |
| boolean | boolean | boolean |
| canonical | (uri) | (uri) |
| code | code | code |
| date | date | date |
| dateTime | dateTime | dateTime |
| decimal | decimal | decimal |
| id | id | id |
| instant | instant | instant |
| integer | integer | integer |
| markdown | markdown | markdown |
| oid | oid | oid |
| positiveInt | positiveInt | positiveInt |
| string | string | string |
| time | time | time |
| unsignedInt | unsignedInt | unsignedInt |
| uri | uri | uri |
| url | (uri) | (uri) |
| uuid | uuid | (id) |
Formal Definitions for extensions:
| Format: | R2 Package | R3 Package | R4 Package |
| R2 Extensions: | n/a |
hl7.fhir.extensions.r2:3.0.1
 |
hl7.fhir.extensions.r2:4.0.1
|
| R3 Extensions: |
hl7.fhir.extensions.r3:1.0.2
| n/a` |
hl7.fhir.extensions.r3:4.0.1
|
| R4 Extensions: |
hl7.fhir.extensions.r4:1.0.2
|
hl7.fhir.extensions.r4:3.0.1
| n/a |
Note for balloters: these packages will be created when R4 is finalized. Until then, these are broken links.
While
implementation
of
this
mixed
Normative
and
Trial
Use
release
is
occurring,
development
will
be
progressing
on
the
next
release.
This
next
release
will
include
additional
clarifications,
resources,
profiles
and
quality
enhancements
over
the
current
release.
release
based
on
implementation
experience
and
ongoing
development
work.
It
will
also
incorporate
fixes
for
issues
raised
with
the
FHIR
change
issue
tracker
.
It
may
be
useful
for
implementers
of
the
STU
to
review
the
development
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
first
this
release.
The
FHIR
development
release
can
be
found
at
build.fhir.org
.
Some
implementers
who
are
dependent
on
content
that
exists
in
a
draft
release
may
choose
to
implement
based
on
a
particular
snapshot
of
the
development
release,
though
in
doing
so,
they
will
limit
their
potential
communication
partners
and
would
not
be
considered
to
be
completely
FHIR
conformant.
partners.
The
next
major
publication
of
FHIR
will
be
Release
4.
5.
It
is
our
hope
that
this
release
5
will
include
the
transition
of
some
of
the
content
of
the
specification
to
more
Normative
.
This
should
include
many
of
the
core
infrastructure
resources
(e.g.
StructureDefinition
,
ValueSet
as
well
key
pages
such
as
the
XML
and
JSON
syntaxes,
RESTful
protocol,
etc.
It
should
also
include
at
least
a
few
content,
including
more
of
the
administrative
resources
such
as
Patient
.
Much
core
patient
summary
clinical
content.
Other
content,
including
most
if
not
all
clinical
knowledge/reasoning,
care
planning,
and
business
financial
resources,
will
are
likely
to
remain
at
the
Trial
Use
level
as
they
are
not
expected
to
meet
the
criteria
for
Normative.
The
anticipated
timeline
for
Release
4
involves
a
finalization
of
scope
by
the
end
of
2017,
balloting
in
April
of
2018
and
publication
around
October
2018.
The
specific
timing
may
vary
based
on
implementer
feedback
and
the
volume
of
contents
received
during
the
ballot
process.
More
information
on
plans
for
Release
4
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
gradually
shift
continue
to
focus
to
providing
additional
guidance
through
the
publication
of
implementation
guides
and
profiles
where
consensus
can
be
found
at
the
international
level.
FHIR
®©
HL7.org
2011+.
FHIR
Mixed
Nomative/Trial
Use
Ballot
(v3.3.0-13671)
CI
Build
hl7.fhir.core#4.4.0
generated
on
Tue,
Apr
3,
2018
12:19+1000.
QA
Page
Fri,
Aug
7,
2020
06:08+0000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
QA
Page
|
Compare
to
DSTU3
R4
|
|
Propose
a
change