Hospital websites had a HIPAA problem because nobody owned the tags

The week

The HHS Office for Civil Rights is the arm of the federal health department that enforces the HIPAA privacy law. On December 1, 2022, it published a bulletin on the use of online tracking technologies by HIPAA covered entities and business associates. Covered entities are hospitals, clinics, health plans and similar organizations. Business associates are the vendors that handle patient information on their behalf.

The bulletin’s subject was an ordinary transaction. Take a patient booking an appointment with a cardiologist on her hospital’s website late at night. She types her name, picks a time, perhaps clicks a box describing her symptoms, and assumes that information goes to the hospital. In 2022, at many hospitals, some of it was also going somewhere else.

Tracking technologies are small pieces of code, often called pixels or tags, that a website runs in the visitor’s browser. They report what the visitor did, such as which page they viewed or which button they clicked, back to an analytics or advertising company. They are everywhere on the commercial web, and they are how a retailer knows its ad worked.

The bulletin said tracking code on authenticated pages generally has access to protected health information, or PHI, the legal term for identifiable health data. Authenticated pages are those behind a login, such as patient portals and telehealth platforms. It added that tracking on some unauthenticated, public pages, such as appointment schedulers or pages about specific conditions, could also involve PHI.

The bulletin gave examples. A login or registration page on a portal could reveal that a visitor was a patient. So could pages where visitors searched for a doctor, booked an appointment or described symptoms. It also covered mobile apps that covered entities offer to patients, which can send device identifiers and in-app activity to third parties in the same way.

Disclosures to tracking vendors therefore needed a permitted basis under the HIPAA Privacy Rule. In practice that meant a business associate agreement, a contract in which the vendor promises to protect the data under HIPAA’s terms, or the patient’s own HIPAA authorization, a specific signed permission.

The bulletin closed several escape routes that vendors and hospitals had relied on. It said it was not enough for a tracking vendor to promise to strip out or de-identify protected information after receiving it, if no business associate agreement was in place. The disclosure had already happened by then. It also said a disclosure without a permitted basis was an impermissible disclosure that could amount to a breach, with the notification duties that follow.

The Security Rule applied as well. Covered entities and business associates were expected to address tracking technologies in their risk analysis and risk management. They were also expected to apply the same administrative, physical and technical safeguards they used for any other system handling electronic patient information. A pixel on a portal page was, in HHS’s framing, a data flow like any other.

The bulletin did not come out of nowhere. In mid-2022, reporting by The Markup found Meta’s tracking pixel sending appointment-scheduling data from a third of the top 100 US hospitals’ websites, and operating inside the patient portals of seven health systems. A growing wave of class actions against health systems followed.

Some health systems had already acted on their own findings. Novant Health in August 2022 and Advocate Aurora Health in October each notified more than a million patients that a tracking pixel on their websites or portals may have sent information to Meta. Those notices treated the flows as reportable breaches, months before the bulletin said that could be the right answer.

The bulletin itself was a guidance document, issued without notice and comment. It did not change the text of the Privacy Rule or the Security Rule. Its force came from describing how OCR read existing rules, and from the fact that OCR was the agency that would investigate complaints.

OCR announced no investigation or penalty alongside the bulletin. It described how it would read the rules when complaints arrived, and complaints from people worried about health websites were already reaching it. For compliance teams the message was about posture: the agency now had a stated position, and every later finding would be measured against it.

The week raised an uncomfortable question for hospital leaders: who, exactly, had decided to put that code there? In many cases, the honest answer was nobody in particular.

The bulletin was guidance, not a new regulation, and its reach on public pages was contested from the start. Its operational message was harder to dispute. A hospital’s website, scheduler and patient portal were part of its HIPAA footprint, yet in most health systems no single person was accountable for the code running on them.

The work it created came down to three questions, usually answered in this order: who owns the web estate, what is actually running on it, and on what terms each vendor receives data. The mechanics of tracking explain why this went wrong so widely and with so little notice.

