Skip to content

Episode 05: The Path to a HIPAA-Compliant Data Solution

Hosted by Aaron Burnett with Special Guest Paul Weinstein

In this episode of Digital Clinic, guest Paul Weinstein, General Manager at Wheelhouse DMG, dives into the complex world of HIPAA-compliant data solutions. The discussion covers the tightening of privacy regulations and how healthcare organizations can maneuver these difficult changes by developing a platform-agnostic approach.  

Aaron and Paul further explore the key components of a successful HIPAA-compliant data analytics framework, emphasizing the importance of leveraging first-party data and working with experienced partners who can help organizations understand their technology stack and unlock the potential of their data while maintaining compliance. This insightful conversation provides valuable guidance for healthcare marketers seeking to balance the demands of data-driven decision-making with the critical need for patient privacy protection. 

HIPAA Privacy Regulations & Achieving Compliance

Welcome to the Digital Clinic, the podcast that goes deep on critical digital marketing trends, strategies, and tactics for the healthcare and medical device industries. Each episode brings you expert guests sharing the knowledge, insights, and advice that healthcare marketers need to be successful in this complex and rapidly evolving digital landscape.  

Aaron: I’m Aaron Burnett, CEO of Wheelhouse Digital Marketing Group. Joining me today is Paul Weinstein, who is General Manager at Wheelhouse. Today’s episode will be a little bit different. Paul and I were having a conversation on how we have developed a platform-agnostic approach to HIPAA-compliant analytics and how that approach has evolved over the past 18 months since the new guidance from the OCR came out around HIPAA compliance and the use of digital tracking technologies. It was a really good conversation that I thought would be useful to other people who are considering their options, thinking about sort of mental and technical framework to consider those options and the way that they can think about leveraging the technology that they already have differently, augmenting it and refining it and utilizing it to develop a really compelling approach to HIPAA-compliant analytics. So, we turned on the cameras, we turned on the microphones, and recorded this episode for all of you. I hope it’s helpful.  

Let’s talk about privacy regulations, HIPAA in particular, and the platform-agnostic approach to achieving HIPAA compliance.  

Paul: Yeah, well, we’ve been doing this a long time. When we started, we had been helping one of our largest healthcare clients solve for what they saw was this impending compliance risk with web analytics. Through that, we solved it utilizing technology that this client already had, it was Tealium at the time, essentially giving them control over the data they were collecting, how they were treating it, and with whom and how they were sharing that data. That project basically created the foundation and the basis for a framework that we’ve now got, to be able to solve this problem with a variety of means and methods and technologies.

What we’re able to do now, based on having done this multiple times with different kinds of technologies and understanding – also, technologies are starting to evolve and kind of come to the table now that they understand that, “Oh, we’ve got to really give our users, our clients, our customers more utility and more control in a compliance situation,” – now there’s more opportunities, and this has evolved even in the last few months, as well. It’s moving quickly, and as we continue to help clients and be exposed to not only their situations but also the vendors that they’re working with, we’ve just come to understand that there’s a multitude of ways to solve this. This isn’t about buying a tool or a platform or a technology to replace your analytics or to make it compliant. This is about taking control over the data you’re collecting, how you’re treating it, processing it, de-identifying it, and who and how you’re sharing it. That’s the crux of what we’re doing here, and everything else is just a different way to do it.  

Aaron: Yeah, I know we, initially, in the couple of months after the OCR guidance in November of 2022, came to market with what we thought was our version of a platform. This is our solution, and we marketed it in that way. As other technologies, as other solutions and options evolved, and as we talked and worked with lots more clients, we did begin to understand that we actually have a framework. We have an approach, and actually, if we serve the clients and their interests best, then we should be invoking different ingredients within that framework, in the manner that works best for them.  

Paul: Yeah, and what’s really true here is what we can do. What we do with this framework is we meet the client where they are. We meet them where they are with their own position on compliance, what their interpretation is of what it means to be compliant. We meet them where their technology stack is. We meet them where they are in their marketing campaign complexity and measurement and all of that. As we’ve looked at and been solving this, there are ways to solve this that are good for maybe a smaller system, a less complex kind of system, with fewer moving parts, maybe they don’t have as big a budget. But, we can solve it in a less complex, more affordable way. Then, all the way to the other end, there’s the enterprise version, this vertical stack version, where we can use tools that, in many cases, these organizations already have. In some cases, these same platforms are becoming more compliant. They’re signing BAAs for more parts of their own stack, so as they’ve kind of come to the table in that regard, more opportunities are opening up for us to be able to utilize those same platforms to achieve the same thing.

