Key Issues of Technical Interoperability Solutions in eHealth Asuman Dogac IST-027065 RIDE Project Outline of the Talk… Introduction to the technical issues through a scenario Demonstration of EHR interoperability IHE Profiles CEN 13606 EHR Content Standard A brief Comparison of the EHR standards Current practices in EU Member States What lies ahead… Demo Scenario One sunny day in Malaga, a person in a meeting experiences a heart attack From the nearest hospital an ambulance is called Demo Scenario On the way to the hospital, the paramedic obtains the demographic information of the patient from the patient’s citizen card and sends it to the hospital by using his mobile device This operation is actually calling the Admit Patient Web service of the hospital Demo Scenario The patient, Dr. Ilias Iakovidis has been living in Brussels for a long time He has had cardiovascular problems and had some surgeries and treatment at the Brussels Hospital Therefore, his EHR is in the Brussel Hospital Information system Demo Scenario Luckily, there exists a “Common EU EHR Registry/ Repository” which is used by the hospitals in Spain and in Belgium to store clinical documents of patients Common EU EHR Registry/Repository Brussels Hospital Malaga Hospital Brugge Hospital Barcelona Hospital Demo Scenario The emergency department of Malaga Hospital assigns a new patient identifier, PID = 10000146 The doctor searches their own hospital information system for clinical information about the patient No information about the patient Then the doctor queries the Common EU EHR Registry/Repository Demo Scenario Query: Give me the EHRs of the patient with PID = 10000146 Wrong PID; PID is local to Malaga Hospital and we need the PID in the Common EU Registry/Repository Solution? PID Manager Name: Ilias Iakovidis BirthDate: 22/03/1967 Malaga PID=10000146 10000146 Common Rep = ? Malaga Hospital Before requesting the EHR, find out Athe newPID patient in the is admitted Common repository Ilias Iakovidis 22/03/1967 Brussels Hospital 10001452 Common Rep/Reg Malaga Hospital Common EU EHR Registry/Repository 35000489 Demo Scenario Now the query is using the correct PID Registry returns document references Doctor selects the needed ones and the document is retrieved from the repository PID = 35000489 doc1.xml Give me the document references doc2.xml ... docn.xml Malaga Hospital Common EU EHR Registry/Repository doc2.xml Demo Scenario The other issue considered in the demonstration is authentication and audit trails The repository needs to be sure that Malaga Hospital and Brussels Hospital are authorized to communicate with it Also each hospital must be sure that the actor it communicates with is the real Repository Allowed Nodes Public Keys Lock with private key Common Rep/Reg Mutual Authentication Allowed Nodes The same process is repeated on the other side Malaga Hospital Try to unlock with public key. If it is opened everything is OK Private Keys Public Keys Malaga Hospital Brussels Hospital Common EU EHR Registry/Repository Demo Scenario Furthermore, audit trail is essential It is necessary to allow a security officer in a healthcare institution to audit activities to detect improper creation, access, modification and deletion of Protected Health Information (PHI) In our scenario, we have a common audit repository Each application creates and sends an audit record to this repository after specified events Demo Scenario Both in the node authentication and audit trail, time is very important since it is a common variable used in the system Therefore, all applications should have consistent time (Recording the correct time in audit records, using correct timestamp authentications) In our demonstration, all aplications make their time consistent by asking the time to a common time server UTC+1 What time is it? What time is it? Malaga Hospital 10:13:28 10:12:16 UTC+1 Brusells Hospital 09:13:28 10:13:28 10:14:48 Demo: Technologies Used NIST IHE XDS Registry Repository (common registry/repository) was available as public domain software from National Institute of Standards and Technology (NIST) from USA On top of this, we have implemented the following profiles (will be available as public domain software): - IHE PIX Manager (for patient ID manager) - IHE ATNA Profile (for node authentication TLS and audit trails) - IHE Consistent Time profile (SNTP) We have used: Care2x HIS (a public domain Hospital Information System) The document content standard is CEN 13606-2000 The Technical Issues Needed to be Addressed Communication Protocols: Most Commonly used is Internet Protocol (IP) Although IP seems to be common between health applications, various application protocols exists in the protocol stack of IP The communication chanels can be: Hospital A Hospital B HTTP SMTP FTP The Technical Issues Needed to be Addressed Message Interoperability: To be able to exchange information among heterogeneous healthcare information systems, messaging interfaces (also called interface engines) are used Currently, the Health Level 7 (HL7) Version 2 Messaging Standard is the most widely implemented message interface standard in the healthcare domain Another one is HL7 v3 standard and there is no well defined mapping between them Proprietary messages are also used in the healthcare domain Message Interoperability Interface Engine Interface Engine HL7-I12 HL7-I12 Patient Referral Patient Referral ^ 12345 Ilias^ Iakovidis 11011010 Network 12345 Iakovidis Ilias Application 1: HIS Database and back end applications Application 2: HIS Database and back end applications Messaging Standards Various Messaging Standards exists on current communication protocols; SOAP, ebXML messaging, EDI The communicating applications on both sides should support the same messaging standard Extracting the message payload Handling the Headers SOAP ebXML Messaging Communicating through Web Services HL7- I12 <patient> <id> <name> HL7I12 Referral Patient </id> <patient> Web Service <id> 12345 </id> <name> Ilias </name> <surname> </name> <surname> Iakovidis </surname> 11011010 </patient> </surname> </patient> HTTP over TCP/IP 12345 Ilias Iakovidis EHR Content Interoperability There are several standards development efforts such as; Health Level 7 (HL7) Clinical Document Architecture (CDA) CEN EN 13606 EHRcom openEHR These standards aim to structure and markup the clinical content for the purpose of exchange 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, lab results etc. are modeled as archetypes, that is, constraint rules that specialize the generic data structures that can be implemented using the reference model EN 13606-2 will be based on Archetypes CEN/TC 251 and ENV/EN 13606 EHRcom A message-based standard for the exchange of electronic healthcare records. It consists of five parts: The Reference Model, Archetype Interchange Specification, Reference Archetypes and Term Lists, Security Features, and Exchange Models (communication protocol). HL7 Clinical Document Architecture (CDA) CDA is organized into three levels where each level iteratively adds more structure to clinical documents Level One focuses on the content of narrative documents with high-level context such as parties, roles, dates and time, places and structural organization of headings Level Two models the fine-grained observations and instructions within each heading through a set of RIM Act classes Level Three specifies semantics each information entity by a unique code which enables machine processing IHE Cross-Enterprise Document Sharing (XDS) There is also an industry initiative called Integrating the Healthcare Enterprise (IHE) which specified the CrossEnterprise Document Sharing (XDS) integration profile for this purpose The basic idea of IHE XDS is to store healthcare documents in an ebXML registry/repository architecture to facilitate their sharing IHE XDS handles healthcare documents in a content neutral way IHE Cross-Enterprise Sharing of Medical Summaries (XDS-MS) XDS-MS is a mechanism to automate sharing of Medical Summaries between care providers. Medical Summary Types: episodic care, collaborative care and permanent care Specifies content as HL7 CDA and Care Record Summary (CRS) IHE Retrieve Information for Display (RID) RID provides a simple and rapid read-only access to patient-centric clinical information that is located outside the user's current application Supports access to documents with CDA Level One, PDF and JPG formats It is defined as a Web service by providing its WSDL description with a binding to HTTP GET Summary of EHR Standards EHR Content EHRcom HL7 CDA IHE RID IHE XDS A reference model and the data structures for EHR content are defined. CDA is organized into Three levels: “Level One“ Focuses on the content of narrative documents; there is no semantics at this level; it is only human readable. Level Two CDA models the fine-grained observations and instructions within each heading through a set of RIM Act classes. A completely structured document where the semantics of each information entity is specified by a unique code will only be possible with “Level Three". IHE RID profile does not specify content; it supports access to existing persistent documents in well-known presentation formats such as CDA 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 standard and CRS CDA implementation guides Summary of EHR Standards EHRcom The Message EHR Communication package, which is under layer development as EN 13606-5, will define how to communicate the EHR extract to a requesting process. HL7 CDA IHE RID IHE XDS HL7 CDA does not define how EHRs can be communicated; the specification states that CDA documents can be transmitted in HL7 messages (in OBX segment) designed to transfer clinical documents. The network and transport protocol is Internet; the messaging protocol is Web services (http GET). In IHE XDS, the network and transport protocol is Internet; the messaging protocol is ebXML messaging (SOAP with attachments) over HTTP or SMTP (email). OTHER ISSUES IN EHR INTEROPERABILITY For EHR interoperability, further technical issues that must also be addressed include: Mapping the patient identifiers among different healthcare applications Authenticating the users across the enterprises Guaranteeing that all the computers involved have consistent time Authenticating Nodes and Obtaining Audit Trail eHealth Interoperability in USA Country Messaging Infrastructure Patient Identification USA Three different identification infrastructures are considered in the NHIN: - Master Patient Identification Repository: Both the record and identification is located on the same regional or national repository - Patient Record pointers: Patient identifiers are located in a national or regional directory and contain pointers to real records - Patient Controlled Identification with Access Cards: Smart Cards and RFID tags Possible technical alternatives for National Health Information Network (NHIN) : - Web Services; - National Central Repository - Regional Repositories - Peer-to-peer network of Regional Registries containing pointers to real patient records - Non-Federated Peer-to-Peer Networks eHealth Interoperability in Canada Country Messaging Infrastructure EHR Interoperability Patient Identification Canada IHE XDS is considered. Patient identification is Handled locally in regions by using Master Patient Indexes (MPI). Canada Health Infoway Project blueprint specifies: An EHR Solution (EHRS): Registry/repository infrastructure to be used for a region (IHE XDS; ebXML registry and Web Services with HL7 v3 messages). Furthermore a peer-to-peer network of EHRS is for seen. For EHR content Hl7 CDA and ASTM CCRs are considered. These identifiers are linked together by using demographics between regions. eHealth Interoperability in Australia Country Messaging Infrastructure Australia Service Oriented Architecture (Web Services ) EHR Interoperability Patient Identification OpenEHR and archetypes Medicare Card HealthConnect event summaries: Medicare smart card pathology tests, diagnostic test is considered for future. results, hospital discharge summaries, chronic illness monitoring, current medications, allergies, immunization information, principal diagnoses eHealth Interoperability in some of the EU member states EU Member State Messaging Infrastructure EHR Interoperability Patient Identification Austria IHE XDS is recommended by EHI (Healthcare Initiative group) ELGA Initiative (Lifelong electronic health record), ONR 112203 for the discharge letter Social Security Number Web Services and SOAP KMEHR-bis (messages for electronic healthcare record) 20 specific XML messages are produced for key medical transactions. Unique national personal identification number is used. Belgium E-Card is used as carrier. La carte d’identite electronique (eID) is planned as a future carrier. National database linking demographics to İdentification number. eHealth Interoperability in some of the EU member states EHR Interoperability EU Member State Messaging Infrastructure Denmark EDI communication BEHR (Basic Structure for Electronic Health Records) Structured, cross-disciplinary, process and problem oriented documentation standard for EHRs. Netherlands HL7 version 3 (HL7v3) with Web Services (SOAP) HL7 CDA Patient Identification Unique national personal identification number. Health insurance cards as carrier. National database linking demographics to identification number. Citizen Service Number. eHealth Interoperability in some of the EU member states EU Member State Messaging Infrastructure EHR Interoperability Patient Identification United Kingdom HL7v3 XML Summary Care Record Messaging Standard located in a central national database named as SPINE. Personal Demographics Services (PDS) providing NHS number. Estonia National ID Code ID Cards (Electronic) National database linking demographics to ID Code. eHealth Interoperability in some of the EU member states EU Member Messaging Infrastructure State EHR Interoperability Patient Identification France Dossier médical Personnel (DMP): EHRcom ebXML messaging (IHE XDS profile is recommended in the request for proposal) Unique National Person Registration number. Smart cards (SesamVitale) Central National database linking demographics to identification number. Germany SOAP, a German protocol OSCI (Online Services Computer Interface), ebXML Messaging Service (ebMS) Electronic Health Card eHealth Interoperability in some of the EU member states EU Member State Messaging Infrastructure Ireland National Healthlink project uses HL7 messages EHR Interoperability Patient Identification PPS person registration number Central National database linking demographics to identification number. Slovenia EDIFACT, HL7 Health Insurance Card Sweden In ePrescription Web Services are used with EDIFACT Messages Unique National Person Identification number. Central National database linking demographics to identification number. What Lies Ahead… The RIDE (http://www.srdc.metu.edu.tr/webpage/projects/ride/) Project is addressing these issues to propose possible alternatives It will prepare a roadmap for the technical interoperability of eHealth systems… Please stay tuned… Thank you very much for your attention Any Questions?