The bulletin reached only part of the market. HIPAA applies to covered entities, meaning health plans, clearinghouses and providers that bill electronically, and to their business associates. A hospital, a physician group, a health plan and a telehealth practice that bills insurers all fall inside it. A consumer health app that sells directly to users usually does not. Those companies answer to the Federal Trade Commission, which polices unfair and deceptive practices and enforces its own Health Breach Notification Rule.

Overlaying both are state wiretap and privacy statutes and the federal Wiretap Act, which plaintiffs used against hospitals and apps alike. A health system’s exposure therefore never depended on OCR alone, a point that matters for how the work should be framed and funded.

How a web page leaks a diagnosis

When you open a web page, your browser downloads text, images and scripts, small programs that run on your device, from many different companies at once. The hospital’s own server provides the page. A video company supplies the video player. A chat company supplies the chat window. And analytics and advertising companies supply tracking scripts.

A tracking pixel gets its name from its earliest form: a one-pixel invisible image. When your browser loaded that image, the image’s owner learned that someone had visited the page. Modern pixels are scripts that can report much more: the page address, the buttons clicked, the text of a search, sometimes what was typed into a form.

Each report arrives with clues about who you are. Your IP address is the numeric address of your internet connection. A cookie is a small file the browser stores so a site, or a tracker, can recognize the same visitor later. An advertising platform that sees the same cookie on many sites, and on its own social network, can often link a page visit to a real person’s account.

Now put those pieces together. A page address such as “/cardiology/book-appointment,” sent with an IP address and a cookie tied to a social media account, says something specific about a specific person. That is why regulators argued that some public pages could involve PHI even without a login.

Search boxes add another path. Many sites put the visitor’s search terms in the page address, so a query for a condition or a medication travels with every tracking request that page sends. A visitor who types a symptom into a site search has, without knowing it, sent that symptom to every vendor whose code runs on the results page.

Two more tools explain how tracking spread. A tag manager is a control panel that lets non-engineers add, remove and configure scripts across a website without changing the site’s code. It is efficient and very convenient, and it means a marketing coordinator can put new code on thousands of pages in minutes. Session-replay tools record a visitor’s clicks, scrolls and keystrokes so designers can watch how people use a page. Helpful for fixing a confusing form, and risky when the form asks about symptoms.

Finally, a word on the legal plumbing. HIPAA lets a hospital share patient information with an outside company that helps it, such as a billing firm or a cloud provider, as long as that company signs a business associate agreement. The agreement makes the vendor responsible for protecting the data, limits what it may do with it, and requires it to report breaches. It is the price of admission to patient data. A company that will not sign one is, in HIPAA’s eyes, a stranger, and handing it patient information without the patient’s written authorization is a disclosure the law does not permit. That simple rule is the heart of the whole tracking problem: the most widely used advertising tools were run by companies that were never going to become a hospital’s business associate.

What happens after the data leaves

Advertising platforms do more than log a page view. They try to match it to a person they already know, because a matched event is worth more to an advertiser. Many pixels offer an “advanced matching” feature that collects an email address or phone number from a form, scrambles it with a one-way function called a hash, and sends the result.

Hashing sounds like protection, and against a casual observer it is. But the platform holds the same email addresses for its own users and can compute the same hash, so the match is exact. A hashed identifier sent to a company that already knows the original is not anonymous to that company.

The matched event then feeds audiences and measurement. A hospital might build an audience of people who visited its oncology pages and show them ads elsewhere. The platform, for its part, may use the signal to tune its own models. Whatever the contract says about use, the hospital has lost control of the data once it is sent.

Mobile apps carry the same risk in a different form. Instead of a pixel, an app includes a software development kit, a bundle of vendor code compiled into the app. It can report screens viewed, buttons pressed and a device advertising identifier. Because the code is compiled in, it is invisible to anyone who only reviews the website.

Who owns the web estate

In many health systems the public website belonged to marketing. An outside agency built and maintained it, a digital team configured analytics, and a tag manager let staff add new scripts without a change request, the formal approval process IT uses before altering a system. The privacy office reviewed the notice of privacy practices posted on the site, not the code behind it.