Again, it’s always the same thing – take control of the data you’re collecting, how you’re treating it, obfuscating it, de-identifying it, hashing and salting – all those kinds of things. Take control of that, your ability to process the data, and then where and how you’re sharing it. It’s not what you collect, it’s what you share, right? You can collect all the data that you want and send it to your own HIPAA-compliant cleanroom, first-party data warehouse, Snowflake, CDP, CRM, but you have to be very careful, very deliberate, and highly controlled in what you share with Google or Meta, if you choose to share something with Meta, or any of the other third-party platforms that you might be needing to activate but aren’t going to sign a BAA. 

HIPAA-Compliant Data Solution Framework

Aaron: Right. Yeah, so the key there is, it’s not the issue of collection that’s problematic. As a covered entity, you can collect whatever you wish. You can collect full fidelity data on a visitor to your website, including IP address, the pages that they visited, forms they filled out, and all sorts of things. It’s the act of sharing with an entity outside of your data infrastructure that isn’t under BAA that’s problematic.  

Paul: Absolutely.  

Aaron: Okay, so let’s kind of go through the ingredients for the framework. 

Paul: Absolutely. Again, there’s three parts of it. First is taking control over the data that you’re collecting. What we’re talking about here is, up until this point, we’ve been putting pixels or tags on client-side, the browser, and collecting and basically giving say, Google, the ability to decide what it collects and how and what it does with that. 

Aaron: That’s sort of the royal “we,” that’s not us. 

Paul: No, that’s not us, that’s third parties. We’ve been putting these third-party pixels on our sites. Those pixels are not controlled by us, not controlled by the covered entity, the healthcare system. They’re controlled by Google or Meta or whoever. Essentially, what the OCR guidance did is they just said, “Listen, that’s not compliant, unless that entity has signed a BAA with you, and you’ve defined and determined what information they’re going to take, how they’re going to use it, and all the rules that would go into a BAA. You can’t do that.” Well, 97% of the healthcare systems in the U.S. have some form of Google Analytics or Google Tag Manager on their site. They’re all immediately out of compliance. The immediate reaction was, “Okay, let’s rip out all these pixels and all these tags, turning the lights off.” Well, the first part of this is essentially moving that collection from being client-side to server-side. Essentially, what we’re doing is, instead of having this pixel directly connect to the third-party, we’re abstracting that, and we’re doing the collection through a server-side connection, which then connects back to that third-party via API, which we can control. The key here is gaining control over the data we’re collecting, sharing, and sending.

In this case, the first element is shifting the collection from being a client-side implementation to a server-side implementation. That can be done in a number of ways. Again, from a platform-agnostic kind of view of this, which is kind of what we’re talking about, you can do that through a server-side implementation of GTM. This again was something that kind of Google added the capability to do transformations within GTM in the server-side context last summer, and so that opened up the opportunity to then use this more, we’ll call it, less complex implementation of GTM server-side. The next version of that is say a Tealium IQ. T IQ is Tealium’s tag management, and using that mechanism, again, deployed server-side to be able to collect the data. What we’re doing is, instead of relying on the third parties’ own libraries, we’re creating our own. What we’re doing is, we’re working directly with our clients to build a bespoke library of all of the different types of data that we’re going to be collecting. Again, that can be quite comprehensive. It doesn’t have to be super tight, but we’re basically deciding what we get to collect, and then we get to decide where it goes and how we treat it from there. Then on the enterprise spectrum, you’ve got Adobe and other means of collecting that are going to be on that enterprise, more complex, implementations of this. 

Aaron: A couple of things to note here. One, on the Google Tag Manager side, I think an important change, aside from transformations, is that you can implement Google Tag Manager in your own private, HIPAA-compliant environment. You can implement Google Tag Manager in Azure or in AWS, and you can do so in an environment where a BAA has been signed, and that’s HIPAA-compliant. Google, other than providing the tag management technology, isn’t involved. Data doesn’t pass to them until there’s a server-side connection. 

Paul: Right. There’s actually three different ways to implement GTM server-side. One is through Google Cloud. You can implement it on Google Cloud, you can sign a BAA with Google Cloud, that BAA is tantamount to a checkbox on the EULA agreement, they’re not going to negotiate their BAA, and essentially their BAA is going to say, “You agreed to not to send us any PHI.” That’s one way to do it. 

Aaron: There’s an interesting aside in the most recent OCR guidance that came out on the 18th of March, where they actually say, “A BAA that specifies that a third-party is not going to receive PHI is not a valid BAA,” which is sort of our position as well. 

