How Leading Healthcare Providers Level Up Their Digital Maturity

Are you talking about basketball? Well, I went to Michigan State, so… but my husband went to U of M, so yeah, he's pretty thrilled this week.

She's not going to be joining us on camera today, but Shelly, who works at ObservePoint — she runs all of our content — she actually won the ObservePoint March Madness bracket. And I believe she said she did not watch a single basketball game all year and basically just went off vibes. And yes, she won. And I watch a lot of basketball and did not come close to winning. So there you have it. If you guys wouldn't mind, let's drop where you're joining from in the chat. I'm joining from Pleasant Grove, Utah — quite pleasant right now in spring.

For everyone joining us today, thank you so much. My name's Ethan Prete. I run marketing at ObservePoint, and I'm thrilled to be joined by the Wheelhouse team. We are going to help everyone who joins today level up their digital maturity, especially as it relates to healthcare. These are very difficult and complex topics, but we're very lucky to have Emily and Mike here to make those simple. Emily, would you mind introducing yourself first?

Yeah, sure. I'm calling in from Michigan, just outside Detroit. I've been working with Wheelhouse DMG for 4 years this month as a front-end developer, and I took ownership of ObservePoint when we started using the software, which was about a year and a half ago now.

I'm dialing in from lovely Seattle, Washington — it's actually really nice and sunny outside, cherry blossoms are popping off. I am the Director of Marketing Sciences at Wheelhouse. I've been here almost 2 years. I lead our data and analytics practice, and my role is really helping healthcare clients figure out the what and the why behind their data strategy — making sure that the data we're collecting is compliant and accessible, and ultimately driving better marketing decisions. I'm excited to chat about this today. It's a topic that's near and dear to my heart.

Well, I'm glad that it is. I want to jump right in. Michael, I know you have a lot of thoughts, so I'm going to drill you with questions first to set the stage — then Emily, I'll bring you in for the implementation side. In terms of high-level pain points, Michael, I know there are a few different main regulatory areas that tend to trip up marketers in the digital space. Would you mind walking us through those?

Yeah, absolutely — and it's tricky being a healthcare marketer right now. There's a lot to comply with while still driving great results. So there are three major pain points. The first is the PHI via metadata rule — the idea that even if someone is anonymously browsing a website, their data can still become protected health information under the right conditions. The second is the BAA issue. Business associate agreements are what you do as a healthcare organization to make sure that anyone you share patient data with is under your chain of trust. The third — and the thing that ObservePoint really helps with most — is the concept of willful neglect. If you don't have a data governance practice to monitor your tracking scripts, you can be penalized by the OCR and HHS for essentially not knowing what you're collecting about users on your site.

It has never been more difficult to be a marketer, but particularly a marketer in healthcare. Those are the three to look out for. I'm just going to let you go, Mike, because this is an area our clients are constantly asking about.

This first rule — the PHI piece — catches a lot of people off guard. Most people think of protected health information as things like medical record numbers, names, phone numbers, addresses. That's true, but HIPAA identifies 18 different identifiers that could constitute PHI under the right conditions. Here's the nuance: things like IP addresses and device IDs are on that list of 18. Under HHS's current interpretation, if a tracking pixel like the Meta Pixel or Google Analytics captures a visitor's IP address while they're on a page about a specific medical condition — say, oncology or a symptom tracker — that combination of IP address plus page is now considered PHI. Think about what that means practically: if a patient Googles "breast cancer treatment options," lands on your service line page, and then a Meta Pixel fires — you've just sent that PHI to a third party without authorization. And companies like Meta and Google will not sign a BAA. That is why having visibility into each script firing on your pages is so critical. You can't manage what you can't see.

That's a great point. I remember kicking off a career in digital marketing about 15 years ago — you could set those pixels up anywhere and the scrutiny was a lot lower. A common misconception I've seen is that compliance and legal teams sometimes assume marketers are just being careless — but tracking all this technology is exactly why companies like ObservePoint exist. The next topic — BAAs — is one that can feel extremely intimidating. What can you tell our listeners about those, Michael?

BAAs can make or break how you're collecting data about customers — both from a third-party perspective and for the tools you use to gather first-party data. Here's the structural problem: under HIPAA, data only becomes PHI when you share it with a third party who is not under your chain of trust. Unless you've signed a BAA with them, you can't share that information. The elephant in the room is that if you're running Google Analytics or the Meta Pixel, those platforms will not sign BAAs — Google and Meta have been very explicit about this. And it's against Google Analytics' terms of service to send in anything that could constitute PII or PHI — they will deactivate your account. I've seen it happen. If you're running Google Analytics on your appointment booking page and that page captures any of the 18 identifiers in a health context, you've made an impermissible disclosure. That's a direct HIPAA violation — not gray area. That's why at Wheelhouse, we've helped our clients shift toward a first-party data strategy, working with tools that will sign BAAs — like Salesforce, Eloqua, or a CDP — so you can still make fully informed marketing decisions.

