key issues of technical interoperability solutions in ehealth asuman dogac ist-027065 ride project

Key Issues of Technical Key Issues of Technical Interoperability Solutions Interoperability Solutions

in eHealthin eHealth

Asuman DogacAsuman Dogac

IST-027065 RIDE ProjectIST-027065 RIDE Project

Outline of the Talk…Outline of the Talk…

Introduction to the technical issues Introduction to the technical issues through a scenariothrough a scenario

Demonstration of EHR interoperabilityDemonstration of EHR interoperability IHE ProfilesIHE Profiles CEN 13606 EHR Content StandardCEN 13606 EHR Content Standard

A brief Comparison of the EHR standardsA brief Comparison of the EHR standards Current practices in EU Member StatesCurrent practices in EU Member States What lies ahead…What lies ahead…

Demo ScenarioDemo Scenario

OneOne sunny sunny day day in Malaga, a person in a in Malaga, a person in a meetingmeeting experience experiencess a heart attack a heart attack

From the nearest hospital an From the nearest hospital an

ambulance is calledambulance is called

Demo ScenarioDemo Scenario On the way to the hospital, the paramedic On the way to the hospital, the paramedic

obtainsobtains the demographic information of the demographic information of the patient from the patient’sthe patient from the patient’s citizen citizen card card and sendand sends it s it to the hospital by using his to the hospital by using his mobile devicemobile device

This operation is actually calling the This operation is actually calling the AAdmit dmit PPatient atient WWeb serviceeb service of the hospital of the hospital


The patient, Dr. The patient, Dr. Ilias Iakovidis has been living Ilias Iakovidis has been living in Brussels for a long timein Brussels for a long time

He hasHe has had had cardiovascular problems and ha cardiovascular problems and hadd some surgeries and treatment some surgeries and treatment atat the the Brussels Brussels HospitalHospital

ThereforeTherefore, his EHR, his EHR isis in the Brussel Hospital in the Brussel Hospital Information systemInformation system

Demo ScenarioDemo Scenario Luckily, there exists a Luckily, there exists a ““Common EU EHRCommon EU EHR RRegistryegistry//

RRepositoryepository”” which is used by which is used by the the hospitals in Spain and hospitals in Spain and in in Belgium to store clinical documents of patientsBelgium to store clinical documents of patients

Brussels HospitalMalaga Hospital

Barcelona Hospital

Brugge Hospital

Common EU EHR Registry/Repository

Demo ScenarioDemo Scenario The The emergency department of Malaga Hospital emergency department of Malaga Hospital assignsassigns a a new new

patient patient identifier, identifier, PID = 10000146 PID = 10000146 The doctor sThe doctor searches theearches theirir own hospital information system for own hospital information system for

clinical information about the patientclinical information about the patient

NoNo information about the patient information about the patient

Then Then the the doctor doctor queriesqueries the the CCommon ommon EU EHR EU EHR Registry/RRegistry/Repositoryepository

Demo ScenarioDemo Scenario Query: Give me the Query: Give me the EHRs ofEHRs of the patient with PID = the patient with PID =

1000014610000146 Wrong PIDWrong PID; PID; PID is local to Malaga Hospital and is local to Malaga Hospital and we we need need

the PID in the the PID in the Common EU Registry/RCommon EU Registry/Repositoryepository Solution?Solution?

Malaga Hospital


Brussels Hospital

10001452

35000489

Common Rep/Reg

Ilias Iakovidis 22/03/1967

Malaga Hospital

PID Manager

A new patient is admitted

Name: Ilias Iakovidis

BirthDate: 22/03/1967

10000146

Before requesting the EHR, find out

the PID in the Common

repository

Malaga PID=10000146

Common Rep = ?


Now Now thethe query is query is using the correct PIDusing the correct PID Registry returns document referencesRegistry returns document references Doctor selects Doctor selects the needed onesthe needed ones and the document is and the document is

retrieved from the repositoryretrieved from the repository

Malaga Hospital


PID = 35000489

Give me the document references

doc1.xml

doc2.xml

...

docn.xml

doc2.xml

Demo ScenarioDemo Scenario The other issue considered in the demonstration is The other issue considered in the demonstration is

