Transcript 16%20-%20Mitchellx - The Team for Research in Ubiquitous

Automated HIPAA Compliance
Checker
Sharada Sundaram
TATA RESEARCH DEVELOPMENT AND DESIGN,
PUNE, INDIA
Peifung E Lam
STANFORD UNIVERSITY,
CA, USA
John C Mitchell
STANFORD UNIVERSITY,
CA, USA
Background and Motivation
 Hospitals collect a lot of data
Personal Health records, like
Medications, Mental Health
information.
 For efficient health care, this
data should be globally readily
available.
 Technology could make it simple
to collect, search, store and
distribute this data.
Business
Associates
Parents
Relatives
Minors
Patient
Public
Release
Covered
Entity
 Security and Privacy
 Business Process


Secure Transmission and
Storage
Access Control, Right
management
Covered Entity
Health Insurance Portability and Accountability
Act (HIPAA)
 Aim

The standards are meant to improve the efficiency and effectiveness
of the nation's health care system by encouraging the widespread use
of electronic data interchange in the U.S. health care system.
 National Standard


To protect the privacy of Personal Health Information (PHI)
For electronic health care transactions
 Rules of PHI disclosure




type of data
its uses
the end user
the person whose data it is, etc.
Vanderbilt Medical Foundation
 Message Passing Portal



[email protected] web
based centralized repository of
patient’s health records.
Patients and Medical
professionals exchange
information like prescriptions, lab
results, payment
Remote access to personal health
information
 MyHealth and HIPAA



Difficult to tell if online systems
are HIPPA compliant.
The cost of litigation for non
HIPAA compliance is high!
HIPAA is difficult to understand
for software professionals.
Server
Patient
Doctor
Nurse
Vanderbilt Medical Foundation
 Message Passing Portal



[email protected] web
based centralized repository of
patient’s health records.
Patients and Medical
professionals exchange
information like prescriptions, lab
results, payment
Remote access to personal health
information
 MyHealth and HIPAA



Difficult to tell if online systems
are HIPPA compliant.
The cost of litigation for non
HIPAA compliance is high!
HIPAA is difficult to understand
for software professionals.
Privacy Policy
Server
Patient
Doctor
Nurse
Policy Specification
 Standalone
 Not coupled with the Software
 Access Control
 Role based, context based access control
 Auditable
 Understand policy compositionally

Logic Programming and Law
Logic Program
Legal Example
 Rules:
 sibling(X, Y) :parent_child(Z, X),
parent_child(Z, Y).
 parent_child(A, B) :father_child(A, B);
mother_child(A, B).
 Facts:
 mother_child(sonia, rahul).
 mother_child(sonia, priyanka).
 Queries:
 ?- sibling(rahul, priyanka).
Yes
 HIPAA Law
Permitted_by_HIPAA(A):from(A, healthcare_provider),
to(A, healthcare_provider),
for(A, treatment).
 Hospital Specific Information
 Role(nurse, healthcare_provider).
 Role(doctor, healthcare_provider).
 Role(carla, nurse).
 Role(jd, doctor).
 Action of sending the PHI
 Permitted_by_HIPAA(A)?
Formal Model - Action
a = <usrc , udst , uabt , mtyp , mpur , areply , c, b>, where
usrc , udst , uabt ∈ U (the set of users or agents),
mtyp
∈ T (the set of types of messages),
mpur
∈ P (the set of purposes),
areply
∈ A (the set of actions),
c = <uby , cttyp > ∈ C (the tuple of consents) with
uby
∈ U (the set of users) and
cttyp
∈ CT (the set of consent types),
b = <uby , uabt , bf > ∈ B (the tuple of beliefs) with
uby , uabt
∈ U (the set of users) and
bf
∈ BF (the set of beliefs).
What medication to give leukemia kid?
usrc
udst
uabt
mtyp
mpur
areply
c
b
Carla
JD
Kid
PHI
treatment
-
-
-
Covered Entities
Ground Facts
Business Associate
%Roles:
inRole(carla, nurse).
inRole(jd, intern).
Employees
inRole(j, janitor).
%TRANSITIVE CLOSURES:
inRole(intern, doctor).
inRole(doctor, covered_entity).
%RELATION:
employee_of(jd, shh).
parent_of(kid, cox).
business_associate(sgh, shh).
Lawyer
Janitor
Nurse
Intern
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;
 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
