HEALTH INFORMATION EXCHANGE NETWORK
INTEROPERABILITY THROUGH IHE TRANSACTIONS
ORCHESTRATION
Francois Andry and Lin Wan
OptumInsight, 160 West Santa Clara Street, CA 95113, San Jose, U.S.A.
Keywords: Integrating the health enterprise (IHE), Cross-community patient discovery (XCPD), Cross-enterprise
document sharing (XDS), Cross-community access query and retrieve services (XCA), Audit trail and node
authentication (ATNA), Interoperability, Orchestration, Choreography, Web services, Service oriented
architecture (SOA), Enterprise service bus (ESB), Health information exchange (HIE), Simple object access
protocol (SOAP), Business process execution language (BPEL), Encryption, Signature, Security assertion
markup language (SAML).
Abstract: Integrating the Healthcare Enterprise (IHE) is an initiative designed to facilitate the integration of healthcare
information systems in order to exchange health care information in a secure, private and efficient manner.
Solution vendors now offer IHE integration profiles as web services that can be integrated locally or
regionally to coordinate standard heath care activities such as clinical documents management. Although
IHE profiles promote the use of standards, the federation of health information systems is difficult because
each node to integrate is generally very different. Each individual node has its own services, communication
protocol, security scheme, performance, customization and extensibility capabilities. In addition, IHE
profiles do not address workflow management process such as the mediation, routing and aggregation of the
content of IHE transaction messages. In this paper, we describe an architecture solution that addresses these
needs and provides the orchestration of IHE transactions (XCPD, XCA, ATNA) to support state wide-
Health Information Exchanges.
1 INTRODUCTION
Integrating the Healthcare Enterprise (IHE) has
gained tremendous momentum in the past few years.
Started as a Healthcare Information and
Management Systems Society (HIMSS) and
Radiological Society of North America (RSNA)
workshop in October 1998 with only 15 participants
including AGFA, Cerner, Fuji, GE, HP, Philips and
Siemens, the IHE initiative has more than 400
members worldwide. IHE provides a standards
based-interoperable framework (IHE 2009) to share
and exchange information between health care
organizations across networks.
Combined with the latest technology and well
established standards (HL7, DICOM, IDC9/10,
LOINC, W3C), clinical data can then be securely
and privately accessed (Masi et al. 2009) and
transmitted locally between network end-points (e.g.
within the same hospital between the practices and a
lab). IHE profiles can also be used across Health
Information Exchanges (HIE) of Regional Health
Information Organization (RHIO), or a state level
(e.g. an individual state in the US, Canada or
Europe), or at the federal level (e.g. the US
Nationwide Health Information Network or
NwHIN). As a result, there is a strong need to
integrate and combine individual IHE profiles end-
points to form “hub of hubs” or “network of
networks” to support health information exchange
between the participating nodes entities.
1.1 Encounters and Clinical Decisions
The motivation for integrating IHE hubs and
networks is to obtain up-to-date information relevant
at the point of care to improve diagnosis and make
better clinical decisions. This is particularly
important for the care giver to have access to
accurate medication, allergy, problems, conditions,
medication, lab and radiology history when the
137
Andry F. and Wan L..
HEALTH INFORMATION EXCHANGE NETWORK INTEROPERABILITY THROUGH IHE TRANSACTIONS ORCHESTRATION.
DOI: 10.5220/0003721501370142
In Proceedings of the International Conference on Health Informatics (HEALTHINF-2012), pages 137-142
ISBN: 978-989-8425-88-1
Copyright
c
 2012 SCITEPRESS (Science and Technology Publications, Lda.)

