51
Interoperability Interoperability between Heterogeneous between Heterogeneous Healthcare Information Healthcare Information Systems Systems John Gillson John Gillson ICW Labs ICW Labs

Interoperability Between Healthcare Applications

  • Upload
    bluesfc

  • View
    4.835

  • Download
    6

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Interoperability Between Healthcare Applications

Interoperability between Interoperability between Heterogeneous Healthcare Heterogeneous Healthcare

Information SystemsInformation Systems

John GillsonJohn GillsonICW LabsICW Labs

Page 2: Interoperability Between Healthcare Applications

InteroperabilityInteroperabilityWhat is interoperability in the healthcare informatics domain?What is interoperability in the healthcare informatics domain?

””Interoperability is the ability of heterogeneous healthcare information Interoperability is the ability of heterogeneous healthcare information systems and software applications to communicate, to exchange data systems and software applications to communicate, to exchange data accurately, effectively, and consistently, and to use the information accurately, effectively, and consistently, and to use the information that has been exchanged”that has been exchanged”

Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project; Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project;

Dogac, Dogac, Namli,Okcan, Laleci, Kabak and Eichelberg; pg. 1;Namli,Okcan, Laleci, Kabak and Eichelberg; pg. 1;http://www.ehealthnews.eu/images/stories/pdf/ride.pdfhttp://www.ehealthnews.eu/images/stories/pdf/ride.pdf

Page 3: Interoperability Between Healthcare Applications

A Lack of InteroperabilityA Lack of InteroperabilityThere is currently a major challenge for the healthcare industry in There is currently a major challenge for the healthcare industry in achieving interoperability among applications provided by different achieving interoperability among applications provided by different vendorsvendors

Each hospital department or medical clinic may use multiple Each hospital department or medical clinic may use multiple applications to share clinical and administrative information among applications to share clinical and administrative information among applicationsapplications

These applications could be legacy applications or state-of-the-art These applications could be legacy applications or state-of-the-art applicationsapplications

Unfortunately, each application may support multiple communications Unfortunately, each application may support multiple communications interfaces that must be continually modified and maintainedinterfaces that must be continually modified and maintained

Achieving interoperability among heterogeneous healthcare Achieving interoperability among heterogeneous healthcare information systems is very important because it will reduce costs information systems is very important because it will reduce costs associated with healthcare and will contribute to more effective and associated with healthcare and will contribute to more effective and efficient patient treatment, management, and careefficient patient treatment, management, and care

Page 4: Interoperability Between Healthcare Applications

Message Interoperability -Message Interoperability -Health Level Seven (HL7)Health Level Seven (HL7)

HL7 version 2.x (HL7 v2.x) application protocol for electronic data exchange is HL7 version 2.x (HL7 v2.x) application protocol for electronic data exchange is the industry standard for transporting clinical and administrative information the industry standard for transporting clinical and administrative information between heterogeneous healthcare applicationsbetween heterogeneous healthcare applicationsThe standard is based on the concept of application-to-application message The standard is based on the concept of application-to-application message exchangeexchangeHL7 version 3 (HL7 v3), like HL7 v2.x, is a standard for exchanging messages HL7 version 3 (HL7 v3), like HL7 v2.x, is a standard for exchanging messages among information systems that implement healthcare applicationsamong information systems that implement healthcare applicationsAs a main difference to HL7 v2.x, HL7 v3 adopts an Object Oriented (OO) 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 approach using Unified Modeling Language (UML) principles which is based on a data model called the Reference Information Model (RIM)on a data model called the Reference Information Model (RIM)HL7 messages are XML documents that can be validated against XML HL7 messages are XML documents that can be validated against XML schemas derived from the conceptual modelsschemas derived from the conceptual modelsUnfortunately as it stands right now, there is an interoperability problem 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 between HL7 v2.x and HL7 v3 messages because there is no well-defined mapping between these messagesmapping between these messages

Page 5: Interoperability Between Healthcare Applications

Message Interoperability -Message Interoperability -Reference Information Model (RIM)Reference Information Model (RIM)

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

Page 6: Interoperability Between Healthcare Applications

Message Interoperability -Message Interoperability - RIM RIM continued…continued…

Within the RIM, all HL7 messages are embedded into a Within the RIM, all HL7 messages are embedded into a Transmission Transmission WrapperWrapper

The Transmission Wrapper is there in order to identify and transfer the The Transmission Wrapper is there in order to identify and transfer the messagemessage