Permitted_by_R :- cat ∧ ¬ exc ∧ req
Category
usrc
covered entity
mtyp
psychotherapy note
Exception
mpur
treatment
usrc
originator
Requirement
c
<originator, ->
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 ∧ req
Forbidden_by_R :- cat ∧ ¬ exc ∧ ¬ req
R_not_applicable :- ¬ cat ∨ exc
Category
usrc
Exception
mtyp
mpur
usrc
Requirement
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
Rule 1
Permitted_by_R1 :- cat1 ∧ ¬ exc1 ∧ req1
Forbidden_by_R1 :- cat1 ∧ ¬ exc1 ∧ ¬ req1
R1_not_applicable :- ¬ cat1 ∨ exc1
Rule 2
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_Rn
Combining Different Clauses
HIPAA Law §164.508.a.2
Covered entity must obtain an authorization for any use or disclosure of psychotherapy note,
except if it to be used by the originator of the psychotherapy notes for treatment;
Category
usrc
Exception
mtyp
covered entity
psychotherapy note
mpur
usrc
treatment
originator
Requirement
c
<originator, S>
HIPAA Law §164.502.a.1.v
Standard: A covered entity may not use or disclose protected health information, except as
permitted or required by this subpart or by subpart C of part 160 of this subchapter.
Permitted uses and disclosures. A covered entity is permitted to use or disclose protected
health information as pursuant to an agreement under, or as otherwise permitted by,
§164.510;
Category
usrc
Exception
mtyp
Requirement
R510
covered entity
health records
Permitted_by_R510(a)
covered entity
psychotherapy note
Permitted_by_R510(a)
Conflict Resolution
 Conflict
 One particular rule allows an action while the other forbids it. Given two rules R1
and R2
 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
 Non recursive first order logic

An HIPAA policy is a set of logic rules such that the dependency
graph is acyclic.
 Structured Negation

Uses a subset of stratified negation
 Without Function parameters


Makes it complete
Terminates. Bounded search.
 Declarative Nature

Allows automatic logical combination of the policies.
 Decidable in Polynomial Time

Terminates with correct output.
Restrict Expressability
 Temporal relations
 Current action based on Past
 Save history with the tags. Search and allow.
 Future obligations: Schedule a search through history and
identify the necessary obligations
 No Functions of parameters
 Compliance checker is more predicate reasoning
 Incidentally for all the rules in the law first order logic suffices
 Stratified negation
 Systematic use of negation.
 Sections of the law need to be translated carefully
