Design of Health TechnologiesDesign of Health Technologieslecture 22lecture 22

John CannyJohn Canny11/28/0511/28/05

Healthcare IT SecurityHealthcare 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.

Security Rule ComplianceSecurity 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

Security Rule ComplianceSecurity 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.

Data CIA Data CIA (Confidentiality, Integrity, (Confidentiality, Integrity, Availability)Availability)

The security rule is divided into 3 parts:

1. Administrative safeguards

2. Physical safeguards

3. Technical safeguards

Administrative safeguardsAdministrative safeguards

These steps are required at the highest level:1. Risk Analysis must be performed2. Risk Management sufficient for compliance3. Sanction Policy: against employees who don’t

comply4. Information System Activity Review: records

& logs5. Security Responsibility: assign a security

official

Administrative safeguardsAdministrative safeguards

Some required steps:1. Isolate Health Clearinghouse from rest of

organization2. Access Control for protected records3. Access Establishment and modification4. Security Reminders: updates and messages5. Protection from Malicious Software6. Log-in Monitoring: all login attempts7. Password Management

Administrative safeguardsAdministrative safeguards

Standards for availability:1. Data Backup Plan2. Disaster Recovery Plan3. Emergency Mode Operation Plan4. Testing and Revision of contingency plans5. Applications and Data Criticality Analysis:

Identify the critical components in an emergency

Physical SafeguardsPhysical Safeguards

Here are some:1. Facility Access Control2. Emergency Facility Access3. Physical Access to Workstations4. Media Access Controls5. Disposal Policies6. Media Erasure before Re-use

Technical SafeguardsTechnical Safeguards

Here are some:1. Access Controls2. Unique User IDs3. Emergency Access Procedures4. Automatic Logoff (optional)5. Encryption and Decryption (optional)6. Audit Controls (optional)

Technical SafeguardsTechnical Safeguards

Some more optional sections:1. Access Records: who accessed PHI2. Personal Identity: is the user really who they

claim to be? Biometrics? 3. Transmission Security: Secure

communication channels

Over the Atlantic…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”

R(97)5 summaryR(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: 1. Patients should have access2. It should not be illegal in the country3. The information is not likely to cause harm (?)

Gritzalis et al. paperGritzalis 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).

Risk AnalysisRisk Analysis

Risk AnalysisRisk Analysis

Gritzalis et al. paperGritzalis 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.

Gritzalis et al. paperGritzalis 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

Medical service provider Medical service provider responsibilitiesresponsibilities 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

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