The FTC’s breach rule proposal drew the HIPAA line through the middle of a data flow

The week

On May 18, 2023, the Federal Trade Commission proposed amendments to its Health Breach Notification Rule. The proposal would revise definitions to make clear that the rule reaches health apps and similar technologies. It would define a breach of security to include unauthorized disclosures, such as sharing with advertisers, as well as intrusions. A company would not need to be hacked to have a breach; passing health data to an advertising platform without permission could count.

The notice appeared in the Federal Register on June 9, with comments due by August 8, 2023. Its definitions did most of the work. It would add a definition of “health care provider” and of “health care services or supplies,” broad enough to reach many fitness, diet, fertility and medication apps and connected devices. It would make clear that a “PHR related entity” could include companies offering products through a health app’s online services. It would also say that service providers, such as a cloud host, do not become related entities merely by handling the data.

The gap the rule addresses is easy to illustrate. A woman who logs her cycle, her temperature and her pregnancy test results in a fertility app on her phone assumes, as most people would, that this information is protected the way her doctor’s notes are. Often it is not. The federal health privacy law most people have heard of, HIPAA, mainly governs doctors, hospitals, health plans and the companies that work for them. A consumer app she downloaded herself usually falls outside it.

The FTC rule was built to cover that gap. Since 2009 the rule had required vendors of personal health records, and related entities not covered by HIPAA, to notify consumers, the FTC and in some cases the media after a breach of unsecured identifiable health information. A “personal health record” here simply means an electronic record of someone’s health information that the person can manage, such as an app that pulls together data from several places.

The rule had been issued in August 2009 under the Recovery Act, the stimulus law that also contained the HITECH Act’s changes to HIPAA. FTC enforcement began in February 2010. For more than a decade the agency brought no case under it. In May 2020 the Commission opened a routine ten-year review. In September 2021 it issued a policy statement saying that the rule covered most health apps outside HIPAA, and that a breach was not limited to cybersecurity intrusions.

The proposal would also clarify what it means for a product to draw information from multiple sources, which matters because that is one of the tests for whether an app counts as a personal health record. It would allow notice by email and other electronic means, rather than relying on letters, and expand what notices must say.

The proposed notice changes were specific. Email would count only alongside a second channel, such as a text message, an in-app message or an electronic banner. Notices would need to describe the potential for harm, name the third parties that acquired the data where known, and give at least two ways to contact the company. The proposal included a model notice. Violations could bring civil penalties, at the time up to $50,120 per violation per day, adjusted each year for inflation.

The timing told its own story. The FTC had brought its first case under the rule against GoodRx in February. The day before the proposal, it announced a second, against Easy Healthcare, the developer of the fertility app Premom. A rule that had gone unused for years was now being enforced, and the agency was tidying up its wording so that no one could claim to be unsure whether it applied to them.

The GoodRx case, announced on February 1, set the pattern. According to the FTC, the prescription discount company shared information about users’ medications and health conditions with Facebook, Google, Criteo and other firms. In 2019 it had uploaded lists of users who bought particular heart and blood pressure medications to Facebook to target advertising. The company paid a $1.5 million civil penalty for failing to report those disclosures as breaches. The order barred it from sharing health information for advertising. The Premom settlement carried a $100,000 civil penalty. In March, the FTC had separately settled with BetterHelp, an online counseling service, under its general power over deceptive and unfair practices rather than under the breach rule.

The states were moving at the same time. On April 27, Washington’s governor signed the My Health My Data Act, a law aimed squarely at health data outside HIPAA, with consent requirements and a private right of action. Hospitals were dealing with a related problem from the other side. Since a 2022 news investigation found Meta’s tracking pixel on many hospital websites, several health systems had reported breaches to HHS. In December 2022 OCR had issued a bulletin warning HIPAA-regulated entities about online tracking technologies.

The week mattered less for any one company than for the map it drew. The proposal showed, in effect, where HIPAA ends and the FTC begins, and that line often runs straight through a single organization’s products.