It is possible — and one of the main messages I hope comes across today is that you can have your cake and eat it too as a marketer. Too often at conferences I hear companies saying they can either track and get attribution OR be compliant — and that's just not the case. BAAs are not impossible; as long as you're being strategic, it's very doable. One more topic: I want to prime everyone on willful neglect. Every CFO I've worked with brings in an external party to audit the books. Why is it equally important to have something separate from your tag management to independently audit everything you're doing?

When it comes to willful neglect, we're getting into the space of governance and what you can prove. The OCR is really starting to crack down on client-side tracking scripts. The HIPAA security rule requires you to perform a risk analysis — you have to understand what's happening in your web ecosystem. Starting in 2025 and into 2026, OCR has officially made client-side script monitoring a priority of investigation. They're not just asking "do you have a HIPAA policy?" — they're asking "do you know what JavaScript is running in your patients' browsers, and can you prove you're monitoring it?" If you're failing to audit your scripts or enforce your own governance, it's now being categorized as willful neglect — the highest penalty tier under HIPAA security rules, starting at about $73,000 per violation, and it could be assessed per page and per incident. Relying solely on your tag management system is like asking the fox to guard the hen house. You need an independent third-party tool — that's exactly how ObservePoint fits into this ecosystem. You can demonstrate to regulators and legal teams that you're not neglecting this responsibility.

Emily, this is where you've built everything using the ObservePoint tool. I'd love to have you walk through the actual implementation. And for everyone — if you have questions, please drop them in the chat, we'll reserve time at the very end for Q&A.

The important thing Michael alluded to is that with ObservePoint, we're able to tell it what we expect to happen, and then ObservePoint tells us when things don't go according to our expectations — flagging it for us very immediately. That way we're able to respond quickly and determine if something unexpected is nefarious or allowable, and adjust our ObservePoint configurations accordingly.

That's a great point, Emily. I want to give everyone a quick picture of how we think about data flow for our healthcare clients. On the left side of the architecture are your first-party tools — your data warehouse, CRM, CDP, marketing automation platforms. Those are tools you own, that should be under BAA, where you can send the full picture of information, including PHI. On the right side are third-party platforms you need as marketers — web analytics, ad platforms, social media. These receive only limited, aggregated, de-identified, consented data. The key insight: this architecture only works if you can verify you're actually behaving the way you designed it. A developer pushing a new CMS template, or a marketing team installing a chat widget — any of those can introduce new scripts that bypass your carefully designed data flow. That's where ObservePoint helps.

At our core, ObservePoint is an automation tool. It lets you scan any website and see exactly how your site's responding — what scripts are loading, what cookies are being set, what data's being collected. We do that in two primary ways: audits and journeys. Journey monitoring lets you simulate real user flows — like appointment booking or patient portal handoffs — where compliance stakes are highest. Audits let you scan entire page sets for a complete view of every client-side script, tag, and cookie. One group we work with used our Initiator view and found 17,000 unapproved cookies on their website. They traced them back to a handful of initiator sources — YouTube being one — and were able to cut off entire chains at once. They're now down to zero. Michael, want to jump into journeys and alerts?

For sure. This is where the rubber meets the road, and Emily has set our team up for success. We have appliances in our tag management system that look for potential PII leaks and help us catch them before they reach third parties that are not under BAA. I'll kick it over to Emily to speak about how we configure these.

That's a good example of how Michael and I work together. He configures the tag management system to collect data compliantly, and my role is boots on the ground with ObservePoint — configuring it to monitor the collection and sharing of that data to give us confidence that the TMS is doing what we expect. I have some journeys set up with 20 steps navigating through a full user experience — we can emulate form fills, button clicks, page navigations. One example: I set up a test with a URL containing fake PII — a query parameter with an email and first name — and we're checking whether those parameters are stripped before data is sent. PII in URLs can happen from form submissions, CMS quirks, or third-party systems appending names or email addresses without you even being aware. We then attach rules to each journey step. If the rule is "make sure there's no question mark in this URL" — because that would indicate a query parameter — and it fails, we get a notification immediately and can investigate. It might not be nefarious, but we have the opportunity to look into it quickly.

