HIPAA Security and Privacy Katharine Chang Ashlesha Joshi

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 • It includes requirements for the security and privacy of protected health information (PHI) • Electronic PHI is of particular concern

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.

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

HIPAA Principles 1. (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.

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.

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.

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

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

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

How Design Relates to Principles • Key. Note – – 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

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

Key. Note • 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

Our Use of Key. Note • 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

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

Another Example Policy keynote-version: 2 comment: doc 1 is granting read and insert access to doc 2 for pat 1's patients_record and referral authorizer: "DSA: abcd 123456" # doc 1's pub key licensees: "DSA: dead 1357" # doc 2's public key conditions: app_domain == "HIPAA" && patient_id == "pat 1" && (requested_act == "READ" || requested_act == "INSERT") && (data == "patients_record" || data == "referral") -> "true"; signature: "DSA-SHA 1: 1 f 4 C 539 B 02" # signed by doc 1 with his private key

What Key. Note Doesn’t Do • Emergency access – Would be possible to handle in Key. Note, 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

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

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

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

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

Questions or Comments?