The FTC’s 2021 policy statement had first said that health apps were covered and that sharing could be a breach. GoodRx and BetterHelp then showed the agency would act. The May 2023 proposal added detail, and the detail carried the practical weight.

It set out which products sit on which side of HIPAA. Read closely, it showed that the boundary runs through products and data flows, not between organizations. A health system, a drug maker or a digital health vendor can be on both sides at once. That is an uncomfortable idea for leaders used to thinking “we are a HIPAA organization” or “we are not.” The honest answer for many is “it depends which product, and which stream of data, you mean.”

The stakes differ by type of organization. A health system mostly lives under HIPAA but runs marketing and wellness products that may not. A health plan has the same split, plus member apps fed by mandated interfaces. A drug or device maker usually stands outside HIPAA altogether, yet receives health data from providers, pharmacies and patients. A digital health company may hold both kinds of data inside one codebase. A retail pharmacy or discount card company can be a covered entity for dispensing and something else for its app.

The useful work was to place each product and flow in one of three positions: products run as part of care, products offered directly to consumers, and data that patients send across the line. The vocabulary comes first.

Five terms that decide who regulates what

HIPAA is the main federal health privacy law. It applies to “covered entities,” meaning health care providers, health plans and clearinghouses, and to their “business associates,” the vendors that handle patient information on their behalf, such as a billing company or a cloud software provider. Its rules attach to the institutions of the health care system rather than to health information wherever it goes.

The FTC’s Health Breach Notification Rule fills part of the space HIPAA leaves empty. It applies to vendors of personal health records and related entities that are not covered by HIPAA. Its core demand is simple: if there is a breach, tell people.

A breach in ordinary speech means a break-in. The proposal widened the meaning to include unauthorized disclosure. If a company hands health information to an advertiser without the user’s authorization, that is treated as a breach even though no criminal was involved. The door was not forced; it was held open.

A data flow is any route by which information leaves one system and arrives in another. A form submission that goes to a database is a flow. So is the unannounced message an app sends to an analytics company every time a user taps a button.

An application programming interface, or API, is a standard doorway that lets one piece of software ask another for information. When a patient connects an app to a hospital record, the app knocks on the hospital’s API and, with the patient’s permission, receives data back. The API fixes where the request is made, how it is made and what can be handed over.

A software development kit, or SDK, is a ready-made bundle of code that app developers drop into their product to add a feature without building it themselves: analytics, crash reports, ad measurement. An SDK works like a subcontractor who moves into your building with their own phone line out: useful, but you need to know who they are calling.

Three narrower terms that carried weight

Unsecured information is information that has not been made unreadable by methods HHS guidance specifies, chiefly encryption and destruction. Under both HIPAA and the FTC rule, a breach of properly encrypted data generally does not trigger notice. That safe harbor is irrelevant to a disclosure-type breach. When a company itself sends readable data to an advertiser, encryption at rest or in transit protects nothing, because the recipient was meant to read it.

A PHR related entity is a company that offers products or services through a personal health record vendor’s website or online services. It can also be one that accesses or sends unsecured health information to a personal health record. The proposal would extend this to products offered through apps, and limit it to entities that actually access or send the data. A company running a connected scale that feeds a health app could fall here.

A third party service provider handles data on behalf of a covered company, such as a hosting firm. Under the rule it must tell the company it serves about a breach, rather than notify consumers itself. The proposal made clear that such a provider does not become a related entity merely by touching the data. That preserved the ordinary model of outsourcing to cloud and analytics vendors, provided they act on the company’s instructions and not for their own purposes.

Position one: products run as part of care

Covered entities and their business associates, acting in those roles, are governed by HIPAA’s breach rule, not the FTC’s. A health system’s patient portal, its EHR-connected app and its telehealth platform fall here. (An EHR, or electronic health record, is the clinical system where doctors and nurses document care.) For these products the proposal changed little directly.

The edges are less tidy. Health systems also run wellness apps, fitness challenges, symptom checkers and pregnancy apps, sometimes built and operated by a marketing agency. Whether such a product is part of the organization’s HIPAA-covered activity depends on facts: who operates it, for what purpose, and whether it handles protected health information. The answer decides which breach rule, which consent standard and which regulator apply.

