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. saml:AuthnRequest • 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 Cross User Authentication • 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 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 XACML Request resourceType: General Clinical Information resourceID: ds-76513.xml patient Id: 76513 action: read subject role: General Care provider subject name: John Doe Retrieve patient consent (Ilias Iakovidis, Geneva Hospital) • 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 Policy Decision Point (PDP) The Common EU EHR Registry/Repository

14. Send Audit 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. • 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 Specializes entry Relationship 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. R-MIM Derivation Rules R-MIM Derivation Rules Source Archetype Target Archetype 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