The patient portal usually sat with IT and the team that runs the electronic health record, the EHR, the core clinical system that holds patient charts. But the portal often shared an analytics account or tag container with the public site, so decisions made for marketing could reach pages full of patient information.

That arrangement explains how pixels reached sensitive pages. Nobody decided to send appointment data to an advertising platform. A campaign manager added a pixel to measure conversions, meaning how many visitors went on to book, the tag fired on every page by default, and nobody with privacy responsibility saw the configuration.

The fix was to give the whole web estate one accountable owner, usually a joint arrangement between the CIO’s organization and the privacy officer, with marketing as a customer. Concretely, that meant:

• Moving tag manager administrator rights out of agencies.
• Requiring a ticket and privacy review before any new script goes live.
• Adding web properties to the system inventory that feeds the HIPAA risk analysis, the formal assessment every covered entity must keep of where patient data lives and what could go wrong.
• Agency contracts that prohibit adding third-party code without written approval.

Who should own it, by type of organization

The right owner depends on the shape of the organization. An academic medical center often runs dozens of web properties: the main hospital site, department and lab sites, a foundation site for donors, research recruitment pages and a portal. Many of these were built by different teams on different platforms. The owner here needs a registry of every domain first, and authority to bring stray sites under common standards or retire them.

An ambulatory network or large physician group has the opposite problem. Its website and online scheduling often come from a practice management or scheduling vendor’s templates. The organization may not control the code at all. Ownership there means contract terms that tell the vendor what may and may not run on patient-facing pages, and a right to verify.

A health plan’s member portal handles claims, prescriptions and care management, so it carries plenty of sensitive data, and the plan also markets heavily to prospective members. The split between marketing pages and member pages has to be explicit, with separate tag containers and analytics accounts. A telehealth company that bills insurers is a covered entity with a startup’s marketing habits, and often the most aggressive growth tooling of all.

Across all of them the roles are similar. The privacy officer decides what may be collected and on what basis. The security team runs scanning and access control for the tag tools. IT or digital engineering builds and operates the measurement stack. Marketing states what it needs to measure and accepts the constraints. Writing those roles down settles disputes before they reach a campaign deadline.

The cost was speed. Marketing teams lost the ability to launch a tracked campaign the same afternoon. Organizations that set a service level for reviewing tag requests, such as a few business days for standard tools already approved, kept the new process from becoming a reason to work around it. A control that takes three months becomes a control people learn to bypass.

What is actually running

Most health systems could not say which third-party scripts ran on which pages. That sounds surprising until you see how the web works in practice. Tag managers load code dynamically, so it does not appear in the site’s own files. Agencies add pixels for campaigns and leave them in place long after the campaign ends. Chat widgets, scheduling plug-ins, video players and accessibility tools bring their own trackers. Some data flows are configured inside a vendor’s console and never appear in the page source at all.

A reliable inventory therefore had to come from observed behavior, not from asking around. Teams crawled the public site, using automated tools that visit every page, and, using test accounts, the portal. They recorded every outbound request, every message the browser sent to an outside company, and mapped each to a vendor, a purpose and the data it carried.

Then they classified pages by sensitivity. A page about a specific service line, a provider search, a symptom checker, or a scheduling flow could reveal a condition when combined with an IP address or a cookie identifier. So could URLs carrying a department name or search terms, and form fields captured by session-replay tools. A general page about parking or visiting hours is very different from a page about addiction treatment, and the inventory needed to say so.

The inventory had to be repeated, not filed. Sites change weekly, and a clean crawl in January says little about a campaign launched in March. Mature programs run automated scans on a schedule and on every release, and alert when a new domain appears in outbound traffic from a sensitive page.

How a useful scan is built

A scan that satisfies a regulator or a court is more than a browser plug-in run on the home page. Teams use automated browsers that load each page as a visitor would and record every outbound request. They run each page at least twice: once accepting the cookie banner and once rejecting it. Some sites send data either way, because the banner was never wired to the tags.

