Healthcare Data Privacy Beyond HIPAA: State Laws, 42 CFR Part 2, and Cross-Border Considerations

HIPAA compliance is table stakes, not a finish line. Most healthcare software teams spend a project cycle mapping PHI flows, hardening access controls, and signing business associate agreements — then treat "we're HIPAA compliant" as the end of the privacy conversation. It isn't. The gap between HIPAA and the rest of the regulatory landscape is where a surprising amount of real legal exposure now lives.

State legislatures, the FTC, and federal rules that predate HIPAA have layered additional obligations on top of it — obligations that apply to different entities, data types, and thresholds than HIPAA does. A consumer mental health app, a telehealth platform serving patients in three states, or an SUD treatment program can all be fully HIPAA-compliant and still violate a state privacy statute, 42 CFR Part 2, or the FTC Health Breach Notification Rule. Understanding what sits beyond HIPAA is no longer optional due diligence — it's core architecture.

Table of Contents

• Why HIPAA Isn't the Whole Compliance Picture
• State Health Privacy Laws: CMIA, My Health My Data Act, and the Patchwork Problem
• 42 CFR Part 2: Substance Use Disorder Records and Heightened Consent Rules
• The FTC Health Breach Notification Rule and Non-HIPAA Health Apps
• Consumer Health Data Laws Beyond Washington: Nevada, Connecticut, and the Emerging Pattern
• Cross-Border Data Considerations for Telehealth and Global Health Tech
• Architecting Systems for Multi-Regime Compliance
• Governance, Vendor Management, and Ongoing Monitoring

Key Takeaways

• HIPAA only governs "covered entities" and their business associates, so a large share of consumer-facing health software — wellness apps, fertility trackers, mental health chatbots, direct-to-consumer lab and DNA services — falls outside HIPAA entirely and is instead regulated by the FTC and by state privacy laws.
• California's Confidentiality of Medical Information Act (CMIA) reaches further than HIPAA in-state, explicitly covering businesses that offer software or hardware for consumers to manage their own medical information, and it carries its own breach notification duties and a private right of action HIPAA does not provide.
• 42 CFR Part 2 imposes consent and redisclosure rules for substance use disorder records that remain more restrictive than general HIPAA practice even after 2024 rule changes aligned parts of the two frameworks, and it applies specifically to "Part 2 programs," not to every provider who happens to treat SUD patients.
• Newer state consumer health data laws, starting with Washington's My Health My Data Act, define "consumer health data" broadly enough to include location signals tied to health facilities, app usage, and inferences from non-clinical data — so products that never touch a medical record can still trigger consent and disclosure obligations.

Why HIPAA Isn't the Whole Compliance Picture

HIPAA's scope is defined by role, not data sensitivity. It applies to covered entities — health plans, clearinghouses, and providers who transmit health information electronically for covered transactions — and to their business associates. That framing made sense when health data mostly lived inside hospitals, insurers, and their contractors.

It makes far less sense today. A large volume of sensitive health information now flows through products that are legally not HIPAA covered entities: symptom checkers, fertility trackers, recovery wearables, direct-to-consumer genetic testing, AI mental health companions, and employer wellness portals outside a group health plan. That's a structural gap, not a loophole — and regulators have spent the last several years actively filling it with other tools.

For engineering teams, "are we a covered entity" is only the first question. Teams also need to ask what state their users are in, what kind of data they're collecting, and whether a rule outside HIPAA applies regardless of covered-entity status.

State Health Privacy Laws: CMIA, My Health My Data Act, and the Patchwork Problem

State health privacy law predates, and in some cases exceeds, HIPAA's protections. California's CMIA applies to providers and health plans much like HIPAA does, but also reaches businesses that offer software or hardware letting consumers manage their own medical information — language written to capture exactly the consumer health apps HIPAA misses. CMIA carries its own breach notification requirements and a private right of action, so individuals — not just regulators — can sue over a violation. Recent amendments extended CMIA-style protections toward genetic and reproductive health information, responding to concerns about app data identifying people who sought reproductive care.

Washington's My Health My Data Act (MHMDA), effective 2024, takes a different approach: it creates a new category, "consumer health data," broad enough to include data identifying a consumer's health status plus information reasonably linked to a health condition through inference — location near health facilities, purchase history, app-usage patterns. MHMDA requires affirmative consent for collection and most sharing, restricts geofencing around healthcare facilities, and — like CMIA — includes a private right of action.