Suppose a regional health system’s marketing team commissions an agency to build a “healthy pregnancy” app with weekly tips and a symptom log. It carries the hospital’s logo. Nobody asked whether it is part of care. If it is, HIPAA applies and the agency is likely a business associate. If it is a consumer product, the FTC rule may apply instead, and the analytics tools the agency added by default may be creating unauthorized disclosures with every tap. Same logo, very different legal position, and the decision was made by accident.

Tracking code on hospital websites

The products in position one had their own version of the disclosure problem. OCR’s December 2022 bulletin said that tracking technologies on a regulated entity’s website or app could disclose protected health information to the technology vendor. That was most clearly true on authenticated pages such as patient portals, and in some cases on public pages such as appointment schedulers. Many advertising vendors would not sign business associate agreements. Without one, OCR said, such a disclosure was not permitted.

HIPAA already treated an impermissible disclosure as a presumed breach. Since 2013 a covered entity has had to notify unless a documented risk assessment shows a low probability that the information was compromised. The FTC proposal brought the non-HIPAA world toward the same idea. A health system therefore faced a similar question for its portal under HIPAA and for its consumer app under the FTC rule: did data leave for a purpose the patient never authorized.

The regulators reinforced the point together. In July 2023 the FTC and OCR jointly wrote to around 130 hospital systems and telehealth providers, warning about the privacy and security risks of online tracking technologies. A hospital could not assume that the FTC was only interested in apps, or that OCR was only interested in medical records.

For a business associate the question has a further layer. A marketing agency building a hospital’s app under a business associate agreement may use protected health information only as the agreement permits. If the agency adds its own analytics for its own purposes, the hospital may face an impermissible disclosure, and the agency may face direct HIPAA liability. The agreement should name permitted subcontractors and tools, and require notice before new ones are added.

Digital health vendors face the same split from the other direction. A company may serve hospitals as a business associate and also sell a direct-to-consumer version of the same product. The code is shared. The legal regimes are not. Hospitals contracting with such vendors should ask how data from the two lines of business is separated. They should also ask whether analytics or advertising tools in the consumer version can reach data received under the business associate agreement. The answer belongs in the vendor file, with the date it was given.

The contract can do more than the questionnaire. A business associate agreement with a dual-role vendor can forbid any use of the hospital’s data in the vendor’s consumer products, including for training models or improving features. It can limit de-identification to purposes the hospital approves, require a current list of subcontractors and embedded tools, and give the hospital a right to test or audit. It can also require the vendor to report any flow of hospital data to a party not on the list as a security incident. Those terms turn an assurance into an obligation the hospital can enforce.

Position two: products offered directly to consumers

The second position covers products outside HIPAA that handle identifiable health information. Life sciences companies are often here. Patient support programs, adherence and reminder apps, disease management tools and patient communities are usually offered to consumers directly, not on behalf of a provider. So are many pharmacy, discount card and fertility apps.

Under the proposal, sending health information from such a product to an advertising or analytics platform without the user’s authorization could itself be a breach requiring notice. That changes what breach response must be able to answer. Besides whether the product was hacked, it has to establish whether each data flow out of it was authorized, by whom, and when.

This is a real shift for the people who run incident response. Their playbooks were written for intruders: detect, contain, investigate, notify. A disclosure-type breach has no intruder. It may have been running for months as a normal feature of the product. Detecting it means looking at what the product does on purpose, as well as at what attackers do.

When a consumer product counts as a health record

The rule applies to vendors of personal health records, so the definition of that term decides whether a product is in scope. A personal health record must be able to draw information from multiple sources and be managed, shared and controlled by or primarily for the individual. The proposal said a product qualifies if it has the technical capacity to draw from multiple sources, even if some users never switch the feature on.