Sender applications use the Sender applications use the Control Act Wrapper Control Act Wrapper to communicate receiving to communicate receiving information about the event that triggered the exchanged messageinformation about the event that triggered the exchanged message

The Control Act Wrapper is there to decide what to do with the message, and The Control Act Wrapper is there to decide what to do with the message, and is part of the message semanticsis part of the message semantics

Transmission Wrappers and Control Act Wrappers are used as envelopes for Transmission Wrappers and Control Act Wrappers are used as envelopes for the Message Bodythe Message Body

The Message Body consists of the data to be used to perform the requested The Message Body consists of the data to be used to perform the requested actionaction

Together, the Control Act Wrapper and the HL7 Message Body constitute the Together, the Control Act Wrapper and the HL7 Message Body constitute the complete semantics of HL7 Messagescomplete semantics of HL7 Messages

Page 7: Interoperability Between Healthcare Applications

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

Message Interoperability -Message Interoperability - RIM RIM continued…continued…

Source: Web Services Enablement for Healthcare HL7 Applications - RegioSource: Web Services Enablement for Healthcare HL7 Applications - Regio

Page 8: Interoperability Between Healthcare Applications

HL7 functionalities – HL7 functionalities – Business Logic componentBusiness Logic component

SENDERSENDER““Create an XML representation of a specific HL7 Message Type that includes Create an XML representation of a specific HL7 Message Type that includes Body, Control Wrapper, and Transmission WrapperBody, Control Wrapper, and Transmission WrapperPass that message to the Web Service Adapter for its transmission to the Pass that message to the Web Service Adapter for its transmission to the Receiver Application” [4]Receiver Application” [4]

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

Page 9: Interoperability Between Healthcare Applications

HL7 functionalities – HL7 functionalities – Business Logic componentBusiness Logic component

Source: Web Services Enablement for Healthcare HL7 Applications - RegioSource: Web Services Enablement for Healthcare HL7 Applications - Regio

Page 10: Interoperability Between Healthcare Applications

HL7 functionalities – HL7 functionalities – Web Service Adapter componentWeb Service Adapter component

SENDERSENDER““Read the Transmission Wrapper of received HL7 Messages to determine how to reach the ultimate 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 recipient (for example Receiver Application) on the Web Services Infrastructure, configuring the SOAP Envelope accordinglySOAP Envelope accordinglyBased on HL7 Message Type, application configuration and policies (for example, security) prepare 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 a SOAP message, containing the HL7 XML message as a SOAP body part to be sent over the Web Services InfrastructureServices InfrastructurePass the SOAP Message to the Web service proxy for transmission on the wirePass the SOAP Message to the Web service proxy for transmission on the wireGet ready to receive and – optionally – store related Accept or Application Level acknowledgement Get ready to receive and – optionally – store related Accept or Application Level acknowledgement messages from the Receiver, whenever requested by the Sender” [4]messages from the Receiver, whenever requested by the Sender” [4]

RECEIVERRECEIVER““Receive the SOAP message from the Web Service stubReceive the SOAP message from the Web Service stubVerify the received SOAP message satisfies application configuration and policies constraints (for Verify the received SOAP message satisfies application configuration and policies constraints (for example, security)example, security)Possibly store the received message in a a persistent form of memoryPossibly store the received message in a a persistent form of memoryOptionally unfold the HL7 XML message from the SOAP message and check schema compliance Optionally unfold the HL7 XML message from the SOAP message and check schema compliance for the received HL7 Message with the expected HL7 Message Typefor the received HL7 Message with the expected HL7 Message TypeVerify if any communication (Accept) level acknowledgement needs to be performed, and in that 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.case prepare an appropriate message to be sent to the original Message Sender.Pass the HL7 Message to the Receiver Application” [4]Pass the HL7 Message to the Receiver Application” [4]

Page 11: Interoperability Between Healthcare Applications

HL7 functionalities – HL7 functionalities – Business Logic componentBusiness Logic component

Source: Web Services Enablement for Healthcare HL7 Applications - RegioSource: Web Services Enablement for Healthcare HL7 Applications - Regio

Page 12: Interoperability Between Healthcare Applications

HL7 Patient Referral exampleHL7 Patient Referral example

Sarah

Johnson

12345

HL7-v3Patient Referral

Network

11011010

HL7-v3Patient Referral

12345 Sarah Johnson^ ^