Paul: Yeah so, depending on your interpretation, you could decide to do it that way. It’s not what we recommend. The other two are, again, say, your own Azure instance or on a HIPAA-compliant AWS instance. Either of those you could do as well. But again, we’re installing GTM. Basically, it’s the appliance that we’re installing. It’s not GTM as you think about GTM in a client-side context. Basically, we’re installing the program on the cloud, we have control over it, Google’s not collecting anything that we’re not deliberately sending to them.  

Aaron: Yep. That makes sense.  

Paul: Again, that’s the first kind of step, taking over the collection of the data. The second step is then taking control over how you’re treating the data. By treating I mean, transforming it, de-identifying it, hashing it, and deciding which attribute you send and which you don’t. In some cases, if you’ve got a mix of compliant destinations and non-compliant destinations, you may want to have a particular attribute in its full fidelity, or in a hash or obfuscated version of that same attribute, so that you can send the de-identified version to a non-compliant destination and the full fidelity version to a compliant destination, your own reporting infrastructure, that data hub, which in the GTM context is the transform capability that Google added. In a Tealium context, that’s EventStream. Then, Adobe’s got its own version of that same appliance, which gives you control over where data is sent and how you control it. This data hub acts as that central control switching mechanism, if you will, to decide what’s sent, in what form, to what destination. That’s the second element. Again, there’s multiple ways to do that. You can do GTM, you can do Tealium, you can do Segment, you can do Adobe, there’s lots of different ways. You just need that ability, that utility of being able to transform, obfuscate, and hash the data at an attribute level, so that you can then decide where it goes and in what form.  

The third element is, in a server-side context, you’re basically connecting to these third parties via API. Through that API, we can decide what is sent at a granular attribute level. We can decide which version of that attribute that I just described – where we have the full fidelity version or that de-identified version – it’s in those connections and how we connect to them and how we specify and configure those connections with each individual destination that we can decide, “Okay, for this destination, we’re going to send this particular attribute in its full fidelity because it’s not, when combined with other personal information, deemed PHI.” But in some cases, we may choose to send a conversion pixel and a one or a zero, a conversion flag, back because that’s either all we need from an advertising perspective or all we want to send from a compliance perspective. In either case, we’ve got the control, by virtue of the implementation of the tools I described, to be able to decide. What we’re doing, and how we approach this with our clients is, we’re working in very close coordination with multiple stakeholders on the client-side. We’re working with the marketing folks to understand what their marketing goals are, what their measurement objectives are, what are the things that they were doing that they’d like to get back? They can’t get it all back, at least not in a third-party sense, from Google Analytics or Google AdWords, because we’re going to be sending less data, but maybe in a first-party context they could.

We’re working with the marketing team to deeply understand what their marketing objectives are and the different types of campaigns they run and the way that they build and activate audiences and all that. We’re also working very closely with the technical team in the enterprise architecture teams to understand their own tech stack and the capabilities that they might already have within it. In many cases, when we show up, they already have some of the capabilities we need to give them the control to allow them to be compliant. In those cases, we may show up and somebody might already have Segment as part of their stack. We can leverage this tool that they’ve already invested in, that’s already a part of their own MarTech stack, to be able to give them that control and become HIPAA-compliant, without having to buy this other platform for this other utility that maybe they do or they don’t meet. A key part of our process is really deeply understanding, again, showing up where the client is, going to them and saying, “Okay, well, what do you already have, and how can we use that and leverage it?” In some cases, we do have to add utility to the stack, but we’re only adding the specific utility that you need, not any more than that unless there’s some other business reason that the client might have to do so. 

Aaron: Right. You mentioned that, in most instances, when a solution is implemented, a solution that we have helped to enable and design is implemented, that by definition, we’re sending less data to advertising partners. We’re sending much less data to a Google Analytics, as little as possible to Meta, and similarly to other advertising partners. So then, how do we work with our clients, and in particular the marketing team, so they can continue to drive performance with such truncated data?  

Paul: Yeah, absolutely. One of the things that we’ve been doing for the past year is we have clients that have no data that we are responsible for advertising. We’ve actually been operating in a context where the lights are out.  

Aaron: These are the people who ripped it all out.  

