Server Side Tag Management & HIPAA Compliance

A recent statement issued by the Office of Civil Rights (OCR) at the Department of Health & Human Services, significantly expanded what’s considered Protected health Information (PHI). 

Most importantly, this directive puts direct onus on a covered entity under HIPAA to take measures to protect PHI from getting shared with third-party analytics and marketing platforms by way of on-line tracking codes commonly added to healthcare websites.

What are these expanded PHIs and how does server side tag management help support compliance while simultaneously making useful data available to marketing platforms that are essential for healthcare organizations’ growth?

Simply put, according to the new directive:

  • OCR now extends HIPAA protections to any online visitor who visits a healthcare website, not just a patient or a person known to your healthcare organization. 
  • If this visitor conducts any website pages that contain healthcare conditions, treatments or provider research, that signal could be included in the website’s URL.
  • The URL with health specific data along with the visitors’ IP address could now point to a past, current or future health concern of a potentially identifiable individual.

So any data that may link an individual with a past, present or future health or healthcare or health payment is now PHI. Importantly, this PHI is most likely being shared unencrypted with your third party analytics or marketing providers, such as Google, Meta, LinkedIn, DoubleClick and more, unless measures are taken to prevent it.

Server-Side Tag Management as a Solution to HIPAA Requirements

Server side tag management has emerged as a robust solution that can create a HIPAA compliant solution when implemented correctly. 

To reiterate this important point, server side tag management is not HIPAA compliant out-of-the box. It needs customizations to make it compliant while also passing on useful data events to third party analytics and marketing platforms.

What is server side tag management?

To explain in simple terms, most data collected by your healthcare website is sent directly to analytics and marketing platforms via online tracking code installed on your website. For instance, ePHI is probably being sent directly to Google Analytics servers or Meta servers or any other analytics or marketing platforms you are currently using.

By setting up an a server side container on your cloud provider of choice, you now become an intermediary between your website (often referred to as a client) and your third party analytics and marketing platforms.

Since you own this container and the server, you can now to three things to keep your ePHI data out of unwanted places:

  1. You control all data streams that originate from your website.
  2. You can cleanse and de-identify any ePHI that originates from your website
  3. You can send clean data to third party analytics and marketing platforms while keeping it useful enough to allow for campaigns and attributions to continue being useful.

Customizations in Server Side Tag Management to Allow for HIPAA Compliance

First-Party Data Collection & Data Control – Data collected by your server side setup allows for “first-party” data collection, making it more secure and efficient. 

Since your website visitors’ sessions-specific data is now sent to your own server, as opposed to third-party vendors’ servers, it provides more protection against data leaks, compared to client side tracking.

With the phasing out of third-party cookies by most major browsers, data collection will need to be rearchitected to depend on first party data collection. Server-side tagging provisions for more secure first-party data collection by enabling server-managed cookies and client identification that are less prone to hacks.

Finally, because all data streams are not collected by your server endpoint, you can have total control over data tracking, transformations and enrichment before it is sent to your analytics and marketing vendors.

Data Transformations & Enrichments – Let’s consider the HIPAA identifiers that are the greatest causes of concern for HIPAA compliance purposes. 

There are two types of identifiers, when mapped together, have the potential to connect an individual website visitor with a past, current or future health condition:

  1. A personal identifier, such as an IP address which technically can map to a specific network (it is not a device identifier but for HIPAA compliance purposes, IP is considered an identifier). Other personal identifiers could be a user id (if your website allows for patients to login, for instance, and you have enabled the collection of logged in users via ‘user_id’), device ID, especially when paired with an IP address, and sometimes geographical location, including city, state, latitude and longitude.
  2. Health information – The second type of identifiers are URLs that may contain static components of healthcare condition, treatment or payment for healthcare. As an example, if the url has the following structure:, technically, the URL has health information attached and when linked with a personally identifiable information, such as an IP address, violates HIPAA as it links a health condition (past, present or future) with a potentially identifiable individual.