The practical challenge for multi-state software is that these laws aren't harmonized. A feature compliant under one state's framework can trigger obligations under another, and a single national data model rarely satisfies every jurisdiction without a compliance layer built to reconcile them.

42 CFR Part 2: Substance Use Disorder Records and Heightened Consent Rules

42 CFR Part 2 is a federal confidentiality regime predating HIPAA that governs records from federally assisted programs providing substance use disorder diagnosis, treatment, or referral. It exists because SUD records carry unique risk — disclosure has historically been used in criminal proceedings, employment decisions, and custody disputes in ways other health information typically is not.

The core distinction from HIPAA is consent specificity. Historically, Part 2 required consent naming the specific recipient of a disclosure, rather than HIPAA's broader "treatment, payment, operations" consent. A 2024 final rule, mandated by the CARES Act, narrowed that gap by permitting a single consent to cover future TPO disclosures and aligning breach notification more closely with HIPAA. But the frameworks did not merge — Part 2 still imposes tighter redisclosure limits and restricts using SUD records in legal proceedings without authorization.

The scoping error engineering teams make most often is assuming Part 2 applies to any provider who treats SUD patients. It doesn't — Part 2 applies to federally assisted "Part 2 programs" that hold themselves out as providing SUD treatment. A general ER that occasionally treats overdose patients is typically not a Part 2 program the way a dedicated SUD facility is. Getting that determination right — with counsel, not engineering judgment — decides whether the data model needs a separate consent layer at all.

The FTC Health Breach Notification Rule and Non-HIPAA Health Apps

The FTC Health Breach Notification Rule fills a specific gap: it requires vendors of personal health records and related third parties that are not HIPAA covered entities to notify affected consumers, the FTC, and sometimes the media, following a breach of unsecured identifiable health information — exactly the category HIPAA does not reach.

The rule's relevance grew once the FTC clarified that it covers health apps and connected devices drawing information from multiple sources, not only formal personal health record services. A fertility tracker or wellness app combining user-entered data with a connected device's data can qualify as a "personal health record" under the rule. The FTC has also brought enforcement actions against health apps sharing sensitive data with advertisers without adequate disclosure — treating undisclosed sharing itself as a harm, independent of any breach.

The operational lesson: "we don't handle PHI as a covered entity" is not the same as "we have no breach notification obligation." Any product aggregating health-adjacent data from multiple sources should assume the rule may apply, and build notification workflows accordingly — before a breach tests the assumption.

Consumer Health Data Laws Beyond Washington: Nevada, Connecticut, and the Emerging Pattern

Washington was first, but not an outlier for long. Nevada passed its own consumer health data law around the same time, using a similar structure — broad definitions, consent requirements, geofencing restrictions — with some differences in scope from Washington's approach. Connecticut folded consumer health data protections into amendments to its broader state privacy law rather than passing a standalone statute.

The pattern worth tracking isn't any single statute but the direction of travel: legislatures are converging on the idea that "health data" deserves its own, stricter consent standard within general privacy law, broader than HIPAA's PHI definition. Comprehensive state privacy laws that aren't health-specific — Colorado, Virginia, and others — also typically classify health data as "sensitive data" requiring opt-in consent, adding a layer a HIPAA review alone won't surface.

For any nationally operating company, this makes a single-jurisdiction posture increasingly unworkable. The realistic answer isn't chasing each state's exact language, but building a classification and consent architecture flexible enough to apply the most protective standard by default.

Cross-Border Data Considerations for Telehealth and Global Health Tech

Telehealth and global health tech companies carry a further layer of complexity domestic-only compliance programs frequently underweight: HIPAA has essentially nothing to say about where data physically resides or who outside the U.S. may access it, but other regimes have a great deal to say about exactly that.

For any platform serving EU patients, the GDPR treats health data as a "special category" requiring an explicit legal basis — typically explicit consent — beyond its general standard for ordinary personal data. Cross-border transfer out of the EU requires a valid mechanism, such as the EU-U.S. Data Privacy Framework where the receiving company is certified, or standard contractual clauses with supplementary safeguards where it isn't. Similar concepts appear, with local variations, in the UK GDPR, Canada's PIPEDA, and Australia's Privacy Act.

