# Beyond HIPAA: navigating state privacy laws and 42 CFR Part 2
A patient arrives in your emergency department after an overdose. The ED physician calls the patient's primary care doctor at an affiliated clinic to coordinate follow-up care and mentions the patient's history of opioid use disorder. Under HIPAA, that call is fine: treatment coordination is a permitted disclosure. But if that overdose history came from a federally assisted substance use disorder (SUD) treatment program, the same disclosure can violate 42 CFR Part 2 (a federal regulation, "Part 2" for short) and expose the hospital to liability.
Same patient. Same clinical intent. Two different legal outcomes. This is the core problem of healthcare privacy: HIPAA is a floor, not the whole building.
HIPAA (Health Insurance Portability and Accountability Act, 1996) sets baseline privacy and security rules for protected health information (PHI), meaning individually identifiable health data held by covered entities (hospitals, health plans) and their business associates.
The key HIPAA concept: TPO, which stands for Treatment, Payment, and healthcare Operations. HIPAA lets covered entities share PHI for TPO purposes without separate patient authorization. That is why the ED-to-clinic phone call is normally allowed.
HIPAA is enforced by the Office for Civil Rights (OCR) within the US Department of Health and Human Services (HHS). Civil penalties are tiered by culpability, and OCR publishes resolution agreements. You can browse real cases in the HHS OCR enforcement portal
Part 2 protects records from federally assisted SUD treatment programs. It exists because stigma around addiction can cost people jobs, custody, and housing, so Congress set a higher bar than HIPAA.
The critical difference: Part 2 generally requires patient consent even for treatment coordination. The TPO shortcut does not apply the same way.
Two important updates changed the landscape:
But "more aligned" does not mean "identical." Part 2 still restricts using SUD records in legal proceedings and still demands specific consent language.
The trap is data lineagedata lineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.View full definition →. Once a Part 2 record enters your electronic health record (EHR), how do downstream users know it came from a Part 2 source? Most EHRs were not built to tag data by regulatory origin.
Concrete example: a nurse pulls up a medication list that includes buprenorphine (a common opioid use disorder treatment). If that entry originated from a Part 2 program and lacks a consent flag, sharing that med list with an external provider could breach Part 2 even though HIPAA would allow it.
HIPAA and Part 2 are federal floors. States can and do go higher. When a state law is stricter, it wins (HIPAA preemption only overrides state laws that are less protective).
For a multi-state hospital system, this creates a compliance patchwork. A few real examples:
State reproductive-health privacy laws expanded sharply after 2022. Several states now restrict disclosing reproductive-care data to out-of-state investigators. A hospital system operating in both a restrictive and a protective state must route requests carefully.
Think of it as a stack. For any given data element, the effective rule is the most protective applicable layer:
Effective rule = strictest of:
HIPAA (federal floor)
+ 42 CFR Part 2 (if SUD-program origin)
+ State statute (CMIA, HB 300, MHMDA, etc.)
+ Consent scope on recordA worked example. A patient treated in your Washington facility for opioid use disorder, whose record is later requested by a clinic in Texas:
1. HIPAA: TPO disclosure permitted.
2. Part 2: applies (SUD program origin), so consent required unless an exception fits.
3. Washington MHMDA: consumer-health-data rules may apply to any app-sourced elements.
4. Result: you need valid Part 2 consent covering this disclosure. The strictest layer governs.
Rules on paper mean nothing if your data platform cannot enforce them. Three governance building blocks:
Every sensitive record needs metadata answering: What regulatory regime applies? What state was it collected in? What consent is on file?
A minimal tagging schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → in a data catalogdata catalogA centralized inventory of an organization's data assets, enriched with metadata, that helps people find, understand, and trust the data they need.View full definition → might look like this:
-- Sensitivity tags applied at ingestion
record_id | source_type | reg_regime | state | consent_id
-----------------+------------------+-------------+-------+-----------
RX-88213 | SUD_program | PART2 | WA | C-40021
LAB-55190 | general_clinic | HIPAA | TX | NULL
APP-10233 | wellness_app | MHMDA | WA | C-40109The reg_regime and consent_id columns are what let a downstream query block a disclosure automatically.
You need a system of record for consent that tracks scope, expiration, and revocation. Part 2 consent must name the recipient (or a class of recipients) and the purpose. When consent is revoked, downstream data flows must stop, which requires that revocation propagates to every system holding the data.
Where full tagging is not feasible, some systems segment Part 2 data into a separate, access-controlled zone. This is blunter but easier to audit.
Knowledge check
1. The lesson describes HIPAA as 'a floor, not the whole building.' What does this metaphor primarily convey?
2. In the opening scenario, why does the same ED-to-clinic phone call produce two different legal outcomes?
3. What is the underlying rationale for Part 2 setting a higher bar than HIPAA for SUD records?
4. Select ALL correct answers about how HIPAA's TPO provision functions.
Select all the correct answers.
5. Select ALL correct answers about the scope and enforcement of these privacy frameworks.
Select all the correct answers.
Governance is verified through checks, not intentions. Here is a concrete audit program for a multi-state system.
Run periodic queries on your EHR audit logs to detect disclosures of Part 2 data without a matching consent record. Pseudocode for the core check:
SELECT d.record_id, d.recipient, d.disclosure_date
FROM disclosures d
JOIN records r ON d.record_id = r.record_id
LEFT JOIN consents c
ON r.consent_id = c.consent_id
AND c.recipient = d.recipient
AND c.status = 'ACTIVE'
WHERE r.reg_regime = 'PART2'
AND c.consent_id IS NULL; -- disclosure with no valid consentAny rows returned are potential Part 2 violations to investigate.
HIPAA and state laws require sharing only the minimum data needed. Audit whether bulk exports (for example, to analytics vendors or AI model training) pull more fields than the stated purpose justifies.
If you claim data is de-identified (and therefore out of scope), verify it against the HIPAA Safe Harbor method, which requires removing 18 specific identifiers, or the Expert Determination method. Re-identification risk rises when you combine datasets, so test for it.
Every business associate agreement (BAA) is a liability channel. Check that vendors handling PHI or Part 2 data have current BAAs, and for Part 2, the newer contractual language required by the 2024 rule.
Build a decision log for disclosure requests that records the requesting state, the data-origin state, and the rule applied. This is your evidence if a reproductive-health or SUD disclosure is later challenged.
After OCR guidance on online tracking technologies, hospitals faced scrutiny for third-party pixels leaking PHI from patient portals and appointment pages. Audit your public-facing web properties for trackers that transmit health-related data to advertisers.