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

Post on 23-Dec-2015

213 views 0 download

Tags:

transcript

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

CompanyHospital Drug 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

SanDB= S¢¢¢

SanDB’= 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

Doctor SpecialistElectronic Health Record

Patient Portal

Surrogate

HIPAA Compliance

Nurse

Secretary

Workflow example

Patient

Doctor

Health Answer

Health AnswerHealth Question

Appointment R

equest

Healt

h Q

uest

ion

Health Questio

n

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”

Alice Bob

Charlie’s SSN078-05-1120

Four identifiers of an action:1) Sender2) Receiver3) Person this is about

(subject)4) Type of information

Sender role Subject 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(p1, r1) inrole(p2, r2) inrole(q, r) tt’

() inrole(p1, r1) inrole(p2, r2) inrole(q, r) tt’

is an agent constraint is a temporal condition

Norms assembled into policy formula p1,p2,q:P.m:M.t:T.incontext(p1, c) send(p1, p2, m) contains(m, q, t) { + | + norms+(c) } { | norms(c) }

One technical slide for fun

Organizational process and compliance

ContextualIntegrity

Organizational Objectives

Information Policy

OrganizationalProcess Design

PrivacyChecker(LTL)

UtilityChecker(ATL*)

UtilityEvaluation

ComplianceEvaluation

NormsPurpose

Auditing

Business ProcessExecution

AuditLogs

Run-time Monitor

Privacy PoliciesUtility Goals

AuditAlgs

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 164.502(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 164.514(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 164.502(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 13423 in the same manner that such exceptions apply to section 164.502(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 (164.514(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 CodeFile hitech_13405_b.pl:permitted_by_13405_b(A) :- %is_minimum_necessary(A). is_belief_from_minimum(A), writeln('HITECH rule 13405.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,

-, -

Example164.502 (a) Standard: (1) Permitted uses and disclosures. (ii) For treatment, payment, or health care operations, as permitted by and in compliance with 164.506;

HIPAA TranslationHIPAA Law §164.508.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

Category Exception Requirement

usrc mtyp mpur usrc c

covered entity

psychotherapy note

treatment originator <originator, - >

Permitted_by_R :- cat ∧ ¬ exc ∧ reqForbidden_by_R :- cat ∧ ¬ exc ∧ ¬ reqR_not_applicable :- ¬ cat ∨ exc

HIPAA Translation

HIPAA Law §164.508.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 ∧ reqForbidden_by_R :- cat ∧ ¬ exc ∧ ¬ reqR_not_applicable :- ¬ cat ∨ exc

Category Exception Requirement

usrc mtyp mpur usrc c

+ covered entity psychotherapy note

treatment originator <originator, S>

- covered entity psychotherapy note

treatment originator <originator, S>

X covered entity psychotherapy note

treatment originator

Combining Different Clauses

Permitted_by_R1 :- cat1 ∧ ¬ exc1 ∧ req1

Forbidden_by_R1 :- cat1 ∧ ¬ exc1 ∧ ¬ req1

R1_not_applicable :- ¬ cat1 ∨ exc1

Permitted_by_R2 :- cat2 ∧ ¬ exc2 ∧ req2

Forbidden_by_R2 :- cat2 ∧ ¬ exc2 ∧ ¬ req2

R2_not_applicable :- ¬ cat2 ∨ exc2

Compliant_with_R :- Permitted_by_R1 ∧ Permitted_by_R2 ∧ … ∧ Permitted_by_Rn ∧ ¬ Forbidden_by_R1 ∧ ¬ Forbidden_by_R2 ∧ … ∧ ¬ Forbidden_by_RnRule 1 Rule 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. (cat1 ∧ ¬ exc1) (cat2 ∧ ¬ exc2) =

Overlapping Rules There exist some action such that R1 and R2 both are

applicable.

(cat1 ∧ ¬ exc1) (cat2 ∧ ¬ exc2) Subset Rules

There exist action such that whenever R2 is applicable so is R1. (cat1 ∧ ¬ exc1) (cat2 ∧ ¬ exc2) = cat2 ∧ ¬ exc2

Resolution R1 is applicable when (cat1 ∧ ¬ exc1) ∧ ¬ (cat2 ∧ ¬ exc2)

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?

P1 refines P2 if P1 P2

Requires careful handling of attribute inheritance

Combination becomes logical conjunction Defined in terms of refinement

Medical data in the cloud?

Database

Policy EngineQuery

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

Nurse ICU

OR

DoctorAND

Nurse ICU

SKSK

=

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 EngineQuery

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