encounter occurs far from the patient’s usual
medical center. For example, a patient could be
treated while on vacation or at the nearest trauma
center following a car accident far from his/her
home. Very often, emergency encounters happen
only a few miles from the clinic where the patient’s
primary care physician is located. But because the
networks of these organizations are not connected
there is no possibility for the care giver to have a
direct and easy access to the patient’s clinical data.
In addition, there is a need for regional, state or
federal level IHE integration that can be used to
control specific global catastrophic events such as
pandemic episodes. This type of integration also
offers greater visibility to public health decision
makers in general.
1.2 Integrating IHE End-points
In this paper, we present various options to integrate
IHE web services end-points. We describe the
requirements of a state-wide health information
exchange in the USA and we explain how we have
designed and built a specific solution to address
these requirements.
2 COMBINING TRANSACTIONS
Because IHE transactions are most likely to be
offered as Web Services, combining those
transactions can be done following Service Oriented
Architecture (SOA) and Service Oriented
Computing (SOC) principles (Papazoglou and
Georgakopoulos, 2003). SOA describes the basic
web services communication protocols,
functionalities and how these services are exposed,
discovered and used by clients. SOC on the other
hand, describes how these services can be
aggregated via composition, coordination and
monitoring.
For IHE transactions, an example of composition
would be how to combine cross-community patient
discovery (XCPD) response messages from several
end-points to check which sub-networks hold data
about a specific patient. An example of coordination
might be necessary when querying various hubs in a
network and trying to combine IHE messages from
different end-points within a certain time frame.
Tracking and auditing capabilities for all
transactions that travel across health information
exchange networks are examples of monitoring as
required by healthcare regulations such as HIPAA.
2.1 IHE Profiles as Web Services
IHE profiles are generally implemented as web
services that are accessible via an Internet Uniform
Resource Identifier (URI) over the Hypertext
Transfer Protocol (HTTP). Even though there are
various ways to implement web services, IHE
profiles are usually implemented using the Simple
Object Access Protocol (SOAP) that transport data
content as XML. SOAP uses the Web Services
Description Language (WSDL) to describe the
services as a collection of network end-points, or
ports. WSDL files are accessed to determine which
operations are available for each service. The
Universal Description, Discovery, and Integration
(UDDI) standard can be used for the localization and
introspection of potential web service directory
collections.
2.2 Enterprise Application Integration
Conventional middleware distributed system
infrastructures (e.g. JMS) are generally not sufficient
or flexible enough to mediate, transform, federate
and route messages from and to web services.
Enterprise Application Integration (EAI) goes one
step ahead, trying to separate the applications from
the web services end-points. EAI usually employs a
centralized service broker for this, a set of
connectors and an independent data model. Services
can then send and subscribe to receive messages to
and from the broker. However, this very centralized
approach requires a large amount of up front
development and business process design for the
connectors, as well as high cost of maintenance in
general. Enterprise Service Buses (ESB) is an
infrastructure that leverages EAI principles.
2.3 Orchestration
Orchestration and choreography on the other hand
offer ways to create more dynamic and flexible
composite services using declarative (XML)
business process modelling language.
Like EAI, orchestration uses a centralized
approach (Jiménez-Peris et al., 2008); (Yahyaoui et
al., 2009). Web services orchestration is realized
through Business Process Execution Language
(BPEL) that describe the collaboration and
interaction between the web service participants
(Dogac et al. 2006); (Timm et al. 2009); (Chen et al.
2006).
Business workflows, states, actions, events,
control flows and exception handling can be
HEALTHINF 2012 - International Conference on Health Informatics
138