The portal needs test accounts populated with synthetic patients, never real ones, so the crawler can reach scheduling, messaging, bill pay and results pages. Forms should be filled with recognizable dummy values, so a reviewer can search the captured traffic for those values and see exactly where they went.

Browser scans miss three things. Server-side forwarding, where the hospital’s own systems pass data to a vendor, never appears in the browser. Mobile apps need traffic captured from a test device. Email campaigns can carry their own tracking pixels and link parameters. Each needs its own review, usually by reading configurations and contracts rather than watching traffic.

Third parties inside third parties

The hardest flows to see come from tools that bring their own tools. A chat widget, a scheduling plug-in or a video player can load analytics or advertising code from its own partners, a so-called fourth party. The hospital never chose that code and may not know the company behind it. The scan shows it, but only the contract with the first vendor can stop it.

Vendors also change their code without notice. A plug-in that was clean in one release can add a new partner in the next. That is why scheduled scanning matters more than a one-time review, and why contracts should require notice before a vendor adds any new recipient of data from patient-facing pages.

The results should go into a register with a line for each vendor and page group. Each line records the data elements sent, the identifiers attached, the legal basis, the contract that governs it and the owner who approved it. That register, more than any single scan, is what the risk analysis and any later investigation will lean on.

The output also served a second purpose: evidence for the risk analysis and for any regulator or plaintiff asking what the site did on a given date. In litigation, “we believe the pixel was removed sometime last spring” is a weak answer. A dated scan report is a strong one.

On what terms vendors receive data

OCR’s position was that a tracking vendor receiving PHI needs a business associate agreement, or the patient’s authorization. The major advertising platforms did not sign BAAs for their pixels. A cookie banner, the pop-up asking visitors to accept cookies, does not meet HIPAA’s authorization requirements, which call for specific elements and a signature. For those tools on PHI-bearing pages, the practical answer was removal.

A valid HIPAA authorization is a specific document. It describes the information to be disclosed, names who may disclose it and who will receive it, and states the purpose. It carries an expiration date or event and the individual’s signature and date. It also tells the patient about the right to revoke and that the recipient may redisclose the information. A banner click supplies none of this, and a long consent screen in front of a booking form would deter the patients the form exists to serve.

That left a real business need. Health systems still had to know whether scheduling pages worked and which outreach brought patients in. Patients who cannot book online call the switchboard or go elsewhere, and leaders reasonably want to know which is happening. The common responses were:

• BAA-ready analytics. Switching to analytics vendors willing to sign BAAs and accept HIPAA obligations.
• Server-side measurement. Moving measurement server-side, so the visitor’s browser reports only to the health system, and the health system controls what, if anything, is forwarded to vendors. It works like routing all outgoing mail through your own mailroom instead of letting every visitor post letters directly.
• Stripping identifiers. Removing identifiers and sensitive URL parameters before anything leaves the health system’s environment.

Each option had trade-offs. BAA-ready tools often offered less advertising functionality. Server-side setups needed engineering capacity that marketing budgets had never paid for, so somebody had to decide whose budget would now carry it.

Contracts also had to change. Privacy and security teams began reviewing marketing technology agreements that never used to reach them, checking data use limits, retention, subprocessors, meaning the vendor’s own vendors, and breach notice terms. Some health systems found agency contracts that allowed the agency itself to retain campaign data.

Contract terms worth insisting on

• A business associate agreement wherever the vendor can receive protected information, signed before the tool goes live.
• A ban on the vendor using health system data for its own purposes, including advertising, profiling and model training.
• No new third-party code or data recipients without written approval from the health system.
• Retention limits, and deletion or return of data at the end of the contract, with written confirmation.
• Prompt notice of any incident or unauthorized disclosure, within a set number of days.
• For agencies, return of all tag manager and analytics credentials when the engagement ends.

Not every vendor will agree to every term. A vendor that refuses the second one is telling the health system how it intends to use the data, and that answer should decide whether its code runs on patient-facing pages.

