Interoperability between Heterogeneous Healthcare Information Systems

Interoperability between
Heterogeneous Healthcare
Information Systems

John Gillson
ICW Labs

Interoperability
What is interoperability in the healthcare informatics domain?

”Interoperability is the ability of heterogeneous healthcare information
systems and software applications to communicate, to exchange data
accurately, effectively, and consistently, and to use the information
that has been exchanged”
Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project;
Dogac, Namli,Okcan, Laleci, Kabak and Eichelberg; pg. 1;
http://www.ehealthnews.eu/images/stories/pdf/ride.pdf

A Lack of Interoperability
There is currently a major challenge for the healthcare industry in
achieving interoperability among applications provided by different
vendors
Each hospital department or medical clinic may use multiple
applications to share clinical and administrative information among
applications
These applications could be legacy applications or state-of-the-art
applications
Unfortunately, each application may support multiple communications
interfaces that must be continually modified and maintained
Achieving interoperability among heterogeneous healthcare
information systems is very important because it will reduce costs
associated with healthcare and will contribute to more effective and
efficient patient treatment, management, and care

Message Interoperability -
Health Level Seven (HL7)
HL7 version 2.x (HL7 v2.x) application protocol for electronic data exchange is
the industry standard for transporting clinical and administrative information
between heterogeneous healthcare applications
The standard is based on the concept of application-to-application message
exchange
HL7 version 3 (HL7 v3), like HL7 v2.x, is a standard for exchanging messages
among information systems that implement healthcare applications
As a main difference to HL7 v2.x, HL7 v3 adopts an Object Oriented (OO)
approach using Unified Modeling Language (UML) principles which is based
on a data model called the Reference Information Model (RIM)
HL7 messages are XML documents that can be validated against XML
schemas derived from the conceptual models
Unfortunately as it stands right now, there is an interoperability problem
between HL7 v2.x and HL7 v3 messages because there is no well-defined
mapping between these messages

Reference Information Model (RIM)
HL7’s RIM is a “static model of healthcare information representing
the aspects of the healthcare domain undertaken so far by HL7
standards development activities”
The HL7 v3 standard development process defines rules used to
implement and derive domain-specific information models from the
RIM, finally generating XML schema definitions (XSD) associated with
a particular message type
The HL7 RIM standard “provides a substantial level of message
functionality between applications by structuring envelopes which
support message exchange between applications
HL7 message envelopes are called wrappers, initially modeled by
defining classes and relationships in the RIM
These specifications are then used to create the XML schema for the
message wrappers, following a process outlined in the HL7 Message
Development Framework” [4]

RIM continued…
Within the RIM, all HL7 messages are embedded into a Transmission
Wrapper
The Transmission Wrapper is there in order to identify and transfer the
message
Sender applications use the Control Act Wrapper to communicate receiving
information about the event that triggered the exchanged message
The Control Act Wrapper is there to decide what to do with the message, and
is part of the message semantics
Transmission Wrappers and Control Act Wrappers are used as envelopes for
the Message Body
The Message Body consists of the data to be used to perform the requested
action
Together, the Control Act Wrapper and the HL7 Message Body constitute the
complete semantics of HL7 Messages

RIM continued…
The RIM is the ultimate source from which all HL7 v3 protocol
specification standards draw their information related content

Source: Web Services Enablement for Healthcare HL7 Applications - Regio

HL7 functionalities –
Business Logic component
SENDER
“Create an XML representation of a specific HL7 Message Type that includes
Body, Control Wrapper, and Transmission Wrapper
Pass that message to the Web Service Adapter for its transmission to the
Receiver Application” [4]

RECEIVER
“Retrieve the HL7 Message received by the Web Service Adapter, and unfold
the Transmission Wrapper, Control Wrapper, and Message Body from the
received XML Message
Verify the HL7 Message satisfies the business rules and constraints for that
Interaction
Check if the Sender Application required an Application Level Acknowledge
(HL7 Message Type MCI) and – in that case – send that message” [4]

Business Logic component

Source: Web Services Enablement for Healthcare HL7 Applications - Regio

Web Service Adapter component
SENDER
“Read the Transmission Wrapper of received HL7 Messages to determine how to reach the ultimate
recipient (for example Receiver Application) on the Web Services Infrastructure, configuring the
SOAP Envelope accordingly
Based on HL7 Message Type, application configuration and policies (for example, security) prepare
a SOAP message, containing the HL7 XML message as a SOAP body part to be sent over the Web
Services Infrastructure
Pass the SOAP Message to the Web service proxy for transmission on the wire
Get ready to receive and – optionally – store related Accept or Application Level acknowledgement
messages from the Receiver, whenever requested by the Sender” [4]

