KThe Health Insurance Portability and Accountability Act, or HIPAA for short, is a set of laws around handling health-related data in information systems. It defines safeguards, which are rules you have to follow when handling health data for your customers.
There are three safeguard categories:
- Administrative safeguards, covering personal and processes in your company
- Physical safeguards, which relate to the hardware running the software handling health data
- Technical safeguards, requirements your software has to implement
All three categories have to be handled correctly if you want your API to be HIPAA compliant. In a companion article we covered those key requirements and how to build HIPAA complaint API platforms. In this article we'll down into actually specifics of how to implement the technical safeguards.
There are nine technical safeguards, of which four are required, and five are addressable. Required safeguards must be implemented in any case; addressable safeguards should be implemented if it’s reasonable to do so. If you can’t implement an addressable safeguard, you need to document why and explain why you didn’t implement them - essential in case of a data breach.
While physical safeguards aren’t the topic of this article, keep in mind that you need to host your infrastructure at a HIPAA-compliant provider. Otherwise it's possible that certain technical safeguards could be bypassed by physically accessing the server. If you are planning an on-prem deployment, you need to follow the physical safeguards yourself.
Required Technical Safeguards
Let’s start with the four required safeguards. These are the minimum requirements you need to follow to be HIPAA compliant from a technical perspective.
Unique User Identification
Every user of your system needs to have a unique identifier. so that every action on the system can be traced back to the user who did it.
An easy way to do this is to use a universally unique identifier (UUID). Every major programming language has a library for creating a UUID. UUID generators follow standardized algorithms that create strings that are globally unique without the need for a centralized authority.
HIPAA-compliant managed authentication services, like AWS Cognito, will do this for you. A Cognito user pool will give every new user a unique ID on signup.
If you have to implement unique user identification yourself, you can find implementations of UUID here:
Emergency Access Procedure
You will need a way to access protected healthcare data in case of an emergency. Emergency, in this instance means, means something bad has happened to your system or app. For example, your power went down, or you’re under a cyber attack. In this case, the data needs to be accessible through an alternative means.
To implement this emergency access, you'll need to solve two problems. The first one is some type of off-site backup that lets you access the data even if your data-center burned to the ground. The second one is an alerting system that notifies you that an emergency is currently happening.
For a managed database, like Amazon DynamoDB, this means you need to activate point-in-time recovery for your tables. Once turned on, the last 35 days of your table data is backed up every five minutes, and can be restored.
If you define your table with CloudFormation, you only need to add two attributes for this:
Type: 'AWS::DynamoDB::Table'
Properties:
TableName: phiTable
PointInTimeRecoverySpecification:
PointInTimeRecoveryEnabled: true
For other prominent databases, you can find guides on how to set up backups here:
Audit Controls
Audit controls are all about logging who accesses the healthcare data. It works in tandem with unique user identification. If you get audited, you'll need to point the auditors to the audit log data to show them that everything's correctly tracked.
An easy way to do this is to have dedicated data storage for healthcare data, and log all access. That way, you can be sure that no developer forgets to implement logging when a new feature is added to your app. Also, you won't end up with too many audit logs when you store healthcare data alongside the non-healthcare data.
Another way is to implement event-sourcing. In this data-architecture pattern, you only save the changes in an immutable list and generate the tables on-the-fly. That way, three updates are actually three records in your event-sourcing database and not just the final result. You can see what happened to your data at every point in time and who caused the changes.
You can find information on how to enable access logs for prominent databases here:
Authentication
Keep all your users authenticated, so no anonymous access can happen to healthcare data. The best course of action is to use passwords and multi-factor authentication everywhere access to healthcare data can take place. If one of your users’ authentication factors gets stolen, for instance like an unlocked smartphone, they need to be able to prove they haven't subsequently accessed protected data.
Using a managed service like AWS Cognito can save you time because it's HIPAA compliant out of the box. Auth0 and Okta are very good managed authentication services as well, and they’re also HIPAA compliant.
For your own implementation, you find can find Authentication libraries for major API platforms here:
Addressable Technical Safeguards
Addressable technical safeguards represent the majority of HIPAA requirements, although a slim majority at 52%. Strictly speaking they're optional, but rather you should view their "addressable" nature as safeguards that allow some flexibility on implementation.
Indeed, you could either implement, find an alternative that accomplishes the same objective, or not implement. If you choose not to implement, you need to document why and probably consult an auditor expert/lawyer before going any further.
Automatic Logoff
Keep your user sessions as short as needed and log them off automatically. The basic idea is that if somebody leaves their device after logging in, it could be used by an unauthorized person. If you log your users off after they were inactive online for a minute or two, the chances are lower for unauthorized accesses to occur.
To get this right, you need to have to lower the session timeout for your API connections. Clients can request new session tokens automatically, so it usually isn’t that big of a deal as compared to a GUI application. With a GUI, the user would have to re-login manually.
Encryption and Decryption
All healthcare data should be encrypted and only be decrypted when needed. This means encryption at rest, like on your servers or your users’ devices. This also means encryption in transit when the data goes over the network. The reason for this is obvious — if the data is encrypted, stealing it won’t help an attacker.
While the encryption requirement stated by HIPAA is technology neutral, you should encrypt the data as well as reasonably possible. This means ROT13 isn’t enough, but a one-time pad is overkill. Check what the state-of-the-art encryption mechanisms your technology offers, and stick with that.
Again, managed services like AWS DynamoDB encrypt your data at rest automatically.
Your API should enforce SSL for all connections to conform. Use the strict-transport security header to inform your clients about using SSL. Don’t deliver any data if the protocol is HTTP, it should only redirect with HTTPS with the location header and a 3XX status code. Maybe, give some information in the body that "HTTP isn’t supported".
If you can’t encrypt the data, but there are other mechanisms in place that prevent access to it, you should document that.
Integrity Controls and Mechanisms to Authenticate ePHI
You need a way to be sure that healthcare data wasn’t altered or destroyed in an unauthorized manner.
This means you need to keep data integrity in check, for example, with a check-sum or a digital signature. If an authenticated user signs the changed data, any following changes by unauthorized users will be obvious.
To prevent unauthorized data destruction, you have to implement a backup that won’t sync changes that an authorized user hasn’t digitally signed. If a malicious user deletes data, it will either show up in the audit logs, or the delete won’t propagate to the backup.
Again, event-sourcing can be the solution. Since data is never implicitly deleted and all changes are logged by design.
How to Access ePHI Data From Other APIs?
If you’re already HIPAA compliant for your own data, third-party APIs aren’t a big issue, but if you’re not HIPAA compliant, it can cause additional costs.
When you want to use ePHI data from a third-party API, like EPIC, you also need to apply safeguards. Not all data delivered by an ePHI API falls under the protection of HIPAA, but if the data you request does, you need to implement it. This also includes the physical and administrative safeguards, which aren’t mentioned in this article.
How does Moesif Conform to HIPAA?
Moesif offers a secure proxy, which you host on your own infrastructure. This proxy will encrypt your data before sending it to Moesif and decrypt it before showing it to you, all done with your own private encryption key. The master encryption keys are never stored on Moesif servers; rather, the secure proxy supports popular key stores and handles key rotation automatically.
In the end, Moesif never sees your unencrypted ePHI data.
This approach is also something you can keep in mind for your own APIs. If a customer wants to send you their ePHI data, tell them they should encrypt it first, or offer them your own secure proxy they can host on their own infrastructure.
Summary
If you want to implement a HIPAA compliant API your best course of action is to implement all safeguards, even the optional ones. Lower your risks today and avoid uncomfortable technical and possibly legal problems later on.
Some of the safeguards are actually layered, for example implementing unique user identifiers will follow from standing-up authentication. The same goes for encryption and decryption, both are counted as separate safeguards but actually work together in practice.
Also, backups, authentication, and encryption are good practices that protect your whole business, not just the health-related data you might hold. So the chances are good that your API already has most of the safeguards in place.
You should also check out the managed services by cloud providers like AWS, Azure, or GCP. Often these providers already did the hard work to comply and you just have to choose resources with the right configuration.
Do you want to know how customers use your APIs? Try Moesif API Analytics!
This article was originally written for the Moesif blog by me.
