Key Issues of Interoperability in eHealth

1
Key Issues of Interoperability in eHealth

• Asuman Dogac, Marco Eichelberg, Tuncay Namli,
  Ozgur Kilic, Gokce B. Laleci
• IST-027065 RIDE Project

2
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

3
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

4
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

5
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

6
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)

7
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

XDS Provide and Register Document Set Transaction
authorInstitution Geneva Hospital classCode
consent legalAuthenicator 76513
pc-76513.xml
Geneva Hospital
Patient Consent for Ilias Iakovidis with PID
76513
Common EU EHR Registry/Repository
8
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

authorInstitution Geneva Hospital classCode
DISCHARGE SUMMARY confidentialityCode
General Clinical Information
ds-76513.xml
Geneva Hospital
Discharge Summary of Ilias Iakovidis
Common EU EHR Registry/Repository
9
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

10
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

11
Cross User Authentication

• samlAuthnRequest
• Dear 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

• samlResponse
• Dear ServiceProvider,
• Here are the details you requested
• The user is authenticated at 1000 am with
  sessionID .... from the ip 144.122.230.23
• Session will expire at 1100 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

Identity Provider
ds-76513.xml
Give me the document ds-76513.xml
The Common EU EHR Registry/Repository
Brussels Hospital
12
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

13
Access Control with XACML

• 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

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.
• patients email ilias_at_example.com

Policy Decision Point (PDP)
The Common EU EHR Registry/Repository
14
Send Audit
Security Audit and Access Accountability Message
My Dear Diary, Today at 1012 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.

• Now we have more information about the user
• Need to use it in audit trails

The Audit Record Repository
The Common EU EHR Registry/Repository
15
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

16
An Example
Derived From
Derived From
outBoundRelationship
Entry - code
Observation -code - value
Act -code
ActRelationship
component1
entry Relationship
Specializes
target
Component1
Specializes
clinical Statement
Observation - value
element
Specializes
Element -value - code
EntryRelationship
Derived From
Derived From
CDA R-MIM Classes
HL7 RIM Classes
EHRcom R-MIM Classes
17
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

18
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

19
System Architecture
Reference Information Model
Target R-MIM
Source R-MIM
Mapping Engine
Mapping Definitions
Source Instance
Target Instance
Transformation Engine
20
Thank you for your attention