Automated HIPAA Compliance Checker Sharada Sundaram TATA RESEARCH

  • Slides: 31
Download presentation
Automated HIPAA Compliance Checker Sharada Sundaram TATA RESEARCH DEVELOPMENT AND DESIGN, PUNE, INDIA Peifung

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

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

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 my. Health@Vanderbilt. com web based centralized repository

Vanderbilt Medical Foundation � Message Passing Portal my. Health@Vanderbilt. com 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 Server � My. Health 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. Patient Doctor Nurse

Vanderbilt Medical Foundation � Message Passing Portal my. Health@Vanderbilt. com web based centralized repository

Vanderbilt Medical Foundation � Message Passing Portal my. Health@Vanderbilt. com 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 Privacy Policy Server � My. Health 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. Patient Doctor Nurse

Policy Specification �Standalone Not coupled with the Software �Access Control Role based, context based

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: � HIPAA Law sibling(X,

Logic Programming and Law Logic Program Legal Example � Rules: � HIPAA Law 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 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 ,

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: in. Role(carla, nurse). in. Role(jd, intern). Employees

Covered Entities Ground Facts Business Associate %Roles: in. Role(carla, nurse). in. Role(jd, intern). Employees in. Role(j, janitor). %TRANSITIVE CLOSURES: in. Role(intern, doctor). in. Role(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

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

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 Rule 2 Permitted_by_R 1 : - cat 1 ∧

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

Combining Different Clauses HIPAA Law § 164. 508. a. 2 Covered entity must obtain

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 R 510 covered entity health records Permitted_by_R 510(a) covered entity psychotherapy note Permitted_by_R 510(a)

Conflict Resolution � Conflict One particular rule allows an action while the other forbids

Conflict Resolution � Conflict One particular rule allows an action while the other forbids it. Given two rules R 1 and R 2 � Disjoint Rules There exist no action such that R 1 and R 2 both are applicable. (cat 1 ∧ ⁄exc 1) (cat 2 ∧ ⁄exc 2) = � Overlapping Rules There exist some action such that R 1 and R 2 both are applicable. (cat 1 ∧ ⁄exc 1) (cat 2 ∧ ⁄exc 2) � Subset Rules There exist action such that whenever R 2 is applicable so is R 1. ⁄exc 1) (cat 2 ∧ ⁄exc 2) = cat 2 ∧ ⁄exc 2 � Resolution R 1 is applicable when (cat 1 ∧ ⁄exc 1) ∧ /(cat 2 ∧ ⁄exc 2) (cat 1 ∧

Logic Structure �Non recursive first order logic An HIPAA policy is a set of

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.

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

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). : ['H 164. 522. pl']. TP kid TP O T To m om Attached are Tom’s blood test results O What medication to give lukemia kid? Please clean the room 42 Ad m Tom’s daughter’s medical report TP O Nurse Li z TP O Attached are your ex-wife’s test results Doctor Tom permitted_by_16 4_522_a(A)), writeln('HIPAA rule 164_502_c; '). Su ri Pa y The latest reports would include a $10 surcharge permitted_by_16 4_502_c(A) : is_from_covere d. Entity(A), is_phi(A), (permitted_by_ 164_522_a_1(A); permitted_by_ 164_522_a(A)), writeln('HIPAA rule 164_502_c; '). Janitor

Prototype HIPAA Advisory HIPAA Compliance checker http: //crypto. stanford. edu/privacy/HIPAA/messages

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

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,

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:

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 disclosures. A covered entity is required to disclose protected health information: – (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

Insider then Outsider doctor Freelance journalist Covered Entity In the Past Present

Conclusions � Modularity With the separation of law and hospital specific facts. � Executable

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!

Thank You!

Code Open source Project: http: //code. google. com/p/hipaa • § 164. 502 Uses and

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?

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.

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.

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

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

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

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.