⚕️HIPAA Mode
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
HIPAA mode is a feature that Freshpaint provides to give customers full control over what Protected Health Information (PHI) is sent to their destinations. Freshpaint allows you to configure explicit lists of properties, called allowlists, for each of your destinations so you opt into what you send and how you send it.
PHI is the combination of Personal Identifiable Information (PII) and health information. Examples of PII include:
Names
IP Addresses
Non-anonymized user IDs
Emails
Examples of health information include:
Diagnoses
Treatment information
Medical test results
Prescription information
The Enforced Allowlists feature allows you to send properties classified as PHI to your HIPAA-compliant destinations, and send only non-PHI properties to non-HIPAA compliant destinations. Freshpaint does this by allowing you to specify a list of properties that are known to not contain PHI. Whenever Freshpaint sees a property that is not in this allowlist, Freshpaint will remove the property before sending the event to non-HIPAA compliant destinations.
Navigate to the Project Allowlist page to specify which properties are not considered PHI for your Freshpaint Project.
Properties allowed at the Project level will be automatically applied to all Destination Allowlists.
In addition to the Project Allowlist, each destination that supports server-side connection mode has its own allowlist.
In order for Freshpaint to be able to send data to the destination, you must allow each of the required properties. These settings will not affect any other destination.
For example, the Google Ads destination requires the $gclid
and conversion_label
properties. Without these properties, Google Ads will not be able to attribute conversions to your ad campaigns, so the destination will not be able to function.
Certain destinations have additional functionality that is controlled by certain event properties. Freshpaint indicates these properties as "Recommended" and describes the functionality they enable.
For example, to enable the Conversions Report for Google Analytics 4, you would need to allow the conversion
property.
In addition to required and recommended properties, each destination that supports server-side connection mode has a full allowlist, similar to the Project Allowlist. You can use this advanced feature if you need to add properties to the destination's allowlist that are not covered by the Required or Recommended properties.
All of the Required and Recommended Properties that you have allowed will be shown on the Destination Allowlist.
Add properties to the destination's allowlist if they're known to be safe to send to that specific destination. For example you may add the Facebook Ad Click ID to the allowlist for Facebook Conversions API in order to track conversions from your ad campaigns.
Required Properties, Recommended Properties, and Destination Allowlists are available in the latest version of Freshpaint HIPAA Mode. Contact support@freshpaint.io to learn more.
Freshpaint captures a number of properties automatically for each event, for example the URL of the page on which the event occurred. These are known collectively as built-in properties. You can use the PHI Allowlist to specify which ones are known not to contain PHI.
Built-in Property Allowlisting is available in the latest version of Freshpaint HIPAA Mode. Contact support@freshpaint.io to learn more.
Most of these built-in properties are documented under What Data Does Freshpaint Collect?. Special attention should be paid to URL, UTM Parameters, and Other Query Parameters. Suppose an event occurs on http://shoes.com/the/best/shoe?utm_term=shoes&page=2
. The following table illustrates the value of the $current_url
property under different allowlist configurations.
There are separate allowlists for user properties, which are attached to freshpaint.identify
calls, and for group properties, which are attached to freshpaint.group
calls.
ID Masking allows you to identify users in Freshpaint without sending the identifier to non-HIPAA compliant destinations. Freshpaint does this by hashing the user identifier before sending events to non-HIPAA compliant destinations. This anonymizes the user identifier, while still associating events with a single identified user and preserving functionality like identity resolution.
Here's an example. Suppose you identified a user by their email address:
Masking would send values like ada.lovelace@example.com
in a hashed form, scrambled in such a way that a reader at the destination will be unable to determine the original value. This hashing is consistent for a given value. If ada.lovelace@example.com
is hashed into iuUwhqIm1kEriZsVlu5TsGgX6/y5Pwfn
, then you can count on it being that value every time in your destinations.
ID Masking is automatically performed on builtin user identifiers for non-HIPAA compliant destinations. To turn on ID Masking for additional properties, you must configure the allowlist for your destination. Add the property you want to allow, then check the Hashed?
option.
Freshpaint uses the SHAKE3 hash algorithm for ID masking
Freshpaint's HIPAA mode requires your destinations be configured with a server-side connection. If one of your destinations only supports a client-side connection, you will not be able to use them in HIPAA mode.
You may want to send events to a non-HIPAA compliant destination without applying ID Masking or Allowlists. This might be the case when:
You want to send events to a non-HIPAA compliant destination that only supports Client-side connection mode, so you need to disable HIPAA mode to use the client-side destination.
Example: you want to send events to Hotjar, which only supports client-side connections.
You want to send events to a non-HIPAA compliant destination, and the destination needs the original user identifier, so you need to disable ID masking.
Example: you want to send events to your email marketing platform, and you need to preserve the user's email address.
To avoid sending PHI to a non-HIPAA compliant destination, you must restrict PII, health information, or both. Note that this restriction is scoped to all API calls made for a user. For example:
You attach PII (but not health information) to an anonymous user in a destination with a Freshpaint.identify()
API call
Later on, you send a Freshpaint.track()
API call containing health information (but not PII) to the same destination for this anonymous user
You're still sending PHI to the destination, since the destination has received both PII and health information for the same user, even though this information was received in different requests.
When determining whether a destination may collect PHI, it's important to understand exactly what metadata and properties a destination collects, and whether these metadata and properties contain PII or health information.
For example, the Freshpaint Bing Ads destination, when configured in client-side connection mode, collects IP addresses, Freshpaint event names, and page URLs (alongside other metadata). Because an IP address is PII, it's important to ensure the event names and page URLs collected by Bing Ads do not include health information.
If you're unsure whether one of your destinations is collecting PHI, don't hesitate to reach out to support@freshpaint.io.
And of course, you should always consult with your legal team.
URL | UTM Term | Other Query Parameters | $current_url property | Notes |
---|---|---|---|---|
Events may have additional custom properties beyond those automatically captured by Freshpaint, for example if you're using to add data layer properties to your events. You can use the PHI Allowlist to specify the custom properties that are known not to contain PHI.
http://shoes.com/url-redacted-by-freshpaint
When URL is not on the allowlist, Freshpaint will still send the domain name to destinations, along with a fake path that indicates the real path was redacted.
http://shoes.com/the/best/shoe
The domain name and path are preserved but all query parameters are removed
http://shoes.com/the/best/shoe?utm_term=shoes
The page
query parameter is removed.
http://shoes.com/the/best/shoe?page=2
Since Other Query Parameters are allowlisted, any query parameters that aren't UTM parameters are preserved, in this case, page=2
. The utm_term
query parameter is removed.
http://shoes.com/the/best/shoe?utm_term=shoes&page=2
The entire URL is allowed to be sent to the destination.