A separate, consequential issue is data localization: several jurisdictions restrict or condition the export of health data outside their borders. Telehealth platforms need to determine, market by market, whether records must stay within the country of origin or may reside in shared regional infrastructure — a decision designed in from the start, not retrofitted later. Licensure adds a related wrinkle, since many telehealth regimes tie the legality of care delivery to the clinician's and patient's locations, which determines what consent language a session needs and which jurisdiction's breach rule governs it.

Architecting Systems for Multi-Regime Compliance

The technical answer to a fragmented regulatory landscape isn't a separate system per law — that doesn't scale past two or three jurisdictions. The more durable pattern is a data classification layer tagging information by sensitivity and origin (clinical PHI, SUD-related record, inferred health signal, biometric data) independent of which statute applies, paired with a policy engine mapping each classification to the union of obligations across every applicable framework. In practice, that typically means:

• Purpose-specific, revocable consent capture — not a single blanket acceptance — since CMIA, MHMDA, and Part 2 each define acceptable consent differently.
• Segmentation of SUD-related records with their own access controls and redisclosure tracking, distinct from general PHI.
• A breach notification workflow that doesn't assume HIPAA's timelines and thresholds are the only ones in play.
• Jurisdiction and residency awareness baked into the data model — tagging where a user is located and where their data may be stored.

Building this way costs more up front than assuming HIPAA compliance covers everything. It costs far less than retrofitting consent and segmentation logic after a state attorney general inquiry, an FTC complaint, or a Part 2 audit surfaces a gap engineering didn't know existed.

Governance, Vendor Management, and Ongoing Monitoring

None of this is a one-time engineering project. State consumer health data laws are a genuinely active area of legislation, and the FTC has shown sustained willingness to bring enforcement actions over data-sharing practices outside HIPAA's reach entirely. A compliance posture accurate a year ago shouldn't be assumed accurate today without a review cycle to confirm it.

Vendor and subprocessor management deserves particular attention, because these laws frequently extend obligations through the supply chain. A company careful about its own data handling but relying on vendors selected under HIPAA-only due diligence may still be exposed under CMIA, MHMDA, or the FTC rule if that vendor's practices don't hold up under the broader standard.

Practically, that argues for a standing governance function — a dedicated privacy team, a cross-functional committee, or an outside compliance partner — tracking state legislative activity, FTC enforcement trends, and Part 2 rule updates, and translating changes into engineering backlog items rather than static policy documents.

Solid HIPAA engineering discipline is necessary groundwork for everything covered here, but not sufficient on its own — for teams still solidifying that foundation, our guide to building HIPAA-compliant healthcare software is the right starting point, and it pairs well with the broader controls in our healthcare data security best practices guide. If your team is navigating state privacy law, 42 CFR Part 2, or cross-border telehealth data flows and wants an architecture review before those gaps become findings, get in touch with Halkwinds.

Frequently Asked Questions

Does HIPAA compliance automatically satisfy state health privacy laws like CMIA or Washington's My Health My Data Act?

No. HIPAA addresses covered entities and business associates handling PHI, but laws like CMIA and MHMDA apply to a broader set of businesses and add obligations — private rights of action, geofencing restrictions — HIPAA doesn't include. A company can be fully HIPAA-compliant and still violate an applicable state law.

Does 42 CFR Part 2 apply to every healthcare provider that treats patients with substance use disorders?

Not automatically. Part 2 applies to "Part 2 programs" — federally assisted entities that hold themselves out as providing SUD diagnosis, treatment, or referral. A provider that occasionally encounters SUD patients isn't necessarily a Part 2 program; determining status typically requires legal review.

Does the FTC Health Breach Notification Rule apply to our health app if we're not a HIPAA covered entity?

It can. The rule reaches vendors of personal health records outside HIPAA's scope, and the FTC has clarified this includes health apps and connected devices combining data from multiple sources. Not being a covered entity does not exempt an app from breach notification obligations.

What counts as "consumer health data" under laws like Washington's My Health My Data Act?

These laws generally define it broadly to include information identifying a consumer's health status, plus data that can reasonably be used to infer a health condition — location near health facilities, purchase history, app usage patterns — not just clinical records.

What's the biggest architectural mistake healthcare software teams make when addressing these laws?

Treating each law as a one-off checklist rather than building a shared data classification and consent architecture that can absorb new jurisdictions and statutes. Teams that bolt on point solutions per regulation typically end up rebuilding consent logic repeatedly as new laws take effect.