Application 1: HIS Database and back end applications

Application 2: HIS Database and back end applications

Interface Engine Interface Engine

Source: Key Issues of Technical Interoperability Solutions in eHealth; DogacKey Issues of Technical Interoperability Solutions in eHealth; Dogac

Page 13: Interoperability Between Healthcare Applications

Communicating via Web ServicesCommunicating via Web Services

Sarah

Johnson

12345

<id> </id><name>

</name>

<surname>

</surname></patient>

<patient>HL7- v3 Patient Referral

Web Service

HTTP over TCP/IP

11011010

<id> </id><name>

</name>

<surname>

</surname></patient>

<patient>

HL7- v3

12345

Johnson

Sarah

Source: Key Issues of Technical Interoperability Solutions in eHealth; DogacKey Issues of Technical Interoperability Solutions in eHealth; Dogac

Page 14: Interoperability Between Healthcare Applications

Electronic Healthcare Record Electronic Healthcare Record (EHR)(EHR)

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

Page 15: Interoperability Between Healthcare Applications

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

Page 16: Interoperability Between Healthcare Applications

CEN/TC 251 and CEN/TC 251 and ENV/EN 13606 EHRcomENV/EN 13606 EHRcom

AA message-based standard for the exchange of electronic message-based standard for the exchange of electronic healthcare records.healthcare records.

It consists of five partsIt consists of five parts::– The Reference Model,The Reference Model,– Archetype Interchange Specification,Archetype Interchange Specification,– Reference Archetypes and Term Lists,Reference Archetypes and Term Lists,– Security Features, andSecurity Features, and– Exchange Models (communication protocol).Exchange Models (communication protocol).

Page 17: Interoperability Between Healthcare Applications

HL7 Clinical Document HL7 Clinical Document Architecture (CDA)Architecture (CDA)

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

Page 18: Interoperability Between Healthcare Applications

IHE Cross-Enterprise Document IHE Cross-Enterprise Document Sharing (XDS)Sharing (XDS)

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

Page 19: Interoperability Between Healthcare Applications

IHE Retrieve Information for IHE Retrieve Information for Display (RID)Display (RID)

RIDRID provides a simple and rapid read-only access to patient-centric provides a simple and rapid read-only access to patient-centric clinical information that is located outside the user's current clinical information that is located outside the user's current applicationapplication

Supports Supports access to access to documents with CDA Level One, PDF and JPG documents with CDA Level One, PDF and JPG formatsformats

It is It is defined as a Web service by providing its WSDL description defined as a Web service by providing its WSDL description with a binding to HTTP GETwith a binding to HTTP GET

Page 20: Interoperability Between Healthcare Applications

Summary of Summary of EHR StandardsEHR Standards

EHRcom HL7 CDA IHE RID IHE XDS

EHR EHR ContentContent

A referencemodel and thedata structuresfor EHRcontent aredefined.

CDA is organized intoThree levels: “Level One“Focuses on the content ofnarrative documents; is only humanreadable. Level Two CDAmodels the fine-grainedobservations andinstructions within eachheading through a set ofRIM Act classes. Acompletely structureddocument where thesemantics of eachinformation entity isspecified by a unique code will only be possible with “Level Three".

IHE RID profiledoes not specifycontent; itsupports accessto existingpersistentdocuments inwell-knownpresentationformats such asCDA Level One,PDF and JPEG.

IHE XDS profile is content neutral; it does not specify how content should be structured and encoded. However, IHE continues to specify further profiles and one recent profile IHE XDS MS HL7 specifies medical summaries based on HL7 CDA standards and CRS CDA implementation

Source: Key Issues of Technical Interoperability Solutions in eHealth; DogacKey Issues of Technical Interoperability Solutions in eHealth; Dogac

Page 21: Interoperability Between Healthcare Applications

Summary of Summary of EHR StandardsEHR Standards

EHRcom HL7 CDA IHE RID IHE XDS

EHR EHR Communication Communication LayerLayer

The Messagepackage, whichis underdevelopment asEN 13606-5, willdefine how tocommunicatethe EHR extractto a requestingprocess.

HL7 CDA does notdefine how EHRs canbe communicated;the specificationstates that CDAdocuments can betransmitted in HL7messages (in OBXsegment) designedto transfer clinicaldocuments.

The network andtransport protocol isInternet; themessagingprotocol is Webservices (httpGET).