In addition to static components of URLs, there may be dynamic components that may be passed from your web browser to your server container (in a server side setup) that may contain very transparent individual identifiable information, such as email addresses, names, etc. 

A server side setup allows for encryption for both components of PHI identifiers. However, complete encryption of this data may make your analytics and marketing campaigns unattributable and useless.

For instance, if you hash (a type of data encryption) the IP address of your website visitor, you lose all tracking of city or regional level data. Thus, you will be unable to analyze where your website visits, events and conversions are coming from – and that’s a big hit when it comes to geo-specific marketing campaigns.

Similarly, if you are running a retargeting campaign based on an audience profile that shows interest in a specific healthcare service, by hashing the page location, page path and page title of the page visited, you have rendered the retargeting campaign useless.

Server-side tagging however, allows for data transformations and enrichments that extend beyond simple hashing. 

Custom Activations – We create advanced custom audience insights based on PHI data streams received from web browsers. The custom data insights are then stripped of PHI and activated to be sent to third party vendors that allow us to continue marketing campaigns as envisioned but still keep ePHI out of outbound data streams.

For instance, to enable Facebook conversions tracking in a compliant fashion, we create custom conversion events on our client server container with non health specific conversion names. These conversion data events are sent to our secure server container, where we strip the event data of any ePHI by hashing all health information identifiers, such as page location, page title and page path. We then forward this stream to Facebook with a Facebook id, ip address and the conversion event but without any associated health information.

Similar solutions can be designed for other commonly-used marketing platforms, including Google Ads, and analytics platforms such as Google Analytics 4. 

Based on need, server side containers also allow for parsing information into database warehousing tools, such as Big Query, where data can be cleansed of PHI and sent as outward streams to third party platforms for marketing purposes.

A data warehouse can also be utilized for internal retention of data for custom data insights and enrichments. 


The Federal Trade Commission (FTC) along with the Office of Civil Rights (OCR) at the Department of Health & Human Services has issued warnings to several health care systems over the use of online tracking technologies in 2023. The healthcare analytics & compliance community expects the first set of enforcement actions related to online tracking to begin in 2024. This will intensify a series of class action lawsuits and settlements around sharing of protected health information with advertising platforms, such as Meta & Google, by at least 21 hospital, health systems and technology companies.

In light of rising concerns about privacy, in general, and protection of health information, in particular, server-side tagging offers a robust solution.

Contact our analytics team at Webtage to start a conversation about making your MarTech HIPAA compliant.

How to Make GA4 Web Analytics HIPAA Compliant

How to Make GA4 Web Analytics HIPAA Compliant 

In today’s digital landscape, privacy and data protection are of utmost importance. Covered entities under HIPAA (Health Insurance Portability and Accountability Act) need to ensure that they are taking the necessary steps to protect electronic protected health information (ePHI) while still gaining valuable insights from analytics. 

What are these identifiable ePHIs that may be collected from your website that may be introduced by third-party tracking code and may implicate you of HIPAA violations, according to the new HIPAA guidelines?

“When consumers visit a hospital’s website or seek telehealth services, they should not have to worry that their most private and sensitive health information may be disclosed to advertisers and other unnamed, hidden third parties,” said Samuel Levine, Director of the FTC’s Bureau of Consumer Protection. 

This article will deal specifically with ePHIs that may now make you non-compliant based on new risks introduced by online tracking technologies, as the Office of Civil Rights (OCR) at the Department of Human & Health Services (HHS).  In this article we will discuss ways to make Google Analytics 4 (GA4) compliant, considering that GA4 commands close to 89% of web analytics platform market share. 

After covering how to make analytics platforms HIPAA compliant, we will then move to HIPAA compliance for third-party marketing platforms, such as Facebook Ads and Google Ads in our next blog post.

Google Analytics 4 Settings

