Transcript Document
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 Malaga Hospital Brussels 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 Common Rep = ?
Malaga Hospital Before requesting the EHR, find out Ilias Iakovidis 22/03/1967
Brussels Hospital 10001452 Common Rep/Reg 35000489 Malaga Hospital
repository Common EU EHR Registry/Repository
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
Malaga Hospital PID = 35000489 Give me the document references doc1.xml
doc2.xml
...
docn.xml
doc2.xml
Common EU EHR Registry/Repository
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
Allowed Nodes
Also each hospital must be sure that the actor it communicates with is the real Repository
Common Rep/Reg Public Keys
Lock with private key Mutual Authentication The same process is repeated on the other side Try to unlock with public key. If it is opened everything is OK
Allowed Nodes Malaga Hospital Brussels Hospital Public Keys
Malaga Hospital Private Keys 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 UTC+1
What time is it?
What time is it?
Malaga Hospital Brusells Hospital
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 HL7-I12 Patient Referral ^ HL7-I12 Patient Referral 12345 Ilias ^ Iakovidis Interface Engine
11011010
12345 Iakovidis Ilias Application 1: HIS Database and back end applications
Network
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
12345 Iakovidis Ilias HL7- I12
12345
Ilias
Iakovidis
HTTP over TCP/IP
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 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
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
EHR Content
Summary of EHR Standards
HL7 CDA IHE RID EHRcom 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 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
EHRcom
Summary of EHR Standards
HL7 CDA IHE RID EHR Communication layer The Message package, which is under development as EN 13606-5, will define how to communicate the EHR extract to a requesting process.
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).
IHE XDS 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 USA
-
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 Patient Identification 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
eHealth Interoperability in Canada
Country Messaging Infrastructure Canada Canada Health Infoway Project blueprint specifies: EHR Interoperability IHE XDS is considered.
An EHR Solution (EHRS): Registry/repository infrastructure to be used for a region (IHE XDS; ebXML registry and Web Services with HL7 v3 messages).
For EHR content Hl7 CDA and ASTM CCRs are considered.
Patient Identification Patient identification is Handled locally in regions by using Master Patient Indexes (MPI). These identifiers are linked together by using demographics between regions.
Furthermore a peer-to-peer network of EHRS is for seen.
eHealth Interoperability in Australia
Country Australia Messaging Infrastructure Service Oriented Architecture (Web Services ) EHR Interoperability OpenEHR and archetypes Patient Identification Medicare Card HealthConnect event summaries: pathology tests summaries , , diagnostic test results, hospital discharge chronic illness monitoring, current medications , allergies , immunization information, principal diagnoses Medicare smart card is considered for future.
eHealth Interoperability in some of
EU Member State Austria Belgium
the EU member states
Messaging Infrastructure EHR Interoperability Patient Identification Social Security Number IHE XDS is recommended by EHI (Healthcare Initiative group) Web Services and SOAP ELGA Initiative (Lifelong electronic health record), ONR 112203 for the discharge letter KMEHR-bis (messages for electronic healthcare record) produced 20 specific XML messages are for key medical transactions.
E-Card is used as carrier.
Unique national personal identification number is used.
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
EU Member State Denmark Netherlands Messaging Infrastructure EHR Interoperability EDI communication BEHR (Basic Structure for Electronic Health Records) Structured, cross-disciplinary, process and problem oriented documentation standard for EHRs.
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 United Kingdom Messaging Infrastructure HL7v3 XML Messaging Standard EHR Interoperability Summary Care Record located in a central national database named as SPINE.
Patient Identification 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
EHR Interoperability Patient Identification EU Member State France Messaging Infrastructure ebXML messaging (IHE XDS profile is recommended in the request for proposal) Dossier médical Personnel (DMP): EHRcom Unique National Person Registration number.
Smart cards (Sesam Vitale) Germany SOAP, a German protocol OSCI (Online Services Computer Interface), ebXML Messaging Service (ebMS) Central National database linking demographics to identification number.
Electronic Health Card
eHealth Interoperability in some of the EU member states
EU Member State Messaging Infrastructure EHR Interoperability Patient Identification Ireland National Healthlink project uses HL7 messages PPS person registration number Slovenia EDIFACT, HL7 Central National database linking demographics to identification number.
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?