1 / 38

Key Issues of Technical Interoperability Solutions in eHealth

This talk outlines key issues in technical interoperability solutions in eHealth, including EHR interoperability, IHE profiles, EHR standards, current practices in EU Member States, and future developments.

copejames
Download Presentation

Key Issues of Technical Interoperability Solutions in eHealth

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Key Issues of Technical Interoperability Solutions in eHealth Asuman Dogac IST-027065 RIDE Project

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

  3. Demo Scenario • One sunny day in Malaga, a person in a meeting experiences a heart attack • From the nearest hospital an ambulance is called

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

  5. 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 atthe Brussels Hospital • Therefore, his EHRis in the Brussel Hospital Information system

  6. Demo Scenario • Luckily, there exists a “Common EU EHRRegistry/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

  7. Demo Scenario • The emergency department of Malaga Hospital assignsa 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

  8. 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 Ilias Iakovidis 22/03/1967 Name: Ilias Iakovidis BirthDate: 22/03/1967 10000146 Brussels Hospital 10001452 Malaga PID=10000146 Common Rep = ? Common Rep/Reg 35000489 Malaga Hospital Malaga Hospital Before requesting the EHR,find out the PID in the Common repository A new patient is admitted Common EU EHR Registry/Repository

  9. 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 Give me the document references doc1.xml doc2.xml ... docn.xml Malaga Hospital Common EU EHR Registry/Repository doc2.xml

  10. 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 Try to unlock with public key. If it is opened everything is OK Lock with private key Mutual Authentication Allowed Nodes Public Keys Allowed Nodes Public Keys Common Rep/Reg The same process is repeated on the other side Malaga Hospital Brussels Hospital Common EU EHR Registry/Repository Malaga Hospital Private Keys

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

  12. 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 What time is it? UTC+1 What time is it? UTC+1 Malaga Hospital Brusells Hospital 10:13:28 10:12:16 09:13:28 09:13:28 10:13:28 10:14:48

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

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

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

  16. Message Interoperability Interface Engine Interface Engine Transmitting HL7-I12 Patient Referral HL7-I12 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

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

  18. Communicating through Web Services Processing Transmitting Processing HL7- I12 HL7- I12 Patient Referral Web Service <patient> <patient> <id> </id> <id> 12345 </id> <name> <name> Ilias </name> </name> <surname> <surname> Iakovidis 11011010 </surname> </surname> </patient> </patient> HTTP over TCP/IP 12345 Ilias Iakovidis

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

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

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

  22. 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 Threespecifies semantics each information entity by a unique code which enables machine processing

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

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

  25. IHE Retrieve Information for Display (RID) • RIDprovides 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

  26. Summary of EHR Standards

  27. Summary of EHR Standards

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

  29. eHealth Interoperability in USA

  30. eHealth Interoperability in Canada

  31. eHealth Interoperability in Australia

  32. eHealth Interoperability in some of the EU member states

  33. eHealth Interoperability in some of the EU member states

  34. eHealth Interoperability in some of the EU member states

  35. eHealth Interoperability in some of the EU member states

  36. eHealth Interoperability in some of the EU member states

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

  38. Thank you very much for your attention Any Questions?

More Related