Consent Management: A Scalable Nationwide Approach

April 10, 2012

2

Agenda Introduction Background

– MITRE Research Program– Goals for this project– Consent Management Background– Comparison with S&I Effort

Architecture– Design goals– Operations Concept

Adoption and Transition Plans Integration with What Do You Trust? Discussion Contacts

3

MITRE Research

MITRE Research is a competitive program – Funded by internal dollars– Targeted to specific focus areas, including health care– Advances specific technologies for transition to the public and private

sectors

Two consent-related projects– Kairon– What Do You Trust?

4

Consent Management Background

Better Handling Of Consent Is A Critical Success Factor For The NwHIN

– To satisfy HIPAA/ ARRA/ HITECH/ Privacy Act

– To build trust & obtain patient and provider acceptance of electronic exchanges

– To enable meaningful use

Paper Consents

•Single Use•Not Modifiable•Hard to access•No Traceability or Audit Trail

A better way: establish infrastructure to manage each patient’s consents, nationwide.

5

Ambitions for a consent management system

Comply with special protections in 2012 federal law (42CFR, 38CFR …)– Annotate data appropriately, and make it sticky as data passes– Cope with change

Research and other secondary use cases Patient expresses their own desires

– May restrict release for “treatment”

Generalized (reusable) consents on intuitive categories Defaults and overrides and mix-ins of state rules, provider

rules Create standards for health transactions Enable viable, competing consent products

S&I ??

K?

K?

K?

K?

K

S&I ?K?

Project Summary

Problem Statement: How can complicated policies be written such that they can be implemented across institutions using current enforcement mechanisms?

Key idea: Rulesets can capture the needed rules (long term, late binding of data to policy) and can be incrementally simplified

Followed by: evaluate assertions of request purpose, treatment relationship, and professional qualifications that give someone authority to see patient data– Physicians– Clinicians– Other stakeholders

6

7

Kairon Scope

In-scope– Each patient has a unified

Consent declaration, editable from anywhere

– Nationwide access to consent requests (i.e., any stakeholder can use the service to request access to patient data)

– Generation of human-readable and executable policy statements for record holder, patient, and recipient

– Audit trail of consent requests and the policy sent to record holder policies

– Facilitating expression of state policy mandates

Out of scope– Authentication, authorization

and governance of any parties

– Resolving identities of Patient and record holder

– Partial validation that the record holder followed policy recommendations (depending on machine-processable tags)

– Expressing actual rules of 50 states.

– Encryption management

Kairon Use Cases Created for Initial Research

Create demographic record (profile)

Establish simple preferences Create an alias Express secondary use

preferences Withdraw consent for

research Employer occupational health

data authorization “Break the glass” emergency

access

Authorize ER staff Change consents Consumer reviews audit log Consent system receives a

data permissions request Authorize hospital staff Authorization – simple case Provider creates a profile Consent to release consents

9

10

The following foils originally emphasized what’s in the prototype

My rewrite emphasizes instead what is added to handle Consent. I use color for that, just dash outlines for what we’ve implemented.

Kairon Architecture (Enhanced+AR)

11

Request UI Request Submission

Consent Switchboard

Consent Mgr

Evidence System

Consent DB

Policy Reasoner

(1)

Record Holder Server

EHR

Policy Reasoner/enforcer

1) Pass query to RH, and

get consent ID

2) Request relevant

consents(request,

consentID)

Find local patient ID

Look up attached

consent-ID

Create query and filter results

optional: add consent predicates)

Kairon Prototype

12

Request UI Request Submission

Consent Switchboard

Consent Mgr

Evidence System

Consent DB

Policy Reasoner

(1)

Record Holder Server

EHR

Policy Reasoner/enforcer

1) Pass query to RH, and

get consent ID

2) Request relevant

consents(request,

consentID)

Find local patient ID

Look up attached

consent-ID

Create query and filter results

optional: add consent predicates)

13

Kairon Architecture (Textured must be trusted)

14

Request UI Request Submission