That clarification closed a common argument. Many apps take data a user types in and can also pull data from a phone’s health platform, a wearable or another service through an API. Under the proposal, that capacity is enough. A medication reminder app that only stores what the user enters might fall outside; the same app with an optional link to a pharmacy account or a fitness tracker likely falls inside.

Life sciences companies meet this through patient support programs. A patient may sign a HIPAA authorization letting a doctor or pharmacy share information with the manufacturer’s support hub. Once that information reaches the manufacturer, HIPAA no longer governs it in the manufacturer’s hands. If the program also offers an app that pulls refill data and user entries together, the FTC rule may apply to that app. A brand team’s campaign tags and the hub’s data can then end up in the same analytics account unless someone separates them deliberately.

What a disclosure-type breach demands of the response team

The FTC rule requires notice to individuals without unreasonable delay and within 60 calendar days of discovery. Breaches affecting 500 or more people also require notice to the FTC, and sometimes to the media. A disclosure that ran as a product feature raises questions an intrusion rarely does. When did discovery happen: when an engineer noticed the kit, or when legal concluded it was unauthorized. How many people were affected over the months it ran. Which third parties received what, so they can be named in the notice and asked to delete it.

Answering those questions requires product, engineering, marketing, privacy and legal in the same room early. The response plan should name who decides that a known data flow may be a breach, because that decision starts the notification clock. It should also set out how the company will ask recipients to delete data, and how it will record their answers.

Why mobile apps are the hard part

Mobile apps make that hard. Website tags can be scanned from outside. (A tag, sometimes called a pixel, is a small snippet on a web page that reports visits back to an analytics or advertising company; because it sits in the page, outsiders can see it.) Mobile software development kits for analytics, crash reporting, attribution and advertising are compiled into the app and send data from the device. “Compiled in” means they are baked into the finished product, invisible from the outside, and they travel with every copy installed on every phone.

Many app teams could not list every kit in their current release, let alone what each sent. That is not usually negligence. Kits get added for a campaign, inherited from an earlier version, or pulled in as a dependency of another kit. Over a few years an app can accumulate passengers no one remembers inviting.

The controls are specific. Maintain an inventory of kits per app version. Review each new kit and each kit upgrade before release. Test what the app actually transmits on a device. Tie consent records to the specific flows they authorize, so a later question about one flow can be answered from records rather than reconstructed.

Suppose a drug maker’s adherence app receives a regulator’s question about whether it shared users’ medication data with an advertising platform last spring. One company spends weeks interviewing former contractors and digging through old code. Another opens a register, finds the app version in use at the time, sees which kits it contained, pulls the device test showing what each sent, and matches it to the consent screen users saw. The second company may still have a problem, but it can describe it accurately and quickly, which is most of what regulators and customers want at first.

Testing what an app actually sends

Device testing has a known method. A tester installs the release build on a test phone and routes its traffic through an intercepting proxy. The tester then walks through the main user journeys: sign-up, logging a symptom, searching for a condition, booking a visit. Each outbound request is recorded with its destination and contents. The results are compared with the kit inventory, the privacy policy and the consent screen.

Testing often turns up flows no one designed. Many analytics kits record screen names and button labels automatically. A screen called “Pregnancy test result” or a button called “Log panic attack” reveals health information even when no medical field is sent. Kits may also send device advertising identifiers, which allow the recipient to link the event to other activity. Renaming events, switching off automatic collection and stripping identifiers are routine fixes once someone has seen the traffic.

Device tests cannot see everything. Some flows run from the company’s own servers to an advertising or analytics platform, through server-to-server integrations that advertisers offer as an alternative to tags. Those flows never appear on the phone. The register therefore needs a server-side section too, reviewed with the engineers who own the integrations.

App store disclosures offer a useful cross-check. Apple’s privacy labels and Google Play’s data safety section ask developers to declare what data the app collects and shares. A mismatch between the label, the policy and the observed traffic is exactly the kind of inconsistency a regulator or a plaintiff’s lawyer will find.

Position three: data patients send across the line

