Privacy Challenges and Solutions for Health Information Systems John C Mitchell, Stanford University

Themes  Privacy  Two approaches  Policy-based systems: provide info only if privacy policy allows  Anonymization: perturb publicly released data to preserve privacy  Healthcare provides practical example  Some background information on US healthcare trends  HIPAA regulation (also HITECH, additional hospital policies)  Balance: want good medical care, privacy from insurers  Formalization of privacy policy  Add policy-based reasoning to information systems  Also enables educational tools, other applications  Many unsolved problems  Combine related policies  Integrate individual, aggregate privacy

US Healthcare Crisis Ahead  Aging population  Not enough care facilities  Increasing costs  Cannot afford care if current trends continue  What can we do?  Keep patients out of the hospital  5% of population incurs 30% of total cost, ~10% incurs 60% [NPR]  Help people stay in their homes longer  Information systems  Better bidirectional communication with patients  Better information  better diagnosis, fewer errors  Telemedicine, home monitoring can serve outpatients

Some terminology  Electronic Health Record (EHR)  Hospitals starting to store information electronically  Allow patients to interact with physicians  Personal Health Record (PHR)  Health Information Exchange (HIE)  Regional networking between hospitals, clinics  Telemedicine (Tel)  Remote monitoring, other applications

Privacy in Organizational Processes Patient medical bills Insurance CompanyHospitalDrug Company Patient information Patient Advertising GOAL: Respect privacy expectations in the transfer and use of personal information within and across organizational boundaries

What is privacy?  Contextual integrity  Normative framework for evaluating the flow of information between agents  Agents act in roles within social contexts  Principles of transmission  Confidentiality, reciprocity, dessert, etc  Differential privacy San DB= S ¢¢¢ San DB ’ = S’S’ ¢¢¢ Distrib. distance ≤  Adam Smith

Contextual Integrity  Philosophical account of privacy  Transfer of personal information  Describes what people care about  Flow governed by norms  Agents act in roles in social contexts  Information categorized by type  E.g., personal health information, psychiatric records, …  Rejects public/private dichotomy  Principles of transmission  Confidentiality, reciprocity, dessert, etc [Nissenbaum 2004, BarthDMN ‘06]

Example: accessing patient health info Patient DoctorSpecialist Electronic Health Record Patient Portal Surrogate HIPAA Compliance

Nurse Secretary Workflow example Patient Doctor Health Answer Health Question Appointment Request Health Question Privacy: HIPAA compliance+ Humans + Electronic system Utility: Schedule appointments, obtain health answers

Goals  Express policy precisely  Enterprise privacy policies  Privacy provisions from legislation  Analyze, enforce privacy policies  Does action comply with policy?  Does policy enforce the law?  Support audit  Privacy breach may occur. Find out how it happened

Privacy Model: “Contextual Integrity” AliceBob Charlie’s SSN Four identifiers of an action: 1)Sender 2)Receiver 3)Person this is about (subject) 4)Type of information

Sender roleSubject roleAttribute Transmission principle Gramm-Leach-Bliley Example Recipient role Financial institutions must notify consumers if they share their non-public personal information with non- affiliated companies, but the notification may occur either before or after the information sharing occurs

CI Norms and Policies  Policy consists of norms (+)inrole(p 1, r 1 )  inrole(p 2, r 2 )  inrole(q, r)  t  t’     (  )inrole(p 1, r 1 )  inrole(p 2, r 2 )  inrole(q, r)  t  t’       is an agent constraint   is a temporal condition  Norms assembled into policy formula   p 1,p 2,q:P.  m:M.  t:T.incontext(p 1, c)  send(p 1, p 2, m)  contains(m, q, t)   {  + |  +  norms + (c) }   {   |    norms  (c) } One technical slide for fun

Organizational process and compliance Contextual Integrity Organizational Objectives Information Policy Organizational Process Design Privacy Checker (LTL) Utility Checker (ATL*) Utility Evaluation Compliance Evaluation Norms Purpose

Auditing Business Process Execution Audit Logs Run-time Monitor Privacy Policies Utility Goals Audit Algs Policy Violation + Accountable Agent

HITECT Act and other extensions  Extends HIPAA to business associates  Closes HIPAA loophole  Tracking of information used in Payment, Treatment Operations (PTO)  Regulatory environment evolving  Additional provisions, e.g. minimum necessary information  a covered entity shall be treated as being in compliance … only if … limits such protected health information … to the minimum necessary to accomplish the intended purpose …

