190 likes | 347 Views
Outline of the Talk. Prerequisites for EHR Interoperability: A Possible Network and Policy InfrastructureDemonstration of Semantic EHR interoperability between CEN 13606-1 EHRcom StandardHL7 Clinical Document Architecture (CDA)What lies ahead. The Network and Policy Infrastructure. For intero
E N D
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
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
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
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
14. Send Audit Now we have more information about the user
Need to use it in audit trails
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
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
20. Thank you for your attention