The third position is the crossing itself. Federal interoperability rules require certified EHRs and many payers to give patients access to their data through standardized application programming interfaces, including in apps the patients choose. “Interoperability” just means systems being able to exchange information in a common format, so that one system can read what another sends.

Once data reaches an app the patient selected, HIPAA generally stops governing it, unless the app is working for a covered entity. The proposal’s clarification about drawing from multiple sources made it likelier that such apps fall under the FTC rule instead. So the same lab result can be under HIPAA in the hospital’s system at noon and under the FTC’s rule in a consumer app at 12:01, carried across by the patient’s own request.

A health system or payer cannot generally refuse a patient’s request because it dislikes an app’s privacy practices. That surprises many boards. The rules behind it are specific. HIPAA’s right of access lets an individual direct a copy of their records to a third party, including an app. OCR has said a covered entity may not refuse such a request because it worries about how the app will protect the data. It may still protect its own systems from a genuine security risk. The information blocking rules under the 21st Century Cures Act add a further constraint on providers, EHR developers and exchanges. Discouraging a patient from using an app, beyond giving accurate information, can be treated as interference. The policy choice behind the rules is that patients own access to their information and may take it where they like, including to apps the organization would never have chosen.

It can inform patients. CMS rules let payers ask apps to attest to having a privacy policy, and require payers to give patients educational material about choosing apps. (CMS, the Centers for Medicare & Medicaid Services, is the federal agency that runs those programs and sets many payer rules.) Providers can do something similar at the authorization screen, the moment when a patient approves an app’s connection.

The technical design shapes what is possible. Patient-facing interfaces generally follow the FHIR data standard and an authorization flow in which the patient logs in through the provider or payer and approves the app’s requested access. Each registered app has an identifier, and each approval creates a record. Those records are the raw material for knowing which apps hold which patients’ data.

Payers and providers face this differently. Medicare Advantage organizations, Medicaid and CHIP programs and plans on the federal exchanges have had to offer a Patient Access API since 2021 under CMS rules. Providers meet the same pressure through certified EHR technology and the information blocking rules. Commercial employer plans are mostly outside the CMS mandate, so their exposure depends on what they chose to build.

They can also keep a register of which apps have received data through their interfaces, and for how many patients. If an app is later found to have shared data improperly, that register lets the organization tell its own patients quickly. No rule requires that step, but patients will expect it. When a story breaks about a popular app misusing data, the first call many patients make is to the hospital whose logo was on the record.

When a connected app goes wrong

A short playbook helps when an app that pulls patient data is accused of misusing it. First, confirm the facts from public sources such as an FTC complaint or the app’s own notice, rather than press reports alone. Second, use the connection records to count affected patients and identify them. Third, decide with communications and privacy what to tell those patients: what happened, that the app is not part of the organization, and how to revoke its access in their own account settings.

Whether the organization may block the app’s future access is a separate and narrower question. The information blocking rules include exceptions for privacy and security, but they come with conditions. That decision should go to counsel, with the facts written down. Telling patients how to protect themselves is almost always available; cutting off an app on the organization’s own initiative needs a stronger basis.

The one record that ties it all together

All three positions depend on one record: a list of digital products and outbound data flows, each tagged with the regime that governs it and the reason. It sounds bureaucratic. It is actually the foundation of every faster, cheaper answer the organization will need later, whether for a regulator, a journalist, a plaintiff’s lawyer or a worried patient.

Products launched by marketing, digital or commercial teams often get legal review once, at launch. The data flows change with every release. A product that was correctly classified two years ago may have added a chatbot, a new partner or an advertising kit since. The tagging should be revisited when a product adds a feature, a partner or a software kit, and confirmed with counsel when the facts are close.

What each entry needs to hold

A useful entry is short but specific. It names the product and its business owner, the company or agency that operates it, its purpose, and whether it is offered as part of care. It lists the data collected, the sources it draws from, and every outbound flow: kits, tags, server integrations, partners and APIs. For each flow it records the governing regime, the legal basis or consent, the contract in place and the date of the last test.