authentication and audit trailsauthentication and audit trails The repository needs to be sure that Malaga Hospital and The repository needs to be sure that Malaga Hospital and

Brussels Hospital are authorized to communicate with itBrussels Hospital are authorized to communicate with it Also each hospital must be sure that the actor it communicates Also each hospital must be sure that the actor it communicates

with is the real Repositorywith is the real Repository

Malaga Hospital Common EU EHR Registry/Repository

Allowed Nodes

Public Keys

Common Rep/Reg

Allowed Nodes

Public Keys

Malaga Hospital

Brussels Hospital

Mutual Authentication

Private Keys

Lock with

private key

Try to unlock with public key. If it is

opened everything is OK

The same process is

repeated on

the other side

Demo ScenarioDemo Scenario Furthermore, audit trail is essentialFurthermore, audit trail is essential It is necessary to allow a security officer in a healthcare institution to It is necessary to allow a security officer in a healthcare institution to

audit activities to detect improper creation, access, modification and audit activities to detect improper creation, access, modification and deletion of Protected Health Information (PHI)deletion of Protected Health Information (PHI)

In our scenario, we have a common audit repositoryIn our scenario, we have a common audit repository Each application creates and sends an audit record to this Each application creates and sends an audit record to this

repository after specified eventsrepository after specified events

Demo ScenarioDemo Scenario Both in the node authentication and audit trail, time is very important Both in the node authentication and audit trail, time is very important

since it is a common variable used in the systemsince it is a common variable used in the system Therefore, all applications should have consistent time (Recording Therefore, all applications should have consistent time (Recording

the correct time in audit records, using correct timestamp the correct time in audit records, using correct timestamp authentications)authentications)

In our demonstration, all aplications make their time consistent by In our demonstration, all aplications make their time consistent by asking the time to a common time serverasking the time to a common time server

Malaga Hospital Brusells Hospital

10:12:16 09:13:28 10:14:48

What time is it?

What time is it?

09:13:2810:13:28 10:13:28

UTC+1 UTC+1

DemoDemo: Technologies Used: Technologies Used NIST IHE XDS Registry Repository (common NIST IHE XDS Registry Repository (common

registry/repository) was available as public domain registry/repository) was available as public domain software from National Institute of Standards and software from National Institute of Standards and Technology (NIST) from USATechnology (NIST) from USA

On top of this, we have implemented the following On top of this, we have implemented the following profiles (will be available as public domain software): profiles (will be available as public domain software):

- IHE PIX Manager (for patient ID manager) - IHE PIX Manager (for patient ID manager) - IHE ATNA Profile (for node authentication TLS and - IHE ATNA Profile (for node authentication TLS and audit trails) audit trails) - IHE Consistent Time profile (SNTP) - IHE Consistent Time profile (SNTP)

We have used: We have used: Care2x HIS (a public domain Hospital Information System) Care2x HIS (a public domain Hospital Information System) The document content standard is CEN 13606-2000The document content standard is CEN 13606-2000

The Technical Issues Needed to be The Technical Issues Needed to be AddressedAddressed

Communication ProtocolsCommunication Protocols: : Most Commonly used is Most Commonly used is Internet Protocol (IP)Internet Protocol (IP) Although IP seems to be common between health applications, Although IP seems to be common between health applications,

various application protocols exists in the protocol stack of IPvarious application protocols exists in the protocol stack of IP

The communication chanels can beThe communication chanels can be::

Hospital A Hospital B

SMTP

FTP

HTTP

The Technical Issues Needed to be The Technical Issues Needed to be AddressedAddressed

Message InteroperabilityMessage Interoperability: : To be able to exchange information among To be able to exchange information among

heterogeneous healthcare information systems, heterogeneous healthcare information systems, messaging interfaces (also called interface engines) messaging interfaces (also called interface engines) are usedare used

Currently, the Health Level 7 (HL7) Version 2 Currently, the Health Level 7 (HL7) Version 2 Messaging Standard is the most widely implemented Messaging Standard is the most widely implemented message interface standard in the healthcare domainmessage interface standard in the healthcare domain