In IHE XDS, the network and transport protocol is Internet; the messaging protocol is ebXML messaging (SOAP with attachments) over HTTP or SMTP (email)

Source: Key Issues of Technical Interoperability Solutions in eHealth; DogacKey Issues of Technical Interoperability Solutions in eHealth; Dogac

Page 22: Interoperability Between Healthcare Applications

Master Patient Index (MPI)Master Patient Index (MPI)

A component which allows for generating a unique patient ID in A component which allows for generating a unique patient ID in heterogeneous patient management systemsheterogeneous patient management systems

Demographic patient data can be connected across hospital Demographic patient data can be connected across hospital boundaries aiming at the integration of different application systemsboundaries aiming at the integration of different application systems

Serves as the basis for a cross-facility electronic patient recordServes as the basis for a cross-facility electronic patient record

Automatically link local data set from various source systems to Automatically link local data set from various source systems to unique patient identifications – extensive editing optionsunique patient identifications – extensive editing options

Create and edit data setsCreate and edit data sets

Identify and import data set changesIdentify and import data set changes

Page 23: Interoperability Between Healthcare Applications

Master Patient Index (MPI)

Main Patient Data

Sarah JohnsonID = 1, H X

Sarah JohnsonID = 63, MPI

Sarah JohnsonID = 47, GP Y

Jack SmithID = 23, H X

Jack SmithID = 84, MPI

Jack SmithID = 1, GP Y

GP Y

Local Patient Data

Hospital X

MPI - Business LogicMPI - Business Logic

Sarah JohnsonID = 1

Sarah JohnsonID = 47

Jack SmithID = 23

Jack SmithID = 1

Page 24: Interoperability Between Healthcare Applications

Hospital 1

New admission

Master Patient Index (MPI)

New index patient New

Sarah JohnsonID = 1, Hospital 1

Sarah JohnsonID = 67, MPI

MPI - New AdmissionMPI - New Admission

Sarah JohnsonID = 1

Recycle Bin

Recyc

le Sarah JohnsonID = 1, Hospital 1

MapSarah JohnsonID = 1, Hospital 1

Sara JohnstonID = 13, MPI

Page 25: Interoperability Between Healthcare Applications

Master Patient Index (MPI)

Keep

? Decide

?Sarah JohansonID =1, Hospital 1

Sarah JohnsonID = 67, MPI

Sarah JohansonID = 67, MPI

Hospital 1

Changed data set

Sarah JohansonID = 1

MPI - Change of Patient Data SetMPI - Change of Patient Data Set

Recycle Bin

Recyc

le Sarah JohansonID =1, Hospital 1

Break up

Break up mapping New

Sarah JohansonID =1, Hospital 1

Sarah JohnsonID = 67, MPI

Sarah JohansonID = 90, MPI

Page 26: Interoperability Between Healthcare Applications

Virtual Medical Record (VMR)Virtual Medical Record (VMR)

Unified view of medical data from various source systems and Unified view of medical data from various source systems and personal health recordspersonal health recordsCentralized availability of medical data and encounters, as well as Centralized availability of medical data and encounters, as well as documents and imagesdocuments and imagesExport medical data, such as diagnoses, procedures, medications Export medical data, such as diagnoses, procedures, medications and lab resultsand lab resultsExtensive search and filter mechanismsExtensive search and filter mechanismsUpload documents; call up, fill in and edit formsUpload documents; call up, fill in and edit formsStandardized interface for integrated source systems – for Standardized interface for integrated source systems – for bidirectional exchange of medical databidirectional exchange of medical dataWeb-based integration interface – seamless access to the EPR Web-based integration interface – seamless access to the EPR from third-part applicationsfrom third-part applications

Page 27: Interoperability Between Healthcare Applications

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

Jack Smith

ID = 1,Hospital 2

ID = 47,Hospital 1

Jack SmithID = 47, Hospital 1

Jack SmithID = 1, Hospital 2

Case 1

Document 1

Case 2

Case 3

Document 3

Document 5

Document 4

Document 2

Combining MPI and VMRCombining MPI and VMR

Page 28: Interoperability Between Healthcare Applications

Healthcare Service Bus (HSB)Healthcare Service Bus (HSB)

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

Page 29: Interoperability Between Healthcare Applications

HSB landscapeHSB landscape

Page 30: Interoperability Between Healthcare Applications

Achieving InteroperabilityAchieving Interoperability

