The FTC’s breach rule proposal drew the HIPAA line through the middle of a data flow
The FTC had already said health apps outside HIPAA owe breach notice for unauthorized sharing. Its May 2023 proposal mattered for its definitions, which showed that one patient’s data can change regulators as it moves between a hospital, a consumer product and an app.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On May 18, 2023, the Federal Trade Commission proposed amendments to its Health Breach Notification Rule. 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. 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, not only intrusions. It would also clarify what it means for a product to draw information from multiple sources, allow notice by email and other electronic means, and expand what notices must say. The FTC had brought its first case under the rule against GoodRx in February. The day before the proposal, it announced a second, against the developer of the fertility app Premom.
Earlier in this series we covered the FTC’s 2021 policy statement, which 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. 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.
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. 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.
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.
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. The question is no longer only whether the product was hacked. It is whether each data flow out of it was authorized, by whom, and when.
Mobile apps make that hard. Website tags can be scanned from outside. Mobile software development kits for analytics, crash reporting, attribution and advertising are compiled into the app and send data from the device. Many app teams could not list every kit in their current release, let alone what each sent. 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.
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. 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.
A health system or payer cannot generally refuse a patient’s request because it dislikes an app’s privacy practices. 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. Providers can do something similar at the authorization screen. 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.
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. Products launched by marketing, digital or commercial teams often get legal review once, at launch. The data flows change with every release. 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.
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. 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. Patient-directed data flows kept growing. CMS rules finalized in January 2024 required more payer APIs by 2027, and in July 2025 CMS gathered pledges from dozens of technology companies to expand patient-facing apps. Each step moved more health data across the line the proposal described. Federal enforcement priorities shifted after 2025, but the rule stayed in force. Classifying each product and flow remains the first task for any organization with a consumer-facing health product.