specified. Messages can be received and sent
directly from and to WSDL ports. Results received
asynchronously from web services can be combined
to create new messages.
2.4 Choreography
Choreography is another approach. It is more
distributed and collaborative in nature (Kilic et al.,
2010) and uses the Web Service Choreography
Interface (WSCI) specification and the WSDL
description files to represent the flow of messages
exchanged between the Web services involved.
Choreography seems more flexible than
orchestration since it does not rely on a central
element that could become a bottle neck and seems
to offer more complex interaction potential between
web services.
However, choreography has some drawbacks
including the necessity for all web services to be
aware of overall business process workflow. In
addition to this, performance can be an issue if high
volume message transactions between the end-points
peers are not handled properly. Moreover, there is
no clear responsibility for the overall workflow
leading to legal issues related to monitoring and
maintenance (Janssen and Kuk, 2007).
Figure 1: Orchestration and choreography.
3 STATE-WIDE HEALTH
INFORMATION INTEGRATION
In the US, a certain number of initiatives (Table 1)
aim at the development of state-wide health
information networks. The goal is to promote the
exchange of health information and improve the
coordination of care and population health at the
state level. These state level integration projects are
generally built on top of existing Regional Health
Information Organizations (RHIOs).
The nodes of the network correspond to
practices, hospitals, labs, or more complex
organizations such as RHIOs and services
representing state agencies. Added value services
encompass other highly specialized services such as
patient access, CCD and lab results translation,
eligibility and decision support.
Table 1: US state-wide health information networks.
State Project
Delaware Delaware Health
Information Network
(DHIN)
Indiana Indiana Health Information
Exchange (IHIE)
Tennessee Health Partnership for
Tennessee (HIP TN)
New York State-wide Health
Information Network for
New York (SHIN-NY)
Utah Utah Health Information
Network (UHIN)
West Virginia West Virginia Health
Information Network
(WVHIN)
Wisconsin Wisconsin State-wide
Health Information
Network (WISHIN)
In this type of architecture, core services serve as
the gateway through which end-point nodes can
either communicate among themselves or with the
other services offered by network.
Figure 2: State-wide HIE interoperability network
orchestration.
The core services can include services such as
trust broker, matching (e.g. master patient index),
master facilities index, master clinical index and
Federal NwHIN gateway access.
3.1 Privacy and Security
As for regional integration, state-wide integration
puts a lot emphasis on privacy and security for the
access and manipulation of protected health
information (PHI) as mandated by HIPAA.
Health information exchange at the state level
have mechanisms that give the ability to the patients
HEALTH INFORMATION EXCHANGE NETWORK INTEROPERABILITY THROUGH IHE TRANSACTIONS
ORCHESTRATION
139

to indicate whether or not their data will be included
in the exchange (opt-in/opt-out model) based on the
state regulations. These networks also have tracking
and auditing capabilities at each level such as end-
point nodes transactions, orchestration mechanism
and external services to enforce user accountability.
When integrated, the access to the end-point
nodes, the service providers and the Health
Information Exchange are limited to authorized
users only. Processes and detection mechanisms are
put into place to uncover breaches, security
incidents, and other violations.
Transport Layer security is usually enforced by
using two-way TLS. All end-points of the network
that talk to each other must exchange certificates
containing a certificate authority (CA) and a public
encryption key to be able to encrypt messages before
sending them.
The SOAP payload is frequently required to be
encrypted and signed, to enforce privacy,
authenticity and non-repudiation of the IHE
messages that are exchanged.
Finally, valid SAML assertions (SAML 2009)
can be added in the requests with all required user
information for security and audit purposes.
3.2 IHE Profiles
The health exchange services use IHE profiles to
communicate between each other:
 Cross-Community Patient Discovery (XCPD): to
locate community end-points holding specific
patients with relevant health data;
 Cross-Community Access (XCA) Query: to
return the list of documents for selected patients;
 Cross-Community Access (XCA) Retrieve: to
obtain relevant associated clinical documents such
as Continuity of Care Document (CCD);
 Audit Trail and Node Authentication (ATNA): to