RECEIVER
“Receive the SOAP message from the Web Service stub
Verify the received SOAP message satisfies application configuration and policies constraints (for
example, security)
Possibly store the received message in a a persistent form of memory
Optionally unfold the HL7 XML message from the SOAP message and check schema compliance
for the received HL7 Message with the expected HL7 Message Type
Verify if any communication (Accept) level acknowledgement needs to be performed, and in that
case prepare an appropriate message to be sent to the original Message Sender.
Pass the HL7 Message to the Receiver Application” [4]

HL7 Patient Referral example

Interface Engine Interface Engine

HL7-v3 HL7-v3
Patient Referral Patient Referral

^ 12345 ^
Sarah Johnson

11011010

Network
12345
Johnson

Sarah
Application 1: HIS Application 2: HIS
Database and back Database and back
end applications end applications
Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac

Communicating via Web Services

HL7- v3 HL7- v3
<patient> <patient>
Patient Referral
<id> </id> <id> 12345 </id> Web Service
<name> <name>
Sarah
</name> </name>
<surname> <surname>
Johnson
</surname> </surname>
</patient> </patient>

HTTP over TCP/IP
12345
Johnson

Sarah


Electronic Healthcare Record
(EHR)
The EHR of a patient is represented as a digitally stored healthcare information
record about an individual’s lifetime with the purpose of supporting continuity of care,
education and research, and ensuring confidentiality at all times
A number of standardization efforts are in place to provide the interoperability of
EHRs such as CEN/TC EHRcom, openEHR, and HL7 Clinical Document Architecture
(CDA)
Standards such as CEN/TC 251 EHRcom, openEHR, and CDA aim to structure and
markup the clinical content for the purpose of patient data exchange
There is also an industry initiative called Integrating the Healthcare Enterprise (IHE)
which specifies the Cross-Enterprise Document Sharing (XDS) integration profile for
this purpose
As previously discussed with HL7 messaging, considerable clinical information about
a patient is passed around through the messages exchanged among healthcare
applications
So what are the differences between the patient data contained in an HL7 message
compared with the patient data contained in an EHR?
The differentiation is evident because an EHR is the collection of relevant data about
an individual’s lifetime usually in a document structure

GEHR/openEHR Initiative
This approach uses a two-level methodology to model the EHR
structure
In the first level, a generic reference model that is specific to the
healthcare domain is developed and contains only a few classes (e.g.
role, act, entity, participation)
In the second level, healthcare and application specific concepts such
as blood pressure, cholesterol, blood glucose, lab results, etc. are
modeled as archetypes
An archetype definition basically consists of three parts: descriptive
data, constraint rules, and ontological definitions
Descriptive data types include parameters for containing a unique
identifier for the archetype, a machine-readable code describing the
clinical concept modeled by the archetype
Constraint rules are the core of the archetype and define restrictions on
the valid structure and content of the EHR record
Ontological definitions define the controlled vocabulary or machine-
readable codes that can be used in specific instances of the archetype

CEN/TC 251 and
ENV/EN 13606 EHRcom
A message-based standard for the exchange of electronic
healthcare records.
It consists of five parts:
– The Reference Model,
– Archetype Interchange Specification,
– Reference Archetypes and Term Lists,
– Security Features, and
– Exchange Models (communication protocol).

HL7 Clinical Document
Architecture (CDA)
The HL7 CDA is a document markup standard that specifies the
structure and semantics of “clinical documents” for the purpose of
exchange
A CDA document is a defined and complete information object that
can include text, images, sounds, and other multimedia content
CDA documents are encoded in XML
CDA is organized into three levels where each level iteratively adds
more structure to clinical documents
Level One focuses on the content of narrative documents with high-
level context such as parties, roles, dates and time, places and
structural organization of headings
Level Two models the fine-grained observations and instructions
within each heading through a set of RIM Act classes
Level Three specifies semantics each information entity by a unique
code which enables machine processing

IHE Cross-Enterprise Document
Sharing (XDS)
There is also an industry initiative called Integrating the Healthcare
Enterprise (IHE) which specified the Cross-Enterprise Document
Sharing (XDS) integration profile for this purpose
The basic idea of IHE XDS is to store healthcare documents in an
ebXML registry/repository architecture to facilitate their sharing
IHE XDS handles healthcare documents in a content neutral way

IHE Retrieve Information for
Display (RID)
RID provides a simple and rapid read-only access to patient-centric
clinical information that is located outside the user's current
application
Supports access to documents with CDA Level One, PDF and JPG
formats
It is defined as a Web service by providing its WSDL description
with a binding to HTTP GET

