Presentation is loading. Please wait.

Presentation is loading. Please wait.

TATA RESEARCH DEVELOPMENT AND DESIGN, PUNE, INDIA Automated HIPAA Compliance Checker STANFORD UNIVERSITY, CA, USA STANFORD UNIVERSITY, CA, USA Sharada.

Similar presentations


Presentation on theme: "TATA RESEARCH DEVELOPMENT AND DESIGN, PUNE, INDIA Automated HIPAA Compliance Checker STANFORD UNIVERSITY, CA, USA STANFORD UNIVERSITY, CA, USA Sharada."— Presentation transcript:

1 TATA RESEARCH DEVELOPMENT AND DESIGN, PUNE, INDIA Automated HIPAA Compliance Checker STANFORD UNIVERSITY, CA, USA STANFORD UNIVERSITY, CA, USA Sharada Sundaram Peifung E LamJohn C Mitchell

2 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. Security and Privacy  Business Process  Secure Transmission and Storage  Access Control, Right management Covered Entity Business Associates Patient Parents Minors Relatives Public Release Covered Entity

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

4 Vanderbilt Medical Foundation NurseDoctor Server Patient Message Passing Portal  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.

5 Vanderbilt Medical Foundation NurseDoctor Server Patient Message Passing Portal  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

6 Policy Specification Standalone  Not coupled with the Software Access Control  Role based, context based access control Auditable  Understand policy compositionally

7 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)? Logic Programming and Law

8 Formal Model - Action u src, u dst, u abt ∈ U (the set of users or agents), m typ ∈ T (the set of types of messages), m pur ∈ P (the set of purposes), a reply ∈ A (the set of actions), a =, where c = ∈ C (the tuple of consents) with u by ∈ U (the set of users) and ct typ ∈ CT (the set of consent types), b = ∈ B (the tuple of beliefs) with u by, u abt ∈ U (the set of users) and bf ∈ BF (the set of beliefs). What medication to give leukemia kid? u src u dst u abt m typ m pur a reply cb CarlaJDKidPHItreatment---

9 Ground Facts %Roles: inRole(carla, nurse). inRole(jd, intern). 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). LawyerJanitorNurseIntern Employees Business Associate Covered Entities

10 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 Permitted_by_R :- cat ∧ ¬ exc ∧ req CategoryExceptionRequirement u src m typ m pur u src c covered entitypsychotherapy notetreatmentoriginator

11 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

12 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

13 Combining Different Clauses HIPAA Law § 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; CategoryExceptionRequirement u src m typ m pur u src c covered entitypsychotherapy notetreatmentoriginator CategoryExceptionRequirement u src m typ R510 covered entityhealth recordsPermitted_by_R510(a) HIPAA Law § 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, § ; covered entitypsychotherapy notePermitted_by_R510(a)

14 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. (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 )

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

16 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

17 Online HIPAA policy verification engine HIPAA Law § Standard: Uses and disclosures of protected health information subject to an agreed upon restriction. as otherwise provided in § (a). Nurse ‏ Doctor Janitor What medication to give lukemia kid? Please clean the room 42 Attached are Tom’s blood test results The latest reports would include a $10 surcharge Tom’s daughter’s medical report Attached are your ex-wife’s test results :- ['H pl']. permitted_by_16 4_502_c(A) :- 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;'). kid Tom Liz Suri TPO Pay TPO Adm TPO Tom

18 Prototype HIPAA AdvisoryHIPAA Compliance checker

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

20 Insider gaining PHI § 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. Covered Entity Nurse PHI Don’t go in that room as patient has SARS

21 Outsider gaining PHI § 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 doctorGovernment Secretary Covered Entity

22 Insider then Outsider doctor Covered Entity Freelance journalist In the PastPresent

23 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

24 Thank You!

25 Open source Project: § Uses and disclosure of protected health information § Uses and disclosure to carry out treatment, payment, or health care operations. Code Illustration

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

27 Rules Translated Standard Disclosure Minimum Necessary De-Identified Information Disclosure Disclosure to Business Associates Personal representatives Whistle blowers § Uses and disclosure of protected health information. § Uses and disclosure to carry out treatment, payment or health care operations.

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

29 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

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

31 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. Suggestions


Download ppt "TATA RESEARCH DEVELOPMENT AND DESIGN, PUNE, INDIA Automated HIPAA Compliance Checker STANFORD UNIVERSITY, CA, USA STANFORD UNIVERSITY, CA, USA Sharada."

Similar presentations


Ads by Google