1 / 19

Key Issues of Interoperability in eHealth

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

yale
Download Presentation

Key Issues of Interoperability in eHealth

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    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

More Related