Online HIPAA policy verification engine
HIPAA Law
§164.502
Standard: Uses and
disclosures of
protected health
information subject
to an agreed upon
restriction. as
otherwise provided
in § 164.522(a).
:['H164.522.pl'].
What medication to give lukemia kid?
Attached are Tom’s blood test results
The latest reports would include a $10 surcharge
Attached are your ex-wife’s test results
Nurse
Please clean the room 42
Tom’s daughter’s medical report
permitted_by_16
4_502_c(A) :-
Doctor
is_from_covered
Entity(A),
is_phi(A),
(permitted_by_1
64_522_a_1(A);
permitted_by_16
4_522_a(A)),
writeln('HIPAA
rule
164_502_c;').
permitted_by_16
4_522_a(A)),
writeln('HIPAA
rule
164_502_c;').
Tom
Janitor
Prototype
HIPAA Advisory
HIPAA Compliance checker
http://crypto.stanford.edu/privacy/HIPAA/messages
Uses of this translation
 Can unauthorized insider get phi?
 Can outsider get phi?
 Change this
 Tests
 Verification of implementation. Runs individual test cases.
 Exhaustive search
 Law cases: Very elaborate to code. Simple ones were satisfied
by HIPAA.
Insider gaining PHI
• § 164.506 Uses and disclosures to carry out treatment, payment, or health
care operations.
– (c) Implementation specifications: Treatment, payment, or health care
operations.
•
(1) A covered entity may use or disclose protected health information for its own
treatment, payment, or health care operations.
PHI
Don’t go in that room as patient has SARS
Nurse
Covered Entity
Outsider gaining PHI
• § 164.502 Uses and disclosures of protected health information: general rules.
–
(a) Standard. A covered entity may not use or disclose protected health information,
except as permitted or required by this subpart or by subpart C of part 160 of this
subchapter.
•
(2) Required
information:
–
disclosures. A covered entity is required to disclose protected health
(ii) When required by the Secretary under subpart C of part 160 of this subchapter to
investigate or determine the covered entity's compliance with this subpart.
Entire database of personal health info
For compliance verification
doctor
Covered Entity
Government Secretary
Insider then Outsider
doctor
Freelance journalist
Covered Entity
In the Past
Present
Conclusions
 Modularity
 With the separation of law and hospital specific facts.
 Executable Law
 A standard HIPAA policy implemented everywhere.
 Verifiable
 Easy to read and understand by Software Engineers, Lawyers, Health
Care professionals.
 Proof of satisfiability
 Returns the rule that satisfies the query result.
 Composeability of different policies?
 OK at the clause level; more work needed on hospital policy + HIPAA
 Auditability
 Interpretation of the query log to obtain the proper insights.
 Anomalies
 Testing of policy reveals corner cases in HIPAA law
Thank You!
Code
Open source Project:
http://code.google.com/p/hipaa
• § 164.502 Uses and disclosure of protected health
information
• § 164.506 Uses and disclosure to carry out treatment,
payment, or health care operations.
Illustration
http://crypto.stanford.edu/privacy/HIPAA
Challenges
•
•
•
•
•
•
Difficult for engineers to interpret law
What do we model?
How much detail should we model?
Is it complete?
Is there a strategy for a patient to get his questions answered?
Is one translation better than other?
•
•
•
•
Laws are not written to be logical!!
HIPAA specifies what to implement not how.
It definitely does not replace the human auditor
Difficult to formalize exactly, its based on interpretation and
requires a lot of iterations of corrections.
Rules Translated
§ 164.502 Uses and disclosure of protected health
information.
§ 164.506 Uses and disclosure to carry out
treatment, payment or health care operations.
• Standard Disclosure
• Minimum Necessary
• De-Identified Information Disclosure
• Disclosure to Business Associates
• Personal representatives
• Whistle blowers
Assumptions
•
•
•
•
•
•
Everything can be represented as messages.
All fields are accurate.
Ideal world with authenticated / authorized identities.
All information is passed through the system.
Its not replacing the HIPAA training but assisting it.
Few parts like the ‘doctor believes in good judgement’ could not be coded.
Formal Results
 Soundness:
 Every provable query is universally valid, i.e., true in all
domains under standard semantics.
 Reports no false positives
 Completeness:
 Every universally valid formula, under standard semantics, is
provable.
 Reports all vulnerabilities
 Effectiveness:
 There is a proof-checking algorithm that can correctly decide
whether a given sequence of symbols is a valid proof or not
Potential Shortcomings in HIPAA
• There are many such outside agents who could gain legitimate access to PHI and
are not regulated by HIPAA after they gain access.
• HIPAA does not regulate information once it leaves their definition of covered
entity.
• DISCLAIMER: All these shortcomings are based on what we looked at. Might be
they are not there at all.
Suggestions
• Cover all agents who hold phi of other people under HIPAA. Treat them as
covered entities.
• During emergency the patient data should be available easily to any person who
can help at that moment.
Surprisingly there is no mention of emergency!
• The system implementation at a hospital should be resilient to id thefts along
with having all the security features in place.