Kaironbriefing041012+editsv2x

burnwholeInternet and Web Development

Feb 5, 2013 (4 years and 5 months ago)

95 views

Consent Management: A Scalable
Nationwide Approach



April 10, 2012

1

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

2

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?



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

3

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.

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

4

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

5

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


6

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

8


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.

9

Kairon Architecture (
Enhanced+AR
)

10

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

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)


12

Kairon Architecture

(Textured must be trusted)

13

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 Maturity

Accepted Practices

Inchoate

Technical Complexity

Low

High

Emergency
Access

Integrate with
State Mandates

Intelligent
Redaction

ID Matching

Elicit Patient
Preferences

Automate
Enforcement

Implemented

Grand
Challenges

Under
Development

Integrate Care
Relationships

Audit

14

Patient Review
& Approve

Query for
research
recruiting

Assign, manage
Consent IDs

Kairon

Architecture (Enhanced)

16

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

19

Example Privacy Preferences

Recipient

Purpose

Allowed

Types

Disallowed
Topics

Primary Care
Provider = Dr. Blass

Treatment

Any

None

Drs. referred

by

Dr. Blass

Treatment

Any

Mental Health
except

m
edications

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

20

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

by

Dr. Blass

Treatment

Allergies,
Medications

Mental Health

Any

Emergency
Care

Any

Mental Health

Any

Research

Not Imagery

PII, Mental
Health

21

Preference Simplification

(through Rule Minimization)

Allow

Direct Care
Providers

X = Primary
Care Provider

Referral from

X to Recipient

Purpose =

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

22

Rewritten Preferences

Blass

Walsh

Nelson

Treatment

Any

(Allergies

or
Medications) and
NOT Mental Health

None

Emergency Care

Any

NOT Mental Health

Research

NOT Imagery, NOT PII and NOT Mental Health

23

<AND>


<OR>


<String
-
is
-
in(‘medication’, Select(datatype))/>


<String
-
is
-
in(‘allergy’, Select(datatype))/>


</OR>


<String
-
is
-
in(‘NOT
-
mental
-
health’, Select(topic)))/>

</AND>

Sample Response

24

Demo

25

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

26

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

Kairon

Benefits 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)

27

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

29

What Do You Trust?
Problem
Definition

30


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
m
eaningful use scale
s

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


31

What Do You Trust?

Goal

32


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?)


I
nterfacing
to many different sources of credentials (we do not
demand that all sources support a standard interface).


V
erifying
claims to have credentials


R
unning
7 x 24 servers


E
valuating
trust


Scalable
in variety as well as number of players, and extensible.


What Do You Trust?

Exploring the Issues

33


Identity Issues


Identifying Assertion Aggregators


Assertion Claims Standards


Mapping Roles to Consents


Scaling

and Federating

What Do You Trust?

Identity Issues Effect The Solution

34


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

35


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

36


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

37


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

38

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
l
ogic
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

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.


39

Source Forge Sites


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


http://
kaironconsents.sourceforge.net
/

40

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



41

Backup


42

Kairon

Sample 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?

43

Single
Consent
Manager

Multiple
Consent
Managers

Multiple
Consent
Managers

Multiple
Consent
Managers

OR

Kairon

Sample Behavior and Design Issues


Validating that
the patient and record
-
holder
user interfaces work
s


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.


44

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


Kairon

Technical 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)



45

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

46

Kairon

Strength 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

47

Kairon

Strength 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

48

Kairon

Recent 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

49