THANK YOU FOR SUBSCRIBING
If you are a US-based healthcare entity, and you electronically bill for your services, you probably fall under HIPAA regulations. HIPAA requires encryption to protect patient data. This article will discuss the key points of this requirement.
Encryption is scrambling data in a way that restricts access to that data, unless you have the decryption key. Encryption is a method by which we achieve confidentiality. Confidentiality means that only the people that are supposed to see the data, can see the data.
In US Healthcare, the Health Insurance Portability and Accountability Act of 1996 (HIPAA,) requires healthcare covered providers, payers and clearing houses to protect the confidentiality of patient protected health information (PHI). HIPAA is very clear that this is a requirement. So how does the HIPAA covered entity (CE) do this?
HIPAA defines two types of situations, data at rest and data in motion (across public networks.) For data in motion, HIPAA requires CE’s to encrypt the data across public networks. To do this, CE’s use SSL/TLS, VPNs, and Secure FTP. HIPAA doesn’t require one or the other specifically; however those are the three standard ways this is done.
For data at rest, HIPAA says this requirement is “addressable.” Addressable doesn’t mean you can do it if you want to do it. Addressable under HIPAA means that you will either do it, or you will find compensating controls, valid ways to secure the confidentiality of that data otherwise. Encryption is not something we worry about from a remote attacker (logical) perspective. Encryption is something that protects the data, even if you have physical access to the disk. Therefore, to meet this “addressable” requirement, we either encrypt the data at rest, or we have solid physical controls to prevent someone from gaining physical access to the disk. Ideally, if the data at rest is encrypted, even if someone had physical access, they couldn’t decrypt the data without the key. Without that at-rest encryption, we have to make sure no one can physically access the disk.
"Our ultimate goal is to provide world-class healthcare to those who count on us in their most vulnerable moments"
In order to encrypt our PHI, we use various types of encryption. If we have a website by which you can access PHI, we use SSL (or TLS today.) Without getting too technical, we use both public and private key encryption in this situation.
Public key encryption (asymmetric) is the use of two keys–a public key and a private key. The public key is, well, public. Anyone can get it. But the only one that can decrypt the data encrypted with my public key is me–why? Because I’m the only one that holds that private key. Hence the term–“private.”
HTTP, as we all know, is unencrypted. HTTPS is secure HTTP. The security is encryption. That encryption is done via SSL/TLS–public key encryption. So when you hit an HTTPS site, you’re using that company’s public key to encrypt the data you send them–they use their private key to decrypt it.
One thing that isn’t common knowledge is that your entire communication with that site is not done via public key encryption. That public key encryption is used to share a “private key.” That private (symmetric) key is then used to set up the remaining communications.
Private Key is the use of one shared encryption key between two parties who wish to communicate securely. In the case of the website, once we’ve shared that private key, we (my browser and the website) use that to pass secure traffic back and forth.
Private Key encryption is also used in secure file transfer (SFTP), VPNs, and others. Private key encryption is faster than public key, because it allows bulk encryption of the data. This basically means that the encryption algorithm doesn’t encrypt bit-by-bit but encrypts with bulk encryption–larger blocks of concurrent data.
From an organizational standpoint, HIPAA covered entities must, first and most importantly, perform reasonable IT risk management. In the risk management process, we assess if the data encryption meets our organizational requirements around encryption, at rest and in motion. We must know if that data is being transmitted and/or stored in a way that meets the compliance requirement.
But encryption has some downsides. It can be slow, hard to use, and expensive. We not only have to be HIPAA-compliant, but we have to be able run our healthcare operations cost-effectively and operationally-sound. We must have the expertise on staff to not only assess our requirements for a particular solution, but to also deploy those in a way that not only meets regulatory muster but also operational requirements.
The industry has come a long way in making encryption transparent. We can now encrypt our Storage Area Networks (SAN)–we can encrypt our user’s desktops, both in software and hardware. Our challenge is in meeting regulatory compliance while also ensuring our business can run, and that we can efficiently serve our customers, the patients.
Encryption of PHI is a regulatory requirement. We must truly understand what that means, what that entails, and how that impacts us from a budget and operational perspective. If we understand this, we are better prepared to help our organizations meet the HIPAA requirements but also ensure our healthcare operations continue to function. Our ultimate goal is to provide world-class healthcare to those who count on us in their most vulnerable moments.