HHS Guidance: A Wakeup Call for Privacy in Healthcare
Advocate Aurora Health (AAH) recently notified its patients that their protected health information had been leaked with tracking tool vendors [Meta] because it had embedded the tools on its website and patient portals.
The leak affects over 3 million users, putting this privacy incident among the top three largest reported healthcare data breaches in 2022.
The pixel records identifiers like IP Addresses, Protected Health Information (PHI) data appointment details, type of appointment, medical provider information, and other sensitive data.
The Pixel fallout has expanded to more hospitals, including WakeMed Health, Novant Health, and Community Health. As per Markup investigation, one-third of the top 100 hospitals in the US share patient data with Meta pixel [Facebook]. This has resulted in patients and care providers suing the hospitals and forced the U.S. Department of Health and Human Services (HHS) to issue guidance on using trackers on hospital websites, portals, and mobile applications.
A knee-jerk reaction and solution would be to remove Meta's tracking pixel altogether from the websites and apps. While that is a starting point, businesses have legitimate reasons for marketing and advertising. These pixels could return to the websites and apps in a different avatar very soon. Plus, HHS guidance is much broader than just Meta Pixel, and it would make sense to look at the following:
- What data elements and their combinations are PHI
- What are tracking technologies
- Steps to comply with the guidance
The HHS's Guidance
Healthcare organizations [like hospitals, health tech startups, health apps, et al.] regulated under HIPAA may use third-party tracking tools, like Meta Pixel, to analyze performance across channels. What these organizations shouldn't do is use the tracking tools in a way that might expose patients' protected health information [PHI] to third-party vendors.
In the bulletin, HHS warned organizations that using tracking tools in patient portals could constitute a HIPAA violation. And if the data has to be transmitted, they must enter into business associate agreements [BAA] with the vendors of these technologies to ensure compliance.
The guidance further clarified that just a notice of pixel use does not permit PHI disclosure and that HIPAA-compliant authorizations for pixels are required.
Below are a list of data types HHS considers as PHI:
|Data Types||Data Elements||Is PHI||Reason|
|Online Identifiers||IP Address, Geo-Location Data, Device Identifiers||Yes||Linking the identifier with the portal is enough to know that the user is being serviced by the health provider.|
|Account Data||Unique User IDs (UUID)||Yes||It can't identify users with these, but if combined with other data where UUIDs were shared, it becomes an identifier for third parties too.|
|PII||Name, Email Address, Phone Number, National Identification||Yes||Linking the identifier with the portal is enough to know that the user is being serviced by the health provider.|
Unauthenticated Website Pages
Other than this, the following data elements are PHI and need to be tracked:
- Medical record number
- Dates of appointments
- Symptoms or health conditions
- Search for doctors or schedule appointments
While Meta Pixel is in the news, the HHS guidance goes beyond that to define tracking technology broadly as any script or code embedded inside a website or a mobile app that collects user information.
This definition is broad enough to cover most third-party scripts or SDKs in websites and mobile apps. HHS talks about the following kind of script or SDK as tracking:
- Cookies, Web Beacons, and Pixels: Used for advertising like Meta Pixel, LinkedIn Pixel
- Session Replay tools: Used for Marketing like Fullstory or Hotjar
- Profiling: Could even be Analytics tools like Google Analytics, Mixpanel, Amplitude
- Fingerprinting tools
This list is not exhaustive; from the guidance, it seems any third party gathering user's personal information is considered a tracker.
How to Comply with HHS Guidance
Get Visibility on Data Flows
1. Create an inventory of all user-facing products
a. Websites, including marketing websites
b. Web-Portals behind a login/signup
c. Mobile Applications
3. Map what data elements are flowing to each of these third parties.
You can do this data mapping exercise with your engineering and marketing teams to get this information. It will be manual, take a lot of time, and still might be inaccurate.
Alternatively, you can use Privado, a privacy code scanning solution, to scan these products and automatically get visibility on all your data flows.
Once you have the data flow, the next step would be to fix these issues in the code. Here are some examples you could use:
- Don't fire trackers on appointment pages or pages which could reveal the health condition
- Check the query parameters of your URL, for example: hospital.com/q?search='healthcondition'; either don't send them to trackers or fix the URLs
- See when all these trackers get initiated and remove some of these events altogether. For example, don't send a successful appointment event to Google Analytics
- Remove some of these trackers altogether
- Sign BAA with all of these trackers
If you want to operate digital properties like apps, portals, and websites where patients will visit and share their details, you need to comply with the HHS' guidance.
The path to compliance needs you to:
- Create up-to-date data maps to find out the vendors where user data is flowing.
- Ensure that all disclosures of PHI to tracking technology vendors are permitted by the Privacy Rule.
- Establish a BAA with the identified vendor that meets the definition of a "business associate."
- Implement administrative, physical, and technical safeguards in accordance with the Security Rule.
- Provide breach notification to affected individuals, the Secretary, and the media of an impermissible disclosure of PHI.
But even if you complete all of the above steps, the software development team at your organization will continue to push new code changes every other week.
This means that the data flow map you created to understand who is collecting user data and the list of third-party services linked to your product will go out of date quickly. These new changes might have a different set of third parties where user data flows or there might be some new properties where data is collected that can bring new PHI data flows to the online trackers.
To solve this, you need to take a proactive approach of ensuring all of these changes are compliant and not introducing a PHI data flow. This is also referred to as the Privacy by Design approach, and you can achieve this by running assessments of all software changes planned before they go live.
While this Privacy by Design approach looks perfect on paper, implementing it when you have too many changes becomes impossible.
If a new code change introduces a data flow to tracking tools, Privado prevents that change from going live, helping your company always comply with HIPAA.
Anuj Agrawal is a Developer Relations Engineer at Privado