Design of Health Technologies lecture 22

1. Design of Health Technologieslecture 22 John Canny11/28/05

2. Healthcare IT Security Security is a critical aspect of Health IT performance: without secure systems, privacy protection is impossible. The Health and Human Services Agency published a proposed “security rule” in August 1998. Final rule was adopted Feb. 2003. It’s a set of best practices for securing information systems. Compliance is mandatory for health providers, plans, and clearinghouses.

3. Security Rule Compliance Large organizations were required to comply by April 21, 2005. Small organizations must comply by April 21, 2006. Final rule is available here: http://www.cms.hhs.gov/hipaa/hipaa2/regulations/security/default.asp

4. Security Rule Compliance The security rule creates an additional burden on providers to improve their IT infrastructure. On the flip side, the same improvements might actually improve service (e.g. enabling internet-based secure health information access, or secure wireless). A more sanguine perspective is that any mandatory IT upgrade is an opportunity for global improvement – many problems can be fixed at once.

5. Data CIA (Confidentiality, Integrity, Availability) The security rule is divided into 3 parts: • Administrative safeguards • Physical safeguards • Technical safeguards

6. Administrative safeguards These steps are required at the highest level: • Risk Analysis must be performed • Risk Management sufficient for compliance • Sanction Policy: against employees who don’t comply • Information System Activity Review: records & logs • Security Responsibility: assign a security official

7. Administrative safeguards Some required steps: • Isolate Health Clearinghouse from rest of organization • Access Control for protected records • Access Establishment and modification • Security Reminders: updates and messages • Protection from Malicious Software • Log-in Monitoring: all login attempts • Password Management

8. Administrative safeguards Standards for availability: • Data Backup Plan • Disaster Recovery Plan • Emergency Mode Operation Plan • Testing and Revision of contingency plans • Applications and Data Criticality Analysis: Identify the critical components in an emergency

9. Physical Safeguards Here are some: • Facility Access Control • Emergency Facility Access • Physical Access to Workstations • Media Access Controls • Disposal Policies • Media Erasure before Re-use

10. Technical Safeguards Here are some: • Access Controls • Unique User IDs • Emergency Access Procedures • Automatic Logoff (optional) • Encryption and Decryption (optional) • Audit Controls (optional)

11. Technical Safeguards Some more optional sections: • Access Records: who accessed PHI • Personal Identity: is the user really who they claim to be? Biometrics? • Transmission Security: Secure communication channels

12. Over the Atlantic… The European Parliament has been passing security and privacy rules as well. “On the protection of medical data” (Recommendation R(97)5) is still a recommendation. The most recent is Directive 2002/58 “Privacy and electronic communications: Processing of personal data and the protection of privacy in electronic communication”

13. R(97)5 summary The European recommendation covers a lot of ground in the short document. It specifies both HIPAA-style privacy rules, as well as data-protection procedures. Stronger emphasis on results of genetic testing: • Patients should have access • It should not be illegal in the country • The information is not likely to cause harm (?)

14. Gritzalis et al. paper This paper is based mostly on EU directives on general electronic privacy, as well as the medical security proposal. The paper also includes a sample RA (Risk Analysis) for the Beta-Thalassemia unit using CRAMM (CCTA Risk Analysis and Management Methodology).

15. Risk Analysis

16. Risk Analysis

17. Gritzalis et al. paper Proposals: • Authentication: Smart cards, X.509 certificates, CHAP, EAP • Communication: SSL, application-level security Disclosure from client machines (discourage): • Through explicit web form fields • Cookies and client-side script engines Anonymization methods: various technical approaches are listed, not clear any of these are intended to be used.

18. Gritzalis et al. paper ASP model: Control local code execution. Any code to be executed locally must be signed by someone (e.g. Microsoft or Verisign). Aside: Smart phones typically include additional quality control for locally-run code: e.g. “True Brew” certification for Qualcomm Brew phones. Other Certification Programs: • Sony (Playstation) • Microsoft (Xbox) • Nintendo etc…. • Microsoft for Windows device drivers

19. Medical service provider responsibilities • Inform users about their services, ask for consent for required uses of client information. • Use standards such as CEN and HL7 • Use RBAC (Role-Based Access Control) • Moderated Mailing Lists (?) w/ usage permissions • Do not downgrade functionality to users who refuse to provide specific information

20. Discussion Questions Q1: Is Quality Certification a viable method for helping to secure medical software? Points of comparison: phone and driver software just mentioned, medical equipment, drugs,… How could it be implemented? Q2: Implementation of the security rule usually requires a significant overhaul of IT infrastructure. Discuss the trade-off in building secure systems “from scratch” vs. a “generalized firewall” approach which puts secure screens around vulnerable IT.