From W3C Wiki
Jump to: navigation, search
HCLS Home COI Home TER Home Discussions Post to HCLS listserv

Patient Data Security and Privacy

With the resolution to reform Healthcare and financial incentives from governments at all levels, there is an accelerated pace for the implementation of the national Electronic Medical Records. Highly private and sensitive personal information are being captured in digital format and stored in an increasingly connected network. Furthermore, these medical and personal information could be used in other unforeseeable ways, serving purposes ranging from quality assurance, medical research, to even targeted marketing and commercial exploitation.

Semantic Web technology is making headway to link data and connect people. However, in healthcare domain, this very success puts Privacy at much greater risks. Previously sufficient de-identification technique may be rendered inadequate because it is now possible to re-identify an identity via inferencing on the web.

Both the Clinical Observation Interoperability group "COI" and Terminology group "TERM" were confronted with the challenges of patient consent and privacy while attempting to connect patient data for secondary uses in a web of data and web of semantics.

The definition and sensitivity towards patient pravicy and consent depend on a wide range of factors including care environment, culture, region, political and religious believes, and the use of patient data. The current security model is mainly based on predefined roles and relies on cryptography technology for managing patient consent and ensure confidentiality. It is not able to handle the complexity of patient confidentiality context and its changes. The full stack of semantic web technology from RDF to Trust layer promises much richer expressiveness and verification mechanisms, which seem to be the natural framework to address these challenges.

This wiki space is set up to capture the healthcare privacy scenarios and the semantic web solution for this highly complex problem

Integrating the Health Enterprise (IHE) Patient Privacy Framework

IHE is an open, not for profit organization that promotes and facilitates the adoption of IT standards among healthcare community. IHE Patient Privacy Framework provides a list of scenarios on managing patient data security= in healthcare domain.

Currently, the patient consent is managed as following:

  1. Care Provider Institute create a privacy policy where each policy is given an Object Identifier (OID) that links it to one of the policies defined by IHE's Health Information Exchange white paper .
  2. Patient's acknowledgement of the above policies are captured using HL7 consent structure within a Clinical Document Architecture (CDA) document.
  3. When the document (patient health record) is submitted to Cross Enterprise Document Sharing (XDS) Repository, it is labeled with the Object Identifier (OID) and permissions, restrictions, and obligations. The confidentiality code is captured in the XDS Repository Metadata store.
  4. When the document is consumed, permissions, restrictions, and obligations are enforced based on the attached OIDs.

IHE describes the following list of Privacy Policies for Health Information Exchange (HIE), which healthcare information systems should be able to to define and enforce:

  • Explicit Opt-In (patient elects to have some information shared) is required which enables HIE allowed document use
  • Explicit Opt-Out (patient elects to not have information shared) stops all document use
  • Implicit Opt-In allows for document use
  • Explicit Opt-Out of any document publication
  • Explicit Opt-Out of sharing outside of use in local care events, but does allow emergency override
  • Explicit Opt-Out of sharing outside of use in local care events, but without emergency override
  • Explicit authorization captured that allows specific research project
  • Change the consent policy (change from opt-in to opt-out)
  • Allow direct use of shared documents, but not allowed to re-publish
  • Enable use of document retrieval across communities using IHE Cross-Communitay Access Profile (XCA)
  • Explicit individual policy for opt-in at each episode of care event
  • Explicit policy enabling the use of the data at a specified facility

Following policies might be possible depending on the maturity of the organization and its infrastructure:

  • Allow access only to care providers with a direct treatment relationship
  • Spouse not allowed access (to all or specific document)
  • Parent is not allowed access (to all or specific document)
  • Restrict access to a specified care-setting
  • All accesses to the data will result in a notification of the patient (eg: email or such)
  • All accesses to the data require that a new consent be captured (eg: capture new signature)

Some policies are not considered to be possible by this profile:

  • Patient identifies individuals that have rights to their data
  • Patient identifies individuals that do not have rights to their data
  • Each access of the data must be individually authorized by the patient a document with a mixture of more/less sensitive information thus needing different levels of protection
  • Notification to those that have used a document under consent that is now revoked pulling back copies of documents that have been used under a consent that is now revoked

Use Case: Granting Patient Data Access Based on Proof

At present, access to patient data is granted to a person based on a patient consent and this person's role. Normally the patient consent statement contains very general terms giving permission to all personnel related to the patient care. This role-based access control model can not adequately express the changing of roles (i.e. a doctor in a hospital today can be a parent of a young patient at a different time).

The scenario below illustrates how the access to the patient data can be granted not just based on the password control, but the verification of the "evidence" (policies and facts).

  • Soutth Lake Clinic maintains a generic access policy If X is a doctor of Y, X can delegate access rights to persons in South Lake
  • Dr. Smith has his delegate access policy if P is the head nurse in South Lake, P can access all my patient data
  • Tina requests access to Alan's file and provides evidence Tina :role :HeadNurse, Policy(SLC), Policy(Dr. Smith), Alan, Smith, Alan  :patientOf  :Smith

Access is granted upon the confirmation of the facts and policies.


HCLS Home COI Home TER Home Discussions Post to HCLS listserv