Summary of
EHR Standards
EHRcom HL7 CDA IHE RID IHE XDS
EHR A reference CDA is organized into IHE RID profile IHE XDS profile is
Content model and the Three levels: “Level One“ does not specify content neutral; it
data structures Focuses on the content of content; it does not specify
for EHR narrative documents; is only supports access how content
content are human to existing should be
defined. readable. Level Two CDA persistent structured and
models the fine-grained documents in encoded.
observations and well-known However, IHE
instructions within each presentation continues to
heading through a set of formats such as specify further
RIM Act classes. A CDA Level One, profiles and one
completely structured PDF and JPEG. recent profile IHE
document where the XDS MS HL7
semantics of each specifies medical
information entity is summaries based
specified by a unique code on HL7 CDA
will only be possible with standards and
“Level Three". CRS CDA
implementation


Summary of
EHR Standards
EHRcom HL7 CDA IHE RID IHE XDS
EHR The Message HL7 CDA does not The network and In IHE XDS, the
Communication package, which define how EHRs transport network and
Layer is under can protocol is transport protocol
development as be Internet; the is Internet; the
EN 13606-5, will communicated; messaging messaging
define how to the specification protocol is Web protocol is ebXML
communicate states that CDA services (http messaging (SOAP
the EHR extract documents can be GET). with attachments)
to a requesting transmitted in HL7 over HTTP or
process. messages (in OBX SMTP (email)
segment)
designed
to transfer clinical
documents.


Master Patient Index (MPI)
A component which allows for generating a unique patient ID in
heterogeneous patient management systems
Demographic patient data can be connected across hospital
boundaries aiming at the integration of different application systems
Serves as the basis for a cross-facility electronic patient record
Automatically link local data set from various source systems to
unique patient identifications – extensive editing options
Create and edit data sets
Identify and import data set changes

MPI - Business Logic

Local Patient Data Main Patient Data

Hospital X Master Patient Index (MPI)
Sarah Johnson Sarah Johnson
ID = 1 ID = 1, H X

Jack Smith Jack Smith
ID = 23 ID = 23, H X

Jack Smith Sarah Johnson
ID = 84, MPI ID = 63, MPI
GP Y
Jack Smith Jack Smith
ID = 1 ID = 1, GP Y

Sarah Johnson Sarah Johnson
ID = 47 ID = 47, GP Y

MPI - New Admission
Hospital 1 Master Patient Index (MPI)

Recycle Bin

le
Sarah Johnson

yc
ID = 1, Hospital 1

ec
R
New admission

Sarah Johnson New index Sarah Johnson Sarah Johnson

ew
ID = 1 ID = 1, Hospital 1 ID = 67, MPI
patient

N
Map
Sarah Johnson Sara Johnston
ID = 1, Hospital 1 ID = 13, MPI

MPI - Change of Patient Data Set
Hospital 1 Master Patient Index (MPI)

Recycle Bin

e
Sarah Johanson

l
yc
ID =1, Hospital 1

ec
R
Changed data set
Keep Sarah Johnson
ID = 67, MPI
Sarah Johanson Sarah Johanson
ID = 1 ID =1, Hospital 1 ?
Sarah Johanson
ID = 67, MPI
? Decide

Break up Sarah Johnson
ID = 67, MPI
Sarah Johanson
ID =1, Hospital 1
Sarah Johanson

ew
ID = 90, MPI

N
Break up mapping

Virtual Medical Record (VMR)
Unified view of medical data from various source systems and
personal health records
Centralized availability of medical data and encounters, as well as
documents and images
Export medical data, such as diagnoses, procedures, medications
and lab results
Extensive search and filter mechanisms
Upload documents; call up, fill in and edit forms
Standardized interface for integrated source systems – for
bidirectional exchange of medical data
Web-based integration interface – seamless access to the EPR
from third-part applications

Combining MPI and VMR
Virtual Medical Record (VMR) Master Patient Index (MPI)

Document 1

Case 1
Jack Smith
ID = 47, Hospital 1
Document 2

ID = 47,
Hospital 1
Jack Smith

Document 3 Case 2

Jack Smith
ID = 1, Hospital 2

ID = 1,
Document 4 Hospital 2

Case 3

Document 5

