key issues of interoperability in ehealth asuman dogac, marco eichelberg, tuncay namli, ozgur kilic,...
TRANSCRIPT
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: [email protected]
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