The privacy office usually owns the register, but it cannot keep it current alone. Product teams should update their entries as part of each release, in the same tool they already use to plan work. The privacy office then reviews changes that touch new data, new recipients or new purposes. A quarterly reconciliation against app store listings, website scans and procurement records catches products that never entered the process.

The cost of not having this record shows up in three places. Money: investigations and outside counsel are far more expensive when facts must be reconstructed. Risk: an organization that cannot say which regime applies may notify under the wrong one, or not at all. Reputation: health data is personal, and patients judge institutions harshly when they learn about sharing from the news rather than from the institution.

A register, release gates and consent tied to flows

The organizations that handle this well share a few habits:

• One owner for the product register. Someone accountable for knowing every consumer-facing digital product, who runs it and which regime governs it.
• Classification with reasons. The reason behind each “HIPAA” or “FTC” label, written down and dated, so the reasoning can be checked when facts change.
• Release gates for apps. No new SDK or SDK upgrade ships without review, and the app’s actual transmissions are tested on a real device.
• Consent tied to flows. Records that show which permission covered which data going to which recipient.
• Vendor answers on file. For dual-role vendors, a dated written explanation of how hospital data is kept apart from the consumer business.
• A register of connected apps. Which third-party apps have pulled patient data through your interfaces, and for how many patients.
• Server-side flows in scope. Integrations that send data from company servers to advertising or analytics platforms, reviewed alongside the kits on the device.
• A named breach decision owner. One person who decides when a known data flow may be a breach, because that decision starts the notification clock.

The failures mirror these. Treating legal review as a launch-day event rather than a recurring check. Assuming “we are a hospital, so everything is HIPAA,” when the marketing department is running a consumer app. Assuming “we are not a covered entity, so health privacy rules do not apply.” Relying on a website scan to understand a mobile app. Writing consent language that is broad and vague, so it cannot later prove that any particular flow was authorized. And building an incident response plan that only imagines hackers.

What the controls cost

The controls have real costs, and marketing teams feel them first. Removing advertising kits and pixels from health products weakens campaign measurement and audience targeting. Consent prompts reduce the share of users whose data can be used for anything beyond the service itself. Patient acquisition may become more expensive, and attribution less precise.

There are partial substitutes. Some analytics vendors will sign business associate agreements and limit use of the data to the customer’s purposes. First-party analytics hosted under the organization’s control keep data in-house. Aggregate, de-identified reporting can answer many campaign questions. Each substitute costs money or capability, and leaders should decide the trade-off openly, before the product team discovers it in a release review.

A business decision with legal consequences

A breach in a patient-facing product can end in a federal investigation and a public disclosure. The products in question are usually launched to grow revenue, deepen patient relationships or support a brand. They are business decisions with legal consequences attached. The approval process should reflect that. A new consumer-facing health product should not receive its build budget until it has a privacy classification, a named owner and a plan for testing its data flows. The leaders who approve them should know which side of the line each product sits on, because that decides who can investigate, what must be disclosed and how a failure will be described in public.

For life sciences companies, the stakes are also commercial. Patient support programs and adherence apps exist because they help patients stay on therapy, which matters to patients and to sales. A disclosure-type breach in such a program can damage trust in exactly the relationship it was meant to build.

Boards and audit committees can oversee this with a few numbers. They include the count of consumer-facing products and how many lack a current classification. Others are how many app releases shipped without a kit review, and how many outbound flows were tested on a device in the past year. Open findings from those tests, with owners and dates, complete the picture. A trend in those figures says more about the organization’s exposure than a policy attestation.

The case that the FTC went too far

The strongest objection came from within the agency and from industry commenters. Critics argued that a statute written about breaches of security was being stretched into a general health privacy rule. They also argued that the new definition of a health care provider swept in almost any app that touches wellness. When the rule was finalized in 2024, two Commissioners dissented on grounds of that kind.

That argument has force as a matter of statutory interpretation, and courts or a later Commission could narrow the rule. It changes less for operations than it seems. Washington’s law, Connecticut’s amendments covering consumer health data and Nevada’s law imposed consent duties on many of the same products. Class action lawyers were already suing over pixels and kits under wiretap and consumer protection laws. Even a narrower federal rule would leave the need to know every product, every flow and its authorization in place.