With all these technologies we have talked about thus far, how With all these technologies we have talked about thus far, how would an application achieve interoperability among the vast would an application achieve interoperability among the vast possibilities of technologies used to facilitate an interoperable, possibilities of technologies used to facilitate an interoperable, heterogeneous healthcare informatics domain?heterogeneous healthcare informatics domain?

The answer would most readily be found in an application called The answer would most readily be found in an application called Professional Exchange Server (PXS)Professional Exchange Server (PXS) developed by developed by InterComponentWare, Inc. (ICW)InterComponentWare, Inc. (ICW)

Page 31: Interoperability Between Healthcare Applications

CASE STUDYCASE STUDYProfessional Exchange Server (PXS)Professional Exchange Server (PXS)

Allowing for smooth data flow across institutions and sectors, PXS aims at Allowing for smooth data flow across institutions and sectors, PXS aims at allowing a holistic view of medical data from heterogeneous systems and allowing a holistic view of medical data from heterogeneous systems and electronic medical recordselectronic medical recordsPXS essentially bridges the gap between different organizations within the PXS essentially bridges the gap between different organizations within the healthcare informatics domainhealthcare informatics domainBy bridging the gap between disparate healthcare informatics systems, PXS By bridging the gap between disparate healthcare informatics systems, PXS enables highly integrated care scenarios across different healthcare sectorsenables highly integrated care scenarios across different healthcare sectorsBy linking local patient data sets and automatic cross-organizational patient By linking local patient data sets and automatic cross-organizational patient identifications, PXS provides a unified patient view on medical patient data identifications, PXS provides a unified patient view on medical patient data across organizationsacross organizationsPXS is not meant to replace systems or procedures, but rather to non-PXS is not meant to replace systems or procedures, but rather to non-invasively leverage the existing messaging infrastructureinvasively leverage the existing messaging infrastructurePXS integrated clinical information systems in a secure and controlled PXS integrated clinical information systems in a secure and controlled manner and enables the flow of information between doctors and hospitalsmanner and enables the flow of information between doctors and hospitals

Page 32: Interoperability Between Healthcare Applications

PXS – Overview of FunctionalityPXS – Overview of FunctionalityPXS consists of 4 key components and 1 adapter:PXS consists of 4 key components and 1 adapter:– Master Patient Index (MPI)Master Patient Index (MPI)– Virtual Medical Record (VMR)Virtual Medical Record (VMR)– Medical Service Bus (MSB)Medical Service Bus (MSB)– Document Management Adapter (DMA)Document Management Adapter (DMA)– LifeSensor Adapter (LSA)LifeSensor Adapter (LSA)

PXS offers an MPI to link together patient records referring to the same PXS offers an MPI to link together patient records referring to the same physical personphysical personThrough the VMR, retrieval of medical information on any patient in any hospital Through the VMR, retrieval of medical information on any patient in any hospital that the patient is associated is definitely possiblethat the patient is associated is definitely possibleThe MSB component is included as a plug-in to the local hospital’s The MSB component is included as a plug-in to the local hospital’s communication server, which processes patient information and forwards this communication server, which processes patient information and forwards this information to the MPI and VMRinformation to the MPI and VMRThe DMA correspondingly provides the patient record with access to the The DMA correspondingly provides the patient record with access to the medical documents stored in the hospital’s primary systemsmedical documents stored in the hospital’s primary systemsThe LSA connects the VMR to the patient’s LifeSensor PHR and thus ensures The LSA connects the VMR to the patient’s LifeSensor PHR and thus ensures a smooth exchange of information between hospitals, patients and physiciansa smooth exchange of information between hospitals, patients and physicians

Page 33: Interoperability Between Healthcare Applications

PXS – General architecturePXS – General architecture

PXSMasterPatient Index(MPI)

VirtualMedicalRecord(VMR)

MedicalService

Bus(MSB)

DocumentManagement

Adapter(DMA)

Browser Patient

Hospital

HIS, RIS, PACS...

Practitioner

PCD, PVS...

Hospital

HIS, RIS, PACS...

Practitioner

PCD, PVS...

P 1

Browser

H 1

H n P n

LifeSensor Adapter(LSA)

HL7

HL7 HL7

HL7

HTTP

HTTP

Physician

Page 34: Interoperability Between Healthcare Applications

PXS - Hospital Group ConnectivityPXS - Hospital Group Connectivity

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

