42 CFR Part 2
The federal regulation that protects substance use disorder treatment records with stricter confidentiality requirements than HIPAA — and the integration nightmare it creates for health systems.
42 CFR Part 2 (Confidentiality of Substance Use Disorder Patient Records) implements 42 U.S.C. § 290dd-2, which prohibits the disclosure of records of the identity, diagnosis, prognosis, or treatment of any patient in connection with a substance use disorder (SUD) treatment program, absent specific exceptions. SAMHSA's 2020 Final Rule modernized Part 2 for the era of health information exchange: it aligned the consent framework with HIPAA by allowing a general designation of "treating providers" rather than requiring patient-specific consent for each disclosure, and it permitted disclosure to health oversight agencies and for payment and operations purposes with consent. The 2024 omnibus rule further aligned Part 2 with HIPAA's treatment, payment, and operations (TPO) permissions, dramatically reducing the friction of Part 2 data in integrated care settings. However, key protections remain: Part 2 data cannot be used in criminal proceedings absent court order, cannot be re-disclosed without patient consent (or without flowing the prohibition-on-re-disclosure notice), and cannot be used against a patient in any civil, criminal, or administrative proceeding.
The engineering reality is that Part 2 data requires segmentation within health systems — it cannot flow freely through standard HIPAA-authorized disclosure channels. EHR systems must support data segmentation at the record, document, or note level, marking SUD treatment data separately and enforcing consent-based access controls. HL7's implementation guides for data segmentation for privacy (DS4P) provide a technical framework using sensitivity labels in FHIR (Confidentiality coding in meta.security) and HL7 v2 segments. In practice, most legacy EHRs have incomplete DS4P support, requiring middleware consent enforcement layers. A common failure pattern: a health system enables a FHIR Patient Access API under ONC certification without implementing consent filtering, inadvertently exposing Part 2-protected SUD records through the API to any authorized application — creating both a Part 2 violation and a potential criminal liability.
The 2024 alignment of Part 2 with HIPAA creates a new complexity: the same data may now flow for TPO purposes under HIPAA rules, but the Part 2 prohibition on use in legal proceedings still attaches to the data in the hands of the recipient. Systems must track data provenance — whether a particular record originated from a Part 2 program — to ensure re-disclosure restrictions are honored downstream. For care coordination platforms aggregating data from multiple sources, this means provenance tagging at ingestion and conditional disclosure logic that evaluates both consent status and receiving party identity. The intersection of Part 2 with TEFCA's exchange use cases is nuanced: the Individual Access Services use case permits patient-directed disclosure of Part 2 data, but other TEFCA use cases require case-by-case analysis against Part 2 consent requirements.
We implement Part 2 compliance through data segmentation architecture built on DS4P sensitivity labeling, with consent enforcement middleware that intercepts FHIR queries and filters results based on current consent status retrieved from a consent service. Our data ingestion pipelines tag records originating from Part 2 programs at source, carrying provenance through all downstream transformations. We build consent management interfaces that support the 2024 rule's broader consent designations while maintaining audit trails of every consent grant, revocation, and data access event involving Part 2 records.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.