And these kinds of query parameters can create PII and PHI more often than you might think. Things like internal search engines on your website — if somebody types a specific query about a health condition, that can create health condition strings that go into a URL query parameter and get passed to your web analytics platform. Free-text input can be a real trap. Some clients even go further and replace condition names in URLs with codes, so the marketing team still understands what content is being viewed, but the full URL with the medical condition isn't shared with Google Analytics or Meta. Those are things we can scan for with journeys and alerts and act on very quickly.

Moving on to notifications — these are one of my favorite parts of ObservePoint. I've worked with monitoring tools in the past where alerts are incredibly vague and you're not sure what direction to go. With ObservePoint, it's quite clear what has failed. We configure alerts to go to individual emails but also to dedicated client channels, so that when a rule fails, multiple people are notified in different ways. We want to make sure someone can respond immediately — I might not always be at my desk. Generally, I'm the first line of defense: I'll investigate the failure, and sometimes it's just a timing issue that clears on a rerun. If it's more severe, I'll loop in Michael and it might require a change to the tag management configuration. In the most severe cases, we go to the client directly — especially on larger websites where a team member may have made a change without realizing it would affect our compliance configuration.

Audits — this is a good one. I'd love to hear how you guys configured these.

Journeys are specific user paths, whereas audits give a much broader view. I have some audits that check just two URLs, and others that scan thousands of pages. One example is an audit of about 28 high-value URLs for our digital advertising team — we're simply checking for a 200 status code, because it's critical these pages have uptime. That audit runs twice a day so we know within 12 hours if something goes down. For less critical items, some audits run once a month for comparative data, and some journeys run twice a week. Cadence really depends on risk level.

It's a great question on cadence. We intentionally cover all different content types — disease pages, treatment pages, patient portals, donation pages — knowing that tracking scripts can behave differently across the site. Disease pages that are more susceptible to HIPAA violations might be scanned daily, while pages that are more of a marketing use case for uptime might be end-of-month checks. The other factor is being able to communicate with different stakeholder groups — both from a marketing measurement perspective and a compliance standpoint. The cadence is really determined by how sensitive each audience is to their needs. It comes back to making sure your most critical revenue pages have always-on monitoring.

We had a question come through: someone noted that Google reCAPTCHA is not HIPAA compliant unless you're using the enterprise version, because only the enterprise license includes BAA support. Has Wheelhouse seen this?

Yes, this has come up a few different times with Google — with embedded YouTube videos, their Maps widgets, and reCAPTCHA. All three of those Google products, by default, send tracking data to Google's servers about usage. We have scripts in our tag management libraries that allow that functionality to still run on your site, but prevent the outbound network requests to Google for tracking. So it is possible to block those pieces while still allowing users to benefit from the functionality — you can prevent that egress of data to Google and still have your cake and eat it too.

One of the biggest things we look for in audits is the sanctity of our data layer. One of the ways we get around HIPAA violations is pivoting to server-side tracking — and having all marketing measurements in your data layer becomes absolutely mission critical. As we remove client-side pixels from healthcare websites, we need to make sure our data layer is capturing everything from a first-party perspective. We're checking for things like session IDs, first-party client IDs, user IDs — data we can collect, but just can't pass to non-compliant third parties. We gather it in the data layer for first-party data stores and confirm it appears on the pages where it needs to appear. This isn't just a compliance play — it's also making sure we're gathering the right information to run performant marketing. We're not just checking whether a variable has a value; we can also check whether the variable even exists in our data layer at all, ensuring tracking uptime across all marketing touchpoints.

The Initiator Report is my personal favorite in ObservePoint. You can take a view like this back to your privacy and compliance teams and really show them you are doing what you say at every step of the user journey. It gives a visual tree of how different scripts execute on your website — what your tag management system is loading versus what's hard-coded into the page. It reveals a lot of hidden complexity; you may think you only have 5 or 6 MarTech tools, but most websites have a lot more. It also shows downstream network requests you might not have explicitly authorized. We had a real client case where everything in the TMS was doing what it should, but the marketing team embedded a YouTube video — and it was causing Google Ads remarketing pixels to fire that were not authorized. We detected it with the Initiator Report and were able to show the client exactly how to embed those videos without triggering Google tracking cookies. We could even take before-and-after snapshots to show compliance teams exactly what changed.

I've heard this about YouTube specifically at least 4 or 5 times this quarter alone — embedded videos causing initiator chains that are damaging to the compliance team. Very critical. The last feature I always joke is how people get promoted using ObservePoint. I had a handful of people corner me at our Sundance conference this year to say that because of reporting, they'd secured promotions or new jobs — because they could show their managers, compliance teams, and privacy teams exactly what they're doing, what they're automating, and how they're protecting the company. I'm a big fan of reporting. Michael?