Page 35: Interoperability Between Healthcare Applications

PXS – ComponentsPXS – Components

PXS System Components

Master Patient Index (MPI)

Virtual Medical Record (VMR)

Document Management Adapter (DMA)

Medical Service Bus (MSB)

Page 36: Interoperability Between Healthcare Applications

PXS – MPIPXS – MPIThe MPI component allows for generating a unique patient ID, called an The MPI component allows for generating a unique patient ID, called an index index patientpatient, in heterogeneous patient management systems, in heterogeneous patient management systems

Demographic patient data can be connected across hospital boundaries Demographic patient data can be connected across hospital boundaries aiming at the integration of different hospital systemsaiming at the integration of different hospital systems

The MPI is the basis and foundation for a cross-facility electronic patient The MPI is the basis and foundation for a cross-facility electronic patient recordrecord

For each patient record in the hospitals’ patient management systems, a local For each patient record in the hospitals’ patient management systems, a local copy with the essential information needed for patient mapping is maintained copy with the essential information needed for patient mapping is maintained inside the MPI databaseinside the MPI database

These local copies of the patient data are referred to as data sets from the These local copies of the patient data are referred to as data sets from the MPI perspectiveMPI perspective

These data sets can be mapped on a reference patient record to the These data sets can be mapped on a reference patient record to the aforementioned aforementioned index patientindex patient

These mappings can link These mappings can link data setsdata sets of different hospitals with one of different hospitals with one index patientindex patient

Page 37: Interoperability Between Healthcare Applications

PXS – MPI PXS – MPI continued…continued…Similarity of patient records is calculated using a flexible probabilistic Similarity of patient records is calculated using a flexible probabilistic model that assignes scored describing the degree of similaritymodel that assignes scored describing the degree of similarity

The MPI used a weighted probabilistic model of estimating the probability The MPI used a weighted probabilistic model of estimating the probability that the patient that the patient data setsdata sets refer to the same refer to the same index patientindex patient

Each probability comparison is given a probability for these matches, and Each probability comparison is given a probability for these matches, and using mathematical algorithms, a score for a match, a non-match, and a using mathematical algorithms, a score for a match, a non-match, and a missing value is computedmissing value is computed

The scores of the individual comparisons are summarized and normalized The scores of the individual comparisons are summarized and normalized into a range between 0 and 1into a range between 0 and 1

0 means that all relevant attributes are different, 1 means that all relevant 0 means that all relevant attributes are different, 1 means that all relevant attributes are equalattributes are equal

As we discussed earlier the HL7 v3 messaging, the MPI receives HL7 v3 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, messages in order to maintain its internal data structures, e.g., admission, changing of data sets, modification and merge of patientschanging of data sets, modification and merge of patients

Page 38: Interoperability Between Healthcare Applications

PXS – MPI PXS – MPI continued…continued…

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

Page 39: Interoperability Between Healthcare Applications

PXS – ComponentsPXS – Components

PXS System Components

Master Patient Index (MPI)

Virtual Medical Record (VMR)

Document Management Adapter (DMA)

Medical Service Bus (MSB)

Page 40: Interoperability Between Healthcare Applications

PXS – VMRPXS – VMRThe VMR component gives access to demographic and medical The VMR component gives access to demographic and medical patient data and documents for healthcare professionalspatient data and documents for healthcare professionals

The VMR provides different views on various medical data such as The VMR provides different views on various medical data such as encounters, diagnoses, observations, and documents of a patientencounters, diagnoses, observations, and documents of a patient

Document content is either copied into the VMR database or Document content is either copied into the VMR database or alternatively remains inside the primary systemalternatively remains inside the primary system

The VMR then only maintains corresponding pointers or references The VMR then only maintains corresponding pointers or references to these documents within the primary systemsto these documents within the primary systems

The functionality of the VMR allows for all medical records from all The functionality of the VMR allows for all medical records from all connected connected data setsdata sets to be assembled and displayed as a cross- to be assembled and displayed as a cross-facility patient recordfacility patient record

Page 41: Interoperability Between Healthcare Applications

PXS – VMR continued…PXS – VMR continued…

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

Page 42: Interoperability Between Healthcare Applications

PXS – ComponentsPXS – Components

PXS System Components

Master Patient Index (MPI)

Virtual Medical Record (VMR)

Document Management Adapter (DMA)

Medical Service Bus (MSB)

Page 43: Interoperability Between Healthcare Applications

