In February the US Department of Health and Human Services imposed this year’s second penalty for alleged HIPAA violations. Arizona-based health system Banner Health has agreed to pay $1,250,000 in fines and roll out a corrective action plan to remedy a 2016 security incident that exposed the protected health information of nearly three million people. On July 13, hackers gained access to individuals’ names, addresses, dates of birth, social security numbers, claims and health insurance information, lab results, medication history and diagnoses, HIPAA Journal reported.
Following a probe into Banner Health’s security practices, the HHS found that the non-profit health care system had failed to carry out accurate and detailed analysis of potential risks and vulnerabilities to protect the confidentiality, integrity, and availability of electronic protected health information. Meaning that the organization didn’t uphold the administrative safeguards of the HIPAA Security Rule, which call for regular reviews of network activity to detect unauthorized access to PHI. An oversight which then turned into a golden opportunity for malicious actors – and eventually, a 1.25-million-dollar dent in the health system’s coffers.
So what are administrative safeguards and how are they different from other types of safeguards? In this article, we’re taking a closer look at the administrative safeguards outlined in the Security Rule, including what they’re supposed to protect and how, plus how organizations can tackle compliance.
The HIPAA Security Rule: what is it and what does it protect?
If you’ve read our previous deep dives into the HIPAA minimum necessary standard and technical safeguards, you’re well aware that the Health Insurance Portability and Accountability Act was signed into law by President Bill Clinton in 1996. Its primary purpose was to protect healthcare coverage for people who have lost or changed employment. More specifically, to help more Americans get health insurance coverage, prevent workers from losing their health insurance between jobs, and minimize waste, fraud, and abuse in health insurance and healthcare delivery.
However, thanks to the rapid evolution of technology as well as the risks they had brought to the privacy of personal information in the healthcare space, by the time the legislation came into effect, its provisions had already been somewhat outdated. This is why the HIPAA Privacy Rule was introduced in December 2000, followed by the HIPAA Security Rule in February 2003. While the HIPAA Privacy Rule safeguards protected health information, the HIPAA Security Rule protects a subset of such information.
“This subset is all individually identifiable health information a covered entity creates, receives, maintains, or transmits in electronic form. This information is called electronic protected health information, or ePHI. The Security Rule does not apply to PHI transmitted orally or in writing,” explains the US Centers for Disease Control and Prevention (CDC). In doing so, the HIPAA Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting e-PHI.
The three safeguards of the HIPAA security rule, explained and compared
Taking up over half of the Security Rule, administrative safeguards are defined as “administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s workforce in relation to the protection of that information.” That is, the security management protocols and workflows, rather than physical or technical means, that covered entities must have in place.
Physical safeguards, by contrast, cover access to both the physical structures of a covered entity and its electronic equipment, be they buildings, equipment, or information systems. In this regard, covered entities’ duties are two-fold. First, they must limit physical access to their facilities without limiting authorized access. Second, they must set out rules for the proper use of workstations and devices, as well as for the transfer, removal, disposal, and re-use of electronic media, to ensure protection of ePHI.
Technical safeguards are related to the technology as well as the relevant policies and procedures that covered entities should implement to protect ePHI and control access to it, including audit controls, user verification, and automatic log-off. They also make it clear that encryption is key in fending off unauthorized use and disclosure and must be applied if, having completed a risk assessment, an entity deems it a suitable safeguard in its risk management of the confidentiality, integrity, and availability of ePHI.
The 9 HIPAA administrative safeguards: an overview
Under the Security Rule, HIPAA-covered entities must implement reasonable and appropriate administrative safeguards to build a foundation for their security programs. It’s important to note here that most HIPAA security standards include implementation specifications, that is, detailed instructions for implementing them. This means that each set of safeguards consists of a set of standards, most of which consist of a set of required or addressable implementation specifications.
If an implementation specification is required, covered entities must have measures in place to fulfill exactly what the specification entails. In case of addressable implementation specifications, covered entities must assess whether they’re reasonable and appropriate for their specific environment. If they’re deemed not to be, the covered entity must document the grounds for its assessment and consider applying an equivalent alternative.
As detailed by the HHS, the administrative safeguards of the HIPAA Security Rule are the following:
1. Security Management Process
Under this standard, covered entities must develop “policies and procedures to prevent, detect, contain and correct security violations.” Meaning the administrative processes that the entity will use to implement its security program across the organization. The standard includes four required implementation specifications: risk analysis, risk management, sanction policy, and information system activity review.
2. Assigned Security Responsibility
Without setting forth any implementation specifications, this standard requires that covered entities appoint a security official responsible for developing and implementing the policies and procedures required for the entity. This requirement is comparable to the Privacy Rule standard that calls for a designated Privacy Official. The Security Official and Privacy Official can be the same person, but don’t have to be.
3. Workforce Security
The third standard prescribes that covered entities must ensure that employees have appropriate access to ePHI and prevent those who don't from accessing it. In doing so, organizations must give staffers the minimum necessary access to ePHI they need to carry out their jobs. Implementation specifications include authorization and/or supervision, workforce clearance procedure, and termination procedures (all addressable).
4. Information Access Management
The fourth standard requires covered entities to implement protocols for authorizing access to ePHI that are consistent with the minimum necessary standard of the HIPAA Privacy Rule to curb the risk of unwanted disclosure, alteration, or destruction of information. Implementation specifications include isolating health care clearinghouse functions (required), access authorization (addressable), and access establishment and modification (addressable).
5. Security Awareness and Training
No security safeguard will protect an organization if its members aren’t aware of how to enforce them. The fifth standard requires covered entities to offer security awareness and training programs for all employees, including management. Implementation specifications cover security reminders (addressable), protection from malicious software (addressable), login monitoring (addressable), and password management (addressable).
6. Security Incident Procedures
This standard states that covered entities must have policies and procedures in place to handle security incidents. This is key because such incidents will occur, no matter how robust covered entities’ safety measures are. Protocols should cover how to detect and report breaches and match the entity’s specific environment and the type of data involved. There is one required implementation specification for this standard, that is, response and reporting.
7. Contingency Plan
The goal here is to build strategies that enable covered entities to reestablish access to ePHI in case of business continuity disruption. Think: fire, vandalism, system failure, or natural disaster. The standard includes five implementation specifications: data backup plan (required), disaster recovery plan (required), emergency mode operation plan (required), testing and revision procedures (addressable), as well as applications and data criticality analysis (addressable).
Covered entities should conduct ongoing monitoring and regular assessment of security plans to make sure they continue to provide adequate protection for ePHI. Initially, the evaluation must be based on the security standards implemented to comply with the Security Rule, then periodic evaluations must be performed in response to environmental or operational changes that impact the security of ePHI. No implementation specification applies.
9. Business Associate Contracts and Other Arrangements
The last Administrative Safeguards standard specifies that a covered entity may allow a business associate to create, receive, maintain, or transmit ePHI on its behalf only if the entity can obtain satisfactory assurances that the business associate in question will appropriately protect the information handled. The standard has one implementation specification regarding written contracts and other arrangements (required).
Common examples of administrative safeguards
- Performing risk analysis to identify potential security risks and assess the probability of the occurrence and magnitude of such risks.
- Specifying audit and activity review functions of information systems as well as what logs and reports should be generated by them.
- Identifying the responsibilities of the Security Official to match the size, complexity and technical capabilities of the covered entity.
- Creating detailed job descriptions to determine what level of access people in different positions should have to ePHI.
- Developing security incident policies and procedures for various types of security incidents, including how to respond and who to report them to.
HIPAA risk assessment: key considerations and resources
Performing a risk analysis is the first step in developing safeguards that check all the boxes set out by the standards and implementation specifications of the Security Rule. Remember that all ePHI created, received, maintained, or transmitted by an organization is subject to the Security Rule. Covered entities should thus achieve compliance by evaluating risks and vulnerabilities in their environments and designing security measures to match the threats to the security or integrity of electronic protected health information.
There’s no one-size-fits-all approach or method to carrying out a HIPAA security risk assessment. The size, complexity, and capabilities of the covered entity, as well as its technical infrastructure, hardware and software security capabilities, probability and impact of potential risks to ePHI and the cost of security measures implementation should all be factored in, points out the American Medical Association. So should a categorized list of all reasonably anticipated risks, vulnerabilities and threats, human, environmental or natural.
That said, the National Institute of Standards and Technology (NIST) in the US provides comprehensive, freely available guidance on good risk analysis and risk management practices. NIST’s Guide for Conducting Risk Assessments detailed in SP 800-30 in particular is regarded as an industry standard for identifying and prioritizing risks to company operations and data assets and developing the right risk responses. As such, it is also widely used and recommended as a HIPAA risk assessment template.
The NIST HIPAA Security Toolkit Application has been developed to help HIPAA-covered organizations of all sizes better understand the requirements of the HIPAA security standards and how to successfully implement them. The Office of the National Coordinator for Health Information Technology (ONC) and the HHS OCR have created a HIPAA Security Risk Assessment (SRA) Tool to assist small and medium-sized health care practices and their associates in ensuring HIPAA Security Rule compliance.
Looking for a HIPAA-compliant, encrypted cloud storage and file sharing solution for managing medical records? See what Tresorit can do for you.