1 / 31

Automated HIPAA Compliance Checker

Automated HIPAA Compliance Checker. Tata research development and design, Pune , India. Sharada Sundaram. Peifung E Lam. John C Mitchell. Stanford University, CA, USA. Stanford University, CA, USA. Background and Motivation. Business Associates. Parents. Relatives. Minors.

mariko
Download Presentation

Automated HIPAA Compliance Checker

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Automated HIPAA Compliance Checker Tata research development and design, Pune, India SharadaSundaram Peifung E Lam John C Mitchell Stanford University, CA, USA Stanford University, CA, USA

  2. Background and Motivation Business Associates Parents Relatives Minors Patient Public Release Covered Entity Covered Entity • 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

  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. Patient Doctor Nurse Vanderbilt Medical Foundation Server • Message Passing Portal • myHealth@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 • 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. Patient Doctor Nurse Vanderbilt Medical Foundation Privacy Policy Server • Message Passing Portal • myHealth@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 • 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.

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

  7. 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)?

  8. Formal Model - Action 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), a = <usrc , udst , uabt , mtyp , mpur , areply , c, b>, where 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?

  9. Ground Facts Covered Entities Business Associate %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). Employees Lawyer Janitor Nurse Intern

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

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

  12. Combining Different Clauses Rule 1 Rule 2 • 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

  13. 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; • 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;

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

  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 §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']. permitted_by_164_502_c(A) :- is_from_coveredEntity(A), is_phi(A), (permitted_by_164_522_a_1(A); permitted_by_164_522_a(A)), writeln('HIPAA rule 164_502_c;'). permitted_by_164_522_a(A)), writeln('HIPAA rule 164_502_c;'). kid TPO What medication to give lukemia kid? Doctor TPO Tom Attached are Tom’s blood test results Pay Tom The latest reports would include a $10 surcharge Liz TPO Tom Attached are your ex-wife’s test results Adm Nurse ‏ Please clean the room 42 Suri TPO Tom’s daughter’s medical report Janitor

  18. Prototype http://crypto.stanford.edu/privacy/HIPAA/messages HIPAA Advisory HIPAA 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 • § 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

  21. 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 Government Secretary Covered Entity

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

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

  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 • 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

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

More Related