The document discusses interoperability between heterogeneous healthcare information systems. It describes standards for achieving interoperability, including HL7 versions 2 and 3 for message exchange, the Reference Information Model (RIM), Clinical Document Architecture (CDA), and Integrating the Healthcare Enterprise (IHE) profiles like Cross-Enterprise Document Sharing (XDS). It also discusses electronic health records (EHRs), master patient indexes (MPIs), virtual medical records (VMRs), and how the Professional Exchange Server (PXS) can bridge gaps between disparate healthcare systems through its various components.

1. Interoperability between Heterogeneous Healthcare Information Systems John Gillson ICW Labs

2. 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

3. 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

4. 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

5. Message Interoperability - 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]

6. Message Interoperability - 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

7. The RIM is the ultimate source from which all HL7 v3 protocol specification standards draw their information related content Message Interoperability - RIM continued… Source: Web Services Enablement for Healthcare HL7 Applications - Regio

8. 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]

9. HL7 functionalities – Business Logic component Source: Web Services Enablement for Healthcare HL7 Applications - Regio

10. HL7 functionalities – 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]

11. HL7 functionalities – Business Logic component Source: Web Services Enablement for Healthcare HL7 Applications - Regio

12. HL7 Patient Referral example Sarah Johnson 12345 HL7-v3 Patient Referral Network Transmitting 11011010 HL7-v3 Patient 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; Dogac

13. Communicating via Web Services Sarah Johnson 12345 <id> </id> <name> </name> <surname> </surname> </patient> <patient> Processing HL7- v3 Patient Referral Web Service Processing HTTP over TCP/IP Transmitting 11011010 <id> </id> <name> </name> <surname> </surname> </patient> <patient> HL7- v3 12345 Johnson Sarah Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac

14. 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

15. 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

16. 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).

17. 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

18. 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

19. 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

20. Summary of EHR Standards Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac 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 IHE RID profile d oes n ot specify content; it s upports access t o existing p ersistent documents in well- k nown presentation formats such as CDA Level One, PDF and JPEG. CDA is organized into Three levels: “Level One“ Focuses on the content of n arrative documents; is only human readable. Level Two CDA models the fine-grained o bservations a nd instructions within each heading through a set of RIM Act classes. A completely structured document where the semantics of each i nformation entity is specified by a unique code will only be possible with “ Level Three&quot;. A reference m odel and the d ata structures for EHR content are d efined . EHR Content IHE XDS IHE RID HL7 CDA EHRcom

21. Summary of EHR Standards Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac In IHE XDS, the network and transport protocol is Internet; the messaging protocol is ebXML messaging (SOAP with attachments) over HTTP or SMTP (email) The network and transport protocol is Internet; the messaging protocol is Web services (http GET). HL7 CDA does not define how EHRs can be communicated; t he specification states that CDA documents can be transmitted in HL7 messages (in OBX segment) designed to transfer clinical documents. The Message package, which i s u nder d evelopment as EN 13606-5, will define how to c ommunicate t he EHR extract to a requesting process. EHR Communication Layer IHE XDS IHE RID HL7 CDA EHRcom

22. 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

23. Master Patient Index (MPI) ‏ Main Patient Data Sarah Johnson ID = 1, H X Sarah Johnson ID = 63, MPI Sarah Johnson ID = 47, GP Y Jack Smith ID = 23, H X Jack Smith ID = 84, MPI Jack Smith ID = 1, GP Y GP Y Local Patient Data Hospital X MPI - Business Logic Sarah Johnson ID = 1 Sarah Johnson ID = 47 Jack Smith ID = 23 Jack Smith ID = 1

24. MPI - New Admission Hospital 1 New admission Master Patient Index (MPI) ‏ New index patient New Sarah Johnson ID = 1, Hospital 1 Sarah Johnson ID = 67, MPI Sarah Johnson ID = 1 Recycle Sarah Johnson ID = 1, Hospital 1 Map Sarah Johnson ID = 1, Hospital 1 Sara Johnston ID = 13, MPI Recycle Bin

25. MPI - Change of Patient Data Set Master Patient Index (MPI) ‏ Keep ? Decide Sarah Johanson ID =1, Hospital 1 Sarah Johnson ID = 67, MPI Sarah Johanson ID = 67, MPI Hospital 1 Changed data set Sarah Johanson ID = 1 Break up New Sarah Johanson ID =1, Hospital 1 Sarah Johnson ID = 67, MPI Sarah Johanson ID = 90, MPI ? Recycle Bin Recycle Sarah Johanson ID =1, Hospital 1 Break up mapping

26. 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

27. Combining MPI and VMR Virtual Medical Record (VMR) ‏ Master Patient Index (MPI) ‏ Jack Smith ID = 1, Hospital 2 ID = 47, Hospital 1 Jack Smith ID = 47, Hospital 1 Jack Smith ID = 1, Hospital 2 Case 1 Document 1 Case 2 Case 3 Document 3 Document 5 Document 4 Document 2

28. 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

29. HSB landscape

30. 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)

31. 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

32. 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

33. PXS – General architecture PXS Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Medical Service Bus (MSB) ‏ Document Management 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

34. PXS - Hospital Group Connectivity Source: ICW Developer Network – New to ICW Professional Exchange Server

35. PXS – Components PXS System Components Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Document Management Adapter (DMA) ‏ Medical Service Bus (MSB) ‏

36. 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

37. 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 patients

38. PXS – MPI continued… Source: ICW Developer Network – New to ICW Professional Exchange Server

39. PXS – Components PXS System Components Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Document Management Adapter (DMA) ‏ Medical Service Bus (MSB) ‏

40. 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

41. PXS – VMR continued… Source: ICW Developer Network – New to ICW Professional Exchange Server

42. PXS – Components PXS System Components Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Document Management Adapter (DMA) ‏ Medical Service Bus (MSB) ‏

43. 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

44. PXS - Components PXS System Components Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Document Management Adapter (DMA) ‏ Medical Service Bus (MSB) ‏

45. 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

46. PXS – MSB continued…

47. 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

48. References [1] 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 [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.rsnelick.pdf [3] Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak and Eichelberg; pg. 2; http://www.ehealthnews.eu/images/stories/pdf/ride.pdf

49. 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/Output/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

50. References continued… [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

51. References continued… [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