Paul: They’ve ripped it all out. I mean, that was the decision made by compliance for a reason, in the absence of a better solution. “I’m just going to rip the pixels out, and marketing you’re just going to have to do the best that you can.” In this situation, that was us. What we’ve been able to do is, getting creative and finding those other sources, those other signals that we can use to help us figure out what’s working and what’s not. When you shift into a HIPAA-compliant analytics solution, out of the gate, what’s true is you’re going to be sending less data to these third parties that you’ve been relying on for a long time. Ostensibly, these free tools have never been free. These free tools came at the cost of privacy, and they came at the cost of compliance. In order to rectify that, we have to send these same free tools less data. What that means is they’re going to have less data to report back to us for us to be able to use to enable targeting, reporting, analysis, understanding user behavior, all of those things. Depending on the tool, depending on the proclivities of the compliance point of view for the organization, we’re going to be sending varying degrees of information back to these third parties, which then means we’re going to get a good degree less back from them. What that means now is, again, it’s not what you collect, it’s what you share. We can collect full fidelity, first-party data. Step one is to be compliant. One way to do that is to rip out tracking altogether.

Step two is to get some semblance of tracking back, turn the lights back on, we call it a dimmer switch. It’s not going to go all the way to bright, but we’re going to be able to turn the lights on a little bit so that we’re not fumbling around in the dark so much. Then once you’ve got that, and we’ve got some of the signal coming back in terms of, “Yes, this ad is converting,” or “This creative is working,” or “This placement is working,” then we can start to think about how do we get more information, more fidelity? The answer is the data that you’re collecting yourself. We’re collecting all this data, and if we’ve got our own first-party data warehouse, cleanroom, CDP, etc., we can utilize that first-party data in a compliant way to be able to get, for certain, a much more detailed view of what’s happening in terms of user behavior, conversion behavior, and all of that. We can also, to a certain degree, start to use that to help us with audience creation and targeting and the like. The answer to the next phase is: first phase, get compliant; second phase, turn the lights back on, but it’s going to be dimly lit; the next iteration is a first-party data strategy. It’s one where, “Okay, we’re actually leveraging all the data that we’re collecting and keeping for ourselves and using for our own compliant marketing purposes.  

Aaron: What we’re doing, if what we’re recommending to our clients, is that they aggregate and they leverage first-party data, that’s great. They’re doing that in their own HIPAA-compliant data warehouse or CDP, we’re working with them, we’re under BAA, we get access to that information as well. But, we still can’t share that information with any advertising platform, with any of these entities that are so powerful, but won’t sign a BAA, so how do you activate that data? How do you turn insights into performance? 

Paul: You’re basically leveraging all of the data on our side of the fence. In some cases, we’ve got access to the marketing data, and with several clients, we’ve also got their own other CRM data or other first-party data sources that we’re combining and using and basically making connections, deriving insights, figuring out what’s working and what’s not, so that we can use that information to then optimize our campaigns, our creative, our targeting, all of that on the other side of the fence. Because we’re under BAA, we can see everything, and we can use all the data to our advantage. What we’re not doing is we’re not just sharing that back to Facebook and saying, “Create me an audience based on this.” What we’re doing is, we’re using it to inform pivots, optimizations, boosting, etc. to be able to really lean into what works and what we know is working because we can see it on our side of the fence, behind the wall. Because again, we’re under BAA, we have access to all that information. We can use it to optimize, make decisions about what’s working and what’s not. It’s driven phenomenal results for our clients when we’ve got that access and we’ve got all that data together in one place.

The Future of Data Privacy & Tightening Regulations

Aaron: Alright, so a couple of final questions. Where do you think all of this is headed? We’ve been talking about privacy regulations as they pertain to HIPAA. In parallel, we have the deprecation of third-party cookies in Chrome by Google. Safari and Firefox already don’t support third-party cookies. You have tightening privacy regulations on a global level. GDPR is quite restrictive. You have 13 states in the U.S. with their own versions of privacy regulations, the most restrictive of them being CCPA in California. Where does all of this head do you think? 

Paul: The reality is that for a very, very long time, we’ve been abdicating control of the collection and utilization of all of this data that is from the users who come into our websites. We’ve been giving it away to Google, we’ve been giving it away to Facebook, and what’s become clear is that whether you’re a covered entity, a financial institution, or just anybody with a conscience, you need to take control over the data that you’re collecting from your consumers and not just give it away. Where this is heading is first-party data strategy. Where this is heading is organizations need to be more purposeful, they have to make more investments, in collecting, treating, storing, and analyzing. They have access to all of this data, they just need both the infrastructure – many of them already have the infrastructure with all of the MarTech investments that have been happening over the last five to ten years – but what they need also is for the people to understand how to get the most out of that data. 

