Comply with HIPAA by masking or blocking PHI from going to destinations
Freshpaint provides several features to restrict and manage Protected Health Information (PHI) in your customer data.
Last updated
Freshpaint provides several features to restrict and manage Protected Health Information (PHI) in your customer data.
Last updated
Freshpaint's gives you full control over how you send data to your destinations. In this guide, we're going to show you how to configure your destinations to make use of HIPAA mode.
A destination is in HIPAA Mode if its connection mode is "Server-side" and HIPAA features are enabled.
Only destinations that support a server-side connection can be used in HIPAA mode.
You can change these options on the destination's configuration page. When handling PHI, you should always enable HIPAA mode unless you've signed a Business Associate Agreement (BAA) with the destination.
Because HIPAA Mode features are applied to events on Freshpaint's servers, client-side destinations do not support HIPAA mode. As a result, destinations where HIPAA features are enabled and the connection mode is "Client-side" are invalid.
When your account is configured for HIPAA, you default to restrict PHI from your destinations. To change this behavior, click the Configure button for HIPAA Settings and you'll see a modal pop up, like this:
Check the box next to Disable ID Masking and Enforced Allowlists only if you want to allow PHI to be sent to a destination.
Once you have HIPAA mode turned on and a destination configured to restrict PHI, you can use allowlists to manage what you can send. Click the HIPAA Allow List and you'll see a screen which looks like this:
You'll see three lists you can configure:
Event properties are ones which are sent with track calls. These include autotrack events and precision track events.
Click the edit icon to configure any one of these sets of properties, and you'll see an interface which looks like this:
You can add the properties that you'll allow to a destination. Once you do, only those properties will be sent. You can see that we've decided to use ID masking for the email property; it'll be sent in a form that is consistent for each unique email address, but from which you won't be able to determine what email it had been. The user_id property will be sent unmasked, meaning it will be clearly recognizable in the destination to which it goes.
Here you can choose to opt into which properties you can send to your destinations. These lists are saved to your ; a production and development environment may have different allowlists.
User properties are ones which are sent with from our SDK.
Group properties are ones which are sent with from our SDK.
