HIPAA Security Rule: Technical Safeguards

The HIPAA security rule technical specifications are one of the three required safeguards of the HIPAA Security Rule. The Physical safeguards focus on policies and procedures for aspects such as how to limit physical access to facilities containing protected health information (PHI), proper care of electronic media, and device security. The Administrative safeguards focus on administrative policies and procedures for aspects such as a security management process and managing access to PHI by a covered entity’s workforce.

In this Article …

• What are HIPAA Technical Safeguards?
• Security Rule Technical Safeguards are Technology Neutral
• 1st Technical Safeguard: Access Controls
• 2nd Technical Safeguard: Audit Controls
• 3rd Technical Safeguard: Integrity
• 4th Technical Safeguard: Person or Entity Authentication
• 5th Technical Safeguard: Transmission Security
• Final Thoughts on the HIPAA Security Regulations

 

What are HIPAA Technical Safeguards?

The technical safeguards of the HIPAA Security Rule require covered entities and business associates to implement technical security measures. It defines these technical safeguards in Section 164.304 as “the technology and policies and procedures for its use that protect electronic protected health information and control access to it.” The standards of the technical safeguards include:

• Access controls,
• Audit controls,
• Integrity,
• Person or Entity authentication, and
• Transmission security.

Like physical and administrative safeguards, technical safeguards include seven implementation specifications. Two of the implementation specifications are required; the other five are addressable implementation specifications. Two of the technical safeguards have no implementation specifications but are still required.

An implementation specification that is described as an addressable implementation specification is not optional. A covered entity may choose not to implement such a technical safeguard. But it must then explain why it is choosing not to implement it, and describe its alternative method for achieving the intent of the technical safeguard.

 

Security Rule Technical Safeguards are Technology Neutral

It is worth noting that the Security Rule Technical Safeguards do not specify any particular type of technology, and are purposely designed to have this neutrality. There are several reasons for this:

1. Technological Flexibility: Technology in the healthcare industry is constantly evolving. So omitting the specification of exact technologies permits covered entities to determine the ones that fit their operations, capabilities, and risk assessment.
2. Diverse Needs in Healthcare: Healthcare organizations vary greatly in size, resources, and the very nature of their business. What may be appropriate for a large urban hospital will be much different for a small rural clinic. This technology-neutral approach allows each entity to implement its own chosen security measures that are reasonable and appropriate for its specific set of circumstances.
3. Innovation Encouragement: The intent is not to stifle innovation by forcing specific technologies and solutions. Keeping this open encourages developers to seek more efficient and secure solutions moving forward.
4. Focus on Outcome: The HIPAA Security Rule is concerned with the end result of keeping electronic protected health information (ePHI) properly protected. As such, technology neutrality keeps the focus on the objective rather than the means.

 

1st Technical Safeguard: Access Controls

The Access Control standard requires a covered entity to implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in the organization’s Information Access Management policy.

This security measure complements the requirements of the Administrative safeguards covering workforce security.

Access Control covers four implementation specifications.

1. Unique User Identification: The Unique User Identification implementation specification requires covered entities and business associates to assign a unique name and/or number for identifying and tracking user identity. There is no particular format required for User Identification. The user identifier must enable the covered entity to track specific user activity when that user is logged into an information system, in other words, to complete an access control audit. This implementation specification is required.
2. Emergency Access Procedure: The second implementation specification, which is also required, is having an Emergency Access procedure. A covered entity must implement policies and procedures that document the instructions and operational practices for obtaining access to necessary electronic protected health information during an emergency situation. Each covered entity must identify the situations that would require emergency access, for instance, natural disasters or man-made situations that would result in restricted or complete lack of access. And there may be different access control procedures during an emergency, but the privacy of ePHI must still be maintained.
3. Automatic Logoff: The third implementation specification is automatic logoff. This is an addressable implementation specification, although a covered entity must explain why they are not implementing this security measure. The procedure should provide for an automatic logoff of a user after a predetermined time of inactivity. If choosing not t address the specification, covered entities must implement security measures that achieve the same result as the automatic logoff specification.
4. Encryption and Decryption: The fourth and final implementation specification under this standard is encryption and decryption.
   • This particular Access control measure can be somewhat confusing. Early on, many covered entities applied encryption to “data in transit”, which is covered in the Transmission Security standard. The HITECH Act of 2009 included provisions related to the penalties for unauthorized disclosures. This change has encouraged many covered entities to encrypt data at rest, too. Electronic protected health information in servers running electronic health record systems is considered data at rest. But so is ePHI on flash drives, disc drives in desktop computers, laptop computers, or even a mobile device.
   • ePHI in an EHR software application is protected by access controls such as user IDs and automatic log-offs. But ePHI in desktops, laptops, flash drives, etc., is vulnerable, as demonstrated by the plethora of breach notifications involving such devices.
   • The HITECH Act was amended in 2020 to include provisions allowing for a type of safe harbor for covered entities and business associates who could demonstrate they had appropriate security measures in place for at least one year prior to a data breach. HHS is required to evaluate the security measures to see if they were in line with best practices in cybersecurity. A covered entity could still be penalized, but the penalty may be mitigated depending on the security protections in place prior to the time of the breach.

 

