The HIPAA Technical Safeguards play an important role in HIPAA compliance inasmuch as they are designed to protect and control access to electronic Protected Health Information (ePHI). The safeguards and the standards within them provide a framework for covered entities and business associates to help ensure the confidentiality, integrity, and availability of ePHI.
Although they were published more than twenty years ago, the HIPAA Technical Safeguards (§164.312) are just as effective at protecting and controlling access to ePHI now as they were then. This is partly due to the language used in the standards and the implementation specifications, but also due to the “flexibility of approach” provision in the General Security Rules (§164.306(b)).
However, sometimes covered entities and business associates do not fully understand the standards. This can lead to HIPAA compliance failures, violations, and data breaches. Therefore, we have compiled a brief guide to the five HIPAA Technical Safeguards using the original notes and analyses published by the Department for Health and Human Services (HHS) in 2003 for added context.
The Five HIPAA Technical Safeguards
- 164.312(a) Access Controls
- 164.312(b) Audit Controls
- 164.312(c) Integrity Controls
- 164.312(d) Authentication Controls
- 164.312(e) Transmission Security
Access Controls
The access controls standard consists of four implementation specifications designed to restrict access to information systems that maintain or use ePHI. The implementation specifications require covered entities and business associates to:
- Assign a unique name and/or number to each authorized user in order to identify users and track their activity.
- Develop (and test in line with CMS’ Emergency Preparedness Rule) procedures for accessing ePHI during an emergency.
- Implement procedures that terminate an electronic session and/or log users off after a period of inactivity.
- Implement mechanisms to encrypt ePHI at rest.
The first two implementation specifications are “required” inasmuch as covered entities and business associates must assign a unique user ID to each authorized user and develop procedures for accessing ePHI in an emergency. The second two implementation specifications are “addressable” inasmuch as they are required unless an alternative measure is equally effective.
The reason HHS tagged the second two implementation specifications as “addressable” is that, at the time the Security Rule was published, few devices and programs included automatic logoff by default. The “addressable” provision allows covered entities and business associates to take advantage of other inactivity lockout solutions provided they are equally effective.
With regards to the encryption of ePHI at rest, when the proposed HIPAA Technical Safeguards were published in 1998, many stakeholders complained about this requirement due to operating in a closed network protected by a firewall. Consequently, HHS allowed covered entities and business associates to decide whether encryption was reasonable and appropriate in their circumstances provided the decision was supported by a risk assessment.
Audit Controls
The second of the HIPAA Technical Safeguards was ahead of its time. This is because this standard requires covered entities and business associates to implement hardware, software, and/or procedural mechanisms that record access to – and examine activity in – information systems that contain or use ePHI. However, the intended purpose of the audit controls was not necessarily to retrospectively review who did what after a data breach or other security incident.
In the original notes and analyses, HHS references NIST SP 800-14 – “The Generally Accepted Principles and Practices for Securing Information Technology Systems”. This publication has an extensive section dedicated to audit controls in which the use of real-time automation is advocated. Real-time automation can be used to trigger safeguards that prevent unauthorized access and/or activities – such as locking a user out of a system if they attempt something above their access level.
At the time, real-time automation was not widely available – especially for small and medium sized enterprises. However, since the emergence of cloud computing, cloud service providers such as AWS (i.e., CloudTrail) and Microsoft (i.e., Azure Monitor) offer a wide range of easy-to-configure services that not only record access to – and examine activity in – information systems, but that can be configured to trigger events to prevent unauthorized access and/or activities.
Integrity Controls
It can also be beneficial to review the notes and analyses relating to this standard before trying to comply with it. This is because the standard states covered entities and business associates must implement policies and procedures to protect ePHI from improper alteration or destruction – without any further context as to what the improper alteration or destruction may be attributable to (i.e., malicious outsider, careless insider, severe weather event, etc.).
While the risk of improper alteration and destruction by humans can be mitigated by assigning users and devices read only access or least privilege access whenever possible, the original intention of this standard was “data authentication” inasmuch as the standard was going to require covered entities and business associates to implement measures such as error correcting memory to prevent data corruption. The notes also advocate backing up data to recover altered or destroyed ePHI.
If a covered entity or business associate uses a cloud service provider such as AWS or Microsoft Azure, this standard is easy to comply with by simply activating integrity controls and automatic backup services. Organizations using on-premises or legacy systems should assign read only access or least privilege access whenever possible, and seek professional compliance advice with regards to deploying additional software and implementing automatic backup.
Authentication Controls
The authentications controls standard is a commonly misunderstood standard as it requires covered entities and business associates to implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. The reason for the misunderstanding is that assigning a unique name and/or number to each authorized user (as required by the Access Controls above) would appear to satisfy this requirement.
However, this is not the case according to the notes and analyses of the HIPAA Technical Safeguards. These state covered entities and business associates should verify user identities via tools such as electronic signatures, call backs, and soft tokens. This means it is not sufficient to assign a unique name and/or number to each authorized user; and, in order to comply with this standard, covered entities and business associates should also use two-factor methods of authentication.
In many cases, it is not practical to comply with this standard because (for example) it would be unreasonable to wait for a two-factor authentication code when trying to access an EHR in an emergency. In theory, it is possible to use the “flexibility of approach” provision to avoid implementing two-factor authentication for all users and devices, but it is best to seek professional compliance advice on this point and document the outcome.
Transmission Security
The transmission security standard requires covered entities and business associates to “implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network” – effectively to protect ePHI in transit. This standard has two implementation specifications requiring measures to prevent ePHI being improperly modified in transit, and requiring the encryption of ePHI in transit “whenever appropriate”.
Both the implementation specifications are “Addressable” because, at the time the HIPAA Technical Safeguards were published, most electronic communications were via dial-up connections that had a low probability of interception. It was also the case that secure channels of communication were not yet widely available and stakeholders raised concerns they would be unable to communicate with patients via email, whereas end-to-end encrypted email services are now commonplace.
The only potential compliance issue for covered entities and business associates is to make sure members of the workforce do not send messages containing ePHI to patients and plan members using communication channels that are unsecure or with whom no Business Associate Agreement has been entered into. Covered entities and business associates can mitigate this potential compliance issue by providing all members of the workforce with comprehensive HIPAA training.
Conclusion
While the HIPAA Technical Safeguards provide a clear framework, they are also flexible. The exact methods and technologies covered entities and business associates choose to implement in order to comply with the standards can vary based on their size, complexity, and capabilities, on their technical infrastructure, hardware and software security capabilities, and on the probability and criticality of potential risks to ePHI – ensuring the chosen methods adequately protect the confidentiality, integrity, and availability of ePHI.