1 / 22

HIPAA Security and Privacy

HIPAA Security and Privacy. Katharine Chang Ashlesha Joshi EECS 598-2 19 April 2004. HIPAA Overview. HIPAA has a number of goals for improving access to and delivery of health insurance and health care

morley
Download Presentation

HIPAA Security and Privacy

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. HIPAA Security and Privacy Katharine Chang Ashlesha Joshi EECS 598-2 19 April 2004

  2. HIPAA Overview • HIPAA has a number of goals for improving access to and delivery of health insurance and health care • It includes requirements for the security and privacy of protected health information (PHI) • Electronic PHI is of particular concern

  3. A Sampling of HIPAA Security Standards • A covered entity must… • Implement technical policies and procedures for electronic information systems that maintain EPHI to allow access only to those persons or software programs that have been granted access rights • Implement policies and procedures to protect EPHI from improper alteration or destruction • etc.

  4. Motivation • To formalize a relevant subset of HIPAA and investigate whether it can be expressed by existing security models • To consider possible design alternatives for systems that need to comply with HIPAA • To investigate how to automate the auditing process

  5. HIPAA Principles • (Access control) For each patient there must exist an access control list of healthcare professionals who may read the patient's records and create new records. The system shall prevent anyone not on the patient's access control list from accessing the records in any way, subject to the exception of Principle 3. 2. (Patient access) Every patient shall have read only access to his or her own information. 3. (Emergency access) In case of an emergency, any healthcare professional can access any patient's PHI.

  6. HIPAA Principles (cont.) 4. (ACL management) One healthcare professional on each patient's ACL shall be designated the administrator of the ACL. Only this person may modify the ACL. 5. (Authentication) The identity of anyone seeking access to PHI must be verified. 6. (Integrity) Unauthorized modification or deletion of PHI shall be prevented. 7. (Audit control) All accesses to PHI shall be logged with the subject’s name, date, and time. All modifications to each patient's access control list should also be logged.

  7. HIPAA Principles (cont.) 8. (Transmission security) Unauthorized access to PHI being sent over a network shall be prevented. 9. (Enforcement) Computer systems that handle PHI shall have a subsystem that enforces the above principles in an effective way. Its effectiveness shall be subject to evaluation by independent experts.

  8. Relation With Other Models • No clear correspondence with BLP, Biba, or Chinese Wall models • Clark-Wilson model • CDIs (Constrained Data Items) • Medical records and access control lists • TPs (Transformation Procedures) • Requests to read, insert or modify patient information and their access control lists • IVPs (Integrity Verification Procedures) • Verifier model • Certification rule 4 • Audit trail

  9. Prototype Design • We designed a prototype system that allows doctors, nurses, and patients to do read, modify, and insert of patient information and medical records as permitted by HIPAA

  10. Design Overview Server machine Client machine KeyNote library encrypt Client application Server application Encrypted PHI database Audit trail (log) Verifier application (offline)

  11. KeyNote Access control Patient access ACL management Integrity Server Emergency access Authentication ACL management Integrity Encryption between client and server Transmission security Audit Trail (log) Audit control Verifier Enforcement How Design Relates to Principles

  12. Design Decisions • Client and server application – Java • Multithreading • Access to database using JDBC • Platform independent • Three-tier model • Client Server Database • Server maintains control over access and updates • Simplifies the deployment of applications • Performance advantage

  13. KeyNote • Application-specific security policies and credentials are expressed using a general purpose framework • Compliance checker determines whether a given action requested by a given principal complies with security policies

  14. Our Use of KeyNote • Every user has a public/private key pair • Security official • Responsible for entering policies • Policies allow each patient’s administrator doctor full access to the patient’s information • Administrator doctor • May enter credentials (i.e., signed assertions) allowing other doctors/nurses read and write access to his/her patients’ information • Policies and credentials are stored in a database

  15. Example Policy keynote-version: 2 comment: doc1 is the administrator doctor for pat1 authorizer: "POLICY" licensees: "DSA:abcd123456" # doc1's pub key conditions: app_domain == "HIPAA" && patient_id == "pat1" && (requested_act == "READ" || requested_act == "MODIFY") && (data == "patients_info" || data == "access_control") -> "true";

  16. Another Example Policy keynote-version: 2 comment: doc1 is granting read and insert access to doc2 for pat1's patients_record and referral authorizer: "DSA:abcd123456" # doc1's pub key licensees: "DSA:dead1357" # doc2's public key conditions: app_domain == "HIPAA" && patient_id == "pat1" && (requested_act == "READ" || requested_act == "INSERT") && (data == "patients_record" || data == "referral") -> "true"; signature: "DSA-SHA1:1f4C539B02" # signed by doc1 with his private key

  17. What KeyNote Doesn’t Do • Emergency access • Would be possible to handle in KeyNote, but would require an assertion that lists every doctor and nurse as licensees to access any patient’s information • Restricting the type of credentials that each administrator doctor may add • We don’t want administrator doctors delegating the right to change patients’ ACL

  18. Verifier Application • Also a Java application • Retrieves log records • Checks logged events vs. new or old policy • Could catch violations due to bugs in server application • If there was an error in the policy, can check if old events comply with corrected policy

  19. Evaluation: Advantages • Three-tier model for better security and performance • Use Java for client and server application • KeyNote for access control • Unified logging mechanism for PHI accesses and policy updates • Verifier automates the auditing process

  20. Evaluation: Disadvantages • Large number of assertions • Might not be scalable • Security official might be a single point of failure • Signing the assertions might be inconvenient for administrator doctors • Server application being compromised could be disastrous • So could administrator doctors' private keys being stolen

  21. Future Work • Evaluate how to make the access control more scalable • Extend model to other user types such as insurance companies and researchers • Extend verifier application to flag suspicious access patterns

  22. Questions or Comments?

More Related