Another one is HL7 v3 standard and there is no well Another one is HL7 v3 standard and there is no well defined mapping between themdefined mapping between them

PProprietaryroprietary messages are also used in the healthcare messages are also used in the healthcare domaindomain

Message InteroperabilityMessage Interoperability

Ilias

Iakovidis

12345

HL7-I12 Patient Referral

Network

11011010

HL7-I12 Patient Referral

12345 IakovidisIlias^ ^

Application 1: HIS Database and back end applications

Application 2: HIS Database and back end applications

Interface Engine Interface Engine

Messaging StandardsMessaging Standards Various Messaging Standards exists on current communication Various Messaging Standards exists on current communication

protocols; SOAP, ebXML messaging, EDIprotocols; SOAP, ebXML messaging, EDI The communicating applications The communicating applications on on bothboth sides sides should support the should support the

same same messaging standard messaging standard Extracting the message payloadExtracting the message payload Handling the HeadersHandling the Headers

SOAP ebXML Messaging

Communicating through Web Communicating through Web ServicesServices

Iakovidis

Ilias

12345

<id> </id><name>

</name>

<surname>

</surname></patient>

<patient>HL7- I12 Patient Referral

Web Service

HTTP over TCP/IP

11011010

<id> </id><name>

</name>

<surname>

</surname></patient>

<patient>

HL7- I12

12345

Iakovidis

Ilias

EHR EHR Content Content InteroperabilityInteroperability

TThere are several standards development here are several standards development efforts such asefforts such as;; Health Level 7 (HL7) Clinical Document Architecture Health Level 7 (HL7) Clinical Document Architecture

(CDA) (CDA) CEN EN 13606 EHRcom CEN EN 13606 EHRcom openEHRopenEHR

These standards aim to structure and markup These standards aim to structure and markup the clinical content for the purpose of exchange the clinical content for the purpose of exchange

GEHR/openEHR InitiativeGEHR/openEHR Initiative This approach uses a two-level methodology to model This approach uses a two-level methodology to model

the EHR structurethe EHR structure

In the first level, a generic reference model that is In the first level, a generic reference model that is specific to the healthcare domain specific to the healthcare domain is developed and is developed and contains only a few classes (e.g. role, act, entity, contains only a few classes (e.g. role, act, entity, participation)participation)

In the second level, healthcare and application specific In the second level, healthcare and application specific concepts such as blood pressure, lab results etc. are concepts such as blood pressure, lab results etc. are modeled as modeled as archetypesarchetypes, that is, constraint rules that , that is, constraint rules that specialize the generic data structures that can be specialize the generic data structures that can be implemented using the reference modelimplemented using the reference model

EN 13606-2 will be based on ArchetypesEN 13606-2 will be based on Archetypes

CEN/TC 251 and ENV/EN 13606 CEN/TC 251 and ENV/EN 13606 EHRcomEHRcom

AA message-based standard for the message-based standard for the exchange of electronic healthcare records.exchange of electronic healthcare records.

It consists of five partsIt consists of five parts:: The Reference Model,The Reference Model, Archetype Interchange Specification,Archetype Interchange Specification, Reference Archetypes and Term Lists,Reference Archetypes and Term Lists, Security Features, andSecurity Features, and Exchange Models (communication protocol).Exchange Models (communication protocol).

HL7 Clinical Document HL7 Clinical Document Architecture (CDA)Architecture (CDA)

CDA is organized into three levels where each level CDA is organized into three levels where each level iteratively adds more iteratively adds more structurestructure to clinical documents to clinical documents

Level OneLevel One focuses on the content of narrative focuses on the content of narrative documents with high-level context such as parties, roles, documents with high-level context such as parties, roles, dates and time, places and structural organization of dates and time, places and structural organization of headingsheadings

Level TwoLevel Two models the fine-grained observations and models the fine-grained observations and instructions within each heading through a set of RIM Act instructions within each heading through a set of RIM Act classes classes

Level ThreeLevel Three specifies semantics specifies semantics each information entity each information entity by a unique code by a unique code which enables which enables machine processingmachine processing

IHE Cross-Enterprise Document IHE Cross-Enterprise Document Sharing (XDS)Sharing (XDS)