GA4 collects a vast range of user data to provide insights into user behavior on your website or app. Web URLs and IP addresses, for instance, contain valuable information about an individual’s online activities, including their browsing history and potentially sensitive healthcare searches that may link individuals with past, current or future health conditions, now considered protected health information.

While GA4, a positive upgrade for privacy concerns, compared to the earlier Google’s Universal Analytics (UA), makes it closer to being HIPAA compliant, there are additional steps that you need to take to ensure full compliance. 

We are mostly concerned with two identifiers recently added to the new list of 18 HIPAA identifiers: unique identifiers (such as IP address and client ids) and page URLs (such as page location, page path, page title, and query parameters that may contain health specific queris and/or unique identifiers). When the latter is combined with a unique identifier, it has the potential to link individuals to a health condition, treatment or payment.

There are a few steps you need to take to ensure compliance:

  • Redact email & query parameters – GA4 allows you to prevent sending email and any personally identifiable information (PII) to Google. This is a good practice in general because you do not want to send any personally identifiable information that can easily be mapped to their health-specific page visits and clearly violate HIPAA. Once you redact any PII that you might be collecting via query parameters, make sure you preview redacted data to ensure, GA4 does not contain any PII in the URLs tracked and stored by GA4.
  • Turn off user-id and user-provided data collection – If your website visitors can login to your website, you may be generating user IDs that may then be a personal identifier that can again be linked to health-specific services, conditions, treatment or payment pages to violate HIPAA.

If you do have the ability for visitors to login to your website, ensure user-ID and user provided data collection is turned off for your website. 

Note: Interested to learn more about user IDs? Here’s a great article that walks through ways to enable user-IDs so you learn how to disable it for your healthcare website.

  • Turn off Google Signals – If user data is not available, Google will map signed-in Google customers who have opted in for ad personalization with third-party data for rich user, cross-device and cross-browser tracking. This allows reporting identities to be linked to individuals and will therefore result in a HIPAA violation. 


  • IP anonymization – We know that Google Analytics collects IP information (though temporarily now under the revamped Google Analytics 4 (GA4)) when a visitor visits your website. The good news? GA4 automatically truncates the last 4 octets of your IP address so if your ip can not really be traced back to your network location. The bad news? Well even though your IP address is never really logged or stored, it is transmitted to allow for location data before it is discarded. To redact IP addresses completely, you will have to rely on server side Google Tag Manager setup. 

However, if you do not want to go through a server side setup, but want to be extra cautious, you may want to mask city-level data by turning off granular location and device data collection for regions you want to be compliant in. For HIPAA, it would make sense to turn off granular location off for all US states in order to make users’ locations even less identifiable. 

