HIPAA Security Rule’s Technical Safeguards for healthcare tech

As we’ve already written in the first part of our regulation series (an introductory instalment on the most common HIPAA violation cases), HIPAA consist of four rules and one of them is Security Rule. In this article, we’re going to talk about a very particular part of this rule, Technical Safeguards and their aspects and details that are necessary to implement in any organization working with protected health information (PHIs).

Now, it’s important to note a few things about HIPAA is that the recommendations outlined in the Rules are divided into required and addressable. The former is obligatory for being HIPAA compliant, the latter is not. However, we do recommend you try applying both of them to your organizations: because they are the best practices, firstly, and secondly, because what “addressable” in one recommendation occurs to be an absolute necessity in another one. For instance, data encryption is stated to be addressable, but it is one of the most effective ways to protect ePHI from being compromised, and that is obligatory.

Technical safeguards of HIPAA Security Rule are what your product team — engineers and project managers especially — should give as much attention as possible. Before we dive into different aspects of technical safeguards, it is worth noting that for all your applications and software you are going to need HIPAA hosting — a hosting that is compliant. Being hosted on HIPAA compliant data storage, however, does not make your application HIPAA compliant: so if you’re planning to use, let’s say, Amazon AWS or Azure, common for handling healthcare projects and compliant, you still need to ensure compliance on your side of the business.

Let’s move to HIPAA technical safeguards.

Access control

This safeguard is needed to ensure authorization and policies on who can access PHI, how to protect it, and how to get to it in case of emergency.

Unique ID. HIPAA requires you to assign unique IDs to every user of your system and develop (or enable) a tracking or reporting system that will show you what your employees are doing with patient data. Incident reports will be important for other technical safeguards, audit control, and they may provide you with insights on when your data was compromised and allow you to establish good fraud detection processes.

Password protection. It’s important that your employees receive training on the importance of strong passwords and the danger of commonly used passwords (these include word “password,” “12345678”, “qwertyasdf”, etc. For this safeguard not displaying a password in any way will be a good practice, as well as not storing it anywhere in the text format. Passwords should be changed regularly according to your security policy.

Automated logout. During the periods of inactivity, the systems should kick off any users, no matter how much progress isn’t saved. The period of inactivity that is required to shut out a user’s access organization determines by researching its processes and finding the most comfortable for employees and safe for user data time range. 15 minutes is a pretty fair deal if we’re talking about office desktop station (that are situated in a secure location)--it’s enough to grab a coffee and come back to resume work. It’s too much, though, for laptops and smartphones people can leave unattended in a cafe, library, car, etc. So, measure your risks.

Encryption and decryption. It’s important that every part of the system that stores, transmits, or interacts with PHI in any way, direct or indirect, must be protected with encryption, as well as system’s internal communications and networks. It’s better not to lead users anywhere outside the system, and if it’s, for instance, necessary to transmit PHI through emails, make it possible to send a link to internal chat (that is protected and secured and requires password-enabled access) through emails instead of sending actual PHI.

Establish emergency access procedures. It’s a set of operational instructions that will allow you to get PHI that is lost to extra situation: it might be natural disasters, robbery, and other rather unpleasant things. To comply with that safeguard, you should think about using more than one web server and database server, at least, for the health data to be available and secure always, no matter the emergencies.

Person or Entity Authentication

Quite obvious technical safeguard that, once again, manages the level of access of your employees and your system users to certain data. Unique ID and password are the means to establish authentication. They must be assigned to every user and customer. These days, two-factor verification is a wonderful way to confirm the identity of a person who tries to access PHI: from confirmation through mobile phone to biometrical verification.

Audit controls

We’ve already mentioned that part. To comply with this safeguard, your system has to automatically track users’ interaction with ePHI, and store the tracked behaviours for six years (though it’s worth mentioning that it’s unclear whether such timing is obligatory for HIPAA or not, the safest option is to do that.) Audit logs (reports) must be unmodifiable.

An audit trail is essential when something is going wrong and PHI is stolen or compromised: you’re able to find out when and why this happens, create a proper --timely and explanatory report--and address the issue through training. But, audit logs are a good training ground even without security issue, as they, ideally, serve as a tool to establish risk-prevention measures.

Integrity

One of the PHI characteristics HIPAA protects is the integrity of health data. What does it mean? A system that handles PHI in any way must protect it from unauthorized access and ensure there aren’t any alterations and malware. Audit control overviews must help with that as well. Also, to ensure integrity, you can do the following:

• Disable any software that isn’t related to business or PHI on production systems and workstations as a part of workstation policies. In other words, don’t let people at workstations that handle PHI surf non-protected sites or use not safe software.
• Detect any logins in the systems, as well as the login attempts as a part of data audit logs.
• Install antivirus and\or OSSEC (or any host intrusion detection system) to detect twists, viruses, and malware in your system. Antiviruses must scan the system regularly, each several hours, to detect breaches and report vulnerabilities.
• Update operating system and software production system use and encourage your customers to do so.

Final recommendation on data integrity and security in HIPAA Technical Safeguards has to do with transmission security.

Transmission Security

As a rule, PHI data should be protected in-rest and in-transit. That means PHI must be stored in encrypted databases (encrypted in rest) which are protected from unauthorized access. And, that PHI must be encrypted when it’s transferred from network to network, end-to-end.

Essentially, encryption is ciphering your data into a code that is accessible through a key before transmission, and decryption is deciphering this code with a key before receiving. Dealing with PHI matters, you need the most secure cryptographic key (at least, of 256-bit.)

Go beyond the basics

It’s important to know about the landscape of cybersecurity threats, especially if you’re building software in healthcare. For instance, in 2020 year the number of SSL attacks — attacks, where the agent is masking as reliable using the SSL traffic streams from Google, Amazon, and other cloud services — increased by 260%. 

To avoid falling to malware and fishing attacks that are conducted or transferred using encrypted traffic, healthcare and the organizations that provide software for it needs to refuse from the legacy system and old on-premise firewalls that can’t inspect all volumes of data-in-transit properly. Both providers and vendors need to understand the shortcomings of implementing the bare minimum — encryption — and dive deep into possible threats that can be used exploiting this bare minimum.

Finally, despite the fact HIPAA's Technical Safeguards should be the main concern for your product engineers and product managers, encourage people in your team to engage with the tech beats, even if it’s just a bit. To motivate them to come up with stronger credentials and be cautious about clicking links on their emails, show them how such things can lead to drastic consequences for your company and for patients whose data your company processes/your hospital treats.

The same goes for choosing software vendors and developers for the healthcare organizations: they must be HIPAA-compliant and Technical Safeguards should be underlying the architecture of the product you've chosen to implement.

Check out our previous take on HIPAA and subscribe to get new Regulation series articles.