Privacy First: Healthcare Privacy Platforms vs Generic CDPs

Customer data platforms (CDPs) are an excellent choice for data management in many industries. But healthcare isn’t one of them.

The culprit lies in the way generic CDPs govern Protected Health Information (PHI) and manage the data flow to advertising, analytics, and other martech tools. Without proper PHI governance, you’re opening the door to potential HIPAA violations.

Healthcare privacy platforms, however, have the guardrails in place that allow you to be HIPAA compliant by default.

To help you make a more informed decision, we put together a list of the key differences between generic CDPs and healthcare privacy platforms.

The differences between a CDP and a healthcare privacy platform

Unlike healthcare privacy platforms, CDPs lack the technology needed to de-identify user data and prevent automatic data sharing. 

Here are the three key differences that make healthcare privacy platforms a HIPAA-compliant choice.

1. Encryption vs cryptographic hashing

The first difference between CDPs and healthcare privacy platforms is their approach to PHI masking. Most CDPs use encryption while healthcare privacy platforms apply cryptographic hashing.

This might sound like something out of The Matrix, so let’s break it down as simply as possible:

For the purposes of HIPAA compliance, the most important difference to remember is that cryptographic hashing is irreversible. Encryption is not.

This means encryption is inadequate to protect PHI.

And as far as the HHS is concerned, encrypted PHI is still PHI – even if a cloud service provider doesn’t have access to a decryption key.

Note that hashing alone also isn’t enough for HIPAA compliance. You need to cryptographically 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.”

Cryptographic hashing, however, irreversibly de-identifies the PHI before forwarding it to a third-party tool like Google Analytics. This helps to ensure HIPAA-compliance.

Let’s use Freshpaint’s ID Masking feature as an example.

If you identify a person using their email (john.taylor@example.com), cryptographic hashing will scramble this value with a secret key into iuUwhqIm1kEriZsVlu5TsGgX6/y5Pwfn. The Freshpaint platform sends the scrambled value to a given destination, without exposing any PHI. The value will stay the same for this user, which allows you to track their journey while complying with HIPAA.

2. Always-off vs always-on data sharing

When you switch on a CDP, it automatically starts sharing data with different destinations. Normally, this wouldn’t be an issue. 

But since you’re a healthcare organization, forwarding IP addresses and other PHI to third-party tools puts you at risk of violating HIPAA.

A healthcare privacy platform takes the opposite approach. It doesn’t share any data until you choose to do so. Freshpaint’s Safe By Default approach, for example, doesn’t send any properties (user, event, or group) to a destination unless they’re on an allowlist.

Here’s what an allowlist looks like for event properties:

Legal and security teams can select which data to share from a centralized dashboard. This information remains easily accessible in a single view so there’s no confusion over the data you’re sharing.

3. Server-side connections vs client-side connections

In the context of web tracking technologies, a client-side connection means that the tracking pixel loads on the visitor’s device when they visit your website. The pixel then collects the data you need for analytics and advertising, and directly forwards it to the destination.

Instead of client-side connections, HIPAA-compliant web tracking requires server-side connections, because they cut off ad and analytics platforms from access to PHI. 

How does this work?

The user data isn’t sent directly to third-party destinations, but is first forwarded to the servers of a healthcare privacy platform. Then, it de-identifies the data before sending it to the destination.

Most importantly, healthcare privacy platforms take server-side support a step further. They’re able to use server-side connections that protect PHI without damaging the quality of data. 

That’s different from the standard server-side destinations of generic CDPs because they don't provide the same data and functionality as the client-side native pixels. That effectively renders rendering your downstream tools useless if you’re trying to use it for HIPAA compliance. They may make you safe but won't feed those tools the data you need for your analysis.  

And if you need another reason to implement server-side connections, you should know that browsers have been increasingly limiting client-side trackers from collecting data for privacy reasons. For example, Apple’s browser, Safari, automatically blocks website trackers. 

Server-side tracking through a healthcare privacy platform allows you to circumvent these blockers and get the data you need to measure website and advertising performance.

The details matter

When you’re evaluating vendors to help build a HIPAA-compliant customer data infrastructure, among all the other questions you need to ask, focus on a few details:

1. Ask them how they handle data being sent to third party tools. We commonly see companies do de-identification through encryption or hashed without a secret key. Both are a clear violation of HIPAA when sending customer data to third-party tools.
2. The other offender we’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.
3. Make sure they’ll sign a BAA at the price level you’ll be paying them. Some CDPs and other data processors will only sign a BAA if you spend a certain amount of money with them.

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.

How a mental healthcare platform created a HIPAA-compliant tech stack

When therapy platform Two Chairs was evaluating different CDPs, one of the company’s priorities was to find a HIPAA-compliant solution.

Scotty Abramson, the Director of Growth at Two Chairs, says “HIPAA compliance is hard. How can we maintain our visibility to understand and make the [user] experience better, but then also maintain and protect [user] privacy and identity?” 

The team ultimately found a solution in Freshpaint. 

Watch the video below to learn more:

Mark Rogers
Director of Content Marketing

The original version of this page was published at:  https://www.freshpaint.io/blog/healthcare-privacy-platforms-vs-generic-cdps?utm_medium=paidsocial&utm_source=martech.health&utm_campaign=martech_product_profile