Exchange
This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
(v4.0.1:
R4
-
Mixed
Normative
and
STU
3).
)
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
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
R4
R3
R2
|
FHIR
Infrastructure
Work
Group
|
Maturity Level : 2 |
|
Though FHIR resources are primarily designed for the RESTful HTTP-based implementation , it is not necessary to use a RESTful interface when exchanging the resources; one way that they can be exchanged is in the context of services. Service Oriented Architecture (SOA) is an architecture pattern using services to encapsulate and provide discrete pieces of application functionality to each other. Services communicate by invoking public interfaces and exchanging information (as parameters and outputs) in accordance with a well-defined service contract.
Generally
speaking,
services
Services
are
cohesive
sets
of
functions
that
maintain
responsibility
for
both
data
and
"state"
"state"
for
the
scope
of
their
responsibility.
Services
have
a
unity
of
function,
such
as
Terminology
Management,
Identity
Management,
or
so
on,
working
with
other
services
in
collaboration
as
part
of
an
orchestrated
workflow.
Data
within
a
service
typically
follows
a
"black
box"
"black
box"
model
and
is
not
classically
exposed,
instead
using
pre-defined
interfaces
to
make
specific
behavioral
requests
for
the
service
to
fill.
To relate this to FHIR, resources in a service-oriented implementation can serve two discrete roles: either as a payload parameter, specifying information flowing into or out of a service; or in a behavioral sense, using FHIR APIs as the invocation mechanism for engaging a service. Service APIs are often realized using either RESTful or SOAP-based interfaces.
Of note, there are potential benefits in considering usage of FHIR and SOA together. FHIR allows for ease of implementation and ready access to data payload in an open way. SOA has maturity around transactional integrity across distributed systems instances, providing a framework for loose-coupling and addressing pre-conditions, exception handling, and other implementation considerations of complex distributed systems.
This section illustrates different contexts to allow implementers to make informed decisions at implementation time, considering potential impacts and solution patterns to benefit specific situations. In doing so, this section will clarify what is meant to apply SOA principles and specifications within a FHIR environment/implementation, and the converse. It will identify the situational factors to consider, and the elements of the SOA discipline that can be applied for more effective FHIR implementation, providing a roadmap on how to optimize your implementation toolkit to make you and your team most effective.
This section is being included as FHIR offers a highly flexible framework for interoperability that can be deployed that can be used in a variety of different ways, and in ways that have the potential to hinder interoperability if not done thoughtfully or consistently. Use of SOA patterns and approaches can mitigate this risk, limiting the potential liability resulting from the extreme flexibility of FHIR and fostering an overall framework that leads to deployment and consistency. SOA provides guidance for how components interact, how to partition responsibilities, and how to manage workflows among different parts of systems, all of which have potential utility in FHIR implementation settings.
Generally,
the
The
definition
of
particular
specific
services
is
a
domain
or
context
specific
task,
and
it
task.
It
is
anticipated
that
this
would
be
done
as
separate
specifications
that
make
use
of
the
underlying
facilities
defined
in
this
specification.
HL7
has
already
defined
a
portfolio
of
services
that
take
advantage
of
REST-
and
SOAP-based
interfaces,
but
the
parameters
passed
to
and
from
those
services
are
not
at
present
resource-based.
These
are
potential
extension
points
that
may
lend
well
for
FHIR
implementation.
Services
defined
like
this
are
able
to
build
on
the
common
underlying
platform
features
defined
in
this
specification
such
as
REST
or
messaging,
and
add
specific
interactions
where
appropriate.
Alternatively,
the
service
interfaces
can
build
an
entirely
separate
implementation.
Note
that
for
each
of
the
items
below,
there
are
paired
sets
of
standards,
an
HL7
Standard
defining
the
functional
specification,
and
an
OMG
Technical
Standard
containing
SOAP
bindings
(for
all
of
the
items
below)
and
REST
bindings
(for
about
half
of
the
items
below).
The portfolio of healthcare SOA service specifications includes:
)
)
)
)
)
Note:
FHIR-enablement
of
the
services
above
is
already
occurring
on
a
limited
basis.
The
Clinical
Quality
Improvement
Framework
(CQIF)
portion
of
the
FHIR
specification
is
an
example
of
a
technical
interface
and
resources
that
have
been
influenced
by
prior
SOA
work.
Similarly,
this
specification
defines
a
Terminology
Service
which
is
tightly
integrated
with
the
RESTful
API
(note:
this
terminology
service
has
different
goals
than
the
CTS2
service,
so
they
are
not
functionally
equivalent).
FHIR
itself
is
a
framework
for
the
instantiation
of
an
RLUS
service.
Definition
of
other
additional
services
based
on
the
service
interface
definitions
provided
by
the
HL7
SOA
work
group
will
be
considered
if
there
is
sufficient
enough
interest
in
this.
Given that there are a set of available services that can be applied directly or used as a pattern in conjunction with FHIR, it merits consideration that there are alternative ways to bring together FHIR and SOA, each of which has benefits and drawbacks. Three specific styles of implementation have been identified:
Determining
which
of
the
above
implementation
styles
is
best
suited
to
a
particular
situation
is
context-dependent.
The
following
table
presents
these
alternatives,
deliberately
using
qualitative
measures
to
help
navigate
to
the
best-fit
based
upon
influencing
factors.
"Harvey
Balls"
"Harvey
Balls"
in
the
table
below
indicate
relative
strengths
and
weaknesses
of
the
implementation
alternatives.
| Solution Quality | Short Description | #1:FHIR + REST (RESTful FHIR) | #2 FHIR + WS* | #3 FHIR + SOA Pattern | Comments |
| Support of transactional integrity | Transactions may involve multiple steps composed together into a single unit | ◒ | ◒ | ● | Transactional integrity is not assured in #1 or #2 but can be hand-coded. #3 assures that this is addressed |
| Support of stateless transactions | Transactions are independent and do not require supporting context | ● | ● | ● |
Each
of
the
implementation
approaches
|
|
Support
of
|
Minimum of dependencies between the calling and responding system; reduces burden on client to manage context of interaction with service | ◒ | ◒ | ● |
The
notion
of
|
| Use of FHIR Resources as Data Payload | Representation of FHIR resources for use as query or return parameters | ● | ● | ● | Data payload includes input data as well as data returned |
| Support of Dynamic Service Discovery | Provides for service registration, search, discovery, and late binding | ◒ | ◒ | ● | This is part of SOA specification and customary in implementations. For the others, it is up to the approach |
| Provides resource-oriented operations | Supports ability to create, read, update, delete resources; | ● | ◒ | ◒ | Direct access to resources/data revisions in a strength of REST and FHIR. Direct access to fine-grained transactional operations are generally not supported within SOA |
| Suitability for atomic transactions | Fitness to support fine-grained transactions, such as data access or targeted update | ● | ◒ | ◒ | REST is ideally suited for point access or updates of specific data elements/resources - functions discouraged within SOA and WS* |
| Suitability for composite transactions | Fitness to support complex transactions: context-sensitivity, multi-step workflows, etc. | ◒ | ● | ● | SOA provides for complex event processing, multi-step sequencing, orchestration |
FHIR resources are designed to be used in a wide variety of contexts. In particular, FHIR resources are required to be suitable for use in a REST environment. This means that there are number of design requirements and choices that impact how suitable resources are for use with services.
If service use was the only consideration, different decisions would be made, and resources would be more suitable for use with services. However, this would curtail their usefulness and reusability in other contexts.
API/Interface
Design
.
Services'
API
design
is
explicit
and
exposes
service
capabilities
which
are
a
part
of
a
service
contract
to
consuming
applications.
This
contrasts
with
what
is
the
default
interface
into
a
FHIR
server
of
a
REST-based
interface
exposing
CRUD
operations
and
stateless
access.
Good
SOA
design
practice
indicates
loosely-coupled
access
(e.g.,
external
clients
do
not
have
visibility
into
the
inner
workings
of
a
service)
improves
implementation
flexibility
over
time,
permitting
design
and
performance
improvements
with
the
maturation
of
the
implementation.
As
such,
interfaces
are
typically
exposed
and
aligned
with
business
functionality
(such
as
"Register
Patient"
"Register
Patient"
or
"Validate
Identity").
"Validate
Identity").
Bridging what is not necessarily a natural-fit between SOA operations and RESTful operations are key to interface design. Implementers may elect to apply finer grained FHIR interactions to be encapsulated in coarse-grained functions, delegating those responsibilities to either implementations within a FHIR instance or to external code not visible to the service consumer.
Principal
within
the
design
objective
is
to
minimize
or
eliminate
responsibilities
on
behalf
of
the
service
consumer
to
understand
or
apply
knowledge
of
the
service
implementation.
This
frees
up
the
service
provider
to
be
able
to
evolve
and
improve
the
inner
workings
of
the
service
without
a
"ripple
effect"
"ripple
effect"
adversely
impacting
service
consumers.
In
doing
so,
technical
dependencies
are
minimized.
Several
good
sources
of
SOA
Design
Patterns
are
available
from
HL7
and
other
public
sources.
Data
Storage
and
Coherence
.
The
approach
to
and
complexities
associated
with
data
storage
and
overall
data
coherence
will
significantly
depend
upon
whether
an
implementation
is
subject
to
enterprise
policies
and
whether
data
consistency
is
the
responsibility
of
the
service
provider
or
consumer.
In
Enterprise
settings,
these
issues
are
typically
governed
by
organizational
policy.
FHIR
servers
and
their
data
persistence
would
need
to
fit
within
that
policy,
with
data
access
being
in
compliance
with
following
that
policy
and
services
interacting
with
"policy
"policy
enforcement
points"
points"
to
assure
that
appropriate
permissions
are
in
place.
Where
data
consistency
is
the
responsibility
of
the
service
(or
server)
use
of
SOA-friendly
interface
protocols,
such
as
SOAP
and
potentially
REST,
create
the
access
channel
for
integration.
This
may
necessitate
defining
minimum
sets
of
data
that
are
required
to
comply
with
data
coherence
expectations
(in
other
words,
a
service
contract
that
specifies
the
collection
of
resources
that
must
be
updated
in
tandem,
and
the
scope
of
what
constitutes
a
‘single
transaction’
'single
transaction'
-
more
on
this
in
the
Transactional
Integrity
section).
In
alternative
implementations
data
storage
is
managed
within
the
FHIR
server,
consistent
with
non-SOA
FHIR
implementations.
Data
consistency
is
the
responsibility
of
the
Server
Server,
but
responsibility
may
carry
to
consuming
applications
(if
they
are
provided
with
sufficient
update
rights
so
as
to
make
that
a
concern).
Data
validation
also
has
a
shared
responsibility,
first
with
the
FHIR
Server,
and
additionally
with
the
authorized
updating
applications.
Data
visibility
is
a
product
of
the
REST
interface,
typically
allowing
CRUD
operations
to
the
data
element
level.
Transactional Integrity . When encapsulating functionality within a SOA-type service, data and transactional integrity are essential in making sure that data received and stored is accurate and consistent with what was received. An issue particularly with update functions, the ability to update multiple different resources and maintain harmony among them as part of a broader transaction is how this is typically realized.
Should
one
part
of
the
update
‘fail’,
'fail',
one
would
expect
all
of
the
other
updates
to
be
"rolled
back"
"rolled
back"
to
a
prior,
stable
state.
Rollback
is
not
expressly
specified
as
part
of
the
FHIR.
Data
update
and
integrity
becomes
the
responsibility
of
each
service.
The
FHIR
specification
does
not
inherently
provide
for
concurrency
management
(e.g.,
managing
of
"deadlock"
"deadlock"
conditions
where
two
resources
each
await
update
permission
from
the
other).
As
a
result,
within
the
FHIR
server
itself
it
is
assumed
that
fault
tolerance
and
server
availability
is
being
managed
(beyond
the
scope
of
the
specification).
Applied use of SOA patterns have benefits in terms of distributed transactional integrity, as SOA has substantially removed burdens from calling (client) applications, instead levying these responsibilities upon the service provider. This has relevance because it is customary in larger scale implementations (such as large enterprises) that service consumers are varied and not necessarily know in advance to the service. As a result, these implementation patterns make for more robust infrastructure, mitigating potential implementation risk and ultimately improving data quality. We note that these elements can be manually accommodated in FHIR implementations, absent use of SOA patterns, though that can lead to inconsistent interpretation, delegated responsibility to client application(s), and the potential for incompatible implementations.
Modularity . The modularity of resources - which resources are defined, and why - is driven by a wide set of considerations around how they are used. Resources are a platform on which a set of business/clinical services of various kinds are provided. Accordingly, the resources are defined for general use, and they can be expected to be less suitable for a particular service than custom defined structures. The pay back is wider re-use of the information that the service deals with.
Effective
"service-orientation"
"service-orientation"
establishes
modularity
at
both
a
macro
and
micro-level.
At
the
macro-level,
services
themselves
are
modular,
componentized,
and
composable.
Since
each
service
has
a
singularity
of
purpose
with
a
well-defined
interface,
they
are
naturally
suited
to
working
in
tandem
with
other
services
and
consistent
with
modular
design.
At
a
more
fine-grained
level,
the
interfaces
into
and
out
of
services
also
allow
for
modularity,
and
the
ability
to
leverage
the
structure
of
FHIR
resources
as
a
payload
descriptor
for
carrying
data
structures
and
corresponding
semantics
across
APIs
is
modularly
based.
Explicit
State
.
All
resources
represent
the
various
states
of
the
record
and
real
world
real-world
entities
involved
in
a
transaction
explicitly.
This
is
necessary
for
use
in
RESTful
and
document
contexts,
where
there
is
no
explicit
transaction.
Service
interactions
are
typically
associated
with
implicit
semantics,
such
as
a
request
to
change
the
status
of
a
particular
resource
to
something
else,
for
example.
The
fact
that
resources
that
carry
this
state
explicitly
as
well
as
the
transaction
fixing
state
implicitly
creates
duplication
between
the
two,
and
this
will
need
to
be
managed.
Error Handling . SOA provides an implementation approach providing consistency in error handling, escalation, and error management. These tools can be leveraged to identify likely error conditions and exceptions based upon prior SOA work, helping to put into place infrastructure within FHIR to manage those exceptions. Moreover, this alignment creates future opportunity to more effectively integrate FHIR resources into an enterprise SOA fabric should that become a need. It is not anticipated that there is a need to change error management for FHIR, except to address payload-specific errors that may arise.
The FHIR specification does not specifically address error handling between and across servers and clients. When implementing within larger or more complex environments, particularly in situations where multiple FHIR servers may be involved (especially if they are provided by different vendors/implementations), error handing and management can quickly become complex and untenable.
Resource References . The most obvious impact is that resources refer to each other using full URL based references , and there are a number of rules around how these references are resolved. In the context of a service, this means that the references between modules carry this extra weight of choice and obligation, even when it might not be necessary.
FHIR resources or bundles may be used as the parameters or outputs of service interfaces.
Orchestration . Orchestration is a term typically used within SOA to describe the steps, sequencing, and dynamic adjustment of workflow to meet a process need. Orchestrations may be entirely automated and fulfilled in a short timeline, or longer and multistep in fulfillment of a business process that may involve manual steps and human intervention. In the context of FHIR implementation, orchestration would refer to the sequencing of collections of FHIR (or service) calls that are used in tandem to fulfil a specific need.
Orchestration is neither natively supported nor unsupported in FHIR, save the availability of the FHIR Batch mode which allows for some degree of compounding of operations. In a SOA environment, orchestration is typically realized by documenting in some formalism, such as Business Process Modeling Notation (BPMN), a sequence of steps and flows, and inherent logic or decision-points affecting that flow. An engine is then capable of executing the process flow, receiving inputs during execution to adjust or adapt those processes based upon situational need as part of delivery fulfillment.
There are many examples where this approach is advantageous. For example, in a Care Management situation, test results, current problems, chief complaint, and potentially even resource availability might affect subsequent steps in fulfilling a care plan. Based upon changes to any of these factors, the sequence of calls and ultimately the systems or FHIR servers involved would vary. The role of automated clinical decision support is another example that naturally ties to workflow orchestration, adjusting care pathways based upon patient evaluation and affecting process flows within a health system.
At
present,
to
support
this
complexity
within
a
FHIR
setting
without
the
use
of
SOA
tools,
these
flows
would
need
to
be
manually
coded,
either
by
having
a
directed
sequence
of
calls,
or
by
creating
an
independent
capability
effectively
acting
as
an
orchestrator.
This
can
be
supported
within
FHIR
exclusively,
but
all
of
the
steps
and
corresponding
state
management
would
need
to
be
done
by
hand.
FHIR
Batch
provides
some
of
this
capability,
allowing
for
aggregation
of
multiple
steps,
but
does
not
necessarily
support
the
event
processing
needed
in
complex.
Security
.
Security
is
inherently
a
dimension
of
any
enterprise
SOA
architecture,
meaning
that
the
responsibility
within
a
service
implementation
is
to
provide
the
"hooks"
"hooks"
to
interact
with
that
architecture.
In
other
words,
the
service
does
not
need
to
create
or
enforce
security,
it
needs
to
interact
with
those
enterprise
components
that
have
that
responsibility.
This
includes
topics
such
as
identity
management,
access
control,
or
other
dimensions
of
a
secure
solution.
SOA
guidance
can
foster
an
effective
design
involving
FHIR
in
support
of
authentication,
policy
enforcement,
role-based
access
controls,
and
a
host
of
other
provisions
and
protections.
It
is
important
to
note
that
within
SOA,
security
is
an
established,
mainstream,
and
mature
offering.
Reuse
of
these
concepts
can
help
prevent
inadequate,
incomplete,
or
ineffective
security
measures
within
FHIR,
and
eliminate
the
need
to
re-invent
solutions
exclusively
for
FHIR.
Enterprises typically have security architecture into which a SOA environment will have already integrated. Service implementations would rely upon this existing infrastructure as part of authentication, access control, etc. Policy enforcement is a function of the architecture and not a specific service itself. Services would rely upon policy enforcement points to govern access to information.
While technical dimensions of security would be addressed by the security architecture directly, FHIR implementers should anticipate that data-specific access control policies would need to be captured and formalized so that they are enforceable within the architecture. For example, if a new service is handling protected health information, the policy enforcement point within the architecture would need to know that the service has that nature of data.
Resource
Identity
.
All
resources
have
a
single
identity
(the
full
URL),
and
a
logical
id
which
may
be
maintained
as
the
resource
moves
from
server
to
server
(see
Managing
Resource
Identity
for
further
discussion).
Since
this
identity
is
used
by
any
reference
to
the
resource,
it
must
be
maintained
when
the
resource
is
exchanged
so
that
references
from
other
resources
to
the
one
being
exchanged
can
still
be
resolved.
Any
use
of
resources
in
a
service
environment
needs
to
address
how
these
references
can
be
resolved.
This
can
be
achieved
by
delegating
the
reference
resolution
to
a
RESTful
framework,
by
ensuring
that
all
the
relevant
resources
are
contained
in
the
service
call,
or
by
making
some
service
based
service-based
arrangement
by
which
additional
resources
can
be
retrieved.
Services
that
exchange
resources
SHOULD
maintain
resource
identity.
Further,
as
explicit
version
tracking
is
not
a
guaranteed
capability
of
a
service
call,
services
that
exchange
resources
should
include
version
information
associated
with
resources
being
exchanged.
Capability Statement . When using RESTful exchange , messaging , and document based exchange, the Capability statement allows authoring and reading applications to describe how they use a resource. The Capability Statement supports trading partner negotiation from specification time through to run-time discovery. The Capability statement doesn't provide any equivalent way to make declarations about services, though this might be added in the future if common requirements emerge. Services are expected to make appropriate arrangements around discovery and compatibility, though it is expected that these will vary considerably.
Services that exchange resources MAY choose to provide support for describing and changing descriptions of service implementations.
At its core, FHIR is based upon the elemental capabilities of Create, Read, Update, Delete (CRUD), allowing access to resources where interaction is primarily based upon these operations. Of note, multi-step or complex processing levies requirements upon the calling, client application. Sequencing of events, particularly when those events involve orchestration of complex or dynamic processes, can benefit from the application of SOA techniques and patterns. This is common where multi-step processing is involved, and particularly important when adjustments to a process flow can be made based upon situational context.
As these areas are both commonplace within health settings and not inherent strengths of FHIR, the marriage of FHIR and SOA techniques provides a viable and beneficial path forward to improving implementation and mitigating risks by leveraging proven and established industry best-practices.
SOA
design
patterns
are
frequently
used
to
govern
interactions
for
dynamic
processes,
non-sequential
workflows,
or
dynamic
workflows
involving
human
intervention
and/or
consideration
of
external
factors
as
part
of
processing.
The
ability
to
model
interaction
patterns
using
languages
such
as
SOAml,
and
to
define
roles
and
role
interactions,
are
tools
that
may
be
useful
to
FHIR
development
in
these
circumstances,
circumstances
-
and
would
be
indicators
signaling
that
SOA
has
the
potential
to
add
value
to
a
FHIR
implementation.
SOA
design
principles
can
provide
guidance
to
a
FHIR
implementer
resulting
in
reduction
of
co-dependencies
between
components,
promoting
"loose
coupling"
"loose
coupling"
and
minimizing
potential
impacts
resulting
from
changes
to
inner
workings
of
one
component
adversely
affecting
others.
(For
those
familiar
with
the
term,
this
encourages
"black
box"
"black
box"
implementation).
SOA provides guidance around data persistence, durability, and expectations in support of the data lifecycle.
FHIR
has
proven
itself
as
beneficial
in
that
it
provides
an
easy-to-implement
and
coherent
approach
to
accessing
healthcare
resources
using
a
modern
protocol
stack.
SOA
has
proven
itself
over
time
in
multiple
vertical
market
segments
as
a
way
to
divide
responsibilities
and
authoritatively
manage
information
across
distributed
systems.
Marrying
the
discipline
of
SOA
with
the
implementation
ease
of
FHIR
is
a
winning
combination
when
the
situation
warrants.
Implementers
should
consider
evaluation
of
the
contextual
landscape
to
determine
where
FHIR
and
SOA
have
the
opportunity
to
can
benefit
from
complementary
implementation
leverage
points.
Recognizing that there are situations where the coming-together of FHIR implementation and SOA techniques are advantageous, there are several implementation approaches available. Note that the selection of which approach is advantageous for any given situation will depend upon a variety of factors: existing legacy implementation and available APIs (particularly for interfacing applications), the strategic direction/IT roadmap of the organization, and so on. Noting that there are different styles of realizing FHIR and SOA together, a recap of the principal alternatives would include:
It is important to note that electing to apply SOA patterns to FHIR implementation does not fundamentally change the nature of what is being implemented. Applied correctly, it results in minor adaptation to coding and interface design resulting in enhanced consistency across implementations as well as enhanced interoperability and robustness.
These considerations are summarized in this table:
| Capability | #1:FHIR + REST (RESTful FHIR) | #2 FHIR + WS* | #3 FHIR + SOA Pattern | Comments |
| Supports dynamic adjustment in workflows | ○ | ◒ | ● | In a native FHIR environment, this must be done by hand. The WS* stack provides for some interaction patterns, but limited. Use of formal notation (BPMN) and service orchestration is most robust option |
| Supports ability to batch multiple operations | ◒ | ◒ | ● | FHIR Batch allows for concatenation of multiple process steps. SOA Orchestration allows for fine grained control, grouping and sequencing of multiple operations |
| Provides for management of data coherence (e.g. Deadlocks, transactions) | ○ | ○ | ● | SOA principles define data governance, assigning responsibility for all data management within a service contract |
|
Provide
support
for
orchestration
languages
(
BPMN
,
SOAml
)
|
○ | ◒ | ● | SOA applies a systematic framework for orchestration using industry accepted formalisms, avoiding costs and complexities associated with an ad-hoc approach |
SOA in a FHIR Environment considers the benefits of applying SOA patterns and best-practices to a FHIR implementation community. In these cases, developers are faced with implementation decisions that have the potential to benefit from existing case studies, design patterns, or guidance that may either help provide consistency among FHIR implementations, or which may address gaps - either known or unidentified - resulting from implicit assumptions around a FHIR implementation.
FHIR in a SOA Environment considers the implications of using FHIR in a large, established enterprise that has or is making investments in SOA infrastructure. In these cases, shared services, enterprise policies, and existing infrastructure is common, and FHIR implementations would need to fit within the fabric of that environment.
Finally, it merits mention that not every FHIR implementation benefits from SOA, and vice-versa. The goal of this section is to help implementers navigate based upon their specific considerations to help determine if and to what extent these approaches provide benefits.
®©
HL7.org
2011+.
FHIR
Release
3
(STU;
v3.0.2-11200)
4
(Technical
Correction
#1)
(v4.0.1)
generated
on
Thurs,
Oct
24,
Fri,
Nov
1,
2019
11:53+1100.
09:37+1100.
QA
Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
|
Compare
to
DSTU2
R3
|
|
Propose
a
change