Healthcare Service Bus (HSB)
EMRs must be used and integrated into clinical practices to make
disparate systems interoperable; this is where the HSB comes into
the picture
The HSB is a healthcare-specific services integration platform
based on the Enterprise Service Bus (ESB); these are sometimes
also referred to as a Medical Service Bus (MSB)
The HSB is built on ESB technology, providing extra features and
enriched services specific to the healthcare domain; these services
will provide rich, complex and high-value communication in
geographically dispersed environments or inter-organization
applications
HSB will provide a rich bundle of core platform services to enable
rapid development; it will enable applications to easily consume
services of third party services
For example, using the HSB, clinical and billing systems can be
integrated using sophisticated workflows

Achieving Interoperability
With all these technologies we have talked about thus far, how
would an application achieve interoperability among the vast
possibilities of technologies used to facilitate an interoperable,
heterogeneous healthcare informatics domain?
The answer would most readily be found in an application called
Professional Exchange Server (PXS) developed by
InterComponentWare, Inc. (ICW)

CASE STUDY
Professional Exchange Server (PXS)
Allowing for smooth data flow across institutions and sectors, PXS aims at
allowing a holistic view of medical data from heterogeneous systems and
electronic medical records
PXS essentially bridges the gap between different organizations within the
healthcare informatics domain
By bridging the gap between disparate healthcare informatics systems, PXS
enables highly integrated care scenarios across different healthcare sectors
By linking local patient data sets and automatic cross-organizational patient
identifications, PXS provides a unified patient view on medical patient data
across organizations
PXS is not meant to replace systems or procedures, but rather to non-
invasively leverage the existing messaging infrastructure
PXS integrated clinical information systems in a secure and controlled
manner and enables the flow of information between doctors and hospitals

PXS – Overview of Functionality
PXS consists of 4 key components and 1 adapter:
– Master Patient Index (MPI)
– Virtual Medical Record (VMR)
– Medical Service Bus (MSB)
– Document Management Adapter (DMA)
– LifeSensor Adapter (LSA)
PXS offers an MPI to link together patient records referring to the
same physical person
Through the VMR, retrieval of medical information on any patient in
any hospital that the patient is associated is definitely possible
The MSB component is included as a plug-in to the local hospital’s
communication server, which processes patient information and
forwards this information to the MPI and VMR
The DMA correspondingly provides the patient record with access to
the medical documents stored in the hospital’s primary systems
The LSA connects the VMR to the patient’s LifeSensor PHR and
thus ensures a smooth exchange of information between hospitals,
patients and physicians

PXS – General architecture

Browser Physician

HTTP

Hospital
PXS
Practitioner
HL7 HL7
Master Virtual
Patient Medical
H1 HIS, RIS, PACS... Index Record P1 PCD, PVS...
(MPI) (VMR)

Hospital Medical Document Practitioner
HL7 Service Management HL7
Bus Adapter
(MSB) (DMA)
Hn HIS, RIS, PACS... Pn PCD, PVS...
LifeSensor Adapter
(LSA)

HTTP

Browser Patient

PXS - Hospital Group Connectivity

Source: ICW Developer Network – New to ICW Professional Exchange Server

PXS – Components

PXS System Components



Document Management Adapter (DMA)

Medical Service Bus (MSB)

PXS – MPI
The MPI component allows for generating a unique patient ID,
called an index patient, in heterogeneous patient management
systems
Demographic patient data can be connected across hospital
boundaries aiming at the integration of different hospital systems
The MPI is the basis and foundation for a cross-facility electronic
patient record
For each patient record in the hospitals’ patient management
systems, a local copy with the essential information needed for
patient mapping is maintained inside the MPI database
These local copies of the patient data are referred to as data sets
from the MPI perspective
These data sets can be mapped on a reference patient record to the
aforementioned index patient
These mappings can link data sets of different hospitals with one
index patient

PXS – MPI continued…
Similarity of patient records is calculated using a flexible
probabilistic model that assignes scored describing the degree of
similarity
The MPI used a weighted probabilistic model of estimating the
probability that the patient data sets refer to the same index patient
Each probability comparison is given a probability for these
matches, and using mathematical algorithms, a score for a match, a
non-match, and a missing value is computed
The scores of the individual comparisons are summarized and
normalized into a range between 0 and 1
0 means that all relevant attributes are different, 1 means that all
relevant attributes are equal
As we discussed earlier the HL7 v3 messaging, the MPI receives
HL7 v3 messages in order to maintain its internal data structures,
e.g., admission, changing of data sets, modification and merge of

PXS – MPI continued…


PXS – VMR
The VMR component gives access to demographic and medical
patient data and documents for healthcare professionals
The VMR provides different views on various medical data such as
encounters, diagnoses, observations, and documents of a patient
Document content is either copied into the VMR database or
alternatively remains inside the primary system
The VMR then only maintains corresponding pointers or references
to these documents within the primary systems
The functionality of the VMR allows for all medical records from all
connected data sets to be assembled and displayed as a cross-
facility patient record