PXS – DMAPXS – DMARetrieving and displaying documents is done independently by the DMA.Retrieving and displaying documents is done independently by the DMA.

The underlying technology of the DMA encapsulates all technical The underlying technology of the DMA encapsulates all technical information and strategies to retrieving a document from its storage and information and strategies to retrieving a document from its storage and controlling issues such as caching, format conversion, etccontrolling issues such as caching, format conversion, etc

The DMA allows patient documents to be accessed in the clinical The DMA allows patient documents to be accessed in the clinical information systeminformation system

In order to be viewed in the VMR, the DMA must request from the primary In order to be viewed in the VMR, the DMA must request from the primary system, the necessary documentssystem, the necessary documents

All common document formats are supported as well as CDA documentsAll common document formats are supported as well as CDA documents

The capabilities of the DMA are numerous; the DMA has internal caching The capabilities of the DMA are numerous; the DMA has internal caching facilities to display documents quickly and is capable of connecting various facilities to display documents quickly and is capable of connecting various hospital primary systems and storage deviceshospital primary systems and storage devices

The functionality extends further by offering connectivity for viewing and The functionality extends further by offering connectivity for viewing and editing DICOM images stemming from Ultrasound, MRT or CT devicesediting DICOM images stemming from Ultrasound, MRT or CT devices

Page 44: Interoperability Between Healthcare Applications

PXS - ComponentsPXS - Components

PXS System Components

Master Patient Index (MPI)

Virtual Medical Record (VMR)

Document Management Adapter (DMA)

Medical Service Bus (MSB)

Page 45: Interoperability Between Healthcare Applications

PXS – MSBPXS – MSBThe MSB component, embedded as a plug-in to the hospital’s The MSB component, embedded as a plug-in to the hospital’s communication server, establishes the connection between hospital communication server, establishes the connection between hospital information systems and the PXS components by setting up constraints for information systems and the PXS components by setting up constraints for HL7 messagingHL7 messaging

The MSB’s main functional task is to translate messages from the hospital 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 environment into HL7 v3 messages, which is used by all components to import and export patient dataimport and export patient data

The translation of HL7 v2.x messages to HL7 v3 messages was illustrated The translation of HL7 v2.x messages to HL7 v3 messages was illustrated earlier with regards to the interoperability issues between HL7 versionsearlier with regards to the interoperability issues between HL7 versions

The MSB is a very important component for providing these message The MSB is a very important component for providing these message translation servicestranslation services

In addition, the MSB manages the message routing, message buffering and In addition, the MSB manages the message routing, message buffering and translation of messagestranslation of messages

Page 46: Interoperability Between Healthcare Applications

PXS – MSB PXS – MSB continued…continued…

ESB

HL7 2.x * MLLP

FIREWALL

ESB

Bridge

PXSAdapter

XML * SOAP-WS

SDK(API)

Hospital ZClient

System

Hospital YClient

System

PXS Proxy

File Sharing

Middleware

WANHL7 2.x * HTTPS

HL7 2.x * MLLP

HL7 2.x * File Exchange

PXSHL7 3 * HTTPS

GPSystem

WAN

HL7 2.x * HTTPS

Hospital YClient

System

Hospital XClient

System

Page 47: Interoperability Between Healthcare Applications

PXS – LSAPXS – LSA

The LSA component allows for seamless integration of a hospital’s The LSA component allows for seamless integration of a hospital’s electronic patient record with the patient-centric LifeSensor PHRelectronic patient record with the patient-centric LifeSensor PHR

Medical data and documents can be imported into the patient’s PHR Medical data and documents can be imported into the patient’s PHR and correspondingly, data and documents of the PHR can be and correspondingly, data and documents of the PHR can be imported into the hospital’s VMRimported into the hospital’s VMR

This bidirectional communication enables the seamless exchange of This bidirectional communication enables the seamless exchange of medical information between hospitals, patients, and physiciansmedical information between hospitals, patients, and physicians

The LifeSensor PHR is very important to the patient since this is The LifeSensor PHR is very important to the patient since this is his/her own view of their own medical data and documentshis/her own view of their own medical data and documents

Page 48: Interoperability Between Healthcare Applications

ReferencesReferences[1] Key Issues of Technical Interoperability Solutions in eHealth and [1] Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak and the RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak and Eichelberg; pg. 1; Eichelberg; pg. 1; http://www.ehealthnews.eu/images/stories/pdf/ride.pdfhttp://www.ehealthnews.eu/images/stories/pdf/ride.pdf