HITECH Excerpt… b) Disclosures Required to Be Limited to the Limited Data Set or the Minimum Necessary.— (1) In general.— (A) In general.— Subject to subparagraph (B), a covered entity shall be treated as being in compliance with section (b)(1) of title 45, Code of Federal Regulations, with respect to the use, disclosure, or request of protected health information described in such section, only if the covered entity limits such protected health information, to the extent practicable, to the limited data set (as defined in section (e)(2) of such title) or, if needed by such entity, to the minimum necessary to accomplish the intended purpose of such use, disclosure, or request, respectively. (B) Guidance.— Not later than 18 months after the date of the enactment of this section, the Secretary shall issue guidance on what constitutes "minimum necessary" for purposes of subpart E of part 164 of title 45, Code of Federal Regulation. In issuing such guidance the Secretary shall take into consideration the guidance under section 13424(c) and the information necessary to improve patient outcomes and to detect, prevent, and manage chronic disease. (C) Sunset.— Subparagraph (A) shall not apply on and after the effective date on which the Secretary issues the guidance under subparagraph (B). (2) Determination of minimum necessary.— For purposes of paragraph (1), in the case of the disclosure of protected health information, the covered entity or business associate disclosing such information shall determine what constitutes the minimum necessary to accomplish the intended purpose of such disclosure. (3) Application of exceptions.— The exceptions described in section (b)(2) of title 45, Code of Federal Regulations, shall apply to the requirement under paragraph (1) as of the effective date described in section in the same manner that such exceptions apply to section (b)(1) of such title before such date. (4) Rule of construction.— The in this subsection shall be construed as affecting the use, disclosure, or request of protected health information that has been de-identified. Our Translation… (b) Disclosures Required to be Limited to the Limited Data Set or the Minimum Necessary.— (1) In General.— (A) In General.— a covered entity shall be treated as being in compliance with HIPAA’s use, disclosure, or request of protected health information only if the covered entity limits such protected health information to the limited data set ( (e)(2)) or is the minimum necessary (note1) to accomplish the intended purpose. (B) Guidance.—Within 18 months, the Secretary should decide what is ‘‘minimum necessary’’, taking into guidance under section 13424(c) and the information necessary to improve patient outcomes and to detect, prevent, and manage chronic disease. (C) Sunset.—Listen to (A) until (B) takes effect. Prolog Code File hitech_13405_b.pl: permitted_by_13405_b(A) :- %is_minimum_necessary(A). is_belief_from_minimum(A), writeln('HITECH rule b;'). File basic_message_wrapper.pl: is_belief_from_minimum(A):- msg_from(A, X), has_msg_belief(A, _, minimum_necessary_ to_purpose, X).

What is the logical structure of HIPAA?  Allow action if  There is a clause that explicitly permits it, and  No clause explicitly forbids it  In more detail...  Action:  to, from, about, type, purpose, consents, beliefs   e.g. Dr., lab, patient, PHI, treatment, -, -  Example (a) Standard: (1) Permitted uses and disclosures. (ii) For treatment, payment, or health care operations, as permitted by and in compliance with ;

HIPAA Translation HIPAA Law § a.2 Covered entity must obtain an authorization for any use or disclosure of psychotherapy note, except if it is to be used by the originator of the psychotherapy notes for treatment; Category (cat): When the rule applies  From: covered entity, Type: psychotherapy note Exception (exc): When the rule does not apply  For: treatment, From: originator Requirement(req): The necessary condition for the rule to permit  Consented_by: originator CategoryExceptionRequirement u src m typ m pur u src c covered entitypsychotherapy notetreatmentoriginator Permitted_by_R :- cat ∧ ¬ exc ∧ req Forbidden_by_R :- cat ∧ ¬ exc ∧ ¬ req R_not_applicable :- ¬ cat ∨ exc

HIPAA Translation HIPAA Law § a.2 Covered entity must obtain an authorization for any use or disclosure of psychotherapy note, except if it is to be used by the originator of the psychotherapy notes for treatment; Permitted_by_R :- cat ∧ ¬ exc ∧ req Forbidden_by_R :- cat ∧ ¬ exc ∧ ¬ req R_not_applicable :- ¬ cat ∨ exc CategoryExceptionRequirement u src m typ m pur u src c +covered entitypsychotherapy notetreatmentoriginator -covered entitypsychotherapy notetreatmentoriginator Xcovered entitypsychotherapy notetreatmentoriginator