establish tracking and auditing capabilities.
3.3 Interaction Overview
XPCD and XCA message exchange between end-
points follow the same pattern. An end-point
initiates a query (XCPD or XCA) and sends it to the
exchange. The message is decrypted and its
signature and SAML assertion are verified. The
message is then broadcasted to all available end-
points in the network. The message is repackaged
for each end-point (encrypted with the public key of
the destinations, signed by exchange and the SAML
assertion is added). Responses coming back from
end-points destinations are collected, decrypted,
verified, aggregated and sent back to the initiating
end-point. At each step of the process Audit Trail
and Node Authentication (ATNA) messages are
generated and stored for auditing.
Here are the specific steps for XCPD profile:
1. When a provider serviced by an end-point wishes
to locate a patient in other communities, the end-
point should initiate an XCPD query to the exchange
on behalf of the provider system (such as an EHR).
2. The exchange record locator service will
determine which end-points should be queried, using
a service registry maintained by the exchange, and
emits XCPD queries to those end-points.
3. Upon receiving the XCPD query from the
exchange, each end-point will locate matching
patients in its domain using local patient matching
algorithms, and return the appropriate results to the
exchange. The returned demographics shall include
the patient’s unique ID in the end-point’s domain,
along with enough key demographic data to allow
the service consumer to determine the quality of the
match.
4 DEVELOPMENT
Most of the development is done through the
declarative design of the BPEL application.
Workflows receive messages, reply and invoke
actions (e.g. storing log entries in a database).
4.1 Mediation
The mediation logic and routing are added to the
workflow. Message parsing, mapping and
transformation are done using XSLT/XPATH
expressions. When the BEPL application is ready, it
is deployed on the SOA/ESB runtime platform. The
end-points are configured and the application is
tested by executing the workflows.
The application is composed of five BEPL
workflows, associated WSDL files, style sheets and
configuration files. The main workflow is in charge
of message security (content attack prevention,
authentication and requests validation), IHE sub-
workflow forwarding and basic input/output log
entries to a database.
The role of the mediation is to control the
message processing and delivery based on some
conditional logic. To help with mediation, the SOA
platform employs a cache that can be used when
aggregating asynchronous responses.
HEALTHINF 2012 - International Conference on Health Informatics
140

Table 2: Sample IHE integration BPEL workflow set.
main workflow . handle security
. select IHE workflows
. log inputs/outputs
XCPD patient discovery
XCA query clinical documents query
XCA retrieve clinical documents retrieve
worker process generic dispatcher and
aggregator workflow
4.2 Configuration
Part of the application configuration is the definition
of the list of end-points (service registry), including
security to specified end-points that are allowed to
communicate between each other. We are also using
XML as a way to describe the end-points in a very
declarative manner. This file is used by the
application, but can be modified at runtime. It
includes the following elements: end-points URLs
and ports, IHE services available, public certificates,
identifiers and friendly names mapping for end-
points.
4.3 Testing
We use soapUI (an open source web service
functional testing tool) to easily simulate the health
exchange network as well as initiating and
responding gateways. With this tool, we were able to
easily hard code requests and turn on or off security
features (timeout, signature, encryption and SAML
assertions). We also used Axolotl Interoperability
Services (IS) that offer SOAP-based IHE web
services (XCPD and XCA) in conjunction with
soapUI to test the health exchange SOA integration
solution.
The ability to quickly create and validate test
cases is critical. It gave us the ability to test harness
end-points individually by simulating calls coming
from the exchange, but also to act as initiating end-
point gateways, querying the exchange and receiving
responses back from the exchange network.
We also used soapUI to test response timeout
scenarios and combine this pure black-box testing
approach with the analysis of transaction logs that
provides a trace of each steps of the orchestration
workflow.
5 CONCLUSIONS
The ability to efficiently and safely share and
integrate information through local and regional
Health Information Exchanges will be critical to
improve healthcare around the world.
Orchestration also has the advantage to be a
much more mature integration technology than
choreography. In addition to this, web service
orchestration offers much more than just technical
benefits (Gortmaker et al. 2004):
 Organizational: standardization, narrow gap
between business analysts and developers;
 Managerial: risk reduction, lower costs, more
flexibility;
 Strategic: IT resilience, delivery time reduction,
less technology lock-in;
 Technical: portability, reuse, interoperability of
tools, less complex code, better maintainability;
 Operational: efficiency, automation, higher level
tasks management.
When deployed on high performance platforms such
as SOA software appliances, this orchestration
solution is easy to test, extend and maintain.
We hope in a future article to describe how this
architecture is going to perform in production by
conducting performance measurement as well as
load tests. We also plan to describe additional end-
points integration such as state level immunization
registries and describe how this SOA architecture
can be used in regional and federal health
information exchange networks.
ACKNOWLEDGEMENTS
We are extremely grateful to Sean Smith, Justin Pun,
Corrina Burnley and Ryan Stewart for their help
with the IHE integration, demos and testing. Thank
you to Daniel Heller who helped manage this project
and Jiun-jiun Ma for the evaluation of the ESB
platform. Our appreciation to Pallav Sharda, Salim
Kizaraly, Daren Nicholso, Rajendra Limay, Josh
Wertheimer and Nicole Spencer for their feedback
and comments. Thank you also to Anand Shroff for
his leadership and support.
REFERENCES
Chen L., Wassermann B., Emmerich W., Foster H., 2006.
Web service orchestration with BPEL. In Proceedings
HEALTH INFORMATION EXCHANGE NETWORK INTEROPERABILITY THROUGH IHE TRANSACTIONS
ORCHESTRATION
141