[2] Towards Interoperable Healthcare Information Systems: The [2] Towards Interoperable Healthcare Information Systems: The HL7 Conformance Profile Approach; Snelick, Rontey, Gebase, HL7 Conformance Profile Approach; Snelick, Rontey, Gebase, Carnahan; p. 2;Carnahan; p. 2;http://www.itl.nist.gov/div897/ctg/messagemaker/papers/IESA2007.rhttp://www.itl.nist.gov/div897/ctg/messagemaker/papers/IESA2007.rsnelick.pdfsnelick.pdf

[3] Key Issues of Technical Interoperability Solutions in eHealth and [3] Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak and the RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak and Eichelberg; pg. 2; Eichelberg; pg. 2; http://www.ehealthnews.eu/images/stories/pdf/ride.pdf http://www.ehealthnews.eu/images/stories/pdf/ride.pdf

Page 49: Interoperability Between Healthcare Applications

References References continued…continued…[4] Web Services Enablement for Healthcare HL7 Applications – Web [4] Web Services Enablement for Healthcare HL7 Applications – Web Services Basic Profile Reference Implementation; Mauro Regio, Microsoft Services Basic Profile Reference Implementation; Mauro Regio, Microsoft Corporation;Corporation;http://msdn.microsoft.com/en-us/library/ms954603.aspx http://msdn.microsoft.com/en-us/library/ms954603.aspx

[5] Aims of the openEHR Architecture[5] Aims of the openEHR Architecturehttp://www.openehr.org/releases/1.0.1/html/architecture/overview/http://www.openehr.org/releases/1.0.1/html/architecture/overview/

Output/aims.htmlOutput/aims.html [6] HL7 Clinical Document Architecture, Release 2.0[6] HL7 Clinical Document Architecture, Release 2.0http://xml.coverpages.org/CDA-Release2-Unofficial.htmlhttp://xml.coverpages.org/CDA-Release2-Unofficial.html

[7] Electronic Business using eXtensible Markup Language[7] Electronic Business using eXtensible Markup Languagehttp://en.wikipedia.org/wiki/EbXMLhttp://en.wikipedia.org/wiki/EbXML

[8] WS/PIDS: Standard Interoperable PIDS in Web Services [8] WS/PIDS: Standard Interoperable PIDS in Web Services Environments; Vasilescu, Dorobantu, Govoni, Padh, Ki MunEnvironments; Vasilescu, Dorobantu, Govoni, Padh, Ki Munhttp://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04358877http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04358877

Page 50: Interoperability Between Healthcare Applications

References References continued…continued…[9] SNOMED CT[9] SNOMED CThttp://en.wikipedia.org/wiki/SNOMED_CThttp://en.wikipedia.org/wiki/SNOMED_CT

[10] LOINC[10] LOINChttp://en.wikipedia.org/wiki/LOINChttp://en.wikipedia.org/wiki/LOINC

[11] Key Issues of Technical Interoperability Solutions in eHealth (IST-[11] Key Issues of Technical Interoperability Solutions in eHealth (IST-027065 RIDE Project); Dogac027065 RIDE Project); Dogachttp://www.ehealthconference2006.org/pdf/DOGAC.pdfhttp://www.ehealthconference2006.org/pdf/DOGAC.pdf

[12] ICW Developer Network – PXS Technical Whitepaper (must be a [12] ICW Developer Network – PXS Technical Whitepaper (must be a registered member of the ICW Developer Network to view the documents)registered member of the ICW Developer Network to view the documents)http://idn.icw-global.com/fileadmin/downloads/PRG/TechnicalWhitepaper_http://idn.icw-global.com/fileadmin/downloads/PRG/TechnicalWhitepaper_en_US_PRG_PXS__2.0_DE_en_US_2.0.pdfen_US_PRG_PXS__2.0_DE_en_US_2.0.pdf

[13] ICW Developer Network – New to ICW Professional Exchange Server[13] ICW Developer Network – New to ICW Professional Exchange Serverhttp://idn.icw-global.com/solutions/icw-professional-suite/professional-http://idn.icw-global.com/solutions/icw-professional-suite/professional-exchange-server/new-to-pxs.htmlexchange-server/new-to-pxs.html

Page 51: Interoperability Between Healthcare Applications

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