PXS – VMR continued…


PXS – DMA
Retrieving and displaying documents is done independently by the DMA.
The underlying technology of the DMA encapsulates all technical
information and strategies to retrieving a document from its storage and
controlling issues such as caching, format conversion, etc
The DMA allows patient documents to be accessed in the clinical
information system
In order to be viewed in the VMR, the DMA must request from the primary
system, the necessary documents
All common document formats are supported as well as CDA documents
The capabilities of the DMA are numerous; the DMA has internal caching
facilities to display documents quickly and is capable of connecting various
hospital primary systems and storage devices
The functionality extends further by offering connectivity for viewing and
editing DICOM images stemming from Ultrasound, MRT or CT devices

PXS - Components

PXS System Components



Document Management Adapter (DMA)

Medical Service Bus (MSB)

PXS – MSB
The MSB component, embedded as a plug-in to the hospital’s
communication server, establishes the connection between hospital
information systems and the PXS components by setting up constraints for
HL7 messaging
The MSB’s main functional task is to translate messages from the hospital
environment into HL7 v3 messages, which is used by all components to
import and export patient data
The translation of HL7 v2.x messages to HL7 v3 messages was illustrated
earlier with regards to the interoperability issues between HL7 versions
The MSB is a very important component for providing these message
translation services
In addition, the MSB manages the message routing, message buffering and
translation of messages

PXS – LSA
The LSA component allows for seamless integration of a hospital’s
electronic patient record with the patient-centric LifeSensor PHR
Medical data and documents can be imported into the patient’s PHR
and correspondingly, data and documents of the PHR can be
imported into the hospital’s VMR
This bidirectional communication enables the seamless exchange of
medical information between hospitals, patients, and physicians
The LifeSensor PHR is very important to the patient since this is
his/her own view of their own medical data and documents

References
[1] Key Issues of Technical Interoperability Solutions in eHealth and
the RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak and
Eichelberg; pg. 1;
[2] Towards Interoperable Healthcare Information Systems: The
HL7 Conformance Profile Approach; Snelick, Rontey, Gebase,
Carnahan; p. 2;
http://www.itl.nist.gov/div897/ctg/messagemaker/papers/IESA2007.rsnelic

[3] Key Issues of Technical Interoperability Solutions in eHealth and
the RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak and
Eichelberg; pg. 2;

References continued…
[4] Web Services Enablement for Healthcare HL7 Applications –
Web Services Basic Profile Reference Implementation; Mauro
Regio, Microsoft Corporation;
http://msdn.microsoft.com/en-us/library/ms954603.aspx
[5] Aims of the openEHR Architecture
http://www.openehr.org/releases/1.0.1/html/architecture/overview/O
utput/aims.html
[6] HL7 Clinical Document Architecture, Release 2.0
http://xml.coverpages.org/CDA-Release2-Unofficial.html
[7] Electronic Business using eXtensible Markup Language
http://en.wikipedia.org/wiki/EbXML
[8] WS/PIDS: Standard Interoperable PIDS in Web Services
Environments; Vasilescu, Dorobantu, Govoni, Padh, Ki Mun
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04358877

[9] SNOMED CT
http://en.wikipedia.org/wiki/SNOMED_CT
[10] LOINC
http://en.wikipedia.org/wiki/LOINC
[11] Key Issues of Technical Interoperability Solutions in eHealth
(IST-027065 RIDE Project); Dogac
http://www.ehealthconference2006.org/pdf/DOGAC.pdf
[12] ICW Developer Network – PXS Technical Whitepaper (must be
a registered member of the ICW Developer Network to view the
documents)
http://idn.icw-
global.com/fileadmin/downloads/PRG/TechnicalWhitepaper_en_US
_PRG_PXS__2.0_DE_en_US_2.0.pdf
[13] ICW Developer Network – New to ICW Professional Exchange
Server
http://idn.icw-global.com/solutions/icw-professional-
suite/professional-exchange-server/new-to-pxs.html

[14] ICW Professional Suite – Professional Exchange Server
http://www.icw-global.com/fileadmin/user_upload/pdf/brochures/icw-
professional-suite/stuffer/icw-pxs-en.pdf

Interoperability between Heterogeneous Healthcare Information Systems

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (6)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Interoperability between Heterogeneous Healthcare Information Systems

Ähnlich wie Interoperability between Heterogeneous Healthcare Information Systems (20)

Mehr von Luigi Ceccaroni

Mehr von Luigi Ceccaroni (20)

Interoperability between Heterogeneous Healthcare Information Systems