of the 28th international conference on Software
engineering (ICSE '06). ACM, New York, NY, USA,
1071-1072.
DHIN: Delaware Health Information Network,
http://dhss.delaware.gov/dhss/dhcc/dhin.html.
Dogac A., Bicer V., Okcan A., 2006. Collaborative
Business Process Support in IHE XDS through
ebXML Business Processes. In Proceedings of the
22nd International Conference on Data Engineering
(ICDE '06). IEEE Computer Society, Washington,
DC, USA.
Gortmaker J., Janssen M., Wagenaar R., 2004. The
advantages of web service orchestration in
perspective. In Proceedings of the 6th international
conference on Electronic commerce (ICEC '04),
Marijn Janssen, Henk G. Sol, and René W. Wagenaar
(Eds.) ACM, New York, NY, USA, 506-515.
HIPAA, The Health Insurance Portability and
Accountability Act of 1996 (HIPAA) Privacy and
Security Rules. http://www.hhs.gov/ocr/privacy/.
HIP TN: Health Information Partnership for Tennessee.
http://www.hiptn.org/.
IHIE: Indiana Health Information Exchange.
http://www.ihie.com/.
Integrating the Healthcare Enterprise - The IHE Initiative:
IT Infrastructure Technical Framework (2009)
http://www.ihe.net.
Janssen M., Kuk G., 2007, Comparing Coordination
Arrangements Enabled by Web Services and Web
Service Orchestration Technology. ECIS 2007
Proceedings. Paper 158.
Jiménez-Peris R., Patiño-Martínez M., Martel-Jordán E.,
2008. Decentralized web service orchestration: a
reflective approach. In Proceedings of the 2008 ACM
symposium on Applied computing (SAC '08). ACM,
New York, NY, USA, 494-498.
Kilic O., Dogac A., Eichelberg M., 2010. Providing
interoperability of eHealth communities through peer-
to-peer networks. Trans. Info. Tech. Biomed. 14, 3
(May 2010), 846-853.
Masi M., Pugliese R., Tiezzi T., 2009. On Secure
Implementation of an IHE XUA-Based Protocol for
Authenticating Healthcare Professionals. In
Proceedings of the 5th International Conference on
Information Systems Security (ICISS '09), Atul
Prakash and Indranil Sen Gupta (Eds.). Springer-
Verlag, Berlin, Heidelberg, 55-70.
Papazoglou, M. P. and Georgakopoulos, 2003. D. Service-
Oriented Computing. Communications of the ACM, 46
(10). 24-28.
Security Assertion Markup Language - SAML
Specifications 2009, http://saml.xml.org/saml-
specifications.
SHIN-NY: Statewide Health Information Network for
New York, http://www.nyehealth.org.
Timm C., Schmutzler J., Marwedel P., Wietfeld C., 2009.
Dynamic web service orchestration applied to the
device profile for web services in hierarchical
networks. In Proceedings of the Fourth International
ICST Conference on Communication System software
and middleware (COMSWARE '09). ACM, Article 18,
New York, NY, USA.
UHIN: Utah Health Information Network,
http://www.mychie.org.
WISHIN: Utah Health Information Network,
http://www.mychie.org.
WVHIN: Wisconsin Statewide Health Information
Network, http://www.wishin.org/.
Yahyaoui H., Maamar Z., Boukadi K., 2009. Web services
synchronization in composition scenarios: the
centralized view. In Proceedings of the 2009
conference on Information Science, Technology and
Applications (ISTA '09). ACM, New York, NY, USA,
114-123.
HEALTHINF 2012 - International Conference on Health Informatics
142