Key Issues of Interoperability in eHealth

Asuman Dogac, Marco Eichelberg, Tuncay Namli, Ozgur Kilic, Gokce B. Laleci

IST-027065 RIDE Project

Outline of the Talk…

Prerequisites for EHR Interoperability: A Possible Network and Policy Infrastructure

Demonstration of Semantic EHR interoperability between CEN 13606-1 EHRcom Standard HL7 Clinical Document Architecture (CDA)

What lies ahead…

The Network and Policy Infrastructure For interoperability, there is a need for a network

and policy infrastructure: Methods to identify and authenticate users; Methods to identify and determine providers of care; Methods to enforce data access authorization policies; Methods to ensure the authenticity of data; Methods to correctly match patients across systems; Methods to share EHRs of patients

A Possible Network Infrastructure (to be demonstrated) Methods to identify and authenticate users: IHE XUA

Profile Methods to identify and determine providers of care: Smart

Cards Methods to enforce data access authorization policies:

XACML, SAML Methods to ensure the authenticity of data: IHE ATNA

Profile Methods to correctly match patients across systems: IHE

PIX Profile Methods to share EHRs: IHE XDS Profile

Demo Scenario Dr. Iakovidis has experienced a heart problem while he is in

Geneva He is admitted to Geneva Hospital Geneva Hospital obtains consents from patients after admission

to the hospital Consent documents are sent to the EU Registry/ Repository After the examinations and the treatment, the patient is

discharged from the hospital with a Discharge Summary Document

Discharge Summary Document is also sent to the Common EU Registry/Repository

After he returned to Brussels his primary physician at Brussels Hospital, Dr. John Doe, wants to access his Discharge Summary

Obtain Patient Consents

The Geneva Hospital provides a Web based service through which the patients fill consent forms

An EU Legislation provides a standard for patient consents (what to ask)

EU has also developed A standard vocabulary for the roles in the

Healthcare Domain A standard for possible types of

information to determine its sensitivity level (confidentialityCode)

Send Consent Common EU Registry/Repository architecture uses XACML

policies For access control and retrieve the patient consents

A patient may give different consents to different care providers

Therefore, the consent sent by the Geneva Hospital is only applicable to documents registered this hospital

Geneva Hospital Common EU EHR

Registry/Repository

XDS Provide and Register Document Set Transaction

pc-76513.xml

authorInstitution: Geneva Hospital

classCode: consent

legalAuthenicator: 76513

Patient Consent for Ilias Iakovidis with PID: 76513

Registering Documents

The policy infrastructure uses Role Based Access Control (RBAC) access control based on information sensitivity level (e.g. My Primary Physician can access my sensitive clinical information)

Therefore, XDS Affinity Domain should use common role and information sensitivity level (confidentialityCode) vocabularies

Geneva Hospital Common EU EHR

Registry/Repository

Discharge Summary of Ilias

Iakovidis

authorInstitution:

Geneva Hospital

classCode:

DISCHARGE SUMMARY

confidentialityCode:

General Clinical Information

ds-76513.xml

What we have now?

Ilias Iakovidis has a Discharge Summary document which is annotated with a confidentiality code “General Clinical Information” in EU the repository

Furthermore, the consent that he gives to the Geneva Hospital is also stored in the EU registry/repository

In this consent, General Care Provider of the patient is allowed to access the records including General Clinical Information if the patient is informed by an email

The consent may also include other restrictions for other roles

Cross User Authentication

Since EU registry/repository may not handle authentication information of all users in Europe, it should trust other entities which can provide this information when requested

These entities are named as Identity Providers which store and provide authentication details (authentication method, credentials, authentication time, etc) of users to their local healthcare enterprise systems

Medical enterprises should communicate with the identity provider that they are related to and provide the information when they authenticate their users to their sytems

Cross User Authentication

Brussels Hospital

The Common EU EHR Registry/Repository

Identity Provider

Give me the document; ds-76513.xml

saml:AuthnRequestDear Requester,

I can give the resource if

- you authenticate yourself to the system with the method Password authentication or better.

- you can send the assertions in 5 minutes.

- the assertions are provided from an identity provider in my trust list

-the user is authorized to read the resource according to policies (consents). In order to decide this I need;