There is also an industry initiative called Integrating the There is also an industry initiative called Integrating the Healthcare Enterprise (IHE) which specified the Cross-Healthcare Enterprise (IHE) which specified the Cross-Enterprise Document Sharing (XDS) integration profile Enterprise Document Sharing (XDS) integration profile for this purposefor this purpose

The basic idea of IHE XDS is to store healthcare The basic idea of IHE XDS is to store healthcare documents in an ebXML registry/repository architecture documents in an ebXML registry/repository architecture to facilitate their sharingto facilitate their sharing

IHE XDS handles healthcare documents in a content IHE XDS handles healthcare documents in a content neutral wayneutral way

IHE Cross-Enterprise Sharing of IHE Cross-Enterprise Sharing of Medical Summaries (XDS-MS)Medical Summaries (XDS-MS)

XDS-MS is a mechanism to automate XDS-MS is a mechanism to automate sharing of Medical Summaries between sharing of Medical Summaries between care providerscare providers.. Medical Summary Types: Medical Summary Types: episodic care, episodic care,

collaborative carecollaborative care and permanent care and permanent care SSpecifies contentpecifies content as HL7 CDA and as HL7 CDA and Care Care

Record Summary (CRS)Record Summary (CRS)

IHE Retrieve Information for IHE Retrieve Information for Display (RID)Display (RID)

RIDRID provides a simple and rapid read-only provides a simple and rapid read-only access to patient-centric clinical information that access to patient-centric clinical information that is located outside the user's current applicationis located outside the user's current application

Supports Supports access to access to documents with CDA Level documents with CDA Level One, PDF and JPG formatsOne, PDF and JPG formats

It is It is defined as a Web service by providing its defined as a Web service by providing its WSDL description with a binding to HTTP GETWSDL description with a binding to HTTP GET

Summary of Summary of EHR StandardsEHR Standards

EHRcom HL7 CDA IHE RID IHE XDS

EHRContent

A referencemodel and thedata structuresfor EHRcontent aredefined.

CDA is organized intoThree levels: “Level One“Focuses on the content ofnarrative documents; thereis no semantics at thislevel; it is only humanreadable. Level Two CDAmodels the fine-grainedobservations andinstructions within eachheading through a set ofRIM Act classes. Acompletely structureddocument where thesemantics of eachinformation entity isspecified by a unique code will only be possible with “Level Three".

IHE RID profiledoes not specifycontent; itsupports accessto existingpersistentdocuments inwell-knownpresentationformats such asCDA Level One,PDF and JPEG.

IHE XDS profile is contentneutral; it does notspecify how contentshould be structured andencoded. However IHEcontinues to specifyfurther profiles and onerecent profile IHE XDS MSHL7 specifies medicalsummaries based on HL7CDA standard and CRSCDA implementationguides

Summary of Summary of EHR StandardsEHR Standards

EHRcom HL7 CDA IHE RID IHE XDS

EHRCommunication

layer

The Messagepackage, whichis underdevelopment asEN 13606-5, willdefine how tocommunicatethe EHR extractto a requestingprocess.

HL7 CDA does notdefine how EHRs canbe communicated;the specificationstates that CDAdocuments can betransmitted in HL7messages (in OBXsegment) designedto transfer clinicaldocuments.

The network andtransport protocol isInternet; themessagingprotocol is Webservices (httpGET).

In IHE XDS, the networkand transport protocolis Internet; themessaging protocol isebXML messaging(SOAP with attachments)over HTTP or SMTP(email).

OTHER ISSUES IN EHR OTHER ISSUES IN EHR INTEROPERABILITY INTEROPERABILITY

For EHR interoperability, further technical For EHR interoperability, further technical issues that must also be addressed include:issues that must also be addressed include: Mapping the patient identifiers among different Mapping the patient identifiers among different

healthcare applicationshealthcare applications Authenticating the users across the enterprisesAuthenticating the users across the enterprises Guaranteeing that all the computers involved Guaranteeing that all the computers involved

have consistent timehave consistent time Authenticating Nodes and Obtaining Audit TrailAuthenticating Nodes and Obtaining Audit Trail