The ObservePoint platform has great built-in reports, and it also has a fantastic API. What we're looking at here is how we bring data into our data visualization platform — we're currently using Amazon QuickSight — so we can bring in audit data from ObservePoint at scale across all our clients. We cross-reference compliance data against site performance. ObservePoint also captures data on Core Web Vitals and accessibility on a per-URL basis, so you can tie that to page performance and see where you have UX problems. We can look at whether slow scripts are driving down conversion rates or compromising accessibility. We report on all of that at scale with the ObservePoint API.

Thank you both. Michael, I want to give you a chance to wrap things up. In summation, what would you tell everyone listening today?

ObservePoint's journey and audit monitoring, combined with strategic rules and alerts, monitor for potential PHI transfers and help us redact offending things like URL parameters before they accidentally reach marketing platforms that are not under BAA. ObservePoint's scalable audits can also automatically check not just tag compliance and data layer issues, but consent preferences as well — helping you understand whether you're actually honoring cookie preferences by not firing certain scripts for users who haven't consented. The Initiator Report provides visual proof for legal teams of what client-side scripts are generating trackers. And the API enables custom integrations that work with your existing workflows. All of this to say: it is not impossible. You can set your analytics up in a way that doesn't compromise your visibility as a marketer while staying compliant. We've seen it time and time again with our clients, and we'd be happy to talk with anyone here about how to implement that for your organization.

We'll share both the video and slides in a follow-up email. Definitely find Emily and Michael on LinkedIn — they're fantastic. Check out wheelhouse.com and their resources page; their blog is awesome. Michael, Emily, anything you want to plug while we wait for questions?

In the back half of 2025, we published a big series called The Ultimate Guide to Martech — it looks at HIPAA-compliant MarTech categories and reveals the tools you should be using in each category, from cloud infrastructure to web analytics platforms to consent management tools. It also helps you understand which tools will and won't sign BAAs, and gives you the lay of the land for making informed platform decisions. I think it can really help folks who joined us today.

Someone's asking about BAAs specifically — we mentioned Salesforce and Eloqua. Is there a best practice for choosing one if someone's in the market?

That needs to be at the top of your list of questions when evaluating any platform — will they sign a BAA, and does signing one drive up the cost? Some tools only include BAA support at an enterprise tier. Generally speaking, CRMs and CDPs will sign BAAs — Salesforce will, Eloqua will from a marketing automation perspective. But I would say: do your due diligence, and make BAA willingness a top-of-funnel evaluation criterion.

Another question: "We recently launched Cookie Consent on our website and our available web analytics have dropped significantly. Have you had experience making the legal argument to include web analytics tracking as part of essential cookies?"

Great question. Our pivot to HIPAA-compliant analytics using server-side tracking means we can trim out pieces that would cause HIPAA violations — redacting IP addresses before data reaches Google Analytics or Meta, and in some cases not even sending a URL to advertising platforms so they wouldn't receive sensitive health condition data. We're sending the bare minimum those platforms need on the server side, with data encrypted in transit and at rest. That satisfies a lot of the HIPAA security arguments. But we can't give legal advice on consent categories — each organization needs to determine its own risk tolerance. What I'd say is: work very closely with your privacy and compliance team. You can sometimes win them over by demonstrating how you're limiting data egress. Jared also notes that GA4 applies behavioral modeling for Consent Mode V2 — so even if someone doesn't give consent, you can still send cookie-less pings that aggregate and anonymize performance data to help model the missing traffic. That's definitely worth looking into.

One more question on visualizations — what do you build in your external BI platform, and what resonates with stakeholders? And worth noting: ObservePoint just launched charting and is targeting dashboarding later this year. That may be all the questions. If I've missed anything, please reach out after. If you're attending Adobe Summit, come find us — we'll have games and would love to chat. We'll also be at the IAPP series in both the US and Europe, next up in Amsterdam, and I'll personally be in London in May. We also have Edge Europe. Thank you all so much for joining — we'll send out the follow-up with slides and the recording. Thank you, Michael. Thank you, Emily. And Happy Masters Weekend, everyone!

To be honest, one of the big value-adds of ObservePoint for us was their reporting head start over competitors. We're interested in bringing it into our data platform to merge it against actual web analytics performance on a page-by-page basis — looking at consent rate, Core Web Vitals, accessibility scores, and tying that to conversion rates and engagement. It doesn't have to be a big, sexy graphic — a well-organized table showing Core Web Vitals impact on landing page performance is hugely valuable. Reporting everything at scale with the ObservePoint API is amazing.

Awesome. Thanks, gang.

Thanks.