Consent Switchboard

Consent Mgr

Evidence System

Consent DB

Policy Reasoner

(1)

Record Holder Server

EHR

Policy Reasoner/enforcer

1) Pass query to RH, and

get consent ID

2) Request relevant

consents(request,

consentID)

Find local patient ID

Look up attached

consent-ID

Create query and filter results

optional: add consent predicates)

Implementation Landscape

Policy MaturityAccepted Practices Inchoate

Tech

nica

l Com

plex

ityLo

wH

igh

Emergency Access

Integrate with State Mandates

Intelligent Redaction

ID Matching

Elicit Patient Preferences

Automate Enforcement

Implemented

Grand Challenges

Under Development

Integrate Care Relationships

Audit

15

Patient Review & Approve

Query for research recruiting

Assign, manage Consent IDs

Kairon Architecture (Enhanced)

17

Request UI (Ruby)

Request Server (Ruby) ID Server

(Tomcat)

Request Manager (TC)

Consent Server (Tomcat)

Evidence System (MySQL)

CDB (MySQL)

Policy Reasoner (Tomcat)

Record Holder Server (TC)

EHR (Vista)

Policy Enforcer (Tomcat)

REST

1) Pass query to RH

2) Retrieve XACML

Consent Server User Interface

20

Example Privacy Preferences

Recipient Purpose Allowed Types

Disallowed Topics

Primary Care Provider = Dr. Blass

Treatment Any None

Drs. referred byDr. Blass

Treatment Any Mental Health except medications

MDs, Phys. Asst., Nurse Practitioners

Treatment Allergies, Medications

Any except ABC Clinic

Emergency Care

Any Mental Health(best efforts OK)

Any Research Not Imagery PII, Mental Health

21

Example Privacy Preferences(less good rules, easier for next slide)

Recipient Purpose Allowed Types

Disallowed Topics

Primary Care Provider = Dr. Blass

Treatment Any None

Drs. referred byDr. Blass

Treatment Allergies, Medications

Mental Health

Any Emergency Care

Any Mental Health

Any Research Not Imagery PII, Mental Health

22

Preference Simplification(through Rule Minimization)

Allow

Direct Care Providers

X = Primary Care

ProviderReferral

fromX to

RecipientPurpose =Treatment

Allowed Categories

Medications

Allergies¬ Mental Health

Purpose =Treatment

Dr. Blass

Research

Purpose =Research

Anonymized

¬ Imagery

¬ Mental Health

Purpose =Emergency

¬ Mental Health

Dr. Walsh:Purpose = Treatment

(Medications or Allergies) and not Mental Health

23

Rewritten Preferences

Blass Walsh NelsonTreatment Any (Allergies or

Medications) and NOT Mental Health

None

Emergency Care Any NOT Mental Health

Research NOT Imagery, NOT PII and NOT Mental Health

24

<AND> <OR> <String-is-in(‘medication’, Select(datatype))/> <String-is-in(‘allergy’, Select(datatype))/> </OR> <String-is-in(‘NOT-mental-health’, Select(topic)))/></AND>

25

Sample Response

26

Demo

27

Kairon Semantic Heterogeneity

Need strong agreement on:– Who = Patient and recipient (plus requestor)– When

Need basic agreement on:– Purposes (treatment, research, billing, etc.)– Sensitive topics (mental health, sexual health, etc.)– Basic datatypes (labs, diagnoses, notes, images, etc.)

Minimal agreement needed on:– Query formulation (rely on manual intervention, as needed)– Mapping of topics and types to underlying EHR

Standards needed for a core vocabulary, which can be extended by implementers.

28

KaironBenefits of This Architecture

Consent management can be distributed or consolidated nationwide

The consent processor does not need access to EHR data. – The record holder need not see the entire Consent database

Modularity and request-time binding allows rapid response to changing government rules and jurisdiction (patient travels)

The human readable policy to be sent to the record holder can be inspected by:– Patient (at request time, or as part of audit trail)– Requestor (except sensitive consent clauses)– Record holder (to check on machine processing, claimed

credentials and relationships)