2nd Technical Safeguard: Audit Controls

For the Audit Controls standard, there is no implementation specification. This standard requires a covered entity to implement various hardware, software, or procedural mechanisms. These mechanisms must be able to record and examine activity in an electronic network that contains or uses ePHI. This security measure does not specify the type of information that must be gathered or how often reports should be reviewed. Covered entities and business associates should have audit control policies that are reasonable and appropriate for their size and complexity. This is a required standard.

 

3rd Technical Safeguard: Integrity

For the Integrity standard, the HIPAA security rules require that covered entities implement written security policies that protect ePHI from improper alteration or destruction. There is one addressable implementation specification for the Integrity standard.

1. Mechanism to Authenticate Electronic Protected Health Information: Covered entities must implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. Part of this standard refers to the risk analysis process any organization creating or maintaining PHI/ePHI is also required to undertake. The risk assessment should consider risks to the integrity of ePHI as part of the risk analysis process. Functions that are traditionally utilized to verify the integrity of data include checksum verification. Digital signatures by authorized users are another way to ensure compliance with the Integrity standard.

 

4th Technical Safeguard: Person or Entity Authentication

There is no implementation specification for this Safeguard, but it is one of the required security standards.

This HIPAA security standard requires covered entities to implement policies and procedures to verify that a person or entity seeking access to ePHI is the one claimed. Various methods are available to covered entities to meet this HIPAA security rule.

• Passwords or PINs unique to a user can be used. Of course, there are best practices related to passwords such as required resets and restrictions on using the same password over and over.
• Smart cards, tokens or a key that is in possession of an individual.
• Biometric identifiers such as fingerprints or facial recognition.

Many organizations have adopted multifactor authentication methods. These can include passwords plus a mobile authentication factor available through a smartphone. Microsoft estimates that multifactor authentication methods can reduce the risk of identity compromise by 99.9% compared to passwords alone.

 

5th Technical Safeguard: Transmission Security

The Transmission Security standard requires a covered entity to implement technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic communications network. A covered entity must first review and document the methods it uses to transmit ePHI as part of a risk analysis. Then it should select an appropriate method to protect the ePHI and document that method.

There are two addressable implementation specifications for this security standard.

1. Integrity controls: In simple terms, Integrity Controls require covered entities to ensure that the data sent is the data received. More formally, it requires security measures to ensure ePHI is not improperly modified without detection during electronic transmission. Implementing network communication protocols is a typical way this specification is addressed.
2. Encryption: This implementation specification requires a covered entity to ensure its risk analysis process includes how it is transmitting PHI electronically, and decide how it will protect the PHI from unauthorized access. If the risk assessment shows there is a reasonable chance of unauthorized access, then some form of encryption must be employed. An example of PHI that may be sent or included in non-secure communications is internet email with PHI in the text or as an attachment. Fortunately, there are several secure email applications available to address this risk.

 

Final Thoughts on the HIPAA Security Regulations

The HIPAA Security Rule is nothing if not comprehensive. It includes physical safeguards, administrative safeguards, and technical safeguards. Security incidents are real, and as the Office for Civil Rights “Wall of Shame” shows, even large organizations with considerable resources can experience large breaches of protected health information – have large fines to prove it. We often advise our clients: don’t wait to improve the security of your ePHI. Implement the changes you would make after a breach before it ever happens!