HIPAA Security and Privacy

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 subjects 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
How Design Relates to Principles

• 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

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 patients administrator
  doctor full access to the patients 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 "DSAabcd123456" doc1's pub key
• conditions app_domain "HIPAA"
• patient_id "pat1"
• (requested_act "READ"
• requested_act "MODIFY")
• (data "patients_info"
• data "access_control")
• -gt "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 "DSAabcd123456" doc1's pub key
• licensees "DSAdead1357" doc2's public key
• conditions app_domain "HIPAA"
• patient_id "pat1"
• (requested_act "READ"
• requested_act "INSERT")
• (data "patients_record"
• data "referral") -gt "true"
• signature "DSA-SHA11f4C539B02"
• signed by doc1 with his private key

17
What KeyNote Doesnt 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 patients
  information
• Restricting the type of credentials that each
  administrator doctor may add
• We dont 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?