eHealth Interoperability in USAeHealth Interoperability in USA

Country MessagingInfrastructure

Patient Identification

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

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 eHealth Interoperability in CanadaCanada

Country Messaging Infrastructure EHR Interoperability Patient Identification

Canada Canada Health Infoway Projectblueprint specifies:

An EHR Solution (EHRS):Registry/repositoryinfrastructure to be used for aregion (IHE XDS; ebXMLregistry and Web Services withHL7 v3 messages).

Furthermore a peer-to-peernetwork of EHRS is for seen.

IHE XDS is considered.

For EHR content Hl7 CDAand ASTM CCRs areconsidered.

Patient identification isHandled locally inregions by using MasterPatient Indexes (MPI).

These identifiers arelinked together by usingdemographics betweenregions.

eHealth Interoperability in eHealth Interoperability in AustraliaAustralia

Country Messaging Infrastructure

EHR Interoperability Patient Identification

Australia Service OrientedArchitecture (Web Services )

OpenEHR and archetypes

HealthConnect event summaries:pathology tests, diagnostic testresults, hospital dischargesummaries, chronic illnessmonitoring, current medications,allergies, immunization information,principal diagnoses

Medicare Card

Medicare smart cardis considered forfuture.

eHealth eHealth Interoperability in some of Interoperability in some of the EU member statesthe EU member states

EU MemberState

MessagingInfrastructure


Austria IHE XDS isrecommended by EHI(Healthcare Initiativegroup)

ELGA Initiative (Lifelongelectronic health record),ONR 112203 for thedischarge letter

Social Security Number

E-Card is used as carrier.

Belgium Web Services andSOAP

KMEHR-bis (messages for electronic healthcare record) 20 specific XML messages are produced for key medical transactions.

Unique national personalidentification number isused.

La carte d’identiteelectronique (eID) isplanned as a future carrier.

National database linkingdemographics toİdentification number.


EU MemberState

MessagingInfrastructure


Denmark EDI communication BEHR (Basic Structurefor Electronic HealthRecords) Structured,cross-disciplinary,process and problemoriented documentationstandard for EHRs.

Unique national personalidentification number.

Health insurance cardsas carrier.

National databaselinking demographics toidentification number.

Netherlands HL7 version 3(HL7v3) with WebServices (SOAP)

HL7 CDA Citizen Service Number.


EU MemberState

Messaging Infrastructure


United Kingdom HL7v3 XMLMessaging Standard

Summary Care Recordlocated in a centralnational databasenamed as SPINE.

Personal DemographicsServices (PDS) providingNHS number.

Estonia National ID Code

ID Cards (Electronic)

National database linkingdemographics to ID Code.


EU MemberState

Messaging Infrastructure EHR Interoperability Patient Identification

France ebXML messaging (IHE XDSprofile is recommended in the request for proposal)

Dossier médicalPersonnel (DMP):EHRcom

Unique National PersonRegistration number.

Smart cards (Sesam-Vitale)

Central National databaselinking demographics toidentification number.

Germany SOAP, a German protocolOSCI (Online ServicesComputer Interface), ebXMLMessaging Service (ebMS)

Electronic Health Card


EU Member State Messaging Infrastructure EHRInteroperability

Patient Identification

Ireland National Healthlink projectuses HL7 messages

PPS person registrationnumber


Slovenia EDIFACT, HL7 Health Insurance Card

Sweden In ePrescription WebServices are used withEDIFACT Messages

Unique National PersonIdentification number.


What Lies Ahead…What Lies Ahead…

The The RIDE RIDE ((http://www.srdc.metu.edu.tr/webpage/projects/ride/http://www.srdc.metu.edu.tr/webpage/projects/ride/)) Project is addressing these issues to Project is addressing these issues to propose possible alternatives propose possible alternatives

It will prepare a roadmap for It will prepare a roadmap for the the technical technical interoperability of eHealth systems…interoperability of eHealth systems…

Please stay tuned… Please stay tuned…

Thank you very much for Thank you very much for your attentionyour attention

Any Questions?Any Questions?

key issues of technical interoperability solutions in ehealth asuman dogac ist-027065 ride project

Documents