A lot of time, what we’re doing is we’re helping our clients configure systems they already have to do the things that it needs to do to be compliant and then helping them understand what they’ve got, in terms of the data, helping them connect data that they already have. There’s all sorts of things that can be done with the tools and the technology that these companies already have. For me, it’s really about thinking about the data that we’re collecting and thinking expansively about this because in many cases, marketing has their own data, sales has their own data, and they don’t meet in the middle. That’s actually where the magic happens, understanding the value of a particular stream of leads that’s coming in and whether it’s working or not. You do that by connecting your first-party data with your marketing data and bringing that all together in one place where you can see it. You can see how your campaigns or your creative are performing, how your users are behaving, or which kinds of users at which step in the funnel are behaving in a way that results in a higher lifetime value or a higher percent conversion or whatever it is. It’s really thinking about your data differently and not thinking that Google Analytics is going to give you the answers because you can’t give Google Analytics all your data anymore. You have to have your own systems and your own means to collect and activate on all that data. It really comes down to first-party data strategy. 

Aaron: I think the implication in your answer then is you think certainly privacy regulations are more restrictive for covered entities, folks affected by HIPAA, but your sense is this is coming for everybody. 

Paul: This is the thin edge of the wedge. Healthcare entities, just because of the nature of the beast, they’re regulated. This is where privacy laws are just the strongest. Obviously, this is where it’s going to start, but finance is not far behind. The deprecation of tags and cookies in general mean we have to think differently about the way that we collect data and how we leverage and activate against it. 

Aaron: What advice would you give for covered entities who are still grappling with this situation and trying to come up with a solution? 

Paul: I would look at what you already have and understand that you probably already have options with the technology that you have in-house. If you don’t have the capabilities in-house, find a partner who can help you understand the capabilities of your technical stack and how those map to the requirements of being compliant, first of all. Further, how you can then start to move on a trajectory towards a first-party data strategy. This is going to be cross functional, it’s going to cross departments, this is an organizational change initiative, where the entire organization has to think about the data they’re collecting, how they’re using it, and how it’s being reported, to the extent that you can champion a first-party data strategy. It’s not only a necessity just to turn the lights back on, if you want to gain the insights that you once had, prior to being compliant, you’re going to need a first-party data strategy. You’re going to need people who understand how to how to collect, glean the insights that you need, visualize it in a way that’s helpful, understanding all parts of the business and the ways that the data from one side can help another. That’s really what it’s going to come down to, really being more intentional and thoughtful and purposeful about the data that you’re collecting and how you’re using it as an organization. 

Aaron: It might be helpful for us, and for you in particular, to enumerate the attributes of the kind of partner that a covered entity should look for to help them figure out what they have and where to from here. 

Paul: Yeah, sure. I think for starters, you need a partner that’s going to really work hard to understand you as an organization. What are your needs, what are your objectives, what are you trying to do, and also not in a one-dimensional way, not just for marketing, but from a technology point of view? Being able to speak the language of the folks that are responsible for your tech stack, being able to work with legal and compliance in a way that helps them understand that we know what’s at stake here, making sure that you’re speaking to the entire organization and understanding what the organization needs, not only from a compliance point of view, a marketing point of view, from a business point of view – these are business problems. The work that we tend to do has a technical element. Sure, we need to understand the technical implications and underpinnings of what we’re trying to do, but this is much more consultative than anything else. Most of the work we’re doing is understanding the needs of each respective stakeholder and what they’ve lost in the process and what they want to get back, and also showing them what the art of the possible is in terms of what they could do with a first-party data strategy. This isn’t about buying a platform, it’s not about buying technology, this is about solving a business problem and also thinking ahead to what other opportunities or capabilities this work can unlock. That’s the kind of partner that I think people, organizations, and covered entities are going to need in a situation like this.  

Aaron: That’s great. 

Related Links

For more information on HIPAA-compliant data solutions and OCR’s updated guidance, visit the links below.

HIPAA-Compliant Data Solution
Clarity for HIPAA Compliance From OCR’s Updated Guidance on Online Tracking 

Questions or comments

Please let us know if you have questions or comments about this episode by emailing Grace Johnson at Want to be a guest on a future episode? Fill out the Be a Guest form at the top of the Digital Clinic page to submit your inquiry.

Make sure to subscribe to the Digital Clinic on Spotify, Apple Podcasts, or Amazon Music to stay up to date on our weekly episodes.

HIPAA Compliance
Please enable JavaScript in your browser to complete this form.
Description of the image