Why filtering and hashing did not settle it

Vendors offered reassurances that hospitals were keen to accept. Some advertising platforms said they ran filters to block sensitive health data from being used. Some agencies proposed hashing every identifier before sending it. The bulletin had already addressed the first: a vendor’s promise to remove protected information after receiving it does not substitute for a business associate agreement. Hashing fails for the reason described earlier, since the platform can reproduce the hash.

The trade-offs in server-side measurement

Server-side collection is often described as the answer, and it can be. It is a design choice, though, not a safe harbor. Once the browser reports only to the health system, the health system decides what to forward. If it forwards the same identifiers and page paths to the same advertising platform, nothing has changed except where the code runs, and the flow is now harder for outside scanners to see.

Done well, a server-side setup strips identifiers, collapses sensitive page paths into general categories, and sends only aggregate or de-identified measures to vendors without a business associate agreement. That needs engineering time, a data owner and documentation of each rule. It also costs marketing some precision. A campaign can no longer be traced to an individual patient’s booking, only to aggregate outcomes.

For many health systems the honest trade was to accept coarser measurement on sensitive pages and keep richer analytics for general pages such as careers, parking and news. Writing that trade down, and having marketing leadership sign it, turned a recurring argument into a settled policy.

Lawsuits, notices and patient trust

The legal uncertainty over public pages did not change this calculation much. Plaintiffs were already suing under state privacy and wiretap laws regardless of OCR’s view, and authenticated pages were clearly covered. Ownership, inventory and vendor terms were worth fixing under any court outcome, which made the project easier to fund. Counsel could track the litigation separately.

When a pixel becomes a breach

The breach question is where the bulletin carried the most operational weight. Under HIPAA’s Breach Notification Rule, an impermissible use or disclosure of unsecured protected information is presumed to be a breach. That presumption stands unless the organization can show a low probability that the information was compromised.

That showing rests on a documented risk assessment of four factors: the nature and extent of the information, who received it, whether it was actually acquired or viewed, and how far the risk was mitigated. A disclosure to an advertising platform that processes the data at scale is hard to fit within a low-probability finding.

Notification then follows fixed rules. Affected individuals must be told without unreasonable delay and no later than 60 days after discovery. HHS must be told, and breaches affecting more than 500 residents of a state or jurisdiction also require notice to prominent media there. The larger breaches appear on HHS’s public breach portal, where plaintiffs’ firms watch for them.

Discovery is where ownership matters again. The 60-day clock runs from when the breach is known, or would have been known with reasonable diligence. An organization with scheduled scans finds a new pixel quickly and can contain it before it touches many patients. One without them finds out from a journalist or a demand letter, after months of exposure.

The stakes run across the whole organization. There is regulatory risk from HIPAA and from state law. There is litigation cost, since class actions are expensive to defend even when they are settled or won. There is the cost of breach notification if a disclosure is treated as a breach.

Above all there is trust. Hospitals ask patients to share the most private facts of their lives. Learning that a visit to a cancer or fertility page fed an advertising system is the kind of discovery patients remember. It can make them less willing to use the digital tools the hospital has invested in. A portal patients avoid is an expensive portal.

The case against the bulletin, and what survives it

The strongest objections were serious. Hospital associations argued that a visit to a public page about a condition says nothing reliable about the visitor’s health. The visitor might be a caregiver, a student, a researcher or an employee. They also argued that analytics help hospitals fix confusing pages and reach patients who need care, and that small and rural hospitals lacked the engineers to rebuild measurement.

Those arguments carried weight, and a court later accepted the first one. But they do not touch the case for ownership. The portal and authenticated pages were never in doubt. State privacy laws and wiretap claims did not turn on OCR’s definition. And a health system that cannot say what code runs on its pages has a governance gap whatever any regulator thinks of a specific data flow. The argument here survives the objections because it never depended on the contested part of the guidance.

