🏥 Should HIPAA cover health apps?
 |
||||||
|
||||||
|
|
||||||
Happy Thursday, Hospitalogists. Was this email forwarded to you? Sponsored by Capacity Health CMS is making ED flow, boarding, and timeliness more visible and consequential. Beginning in 2027, ECAT brings four ED access and timeliness measures into the HOQR framework, tying reporting requirements to 2% of a hospital's Medicare outpatient payment. Improving those measures takes more than chart review, post-hoc reporting, or legacy CDS. It requires clinical decision support built from the patient up, scaled across the department and system. Capacity Health turns the data your hospital already collects into a connected view of every patient and the ED—clinical history, monitoring, interventions, and results into one explainable picture at the point of decision. Clinicians get patient-specific information and evidence. Operational leaders get real-time visibility into flow, boarding, and ECAT performance so teams can see where delays begin, prioritize action, and improve throughput. ECAT measures the bottlenecks. Capacity Health helps you improve them. GUEST POST Stop Trying to Make HIPAA Do a Job It Was Never Built ForWhy “leveling the playing field” by extending HIPAA to consumer health apps would lower the floor, not raise it By Lucia Savage, Principal at Savage Healthcare Strategies, and Deven McGraw, Chief Regulatory & Privacy Officer at Citizen Health Executive Summary
Every time a health app, wearable, or AI symptom-checker makes headlines for something a consumer didn't expect, the same reflex follows: entities covered by HIPAA — hospitals, health plans, their business associates — argue it isn't fair that they live under a comprehensive federal privacy law while consumer-facing apps live under nothing. Level the playing field, they say. Extend HIPAA. It is an understandable complaint. It is also the wrong fix, for a simple reason: HIPAA was never built to protect consumers from apps. It was built to let hospitals, health plans, and their contractors move clinical and payment data through the healthcare system to support individual and population health, without asking the patient’s permission every time. Import that architecture into a consumer product with no treatment or health plan relationship, and you don't raise consumer protection to HIPAA's level. Instead, you import HIPAA's permissive uses and disclosures into a space where there is no need for them. In healthcare, most patients expect their records to move, without the individual consenting each time, in specific, familiar ways — to pay for their care, to satisfy public health reporting duties, to coordinate treatment among providers. A consumer’s expectations for an app are different. Consumers choose apps to serve their purposes — to help them better manage care at home, coordinate care with loved ones, or even to facilitate research or connect with others like them through social networking. As a result, the permissive use and disclosure defaults of HIPAA, designed to facilitate payment for care and population health management, but not consumer purposes, could authorize far more surprising, unconsented uses and disclosures. Meanwhile, apps would get to point to HIPAA compliance as a shield and potentially avoid state consumer health privacy law, while patients would gain fewer privacy rights than they already have in most states today. (See Table 1 for a sample of health apps and platforms, their stated purpose, and an excerpt of their privacy policy or privacy commitments.) 
In fact, we don’t have to import HIPAA’s permitted disclosures into how consumer apps operate because better, more fitting rules for such apps have emerged. And, they emerged and became nearly nationwide without Congressional legislative action. The FTC has already turned its 2024 health-breach rule amendments into a functional consent requirement for apps that collect consumer health data. Furthermore, 23 (and counting) states have enacted real consent-and-rights regimes where Congress hasn't acted. And finally, frameworks — TEFCA's Individual Access Service requirements and the CARIN Alliance Code of Conduct — have converged on a transparency-and-consent model built for exactly this kind of entity. It is not the wild west anymore. It's just not HIPAA, and it shouldn't be. 1. The myth: HIPAA isn't the privacy gold standard it's assumed to beHIPAA gets rhetorical credit for protections it doesn't actually provide. Its Privacy Rule permits covered entities (and, with contractual permission from the covered entities, their business associates) to use and disclose identifiable health information for treatment, payment, and healthcare operations (TPO) without asking the patient first. On top of TPO, the Privacy Rule lists twelve additional categories of use and disclosure that require neither authorization nor, in most cases, any opportunity to object (see box). Add to that HIPAA's permission to de-identify data and then sell or share it freely, with no obligation to tell the patient who buys it or what they do with it, and you have a system that often surprises consumers with its lack of privacy controls. 
None of this is a bug. Inside a hospital or health plan, a rule that lets clinicians share records for treatment, lets a health plan process a claim, and lets a health department respond to an outbreak — all without a fresh authorization each time — is exactly right. That's the job HIPAA was built to do. But none of it was designed with a consumer-facing app, and their distinct purposes, in mind, and none of it should be held up as the standard apps are falling short of. An app operating under HIPAA's actual permitted-use architecture could use and disclose a user's data for a dozen purposes the user never agreed to. A covered entity can sell de-identified data with no disclosure to the individual of who is the buyer or the purpose of the sale, for example. And a HIPAA covered entity can satisfy its transparency obligation with a notice that describes what it's allowed to do rather than what it's actually doing — because that's all that HIPAA's Notice of Privacy Practices requires. That is not a stronger regime than what many consumer apps already face. In a growing number of states, it's considerably weaker. 2. The FTC has already stepped into the gapWhile Congress has spent years failing to pass a general consumer privacy law, the FTC has done something more consequential than it gets credit for. The Health Breach Notification Rule (HBNR) dates to 2009, when HITECH gave the FTC authority to require breach notification from PHR vendors and other entities outside HIPAA's reach. From the start, and building on the FTC's historic consumer protection authority, which is quite broad, the statute — and the FTC's original rule implementing it — defined a “breach of security” broadly, as any unauthorized acquisition of a person's health information. “Breach” was never limited to hacking. But for over a decade, the FTC's own guidance and enforcement stayed focused on conventional security incidents — stolen laptops, unauthorized database access — rather than a company's own data-sharing choices. In a September 2021 policy statement, the FTC made explicit for the first time that this same 2009 language also reaches a disclosure by a company that the consumer did not authorize. For example, a breach would occur if an app shared health data with an ad network without the user's authorization, regardless of whether or not a single server of the app company was ever compromised. Effective in 2024 the FTC updated and amended its regulations. Those amendments then wrote that 2021 reading directly into the rule's text. It also expanded the rule's coverage to unambiguously include health apps, wearables, and connected devices, and specifically confirmed that unauthorized sharing for ad-targeting qualifies as a breach. The legal mechanism is still breach notification; a company doesn't have to obtain consent before collecting data under the rule's text. But the practical effect is that any PHR vendor that goes live without building consumer authorization into its data practices is already in breach on day one, before anything resembling a hack ever happens. The FTC's enforcement actions against GoodRx, Premom, and BetterHelp — brought under the 2021 policy statement, ahead of the rule text itself — show this isn't theoretical. In fact, on July 29, 2026, the FTC sued HIMS/HERS for privacy violations and unfair practices to consumers, in part under its 2024 rule. The HBNR doesn't give consumers a rights bundle. For example, there is no standalone right to access, correct, or delete, no real-time opt-out a consumer can invoke directly. But it is the only nationwide federal framework reaching consumer health apps directly, it applies no minimum threshold on how big or large the app company is, and it has already produced real money fines and real behavior change. That's a meaningfully different landscape than “no cop on the beat.” 3. States have filled the void Congress left openWhere Congress has stalled, states have not. For example, Washington's My Health My Data Act and Nevada's SB 370 apply to any entity collecting consumer health data about their residents, with no minimum size of the business for applicability. Both also require affirmative opt-in consent before collection, the opposite default from HIPAA's permitted-use model. As of summer 2026, there are 23 states that have enacted comprehensive consumer privacy laws that cover health information outside HIPAA, although the laws take effect at various points in time. Most of these have adopted a common framework that treats health data as “sensitive” and requires opt-in consent before it can be processed at all (even by the app developer). In practice, this covers most sales and disclosures of health data before any separate sale-specific right even comes into play. Ordinary, non-sensitive personal data gets a lighter opt-out right instead. On top of that consent architecture, these states build in a full consumer rights bundle: access, correction, deletion, portability, and opt-out of targeted advertising. These rights are enforced by state attorneys general (and, in Washington, backed by a private right of action). California layers California Consumer Privacy Act/California Privacy Rights Act on top of California’s Confidentiality of Medical Information Act for an even broader net. Washington's My Health My Data Act and Nevada's SB 370 also explicitly reach categories HIPAA doesn't: both define “consumer health data” broadly enough to include inferred and derived health information generated by algorithms or machine learning, precise geolocation data indicating health-seeking behavior (with geofencing near medical facilities separately prohibited for data collection or advertising), and biometric and genetic data, none of which is “protected health information” under HIPAA unless it happens to be held by a covered entity and meets the definition of PHI. These laws aren't perfect — most carry revenue or consumer-count thresholds that let smaller apps slip through. And enforcement varies more than a simple “private right of action or not” split suggests: Washington's Consumer Protection Act gives consumers the broadest private right of action, reaching data-sharing violations generally. California's is narrower, limited to statutory breach damages under the CCPA/CMIA, with most other CCPA/CPRA violations enforced by the California Privacy Protection Agency and the state AG. And the common-framework states rely on AG enforcement, with per-violation civil penalty authority — commonly $7,500–$20,000 for intentional violations — doing the real deterrent work in the absence of a private right of action. But structurally, these laws get the model right for a consumer health app (with those expectations different than traditional healthcare) in a way a HIPAA-style extension would not: consent as the default, not the exception; rights that travel with the data regardless of who's holding it; and coverage of the inferred, behavioral, and location-based health data described above — the exact data types Washington's and Nevada's “consumer health data” definitions were written to reach — which HIPAA's framework doesn’t specifically address. 4. Voluntary standards are doing real work, tooThe fourth leg of voluntary standards is easy to dismiss as unenforceable window dressing, and it isn't. TEFCA's Individual Access Service Provider Requirements — a contractually binding standard for any entity offering individual access services inside the TEFCA network — and the CARIN Alliance Code of Conduct, a voluntary code that consumer-facing apps publicly attest to, converge on the same architecture: a public, plain-language privacy notice; informed consent before use and disclosure; advance notice of material changes to data policies; a right to deletion and to a machine-readable export; a low-burden way to revoke consent; encryption and contractual flow-down obligations to vendors; and a documented complaint process. The two frameworks didn't develop these principles independently, either. The TEFCA IAS SOP's own definition of a “material change” to a privacy notice is adapted directly from CARIN's. The TEFCA SOP goes further than CARIN in several places that matter for anyone actually operating inside a health information network: breach notification content requirements; notice obligations when law enforcement compels disclosure; fee transparency; and a secured, auditable consent log. CARIN, in turn, reaches some things TEFCA doesn't: data collectors must be fully transparent and have consent for uses of data for automated decision-making affecting lending, housing, or employment; correction and annotation rights; provenance tracking; transparency around whether and how de-identified data is used and disclosed; and Children’s Online Privacy Protection Act compliance. Between them, a consumer app that takes both seriously — and a growing number do, because CARIN attestation and TEFCA participation both carry real market and network consequences — is already operating under a notice-and-consent regime that is, in important respects, more privacy protective than what HIPAA requires of the hospital down the street. None of this is enforced the way HIPAA is enforced by HHS's Office for Civil Rights, but it isn't unenforced, either. An app that publicly attests to the CARIN Code and then doesn't follow it, or a TEFCA participant that represents itself as meeting the IAS SOP and doesn't, has made a public commitment it isn't keeping. A company NOT following its public commitment is precisely the kind of deceptive practice the FTC can already reach under its existing “unfair or deceptive practices” authority, the same authority behind its GoodRx and BetterHelp actions. That's a real, if less centralized, enforcement backstop than HHS's OCR. Therefore, an honest critique of the voluntary layer is that its teeth belong to the FTC, not that it is toothless. The fix for a voluntary standard that could use more enforcement is to make that enforcement path more consistent or level up the consequences of non-compliance. Applying HIPAA to health apps is not the right fix. 5. Getting the prescription rightPut the four pieces together and the honest picture is this: HIPAA remains the right framework for the entities it was built for: providers, health plans, clearinghouses, and their business associates, moving data for treatment, payment, operations, public health, and other purposes important to a functioning healthcare system. It is not, and was never meant to be, a consumer privacy law. Forcing consumer apps into HIPAA wouldn't raise the floor for consumers who use those apps, either. This is because most consumer apps already answer to real, if uneven, state consent laws, an FTC backstop with teeth, and a converging voluntary standard doing real work. Replacing the state law/FTC/voluntary standards through TEFCA with HIPAA would result in lower standards for consumers, not higher. We need to get the diagnosis right before we consider any federal legislative cure. And the diagnosis is that there already is a significant and growing body of law to protect consumer privacy when they use health apps. Federal legislative approaches that impose HIPAA or even HIPAA-like provisions on the consumer health data space doesn’t level the playing field. It tilts it the wrong way, trading rights consumers already have under FTC rules and in a growing number of states for a more permissive structure that expressly allows data to move without consumer consent. In 2016, ONC in conjunction with substantial input from OCR and FTC, reported to Congress on how consumer health data was regulated outside HIPAA. But since then, there has been a legal sea-change, as discussed above. For example, now the state laws cover 23 states and more than 50% of US residents. The apps ecosystem isn't the wild west it was in 2016. It's time the policy debate caught up with that fact and built the next generation of health privacy law on the model that's already working, rather than the one that was never meant to apply. Sponsored by R1 Most revenue cycle vendors sell AI while denials, yield, and days to collect barely move. Your revenue cycle needs an outcomes company: one accountable for the denial rate, yield, time to collect, and cost to collect. That's what R1 built with Phare, healthcare's first Revenue Operating System. See how R1 is building toward healthcare finance where the answer arrives at the speed of care — claims adjudicated in near real time, collapsing the rework loop that drains billions from providers and erodes trust industry-wide. Big thanks again to Lucia Savage and Deven McGraw for taking the time to put this together and share their insights with all of you. Two people with this much regulatory scar tissue don't hand out takes like this for free, so go give them a follow on LinkedIn if you found this useful. That's it for me today. Talk soon. |
||||||
|
No comments