Interoperability between heterogeneous healthcare information systems by John Gillson


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Interoperability between heterogeneous healthcare information systems by John Gillson

  1. 1. Interoperability betweenHeterogeneous Healthcare Information Systems John Gillson ICW Labs
  2. 2. InteroperabilityWhat is interoperability in the healthcare informatics domain?”Interoperability is the ability of heterogeneous healthcare informationsystems and software applications to communicate, to exchange dataaccurately, effectively, and consistently, and to use the informationthat has been exchanged” Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project;Dogac, Namli,Okcan, Laleci, Kabak and Eichelberg; pg. 1;
  3. 3. A Lack of InteroperabilityThere is currently a major challenge for the healthcare industry inachieving interoperability among applications provided by differentvendorsEach hospital department or medical clinic may use multipleapplications to share clinical and administrative information amongapplicationsThese applications could be legacy applications or state-of-the-artapplicationsUnfortunately, each application may support multiple communicationsinterfaces that must be continually modified and maintainedAchieving interoperability among heterogeneous healthcareinformation systems is very important because it will reduce costsassociated with healthcare and will contribute to more effective andefficient patient treatment, management, and care
  4. 4. Message Interoperability - Health Level Seven (HL7)HL7 version 2.x (HL7 v2.x) application protocol for electronic data exchange isthe industry standard for transporting clinical and administrative informationbetween heterogeneous healthcare applicationsThe standard is based on the concept of application-to-application messageexchangeHL7 version 3 (HL7 v3), like HL7 v2.x, is a standard for exchanging messagesamong information systems that implement healthcare applicationsAs a main difference to HL7 v2.x, HL7 v3 adopts an Object Oriented (OO)approach using Unified Modeling Language (UML) principles which is basedon a data model called the Reference Information Model (RIM)HL7 messages are XML documents that can be validated against XMLschemas derived from the conceptual modelsUnfortunately as it stands right now, there is an interoperability problembetween HL7 v2.x and HL7 v3 messages because there is no well-definedmapping between these messages
  5. 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. 6. Message Interoperability - RIM continued…Within the RIM, all HL7 messages are embedded into a TransmissionWrapperThe Transmission Wrapper is there in order to identify and transfer themessageSender applications use the Control Act Wrapper to communicate receivinginformation about the event that triggered the exchanged messageThe Control Act Wrapper is there to decide what to do with the message, andis part of the message semanticsTransmission Wrappers and Control Act Wrappers are used as envelopes forthe Message BodyThe Message Body consists of the data to be used to perform the requestedactionTogether, the Control Act Wrapper and the HL7 Message Body constitute thecomplete semantics of HL7 Messages
  7. 7. Message Interoperability - RIM continued… The RIM is the ultimate source from which all HL7 v3 protocol specification standards draw their information related contentSource: Web Services Enablement for Healthcare HL7 Applications - Regio
  8. 8. HL7 functionalities – Business Logic component SENDER“Create an XML representation of a specific HL7 Message Type that includesBody, Control Wrapper, and Transmission WrapperPass that message to the Web Service Adapter for its transmission to theReceiver Application” [4] RECEIVER“Retrieve the HL7 Message received by the Web Service Adapter, and unfoldthe Transmission Wrapper, Control Wrapper, and Message Body from thereceived XML MessageVerify the HL7 Message satisfies the business rules and constraints for thatInteractionCheck if the Sender Application required an Application Level Acknowledge(HL7 Message Type MCI) and – in that case – send that message” [4]
  9. 9. HL7 functionalities – Business Logic componentSource: Web Services Enablement for Healthcare HL7 Applications - Regio
  10. 10. HL7 functionalities –Web Service Adapter component SENDER“Read the Transmission Wrapper of received HL7 Messages to determine how to reach the ultimaterecipient (for example Receiver Application) on the Web Services Infrastructure, configuring theSOAP Envelope accordinglyBased on HL7 Message Type, application configuration and policies (for example, security) preparea SOAP message, containing the HL7 XML message as a SOAP body part to be sent over the WebServices InfrastructurePass the SOAP Message to the Web service proxy for transmission on the wireGet ready to receive and – optionally – store related Accept or Application Level acknowledgementmessages from the Receiver, whenever requested by the Sender” [4] RECEIVER“Receive the SOAP message from the Web Service stubVerify the received SOAP message satisfies application configuration and policies constraints (forexample, security)Possibly store the received message in a a persistent form of memoryOptionally unfold the HL7 XML message from the SOAP message and check schema compliancefor the received HL7 Message with the expected HL7 Message TypeVerify if any communication (Accept) level acknowledgement needs to be performed, and in thatcase prepare an appropriate message to be sent to the original Message Sender.Pass the HL7 Message to the Receiver Application” [4]
  11. 11. HL7 functionalities – Business Logic componentSource: Web Services Enablement for Healthcare HL7 Applications - Regio
  12. 12. HL7 Patient Referral example Interface Engine Interface Engine HL7-v3 HL7-v3 Patient Referral Patient Referral ^ 12345 ^ Sarah Johnson 11011010 Network12345 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
  13. 13. 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/IP12345 Johnson Sarah Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac
  14. 14. Electronic Healthcare Record (EHR)The EHR of a patient is represented as a digitally stored healthcare informationrecord about an individual’s lifetime with the purpose of supporting continuity of care,education and research, and ensuring confidentiality at all timesA number of standardization efforts are in place to provide the interoperability ofEHRs 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 andmarkup the clinical content for the purpose of patient data exchangeThere is also an industry initiative called Integrating the Healthcare Enterprise (IHE)which specifies the Cross-Enterprise Document Sharing (XDS) integration profile forthis purposeAs previously discussed with HL7 messaging, considerable clinical information abouta patient is passed around through the messages exchanged among healthcareapplicationsSo what are the differences between the patient data contained in an HL7 messagecompared with the patient data contained in an EHR?The differentiation is evident because an EHR is the collection of relevant data aboutan individual’s lifetime usually in a document structure
  15. 15. GEHR/openEHR InitiativeThis approach uses a two-level methodology to model the EHRstructureIn the first level, a generic reference model that is specific to thehealthcare domain is developed and contains only a few classes (e.g.role, act, entity, participation)In the second level, healthcare and application specific concepts suchas blood pressure, cholesterol, blood glucose, lab results, etc. aremodeled as archetypesAn archetype definition basically consists of three parts: descriptivedata, constraint rules, and ontological definitionsDescriptive data types include parameters for containing a uniqueidentifier for the archetype, a machine-readable code describing theclinical concept modeled by the archetypeConstraint rules are the core of the archetype and define restrictions onthe valid structure and content of the EHR recordOntological definitions define the controlled vocabulary or machine-readable codes that can be used in specific instances of the archetype
  16. 16. CEN/TC 251 and ENV/EN 13606 EHRcomA message-based standard for the exchange of electronichealthcare 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. 17. HL7 Clinical Document Architecture (CDA)The HL7 CDA is a document markup standard that specifies thestructure and semantics of “clinical documents” for the purpose ofexchangeA CDA document is a defined and complete information object thatcan include text, images, sounds, and other multimedia contentCDA documents are encoded in XMLCDA is organized into three levels where each level iteratively addsmore structure to clinical documentsLevel One focuses on the content of narrative documents with high-level context such as parties, roles, dates and time, places andstructural organization of headingsLevel Two models the fine-grained observations and instructionswithin each heading through a set of RIM Act classesLevel Three specifies semantics each information entity by a uniquecode which enables machine processing
  18. 18. IHE Cross-Enterprise Document Sharing (XDS)There is also an industry initiative called Integrating the HealthcareEnterprise (IHE) which specified the Cross-Enterprise DocumentSharing (XDS) integration profile for this purposeThe basic idea of IHE XDS is to store healthcare documents in anebXML registry/repository architecture to facilitate their sharingIHE XDS handles healthcare documents in a content neutral way
  19. 19. IHE Retrieve Information for Display (RID)RID provides a simple and rapid read-only access to patient-centricclinical information that is located outside the users currentapplicationSupports access to documents with CDA Level One, PDF and JPGformatsIt is defined as a Web service by providing its WSDL descriptionwith a binding to HTTP GET
  20. 20. Summary of EHR Standards EHRcom HL7 CDA IHE RID IHE XDSEHR A reference CDA is organized into IHE RID profile IHE XDS profile isContent 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 Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac
  21. 21. Summary of EHR Standards EHRcom HL7 CDA IHE RID IHE XDSEHR The Message HL7 CDA does not The network and In IHE XDS, theCommunication package, which define how EHRs transport network andLayer 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. Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac
  22. 22. Master Patient Index (MPI)A component which allows for generating a unique patient ID inheterogeneous patient management systemsDemographic patient data can be connected across hospitalboundaries aiming at the integration of different application systemsServes as the basis for a cross-facility electronic patient recordAutomatically link local data set from various source systems tounique patient identifications – extensive editing optionsCreate and edit data setsIdentify and import data set changes
  23. 23. MPI - Business LogicLocal 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
  24. 24. MPI - New Admission Hospital 1 Master Patient Index (MPI) Recycle Bin le Sarah Johnson yc ID = 1, Hospital 1 ec RNew 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
  25. 25. 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
  26. 26. Virtual Medical Record (VMR)Unified view of medical data from various source systems andpersonal health recordsCentralized availability of medical data and encounters, as well asdocuments and imagesExport medical data, such as diagnoses, procedures, medicationsand lab resultsExtensive search and filter mechanismsUpload documents; call up, fill in and edit formsStandardized interface for integrated source systems – forbidirectional exchange of medical dataWeb-based integration interface – seamless access to the EPRfrom third-part applications
  27. 27. Combining MPI and VMR Virtual Medical Record (VMR) Master Patient Index (MPI)Document 1 Case 1 Jack Smith ID = 47, Hospital 1Document 2 ID = 47, Hospital 1 Jack SmithDocument 3 Case 2 Jack Smith ID = 1, Hospital 2 ID = 1,Document 4 Hospital 2 Case 3Document 5
  28. 28. Healthcare Service Bus (HSB)EMRs must be used and integrated into clinical practices to makedisparate systems interoperable; this is where the HSB comes intothe pictureThe HSB is a healthcare-specific services integration platformbased on the Enterprise Service Bus (ESB); these are sometimesalso referred to as a Medical Service Bus (MSB)The HSB is built on ESB technology, providing extra features andenriched services specific to the healthcare domain; these serviceswill provide rich, complex and high-value communication ingeographically dispersed environments or inter-organizationapplicationsHSB will provide a rich bundle of core platform services to enablerapid development; it will enable applications to easily consumeservices of third party servicesFor example, using the HSB, clinical and billing systems can beintegrated using sophisticated workflows
  29. 29. HSB landscape
  30. 30. Achieving InteroperabilityWith all these technologies we have talked about thus far, howwould an application achieve interoperability among the vastpossibilities of technologies used to facilitate an interoperable,heterogeneous healthcare informatics domain?The answer would most readily be found in an application calledProfessional Exchange Server (PXS) developed byInterComponentWare, Inc. (ICW)
  31. 31. CASE STUDYProfessional 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. 32. PXS – Overview of FunctionalityPXS 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 thesame physical personThrough the VMR, retrieval of medical information on any patient inany hospital that the patient is associated is definitely possibleThe MSB component is included as a plug-in to the local hospital’scommunication server, which processes patient information andforwards this information to the MPI and VMRThe DMA correspondingly provides the patient record with access tothe medical documents stored in the hospital’s primary systemsThe LSA connects the VMR to the patient’s LifeSensor PHR andthus ensures a smooth exchange of information between hospitals,patients and physicians
  33. 33. PXS – General architecture Browser Physician HTTP Hospital PXS Practitioner HL7 HL7 Master Virtual Patient MedicalH1 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
  34. 34. PXS - Hospital Group ConnectivitySource: ICW Developer Network – New to ICW Professional Exchange Server
  35. 35. PXS – Components PXS System Components Master Patient Index (MPI) Virtual Medical Record (VMR) Document Management Adapter (DMA) Medical Service Bus (MSB)
  36. 36. PXS – MPIThe MPI component allows for generating a unique patient ID,called an index patient, in heterogeneous patient managementsystemsDemographic patient data can be connected across hospitalboundaries aiming at the integration of different hospital systemsThe MPI is the basis and foundation for a cross-facility electronicpatient recordFor each patient record in the hospitals’ patient managementsystems, a local copy with the essential information needed forpatient mapping is maintained inside the MPI databaseThese local copies of the patient data are referred to as data setsfrom the MPI perspectiveThese data sets can be mapped on a reference patient record to theaforementioned index patientThese mappings can link data sets of different hospitals with oneindex patient
  37. 37. PXS – MPI continued…Similarity of patient records is calculated using a flexibleprobabilistic model that assignes scored describing the degree ofsimilarityThe MPI used a weighted probabilistic model of estimating theprobability that the patient data sets refer to the same index patientEach probability comparison is given a probability for thesematches, and using mathematical algorithms, a score for a match, anon-match, and a missing value is computedThe scores of the individual comparisons are summarized andnormalized into a range between 0 and 10 means that all relevant attributes are different, 1 means that allrelevant attributes are equalAs we discussed earlier the HL7 v3 messaging, the MPI receivesHL7 v3 messages in order to maintain its internal data structures,e.g., admission, changing of data sets, modification and merge of
  38. 38. PXS – MPI continued…Source: ICW Developer Network – New to ICW Professional Exchange Server
  39. 39. PXS – Components PXS System Components Master Patient Index (MPI) Virtual Medical Record (VMR) Document Management Adapter (DMA) Medical Service Bus (MSB)
  40. 40. PXS – VMRThe VMR component gives access to demographic and medicalpatient data and documents for healthcare professionalsThe VMR provides different views on various medical data such asencounters, diagnoses, observations, and documents of a patientDocument content is either copied into the VMR database oralternatively remains inside the primary systemThe VMR then only maintains corresponding pointers or referencesto these documents within the primary systemsThe functionality of the VMR allows for all medical records from allconnected data sets to be assembled and displayed as a cross-facility patient record
  41. 41. PXS – VMR continued…Source: ICW Developer Network – New to ICW Professional Exchange Server
  42. 42. PXS – Components PXS System Components Master Patient Index (MPI) Virtual Medical Record (VMR) Document Management Adapter (DMA) Medical Service Bus (MSB)
  43. 43. PXS – DMARetrieving and displaying documents is done independently by the DMA.The underlying technology of the DMA encapsulates all technicalinformation and strategies to retrieving a document from its storage andcontrolling issues such as caching, format conversion, etcThe DMA allows patient documents to be accessed in the clinicalinformation systemIn order to be viewed in the VMR, the DMA must request from the primarysystem, the necessary documentsAll common document formats are supported as well as CDA documentsThe capabilities of the DMA are numerous; the DMA has internal cachingfacilities to display documents quickly and is capable of connecting varioushospital primary systems and storage devicesThe functionality extends further by offering connectivity for viewing andediting DICOM images stemming from Ultrasound, MRT or CT devices
  44. 44. PXS - Components PXS System Components Master Patient Index (MPI) Virtual Medical Record (VMR)Document Management Adapter (DMA) Medical Service Bus (MSB)
  45. 45. PXS – MSBThe MSB component, embedded as a plug-in to the hospital’scommunication server, establishes the connection between hospitalinformation systems and the PXS components by setting up constraints forHL7 messagingThe MSB’s main functional task is to translate messages from the hospitalenvironment into HL7 v3 messages, which is used by all components toimport and export patient dataThe translation of HL7 v2.x messages to HL7 v3 messages was illustratedearlier with regards to the interoperability issues between HL7 versionsThe MSB is a very important component for providing these messagetranslation servicesIn addition, the MSB manages the message routing, message buffering andtranslation of messages
  46. 46. PXS – MSB continued…
  47. 47. PXS – LSAThe LSA component allows for seamless integration of a hospital’selectronic patient record with the patient-centric LifeSensor PHRMedical data and documents can be imported into the patient’s PHRand correspondingly, data and documents of the PHR can beimported into the hospital’s VMRThis bidirectional communication enables the seamless exchange ofmedical information between hospitals, patients, and physiciansThe LifeSensor PHR is very important to the patient since this ishis/her own view of their own medical data and documents
  48. 48. References[1] Key Issues of Technical Interoperability Solutions in eHealth andthe RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak andEichelberg; pg. 1;[2] Towards Interoperable Healthcare Information Systems: TheHL7 Conformance Profile Approach; Snelick, Rontey, Gebase,Carnahan; p. 2;[3] Key Issues of Technical Interoperability Solutions in eHealth andthe RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak andEichelberg; pg. 2;
  49. 49. References continued…[4] Web Services Enablement for Healthcare HL7 Applications –Web Services Basic Profile Reference Implementation; MauroRegio, Microsoft Corporation;[5] Aims of the openEHR Architecture[6] HL7 Clinical Document Architecture, Release 2.0[7] Electronic Business using eXtensible Markup Language[8] WS/PIDS: Standard Interoperable PIDS in Web ServicesEnvironments; Vasilescu, Dorobantu, Govoni, Padh, Ki Mun
  50. 50. References continued…[9] SNOMED CT[10] LOINC[11] Key Issues of Technical Interoperability Solutions in eHealth(IST-027065 RIDE Project); Dogac[12] ICW Developer Network – PXS Technical Whitepaper (must bea registered member of the ICW Developer Network to view thedocuments)[13] ICW Developer Network – New to ICW Professional ExchangeServer
  51. 51. References continued…[14] ICW Professional Suite – Professional Exchange Server