Suppose a regional health system with a dozen hospitals runs its first full scan. It finds scripts from many outside companies on its public site, a social media pixel on its scheduling pages, and a session-replay tool recording the portal’s symptom form. No one in the privacy office knew about any of them. None was malicious. Each had been added by someone doing their job well, with no one asking whether the job included protecting patient data.

What the health system does next matters more than what it found. The fastest wins are removing the social media pixel from scheduling and the session-replay tool from the portal. The slower, more valuable work is deciding who will own the website from now on, so the next scan is not a repeat of the first.

Putting it into practice: a first ninety days

For a leader who wants to move from concern to action, the work breaks naturally into three stages. The timings are illustrative, not a standard, and a large system may need longer.

Weeks one to three: find out

Name an interim owner with authority across marketing, IT and privacy. Run a full scan of the public site and, with test accounts, the portal. Pull a list of everyone with administrator rights to the tag manager and to every analytics account. Gather the contracts for the web agency and each marketing technology vendor. At this stage the goal is a factual picture, not blame. Most of what turns up was added in good faith.

Preserve evidence before changing anything. Tag managers keep version histories, and analytics accounts keep configuration logs. Export them, and save the first scan reports, before tags are removed. If counsel later needs to assess whether a breach occurred, and for how long, those records will be the only reliable account. Many organizations run this phase under counsel’s direction for the same reason.

Include the mobile apps, the email marketing platform and any patient-facing chat or scheduling services in this first pass, since each can send data outside the website. Ask the web agency for a list of every tool it has installed, and compare it against the scan. The gaps between the two lists are usually the most instructive finding.

Weeks four to eight: stop the bleeding

Remove or disable tracking on the pages classified as most sensitive, starting with the portal, scheduling flows and condition pages. Revoke tag manager access for anyone who no longer needs it, especially outside parties. Put a simple rule in place: no new script goes live without a ticket and a privacy check. Tell marketing what they will lose and what the plan is for replacing it, because a team left without any measurement will find its own way to get some.

Weeks nine to thirteen: build the lasting version

Choose the replacement approach for measurement, whether BAA-ready tools, server-side collection or both, and fund it. Set up scheduled scanning with alerts. Add the web estate to the HIPAA risk analysis. Begin renegotiating agency and vendor contracts as they come up for renewal, or sooner where the terms are clearly unacceptable. Report progress to the board’s audit or compliance committee, so the oversight is visible and the ownership sticks.

The work needs no new technology, only a named owner for the website and scans that keep running.

A program that keeps tags in check

A durable program has one named owner for the whole web estate, with privacy at the table, and a living inventory built from automated scans. Pages are classified by what they can reveal. Measurement is routed through systems the health system controls. Marketing contracts are reviewed like any other contract touching patient data. And the review process is quick and predictable, so teams do not route around it.

A technical guardrail

Policy alone tends to erode, so mature programs add a control the browser enforces. A content security policy is a header the website sends that tells the browser which outside domains the page may load scripts from and send data to. Anything not on the list is blocked, whatever a tag manager user configures.

The trade-off is breakage. A strict policy will stop legitimate tools that were never registered, and the first attempt usually breaks something. Teams start in report-only mode, where the browser reports violations without blocking them, and use those reports to build the allowlist. Once enforced, the policy turns the approval process into something the site itself checks. It works best on the portal and scheduling pages, where the list of legitimate outside services is short.

A few measures show whether the program is working. The number of third-party domains receiving data from sensitive pages, which should fall and then stay flat. The time from a new tag request to a decision. The share of web properties covered by scheduled scanning. The number of people outside the organization with tag manager rights, which should be close to zero. A compliance committee can read each of these without a technical briefing.

The program also needs a place in the annual HIPAA risk analysis, with the web estate listed beside the EHR, the data warehouse and the billing systems. Examiners and auditors look for that line. Its absence suggests the website was never treated as a system holding patient data, which was the original problem.

People need training as well as tools. Marketing and digital staff should know which pages are sensitive, why a pixel on them is a disclosure, and how to request a new tool. A short briefing at onboarding and before each major campaign costs little. It also turns marketing from the subject of the controls into a partner in running them.