Combining Different Clauses Permitted_by_R 1 :- cat 1 ∧ ¬ exc 1 ∧ req 1 Forbidden_by_R 1 :- cat 1 ∧ ¬ exc 1 ∧ ¬ req 1 R 1 _not_applicable :- ¬ cat 1 ∨ exc 1 Permitted_by_R 2 :- cat 2 ∧ ¬ exc 2 ∧ req 2 Forbidden_by_R 2 :- cat 2 ∧ ¬ exc 2 ∧ ¬ req 2 R 2 _not_applicable :- ¬ cat 2 ∨ exc 2 Compliant_with_R :- Permitted_by_R 1 ∧ Permitted_by_R 2 ∧ … ∧ Permitted_by_R n ∧ ¬ Forbidden_by_R 1 ∧ ¬ Forbidden_by_R 2 ∧ … ∧ ¬ Forbidden_by_R n Rule 1Rule 2

Conflict Resolution (at translation time)  Conflict  One rule R1 allows an action while the other rule R2 forbids it  Disjoint Rules  There exist no action such that R1 and R2 both are applicable. (cat 1 ∧ ¬ exc 1 )  (cat 2 ∧ ¬ exc 2 ) =   Overlapping Rules  There exist some action such that R1 and R2 both are applicable. (cat 1 ∧ ¬ exc 1 )  (cat 2 ∧ ¬ exc 2 )    Subset Rules  There exist action such that whenever R2 is applicable so is R1. (cat 1 ∧ ¬ exc 1 )  (cat 2 ∧ ¬ exc 2 ) = cat 2 ∧ ¬ exc 2  Resolution  R1 is applicable when (cat 1 ∧ ¬ exc 1 ) ∧ ¬ (cat 2 ∧ ¬ exc 2 )

Logic Structure  Declarative  Allows automatic logical combination of the policies  Non recursive first order logic  HIPAA policy is a set of logic rules with acyclic dependency graph  Structured negation  Uses a subset of stratified negation  No function parameters  decidable in polynomial time  Complete. Terminates with bounded search.

Refinement and Combination  Policy refinement  Basic policy relation  Does hospital policy enforce HIPAA?  P 1 refines P 2 if P 1  P 2  Requires careful handling of attribute inheritance  Combination becomes logical conjunction  Defined in terms of refinement

Medical data in the cloud? Database Policy Engine Query Attribute- based Encryption Attribute- based Decryption Encrypted Medical Data Credentials Data Applications: Affiliated clinics Medical research

Attribute-Based Encryption PK “Doctor” “Neurology” “Nurse” “Phys Therapy” OR Doctor AND NurseICU  OR Doctor AND Nurse ICU SK  = =

Extracting ABE data policy  HIPAA, Hospital policy  Mapping : Action  {allow, deny}  Action:  to, from, about, type, purpose, consents, beliefs   Action characterized by  Attributes of data: from, about, type, consents  Attributes of recipient: to, purpose, beliefs  Data policy  Data with attributes: from, about, type, consents  Has associated access policy {  to, purpose, beliefs  | Policy(  to, from, about, type, purpose, consents, beliefs  ) = Allow}

Remote user Hospital Encrypted medical data in the cloud Database Policy Engine Query Attribute- based Encryption Attribute- based Decryption Encrypted Medical Data Credentials Data Applications: Affiliated clinics Medical research

Ongoing efforts  Hospital policy  Surrogate  Delegate  Education tools  Allow medical staff to pose questions, learn regulations  Theory: is there a canonical example hospital?  Combine with attribute-based encryption  Deductive access control within the enterprise  Cryptographic enforcement when data is exported  Model workflow and evaluate “least disclosure”, etc.  Audit  Medical environment: “break the glass”

Sponsoring Research Projects Looking for students, postdoc

Conclusion  Privacy  Policy-based systems: provide info only if privacy policy allows  Anonymization: perturb publicly released data  Healthcare provides practical test case  Formalization of HIPAA privacy policy  Add policy-based reasoning to information systems  Future work  Extend to hospital policies, other examples  Educational tools, other applications  Theory: is there a canonical example hospital?  Integrate individual, aggregate privacy