The dotted lines of health care
Signing on the dotted line of HIPAA
We've seen a recent flurry of activity in the health care industry around meeting meaningful use (MU) requirements for electronic health records (EHRs). Fortunately, many of the certification requirements – e.g., around quality measures – are fairly explicit. Unfortunately, there's been a relative dearth of guidance from both the government and industry around security and privacy. So the question health care chief information security officers (CISOs) have to ask themselves is, “What exactly are the security and privacy requirements?”Let's take a look at the language around the MU measure, as noted in the Federal Register:
The covered entity's risk management process necessarily provides the foundation for the measure. Most CISOs have a pretty good idea what risk management means, but what does it mean to the government? Section 164.308(a)(1)(ii)(B) of the Health Insurance Portability and Accountability Act (HIPAA) describes risk management as the implementation of “security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a).” In other words, covered entities must implement a complete set of administrative, physical and technical security measures – or controls – as required by the rule.
“Conduct or review security risk analysis per 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process.”
Seems simple enough, but unfortunately – again – we hit a bit of a snag. Compliance with the HIPAA Security Rule has historically been in the eye of the beholder because there was no common understanding around the controls required. What was “HIPAA compliant” to one covered entity may not have been with another.But this is changing. For example, the National Institute of Standards and Technology (NIST) partnered with the Office of Civil Rights (OCR) to conduct a joint conference on HIPAA security in May 2010. The first presentation of the morning was by NIST on its Special Publication (SP) 800-series documents detailing its risk management framework. And more recently, the Department of Health and Human Services (DHHS) published new guidance on risk analysis and specifically addressed the NIST SP 800-series documentation, as well as the Health Information Trust Alliance (HITRUST) Common Security Framework (CSF). The HITRUST CSF is a prescriptive, industry-specific security controls standard that “links various existing frameworks and standards to applicable points in an information security lifecycle.”
Given a common control framework, the other three elements outlined in the MU language are fairly straightforward. The entity must (1) assess the residual risk to ePHI based on a comprehensive set of security control requirements (NIST, HITRUST or similar); (2) update the controls as needed to ensure the proper level of protection is achieved or maintained (as threat and vulnerabilities change); and (3) develop, approve and manage corrective actions needed to address control deficiencies identified during the assessment.
The last part of the problem centers on attestation by management that the covered entity has implemented both general and system-level controls in the EHR system they wish to submit for the MU payments. Essentially, there must be sufficient evidence for management to feel comfortable about “signing on the dotted line.” Given that the EHR technology certification program borrows elements from the National Information Assurance Program (NIAP) implementation of the Common Criteria, I wouldn't be surprised if MU certification documentation ended up looking like a NIST-style System Security Plan (SSP).It is what the government understands.