D'Arcy Gue


How to Navigate Implementation Specifications to Manage Security Risks

April 30, 2014


HIPAA & Security 4 Minute Read

When the HIPAA security rule first came out, many hospitals were frustrated that there wasn’t a simple checklist of security measures that they could follow. Now that Meaningful Use / MIPS is also requiring security assessment and management activity and the Health and Human Services department (HHS) is stepping up enforcement activity, hospitals are under even more pressure to actively manage their security.

Security officers in particular were frustrated when HHS recommended specific actions like implementing single sign-on or the use of complex passwords. Many wondered where in the security rule these recommendation were stated. The answer, in many cases, is that the rule doesn’t say that.  What the rule does give is significant flexibility in the implementation of the controls specifically mentioned in the rule, and even wider latitude in dealing with risks identified in the risk analysis process. 

Security Controls Identified in the Security Rule

The first element of flexibility is that the final Security Rule includes both “Required” and “Addressable” implementation specifications. “Addressable” implementation specifications provide your facility with flexibility in implementing safeguards to ensure compliance with the final Security Standards. You can decide whether a given “Addressable” implementation specification is a reasonable and appropriate security measure to apply within your particular security framework.

The following table shows just one section of the security rule, and its four implementation specifications. 

Standards Sections Implementation Specifications

(R)= Required, (A)=Addressable

Access Control 164.312(a)(1) Unique User Identification (R)
Emergency Access Procedure (R)
Automatic Logoff (A)
Encryption and Decryption (A)

Factors that should guide your decision include:

  • The size, complexity, and capabilities of the organization
  • The available technical infrastructure, hardware, and software security capabilities
  • The costs of security measures
  • The probability and criticality of potential risks to electronic protected health information

If, after you’ve evaluated each specification, you decide not to implement a particular “Addressable” implementation specification, you must document why it would not be reasonable and appropriate, and implement an equivalent alternative measure if a reasonable and appropriate one is available.

Even More Flexibility When Addressing Risks

The Security rule is even more flexible in regard to addressing risks. Except where there are required controls like those mentioned in the previous section. Your security management team has wide latitude in determining appropriate responses to various risks. As you plan which risks to address, recognize that there are at least four decisions that your organization can make with regard to any given risk:

  1. Accept the risk – a documented decision to take no action. This is most likely to be done where a risk has a particularly low chance of happening. For example, the organization may not have a strategy for addressing IT requirements in a prolonged power failure. The hospital may decide to accept that risk, knowing that the entire hospital would be closed in such an event and that the particular value of providing IT services after the hospital is evacuated would be minimal.
  2. Watch the risk – ideally with documented criteria for future action. This is most likely to be seen where a particular risk is currently small, but expected to rise over time, or where a risk is believed to be small, but not well quantified.
  3. Transfer the risk – examples include purchasing insurance and outsourcing a capability to a vendor. Many hospitals do this, by having key systems (particularly electronic medical records) hosted by vendors, allowing the vendor to manage specific controls like disaster recovery, physical security for the server environment, and data integrity measures.
  4. Reduce (mitigate) the risk– by choosing to implement countermeasures to address vulnerabilities.

Key to Successful Risk Management – Documentation

As you address specific risks identified in your risk analysis, if you choose Accept, Watch, or Transfer solutions, your primary responsibilities will be to document your decision, the reasons behind it, and what criteria, if known, would make you reconsider. In this case, the clinical documentation maxim applies, “If you didn’t document, you didn’t do it!”  If you choose to mitigate the risk, then the ability to demonstrate progress through the natural conclusion of the project will be required.

Concentra Health Services, a national occupational health network, recently paid the Office for Civil Rights (OCR) $1,725,220 when an unencrypted laptop was stolen.  Concentra had already recognized the risk to PHI in multiple risk analyses, and 434 out of their 597 laptops had already been encrypted, when the project was stalled. The HHS Press release specifically calls attention to the incomplete project and notes that Concentra’s efforts were “incomplete and inconsistent over time.”

Making these decisions, getting them properly documented and managing implementation of security projects can be a challenge for many hospitals. If you’re unsure about the security of your PHI, or need to address your organization’s level of risk, let us know. Phoenix consultants have been assisting hospitals and large provider groups with their risk management process for over a decade.



Related Posts