The map has to cover every app and feed

The questions below are the ones a board member, an auditor or a regulator could reasonably ask after a news story about health data. Each should have an owner who can answer it from records rather than recollection, and each answer should come with the date it was last checked. An organization that can answer all five within a day has done most of the work this proposal implied.

1. Can you give me a list of every consumer-facing digital product we run, including ones built by agencies, and tell me which privacy regime governs each, why, and when that was last checked?
2. For each mobile app, what SDKs are in the current release, and when did we last test on a device what they actually send?
3. If a regulator asked whether a specific data flow was authorized last year, could we answer from release records, consent screens and device tests rather than from memory?
4. Do we know which third-party apps have received patient data through our APIs, and for how many patients?
5. Does our incident response plan cover a breach with no attacker, where the problem is a feature we built?

With hindsight

The FTC finalized the amendments in April 2024, largely as proposed, and they took effect that July. The final rule confirmed that health apps are covered, that unauthorized disclosure can be a breach, and that notice may be sent electronically. What had been a proposal became the settled rulebook, and the uncertainty some companies had relied on was gone.

The Commission approved the final rule on April 26, 2024, by a vote of three to two, with Commissioners Melissa Holyoak and Andrew Ferguson dissenting. It was published on May 30 and took effect on July 29, 2024. For breaches affecting 500 or more people, companies must now notify the FTC at the same time as individuals, within 60 days of discovery. Notices must identify the third parties that acquired the data, or describe them where naming them would itself pose a risk.

Enforcement around the rule continued through 2024. In April the FTC settled with Cerebral, a telehealth mental health company, over sharing health data with advertising platforms. The same month Kaiser Permanente began notifying millions of members that tracking code on its websites and apps had sent information to third parties. Health systems kept settling class actions over pixels.

The hospital side of the line moved too. OCR updated its tracking technology bulletin in March 2024. 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 some tracking on public, unauthenticated pages as a disclosure of protected health information. That narrowed OCR’s reach over hospital marketing pages. It did nothing to narrow the FTC rule or state laws for products outside HIPAA.

State law added another layer. Washington’s My Health My Data Act and Nevada’s consumer health data law took effect in March 2024, with consent requirements that reach many of the same products. For a national organization, that means a single consumer health app may need to satisfy a federal breach rule and separate state consent rules at once. The product-by-product map described above stopped being a nice-to-have and became the only practical way to keep track.

Connecticut had already amended its privacy law in 2023 to cover consumer health data. Private lawsuits under the Washington law began to appear in 2025, often aimed at the software kits embedded in apps. At the federal level, HHS finalized a HIPAA rule on reproductive health privacy in April 2024, and a federal court in Texas vacated most of it in June 2025. Fertility and pregnancy apps, the products at the center of the Premom case, were left answering mostly to the FTC rule and the states.

Patient-directed data flows kept growing. CMS rules finalized in January 2024 required payers to stand up more APIs by 2027, and to report annual usage of their patient access interfaces starting in 2026. Each step moved more health data across the line the proposal described. More doorways out of the regulated health system mean more data landing in apps outside HIPAA, and more moments when a patient’s information changes regulators without anyone announcing it.

Federal enforcement priorities shifted in 2025, when Andrew Ferguson, one of the two dissenters, became chairman of the FTC, but the rule stayed in force. That distinction matters for leaders. Enforcement priorities can change with administrations; a rule on the books still defines what a breach is, still shapes what plaintiffs and state officials argue, and can be enforced again later for conduct that happened earlier. Building controls around who happens to be enforcing today is a short-term bet.

Health privacy obligations attach to products and data flows, not to an organization’s self-image. Classifying each product and flow remains the first task for any organization with a consumer-facing health product. Leaders who can see that map clearly, and who insist it is kept current as products change, are the ones who will be able to answer hard questions quickly when they come.