Note – As an aside, remember that IP addresses cannot track an individual device, only a network connection. However, other device specific data (referred to as a ‘user-agent’   variable, collected by GA4 may allow you to connect IP and ‘user-agent’ data to a specific device though.

  • Minimum Period for Data Retention – Ensure your data retention for events and users is set to its minimum possible of 2 months. This allows for your GA4 data collection to adhere to the HIPAA minimum necessary rule, which states that under “the HIPAA minimum necessary rule, HIPAA-covered entities are required to make reasonable efforts to ensure that uses and disclosures of PHI is limited to the minimum necessary information to accomplish the intended purpose of a particular uses or disclosure.”

  • Reporting Identity – Finally, for reporting identity under data display settings in your GA4 admin panel, ensure that you select device ID as the reporting identity, instead of the default Blended or Observed. 

Note that device ID combined with IP can still be a personal identifier, which when linked to health conditions, treatments or payment page location can lead to a HIPAA violation. However, with granular location turned off and IP addresses automatically truncated, this is less of a concern unless your legal department advises a stricter adherence to HIPAA, in which case, you should consider a server-side tag management setup (see below).

Server Side Tag Management

While the above settings will allow for some safeguarding against HIPAA violations, these measures are not absolute and fool proof in protecting your against non-compliance. More importantly, redacting data means that you might lose important elements from your attribution analysis or reporting. 

Instead, we strongly recommend a server-side tag management setup to provide you with greater control over your data streams, while also allowing you to safely navigate the third-party cookie free era that we are now entering. Most importantly, server side tag management can help you balance data anonymization (which inevitably leads to data being made less usable for marketing purposes) with usefulness of data. 

Learn more about server-side tag management security and control for HIPAA-compliance in our next blog post.

Alternatives to Server-Side Tag Management

A final word on alternatives for server side tag management. There are HIPAA-compliant analytics platforms, such as those provided by Adobe or Matomo that can be configured for HIPAA compliance. However, migrations to these platforms will require a cost assessment and additionally will require some ongoing management to keep your web & app data analytics HIPAA compliant.

There are also customer data protection (CDP) platforms, such as Freshpaint, Rudderstock, and PikWikPro, that allow for secure data storage, custom audience insights, customer data exports and custom activations and other advanced integrations that are required to keep customer data useful for marketing while keeping ePHI safe from third-party (and presumably HIPAA non compliant) platforms. While most offer a freemium service, HIPAA compliance usually comes with a price tag.


GA4 Settings adjustments, server side tag management, HIPAA-compliant analytics platforms and CDPs are all viable options for healthcare organizations and price points will differ based on number of applications or websites being managed, integrations with third-party marketing platforms, need for data warehousing, analysis & visualization capabilities, hosting provider, privacy & security needs, consent management needs and management.

At the end of the day, the difference between the solutions will depend on your risk tolerance and resulting comfort level with the tradeoff between anonymizing ePHI and usefulness of customer data for marketing purposes.

At Webtage, we take HIPAA requirements, along with technology stack, into account to determine the best HIPAA-compliant MarkTech solutions for your organization. Talk to us to discuss your healthcare MarTech compliance needs

Is Your Healthcare Marketing HIPAA Compliant – What to Know in 2024?

As medical practice owners, you understand the significance of protecting patient data and maintaining legal compliance while providing top-notch care. In this digital era, where information flows seamlessly across platforms, ensuring HIPAA compliance is paramount. 

HIPAA is not just limited to your IT and office operations. It also applies to your healthcare marketing operations. As HIPAA requirements evolve, so must your marketing efforts.

Most recently, the Office of Civil rights (OCR) at the US Department of Health & Human Services (HHS) issued a statement that warned of HIPAA violations with regards to online tracking technologies that are commonly used by healthcare websites & apps. According to the new HIPAA guidelines, identifiable electronic protected health information (ePHIs) may be collected from your website that are introduced by third-party tracking code and may implicate you of HIPAA violations. 

Online tracking may not be the only technology that may be exposing you to HIPAA violations. Here is a list of things your marketing team should be doing to keep your digital tech stack compliant in 2024.

HIPAA Checklist for 2024

Website & HTTPS Protocol – The use of HTTPS (Hypertext Transfer Protocol Secure) protocol strengthens your website’s security by encrypting data transmitted between the client and the web server by using Secure Sockets Layer or Transport Layer Security (SSL/TLS) convention. This ensures that patient information  submitted on your website browser remains confidential during online transmissions. 

However, it’s important to understand that while an https protocol protects data transmission from the client (your web browser or email client, for instance) to your web server, it does not provide end-to-end security for email transmission (more on this later). For that reason, you will need to enable a separate email security protocol to make data transmission from client to web server and back is secure and HIPAA-compliant.

Compliant ePHI Data Encryption & Transmission – Many medical websites have contact forms that allow patients & potential patients to contact them, set up appointments, complete patient registration, release or request medical records, and others. 

This contact form is typically emailed to your staff upon submission. It may also be stored in a database on your web server. You may also send a reply e-mail or SMS to the individual who filled out the form. So there are several data communication streams that are enabled when a contact form is filled and submitted on your healthcare website.

Even with an HTTPS site with SSL/TLS certificates in place, when this data is either stored in a database (at rest) or emailed to a recipient email address in your organization (in transit), protected health information (PHI or ePHI) may not be secure and expose you to a HIPAA violation.

To make it easier to understand, think of SSL/TLS as encrypting the communication channel. However, it does not encrypt the message. So when the email reaches the receiver’s email server, it can be hacked into and PHI can be retrieved. 

In order to be truly HIPAA compliant, you should either enable end-to-end email encryption by integrating S/MIME or a PGP Network, which should be built into your website or applications, along with SSL/TLS. Alternatively, you could set up a custom HIPAA-compliant application that encrypts data at-rest and in-transit while allowing for secure links that can then be shared via email or SMS with the desired audience.

Analytics Tracking – A red hot topic in healthcare marketing in 2024 is whether website analytics that you may have set up for your website and your marketing campaigns is HIPAA compliant. On July 21, 2023, the office of Civil Rights (OCR) at Department of Health & Human Services issued a warning to all hospitals and healthcare providers to guard against “impermissible disclosures of health information to third parties.”

What are these identifiable ePHIs that may be collected from your website that may be introduced by third-party tracking code and may implicate you of HIPAA violations?

Let’s consider Google Analytics 4 (GA4) as a reference point here to understand how Google Analytics tracking code could link a patient with a past, present, or future medical condition, considered protected health information. We know that Google Analytics collects IP information (though temporarily now under the revamped Google Analytics 4 (GA4)) when a visitor visits your website. They may visit treatment or disease specific pages on your website that may connect the individual with the regulated entity, i.e., your healthcare organization. As per the OCR, this “relates to the individual’s past, present, or future health or health care or payment for care” thus making impermissible PHI available to third party technology vendors, such as GA4.

As a healthcare technology & marketing company, we are erring on the side of caution while we set up GA4 for our healthcare clients. While GA4, a positive upgrade for privacy concerns, compared to the earlier Google’s Universal Analytics (UA), makes it closer to being HIPAA compliant, there are additional steps that you need to take to ensure full compliance. 

Server-side tag managers, customer data protection (CDP) platforms, and recommended analytics platform settings are some options available to make analytics tracking HIPAA-compliant. 

We are strong proponents of server side tag management setup that allows you control of your data and what is shared with third-party marketing platforms, thus meeting compliance requirements. And that’s not all, a server side setup also creates a first-party cookie context, improves your data collection, and allows you to circumvent ad blockers (although in the world of privacy-first world, we do NOT recommend circumvention).

Talk to us to see how we can customize your tag management setup to make your analytics and marketing pixels HIPAA compliant. 

Retargeting & Other Marketing Pixels – Another aspect of third-party tracking includes pixel codes, such as Meta Pixels or Google Ad codes that allow for retargeting of your top funnel audience to lead them closer to making an appointment or completing a purchase, is no longer HIPAA compliant. 

Just like web analytics code can relay and store impermissible & identifiable PHI, so can other marketing and retargeting pixels, such as Meta. Furthermore, like Go ogle, Facebook is not willing to sign a Business Associate Addendum (BAA), which is required to keep the covered entity and all its all business associates HIPAA compliant.

This unfortunately means that retargeting ads are currently out of bounds for healthcare organizations, unless PHI identifiers are transformed into anonymized data points before it reaches a third-party tracking or marketing platform. These PHI could be anything from IP addresses, page URLs that contain health information, including health conditions

This solution creates an obvious dilemma – the more anonymized the data that you send over to marketing platforms, the less useful that data becomes. For instance, a simple solution of redacting or encrypting HIPAA identifiers, such as IP addresses and page location/path/referrers that can connect an individual to a  past, present, or future health condition, treatment or payment plan also removes important data points that are needed to optimize or initiate targeted campaigns.

At Webtage, we are implementing server side tag management solutions that allow for creation of PHI-free custom audiences that are then sent to third-party marketing platforms, keeping marketing campaigns free of any HIPAA identifiers.

Social Media Compliance – Social media channels can be a landmine of non compliance covered entities under HIPAA, unless the channels are navigated carefully and cautiously. There are plenty of cautionary tales about healthcare social media marketing gone awry

Bottom line – you never want to post testimonials, pictures, before & afters, or any other information that may link a patient or even a prospective patient with their past, current, or even future health condition. 

If you plan to use user generated content (UGC) or your own content that contains identifiable PHI, do request a media waiver form to be signed by them prior to any social media posting.

Beware that even private messaging to your colleagues on social media will violate HIPAA unless you know for certain that those messages are encrypted end-to-end. Even acknowledging a social post from a patient by stating that your organization treated them or is going to treat them for a condition is a violation of HIPAA.

Some common precautions we take at Webtage is we require our healthcare clients to always have a Media Waiver form signed by patients before their faces, names or other forms of identity is released on social media or on the website. We also never add names of patients to testimonial posts or imagery. Rather, we simply add their initials, thereby removing any identifiers.

Remember that deliberate or thoughtless disclosures of PHI are both HIPAA violations and can result in distress, citations, fines & punitive actions. Work with a marketing team that understands the tightrope of protecting PHI while building trust and marketing your organization.

Review Management – When it comes to review management and HIPAA compliance, businesses in the healthcare industry face unique challenges. With the rise of online platforms and social media, publicly-posted reviews can have a significant impact on a healthcare provider’s reputation. However, it is crucial for these organizations to navigate this landscape while ensuring compliance with HIPAA regulations. This includes any information that could potentially identify an individual’s health condition or treatment.

Negative reviews can be particularly problematic in terms of HIPAA compliance. While businesses need to address customer concerns and feedback, they must do so without violating patient privacy rights. This requires careful monitoring and response strategies that prioritize both reputation management and adherence to HIPAA regulations.

Here’s the golden rule for maintaining HIPAA compliance on publicly-posted reviews. Even if the patient acknowledges that they are your patient, your response should not indicate a patient-provider relationship. In case of a negative review,, a healthcare accountable care organization (ACO) suggests the following:

  • Use neutral, professional language
  • Thank the reviewer for providing feedback
  • Stress that a great experience and patient satisfaction is of importance
  • Detail any changes implemented within the practice, if appropriate
  • Request that the reviewer contact the office if they have questions; however, do not acknowledge if the reviewer was or was not a patient
  • Never post information about a patient or their condition without their authorization

Business Associate Agreement (BAA) – A final word of recommendation. When working with a marketing technology (MarTech) or marketing agency, signing a Business Associate Agreement (BAA) with them is crucial for ensuring HIPAA compliance when handling protected health information (PHI). By entering into a BAA, your marketing providers agree to safeguard ePHI and adhere to HIPAA regulations. This agreement outlines the responsibilities and obligations of the provider, such as maintaining data security measures, reporting breaches, and ensuring compliance with HIPAA rules. 

For instance, while choosing an email marketing automation platform, look for those that offer BAAs to healthcare organizations to help them securely manage PHI within their email campaigns. By partnering with BAA-compliant marketing providers, healthcare businesses can confidently navigate the complexities of HIPAA regulations and protect sensitive patient data.


At Webtage, we are committed to helping medical businesses create compliant marketing and web technologies solutions that provide peace of mind while enhancing patient care.

Talk to us about our HIPAA-compliant web technologies, marketing analytics and digital marketing protocols that provide an end-to-end solutions for your healthcare business. 

Solutions we offer:

  1. Custom server-side tag management solutions for HIPAA-compliant analytics & marketing tracking  
  2. HIPAA-compliant applications that encrypt data at-rest and in-transit 
  3. HIPAA-compliant communication protocols for social media and review management platforms