What It Takes To Make A CDP HIPAA Compliant
Here’s a warning: software companies you might end up evaluating claim they’re HIPAA compliant, but they're not.
At Freshpaint, we’ve worked hand in hand with health tech companies like Osmind and Two Chairs to build a truly HIPAA compliant customer data platform that helps manage the flow of PHI to downstream tools.
And at the core of this is ID Masking, our de-identification feature.
How does de-identification work?
To make sure ID Masking is HIPAA compliant (and I’m going to get a bit technical here), we use cryptographic hashing. Hashing is like encryption, but it’s designed to be irreversible.
But hashing alone is not enough to be considered HIPAA compliant. You need to hash with a secret key (a secret key is like a password).
That’s because hashing without a secret key makes your data susceptible to a dictionary hack where the attackers could use cross-referencing of datasets to identify the user. In other words, a potential PHI disaster.
The US Department of Health & Human Services explicitly calls out that you must use a secret key or “salt” to ensure proper handling of PHI:
“A code corresponds to a value that is derived from a non-secure encoding mechanism. For instance, a code derived from a secure hash function without a secret key (e.g., “salt”) would be considered an identifying element. This is because the resulting value would be susceptible to compromise by the recipient of such data.”
The must haves for a HIPAA compliant CDP
Freshpaint’s ID Masking cryptographically hashes user identifiers using a secret key, and when running HIPAA mode, we require information sharing server to server, so that key will never be exposed. This is the right way to build a HIPAA compliant CDP.
So, for a customer data platform to be HIPAA compliant, we need:
- A BAA
- If you're sending data to third party tools de-identification that uses cryptographic hashing with a secret key
- Must only share data server to server
What to look out for
So what should you look out for when you're evaluating vendors to help you build your customer data infrastructure?
Ask them how they handle data being sent to third party tools. We commonly see companies do de-identification without a secret key which is in clear violation of HIPAA when sending customer data to third party tools.
The other offender I’ve seen is when the code is built in a way that exposes the secret key. This is the same as not having the secret at all. Using that company’s software is going to expose you to HIPAA violations.
When evaluating tools to help manage your customer data, make sure you get more than “we sign a BAA” or “yes, we’re HIPAA compliant.” The details are key here.
If you have questions about keeping your customer data HIPAA compliant, reach out to us. We’d be happy to talk about it.