30

What Do You Trust? – An Important Enhancement to Kairon

Patient consent alone is not enough How will the record holder know whether the requestor’s

assertions are true– Purpose (e.g., emergency, Parkinson’s research)– Credentials– Treatment relationship

What Do You Trust? Problem Definition31

Before NwHIN, providers knew who was requesting records. They got a (fairly) small number of requests, usually written on letterhead. They knew who they trusted.

As meaningful use scales up and requests are sent electronically, it will be very difficult to assess requestors.

One should not allow just anyone claiming a clinical need-to-know to access records. Their assertions need (trusted) validation

Is the requestor:– Really a clinician?– Really working at clinical institution?– Really in a position where they would need to know this information?– ** Really treating this patient **

What Do You Trust? Scope

Develop a prototype of a scalable clinical information sharing trust ecosystem that enables each player to contribute facts that can be used to make judgments about whether to grant a request for clinical information Obtaining credential facts from multiple sources Supporting reasoning about the credibility of the facts in

determining level of trustworthiness

32

What Do You Trust? Goal

33

Goal: A scalable ecosystem that enables each player to do tasks that they’re good at, and rely on others elsewhere. Some of the tasks to be supported are:– Obtaining clinical authentication assertions (e.g. “Sam Jones is a

physician”)– Obtaining evidence regarding the factual nature of the assertions

(e.g., is Sam a licensed physician? Does he work for a hospital?)– Interfacing to many different sources of credentials (we do not

demand that all sources support a standard interface).– Verifying claims to have credentials– Running 7 x 24 servers– Evaluating trust– Scalable in variety as well as number of players, and extensible.

What Do You Trust? Exploring the Issues

34

Identity Issues Identifying Assertion Aggregators Assertion Claims Standards Mapping Roles to Consents Scaling and Federating

What Do You Trust? Identity Issues Effect The Solution

35

Identity management is not in scope of this project However, the quality of the identities provided effect the

capabilities of the assertion evaluation tool– Should we ask the providers to provide all aliases so we can search

for validating assertions?– Should we acquire a list of eMail addresses? (gmail, provider email

address, etc.)?– Should we link to Kairon and make sure that the attributes claimed in

the assertions map to the role that the provider is currently assuming when making the request? A physician could be moonlighting as a disability fraud investigator, for example. All assertions would check out as a valid physician, but the role assumed would be different.

What Do You Trust? Identity Issues: Non Clinicians

36

How do we handle assertions of need-to-know from non-clinicians?– Insurance company claims adjudicators– Attorneys

Malpractice Disability Workman’s compensation

– Public health authorities– Law enforcement

What Do You Trust? Assertion Claims Standards

37

We believe that current exchange standards are necessary but not sufficient

Some important things have already been addressed, e.g., HL7 has a purpose taxonomy

Will need to propose additional standards to cover additional use cases, additional user types– Attorneys– Payer staff– Multiple roles for given individuals– Multiple sources of assertion

What Do You Trust? Adapting the HL7 Security Ontology Meta Model

38

Investigating use of the HL7 Security Ontology as the underlying model for persisting assertions– Implementation would be done using an RDF triple store (Protégé)– SPARQL will be used to support federated queries about the

assertions– SWRL will be used for reasoning

What Do You Trust? HL7 Security Ontology Considerations

39

Advantages: HL7 security ontology is a RDF/OWL

based standard RDF triple store is well suited to assertion

management – scalability and federation RDF/OWL provides richer semantics

because it supports description logic and capabilities for computational reasoning.

SPARQL is a W3C standard for querying RDF triples. It can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF via middleware.

SWRL rules can increase the expressivity of HL7 Security Ontology via semantic rules. In addition, it increases the interoperability of our solution since it is not bound to specific reasoning software

Risks: 

Must map assertions into HL7 standard structures

HL7 security ontology is not widely adopted yet– We will be pioneers in

using the ontology for this type of project

