Exchange
This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
STU
3).
(v3.5.0:
R4
Ballot
#2).
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
|
FHIR
Infrastructure
Work
Group
|
Maturity Level : 2 | Ballot Status : Trial Use |
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
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 definition of particular services is a domain or context specific task, and 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
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 are capable of supporting stateless processing |
|
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
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’ - 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 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’,
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 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, 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 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)
Mixed
Nomative/Trial
Use
Ballot
#2
(v3.5.0-14907)
generated
on
Thurs,
Oct
24,
2019
11:53+1100.
Sun,
Aug
19,
2018
21:54+1000.
QA
Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
|
Compare
to
DSTU2
DSTU3
|
Ballot
Comparison
|
|
Propose
a
change