Due to requests from a prospective client, we needed to research HIPAA compliance. I found a wealth of resources but what I could not find, however, was a primer that allowed software developers to get a bird’s eye view on this complex legal topic.
The solution? I decided to write one!
You can find the PDF at the end of this article. For this post, I want to explore some of the more vital basics, giving you an essential primer for HIPAA.
Why Is HIPAA Important?
HIPAA, or the Health Insurance Portability and Accountability Act, was created in the US to protect personal health information. It influences numerous areas – including software, apps and digital data storage – so it is something we needed to be aware of.
As I did my due diligence, it quickly became clear that, as is usually the case, the reality is far less scary and more nuanced than my original assumptions.
For starters, the technical requirements are only part of the wider HIPAA compliance regulations. So, let’s break this down into something that’s easier to understand.
(Before getting into the article further, please note: I am not a lawyer, but if you are going to sign a Business Associate Agreement (BAA), you should probably consult one!)
The Law
While there’s a lot to discuss, it’s important to remember that the letter of the law closely follows the spirit of the law. These rules were created for a reason. Specifically, HIPAA seeks to ensure Confidentiality, Integrity and Accessibility of patient data.
On a side note, these initial letters spell CIA, which is strong sign of how serious these rules are enforced in the US. Oddly enough, the gentlemen knocking on your door will actually be from the FBI. I guess they couldn’t create a good backronym for that, but they did create civil and criminal penalties for breaking the rules!
Nonetheless, it’s vital you keep this spirit in mind when learning about HIPAA, as there is no Compliance Certificate. Your adherence to the rules is decided by means of an audit.
As for the security rules themselves, there are two types outlined: required and addressable.
You have to implement the required ones in the way stated in the Act – this is pretty straight forward.
You have to implement the addressable rules as well, but you need to decide exactly how to do it. You also need to document why you believe your chosen method is reasonable for your particular situation. Additionally, all of your security standards, policies and procedures have to be documented as well.
Fortunately, even if you aren’t fluent in legalese, the source material (pages 62-73 provide a good general overview) is really not that hard to understand. If you need a little extra help, my PDF contains a glossary of the most commonly used terms, alongside a more understandable explanation of the rules.
It’s also important to remember that State laws still apply and some of them (California with its Silicon Valley, for example) have more stringent requirements than HIPAA when it comes to handling a patient’s data.
Understanding The Rules
Now then, let’s take a look at those rules in regular English, shall we?
First of all, the weakest part in any halfway decent security system is that there are people using it. This is why a large part of HIPAA’s Title II is dedicated to administrative and organisational safeguards against security breaches. They might not be the main focus of this post but you have to keep them in mind.
When working with Protected Health Information (i.e. patients’ information, or PHI), all employees of the company – regardless of access rights – have to know the company-wide security policy (e.g. what the PHI is and who can access it, as well as password policy) and follow it.
Since access to patient data will be only possible via computers that you will be developing the project on, access to said computers must be restricted as well, to the point of keeping visitor logs. This includes servers where the data will be kept if you use some hosting service and, contractually, they have to agree with the exact same rules that I am detailing now (with a BAA).
Should they occur, security breaches must be reported to patients, the media and state officials – and the language used to reach out to patients cannot be legalese.
Storing PHI: The Requirements
In comparison, the technical requirements appear to be much more straightforward and mostly fall under ‘Best Security Practices’.
- PHI must be encrypted both in storage and in transit. Furthermore, the use of email is strongly discouraged.
- You must have an audit trail in place. If the logs contain any PHI, they must be encrypted as well. They should also be monitored to check for security breaches.
- Access control requires unique user identifiers, a permission system regulating which parts of the system can be accessed (with a way to change the permissions) and automatic session terminations after a given time, or after a change of password. I think JWT (JSON Web Tokens) are a natural choice for implementing sessions.
- The system should be protected against malicious software. Keep in mind that, regardless of technical safeguards, it takes just one person to trust the call from the “Microsoft technician” who has detected an infection and needs to remotely connect to your computer…
- Data integrity is crucial and must be ensured. Checksums are a good idea here: they corroborate received data and help indicate if it has been tampered with while in storage.
- If you want to throw away a computer that had access to PHI, you either need to purge the storage media (such as exposing it to a strong magnetic field), physically destroy it (melting, pulverising, shredding etc.) or overwriting the media (rather than simply deleting or formatting the disk). If you want to retain the computer for other uses, the last option is clearly the way to go.
Now, that wasn’t so bad, was it? This is just an abridged version of the rules, but it covers the essential basics!
Meeting HIPAA Requirements
By now, you’ve probably come to the same conclusion as me. A large part of HIPAA’s rules have an administrative or organisational focus and require action on a company level, not on a software level.
Because the onus is on the company, not the tools, at best we can create software that has all the required safeguards. If someone says their service is HIPAA compliant, it usually means they can either be used in systems designed with this in mind or they are willing to sign a BAA with you.
Wrapping Up
HIPAA wants to ensure patient data stays secure and can’t be tampered with. For software requirements, as you can see, they often fit within the realm of “reasonable strict security”. You can select from a number of companies that will gladly offer their services and sign a BAA with you – for a premium, of course.
Yet, before you go on to develop that med-tech service that everyone needs and you earn many million of dollars – please consult a lawyer, just to be on a safe side.
Of course, this post just highlights my research and knowledge into the field. Soon, we will explore the practical side, detailing the AWS architecture for a hypothetical app that needs to be HIPAA compliant!
If you want to learn more, you can read our downloadable PDF here: HIPAA-guide.pdf (98 downloads)
Sources
If you want to do some more reading, I think it’s best to start with the actual sources:
* Official regulation text of HIPAA’s Administrative Simplification Title is, well, the source – even if it’s not the most riveting read.
* US Department of Health & Human Services portal on HIPAA offers a wealth of information and slightly less formal than the regulation text.
* In particular, the audit protocol serves as a good checklist to make sure that your company is HIPAA compliant.
* There is a wealth of resources from companies that offer consulting to ensure their customers’ HIPAA compliance. While I am not advocating for nor against using their services, I have used the resources available here and have found them very thorough and helpful.