40

Conclusions

It is possible to develop an approach to consent management that can be implemented nationwide

Policy clarity is needed in order to make progress (the technology is probably able to enforce most options)

Standards are needed to ensure interoperability, especially with terminology

Governance is needed to ensure that stakeholders follow the policies

Supporting services are needed– Such as authentication, patient identification index, provider index.

41

Source Forge Sites

http://sourceforge.net/projects/kaironconsents/ http://kaironconsents.sourceforge.net/

42

Contacts

Arnon Rosenthal, PhD– 781-271-7577 – arnie@mitre.org

Jean Stanford– jstanford@mitre.org– 301-814-4934

Walt Melo, PhD– 703-983-9914 – wmelo@mitre.org

Gail Hamilton– 703-983-7855 – ghamilton@mitre.org

43

Backup

44

KaironSample Policy Issues Revealed By Use Cases

How much competition is desired? Our architecture can be implemented in a single nationwide utility, or with multiple consent management providers. Greater decomposition requires developing more standards.

What degree of certainty is required for enforcement (and should this be controllable by the patient)?

Managing state policy templates will be complex. How will we validate custodial relationships (e.g.,

minor children)? How will we determine if a physician really does

have a valid treatment relationship with a patient?

Single Consent Manage

r

Multiple Consent

Managers

Multiple Consent

ManagersMultiple Consent

Managers

OR

45

KaironSample Behavior and Design Issues

Validating that the patient and record-holder user interfaces works Applying consent policies to release of patient consent information

– The fact that a consent exists for a substance abuse facility reveals sensitive information

Segregating or tagging of data by topic (e.g. substance abuse) can be helpful. However, patients may expect perfect categorization, which technology will never be able to provide.

Enforcing policy with incomplete knowledge cannot yield perfect outcomes.

We have written a white paper to explain the policy issues and considerations encountered in our work.

46

KaironTechnical Issues

Describing the policies for both humans and machine processing Producing user-friendly displays of

– Policy relevant to current request– Minimal additional consents that would meet the current request– Generalizations of a consent clause that would be more reusable (e.g., “anyone in my

PCP’s network” rather than {Smith, Jones}) Prompting requesters to refine their requests without revealing too much about the

allowable policies– (e.g., “There is a policy that would allow you to see everything during the months of

June-July but not CY2010 and not from Betty Ford Clinic unless you are the patient’s psychiatrist”.)

Applying government defaults and mandates & managing state-specific rule sets Managing the audit trail Establishing, if the consent services are distributed, rules for consistency and

cooperation (e.g., patient transfers between them)

Kairon Rule Strengths

Original work assumed all rules had equal strength– Government rules:

Overrode patient preferences (e.g., public health) Or, established defaults (e.g., allow for treatment)

– Patient rules: Specified more granular constraints than government defaults Required conflict resolution when multiple rules applied

New work generalizes government rules to account for varying levels of patient cognitive involvement

47

KaironStrength Tiers

None = default DENY Unaware = patient-signed, based on legalese Aware = patient-selected, based on defaults Regular = patient-specified rules Special = explicit, focused consent required Mandate (government only)

Within a tier: Patient > Government

48

KaironStrength Tier example

Government – Mandate: Release public health summaries Patient – Special: Release Betty Ford info to PCP Government – Special: Deny ADATP info release Patient – Regular: Do not share mental health info Government – Regular: Release for emergency care Patient – Aware: Release violent crime info for treatment Government – Aware: Deny violent crime exchange (MN) Patient – Unaware: Signed HIPAA statement Government – Unaware: Default HIPAA = TPO None: Deny

49

KaironRecent Technical Modifications

Inputs:– Old = Patient ID + Purpose– New = Datatype + Purpose

Outputs:– Old = XACML policy– New = SQL WHERE clause– (Modifies query to conduct bulk load operation)

Purpose hierarchy:– Add new purpose for each study– Add study groupings (e.g., by topic area)– Longer term = Maintain researcher study mapping

50