The familiar failures:

• Treating the cookie banner as consent. It is not HIPAA authorization.
• Assuming that because a page has no login, it carries no risk.
• Doing one cleanup and declaring victory, then letting tags creep back with the next campaign.
• Leaving tag manager keys with an outside agency.
• Removing all measurement without a replacement, which leaves marketing blind and invites workarounds.

Who answers for the website

• Who is the single accountable owner of our website, scheduler and patient portal, including the code that runs on them?
• Who holds administrator rights to our tag manager, and are any of them outside the organization?
• When did we last scan our public site and portal for outbound data, and how often do we repeat it?
• Which outside vendors receive data from our sensitive pages, and does each have a business associate agreement?
• If a regulator or plaintiff asked what our site did on a particular date last year, could we show them?

With hindsight

The legal picture shifted; the governance case held.

In July 2023 OCR and the FTC, the Federal Trade Commission, which polices unfair and deceptive business practices, sent joint letters to about 130 hospital systems and telehealth providers warning about tracking technologies. Two federal agencies writing directly to that many organizations was a clear signal that the issue was not going away.

The FTC had already shown what that meant for companies outside HIPAA. In February 2023 it brought its first action under the Health Breach Notification Rule, against the prescription discount company GoodRx, over sharing health information with advertising platforms. It followed with actions against the online counseling service BetterHelp in March and the fertility app Premom in May. Health systems were not the target, but the theory of harm was the same.

OCR revised the bulletin in March 2024. Then, in June 2024, a federal court in Texas ruled in a case brought by the American Hospital Association. It vacated the part of the guidance treating certain tracking on unauthenticated public pages as a disclosure of PHI. To vacate means to set aside, so that part of the guidance no longer had legal force. The guidance on authenticated pages such as patient portals was not affected.

The details of the ruling matter. The plaintiffs were two hospital associations and a regional health system. HHS had issued its revised bulletin days before its brief was due, softening the language and adding the example of a student researching a condition for a paper. The court found that the revision left the contested rule essentially the same.

The court’s reasoning focused on the combination of an IP address with a visit to a public page about a condition. It held that such a combination could not by itself be treated as identifiable health information, since the visitor might be looking on behalf of someone else or for reasons unrelated to anyone’s care. It said the vacatur was not meant to limit the rest of the guidance.

Some read the court ruling as a reprieve. But class actions over pixels continued under state law, which did not depend on OCR’s view of public pages. The risk moved rather than disappeared.

Large notifications kept arriving after the bulletin. In April 2024 Kaiser Permanente said it was notifying about 13.4 million people that tracking code on its websites and apps may have sent information to third parties. The disclosure came well after the issue was public, which showed how long such flows can persist in a large organization.

Organizations that put web properties under named ownership and continuous scanning in 2023 found the same controls useful for the state consumer health privacy laws that followed. Those laws were written with digital health data in mind, and they asked the same basic questions: what are you collecting, who receives it and on what terms. A health system with a current inventory and clear ownership could answer them. One that had relaxed after the Texas ruling had to start over.

Washington’s My Health My Data Act, signed in April 2023, was the clearest example. Most of its provisions took effect on March 31, 2024, and it gives consumers a private right of action. It exempts information already governed by HIPAA. That exemption has an awkward consequence for hospitals. Data the Texas court placed outside HIPAA, such as some public-page browsing, can fall within state consumer health laws instead.

In January 2025 HHS proposed a broad update to the HIPAA Security Rule. Among other things, it would require regulated entities to keep a written inventory of technology assets and a network map showing how electronic patient information moves. Whatever its final form, it pointed at the same habit this article argues for: knowing which systems touch patient data and who answers for them.

Ownership mattered more than pixels. Every system that touches patient data needs someone accountable for it, including the systems that do not look like clinical systems. The marketing website turned out to be part of the patient record’s neighborhood, and the controls had to follow.

Counsel should advise on current exposure under those state laws.