Consent Management: A Scalable Nationwide Approach

1. 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 Paper Consents • Single Use • Not Modifiable • Hard to access • No Traceability or Audit Trail • To satisfy HIPAA/ ARRA/ HITECH/ Privacy Act • To build trust & obtain patient and provider acceptance of electronic exchanges • To enable meaningful use 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

6. 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

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

8. KaironUse 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. 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.

10. Kairon Architecture (Enhanced+AR) Request UI Request Submission Evidence System Look up attached consent-ID Policy Reasoner/enforcer Find local patient ID Consent Switchboard Record Holder Server Consent Mgr Create query and filter results optional: add consent predicates) Consent DB PolicyReasoner (1) EHR 1) Pass query to RH, and get consent ID2) Requestrelevant consents(request, consentID)

11. Kairon Prototype Request UI Request Submission Evidence System Look up attached consent-ID Policy Reasoner/enforcer Find local patient ID Consent Switchboard Record Holder Server Consent Mgr Create query and filter results optional: add consent predicates) Consent DB PolicyReasoner (1) EHR 1) Pass query to RH, and get consent ID2) Requestrelevant consents(request, consentID)

13. Kairon Architecture (Textured must be trusted) Request UI Request Submission Evidence System Look up attached consent-ID Policy Reasoner/enforcer Find local patient ID Consent Switchboard Record Holder Server Consent Mgr Create query and filter results optional: add consent predicates) Consent DB PolicyReasoner (1) EHR 1) Pass query to RH, and get consent ID2) Requestrelevant consents(request, consentID)

14. Implementation Landscape Integrate with State Mandates Automate Enforcement Intelligent Redaction High Elicit Patient Preferences Integrate Care Relationships Implemented Technical Complexity Under Development Query for research recruiting Patient Review & Approve Grand Challenges Audit ID Matching Emergency Access Assign, manage Consent IDs Low Accepted Practices Policy Maturity Inchoate

15. Kairon Architecture (Enhanced) Request UI (Ruby) Request Server (Ruby) ID Server (Tomcat) Evidence System (MySQL) Request Manager (TC) Record Holder Server (TC) Consent Server (Tomcat) REST 1) Pass query to RH 2) Retrieve XACML EHR (Vista) Policy Enforcer (Tomcat) CDB (MySQL) Policy Reasoner (Tomcat)

16. Consent Server User Interface

17. Example Privacy Preferences

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

19. Preference Simplification(through Rule Minimization) Dr. Walsh: Purpose = Treatment (Medications or Allergies) and not Mental Health

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

21. Sample Response

22. Demo

23. KaironSemantic 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 agreementneeded 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.

24. 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)

25. 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

26. What Do You Trust? Problem Definition 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 **

27. 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

28. What Do You Trust? Goal 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.

29. What Do You Trust? Exploring the Issues Identity Issues Identifying Assertion Aggregators Assertion Claims Standards Mapping Roles to Consents Scalingand Federating

30. What Do You Trust? Identity Issues Effect The Solution 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.

31. What Do You Trust? Identity Issues: Non Clinicians 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

32. What Do You Trust? Assertion Claims Standards 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

33. What Do You Trust? Adapting the HL7 Security Ontology Meta Model 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

34. What Do You Trust? HL7 Security Ontology Considerations 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

35. 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.

36. Source Forge Sites • http://sourceforge.net/projects/kaironconsents/ • http://kaironconsents.sourceforge.net/

37. 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

38. Backup

39. 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 Manager OR Multiple Consent Managers Multiple Consent Managers Multiple Consent Managers

40. We have written a white paper to explain the policy issues and considerations encountered in our work. 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.

41. 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)

42. KaironRule 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

43. 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

44. 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

45. 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