- the functional role of the user on the patient in your enterprise.

Kind Regards,

EU Registry/Repository

saml:Response

Dear ServiceProvider,

Here are the details you requested;

- The user is authenticated at 10:00 am with sessionID = .... from the ip 144.122.230.23

- Session will expire at 11:00 am

- Authn Method was Password Authentication

- Name of the user is John Doe

- The user is General Care Provider of the patient in the Brussels Hospital.

Kind regards,

Identity Provider

ds-76513.xml

Cross User Authentication

SAML Enhanced Client Proxy (ECP) Profile is implemented in the architecture

Common EU Registry/Repository sends AuthnRequest which includes preferences and conditions about the authentication

The AuthnRequest also includes queries for attributes which are needed for access control decision

Access Control with XACML

The Common EU EHR Registry/Repository

Policy Decision

Point (PDP)

Retrieve patient consent (Ilias Iakovidis,

Geneva Hospital)

XACML Request

resourceType: General Clinical Information

resourceID: ds-76513.xml

patient Id: 76513

action: read

subject role: General Care provider

subject name: John Doe

XACML Response

Permit: you can give the resource

However, there is a obligation;

-Send email to patient Ilias Iakovidis that his record “ds-76513” is accessed by his General Care provider John Doe.

- patient’s email: ilias@example.com

XACML has four elements which define the context; Resource, Subject, Action and Environment

PDP first gets the related policy (consent) by using the resource attributes; resourceID, patientID

Then it evaluates the policy according to XACML Request and environment attributes

Send Audit

Now we have more information about the user

Need to use it in audit trails

The Common EU EHR Registry/Repository

The Audit Record Repository

Security Audit and Access Accountability Message

My Dear Diary,

Today at 10:12 am Dr. John Doe who is working at Brussels Hospital requested the document ds-76513.xml.

The document was submitted from Geneva Hospital as Discharge Summary with the confidentiality code General Clinical Information.

I gave the document to Dr. Doe since the consent that patient has given to the Geneva hospital states that “my General Care Provider can access my General Clinical Information in case I am informed by an email”.

Therefore, I also have sent an email to patient Ilias Iakovidis.

Providing Clinical Statement Interoperability Using R-MIMs, Archetypes and Semantic Tools HL7 CDA R-MIM is derived from HL7 RIM CEN has also provided an R-MIM for prEN 13606-1

EHRcom by also deriving it from HL7 RIM It is possible to transform HL7 CDA instances to

EHRcom instances and vice-versa by mapping the properties

The properties can be mapped: By tracing each property back to the original HL7 RIM class And then by comparing how each EHR standard

constraints the original property

An Example

Act-code

ActRelationship

Observation- value

Element-value- code

Component1

Entry- code

EntryRelationship

Observation-code- value

HL7 RIM Classes EHRcom R-MIMClasses

CDA R-MIM Classes

outBoundRelationship

target

component1

elementclinicalStatement

entryRelationship

Derived From

Specializes

Specializes

Derived From

Derived From

Specializes

Derived From

Rules for Deriving R-MIMs from RIM Class B is derived from the Class A of the RIM Class B does not inherit the attribute x of Class A Class B inherits the attribute x of Class A

Cardinality of attribute x is restricted A constraint is defined for value domain of attribute x A constraint is defined for value of attribute x A constraint is defined on the type of attribute x

Class B does not inherit the association y of Class A Class B defines association y1 which is a specialization of

association y of Class A Cardinality of association y1 is restricted A constraint is defined on the range of association y1

R-MIM Derivation Rules and Archetypes R-MIM Derivation Rules can be used to map the

class properties of one EHR into other However, at the R-MIM Level the concepts are too

generic Domain specific concepts are provided through

archetypes, therefore mapping is realized at the archetype level

Reasoning is needed for the mapping process Web Ontology Language Representation of HL7 RIM, CDA

R-MIM, EHRcom R-MIM and source and target archetypes are used

System ArchitectureReference Information

Model

Source R-MIM

TargetR-MIM

R-MIM DerivationRules

R-MIM DerivationRules

Source Archetype

Target Archetype

MappingEngine

Mapping Definitions

Target Instance

Source Instance

TransformationEngine

Thank you for your attention