Most healthcare software treats consent the way a building treats a fire extinguisher. Required by code. Mounted on the wall. Inspected once a year. Useful when something goes wrong, but not part of how the building actually works.
That posture is workable in a single-provider, single-relationship clinical context. It breaks down the moment a workflow has to coordinate across more than one party. And in regulated, multi-stakeholder healthcare, almost every workflow has to.
The 2024 Final Rule revising 42 CFR Part 2 is in active enforcement as of February 2026. Programs that work with substance use disorder records are being held to a tighter, more explicit consent and disclosure standard than at any point in the regulation’s fifty-year history. The HHS Office for Civil Rights now runs a dedicated Part 2 civil enforcement program. Informal consent workflows are expensive in a way they were not before.
This is the moment to look at what consent architecture actually is, and why purpose-built platforms that treat it as foundation, not feature, are positioned to operate cleanly where bolted-on solutions cannot.
What 42 CFR Part 2 actually requires
42 CFR Part 2 is the federal regulation governing the confidentiality of substance use disorder treatment records. It has been on the books since 1975. Its premise is straightforward and unchanged: people seek treatment for substance use disorder more readily when they trust that the fact of their treatment will not be disclosed without their explicit, informed permission.
What changed in 2024 is the operating posture.
The Final Rule, published February 16, 2024 in the Federal Register, aligned Part 2 more closely with HIPAA in several practical ways. It permitted, for the first time, a single patient consent that covers all future uses and disclosures for treatment, payment, and health care operations (TPO). It required HIPAA-style notices. It introduced HIPAA-aligned breach notification. It created HHS investigative and enforcement authority for Part 2 violations, paralleling HIPAA enforcement.
Programs reading the alignment as “Part 2 is becoming HIPAA” missed the point. The Final Rule preserved Part 2’s distinctive consent regime for everything outside TPO. It strengthened the rules that protect Part 2 records in legal proceedings. It expanded the definition of what counts as a Part 2 record.
The net effect is that programs handling substance use disorder records now operate under two parallel consent regimes, depending on the disclosure: one consent posture for TPO, a different one for everything else. The regimes are not interchangeable. The records they govern are not interchangeable. The workflows the records support are not interchangeable.
This is the reality that consent architecture has to model.
Single-consent-for-TPO and category-based consent for non-TPO
The Final Rule allows a Part 2-covered program to obtain one written consent from the patient that covers all future TPO disclosures. This is a meaningful operational simplification for the day-to-day work of a program. A coordinator does not need to chase a fresh signature every time a billing entity needs a record.
Outside TPO, the rule is different. Disclosures to civil, criminal, administrative, or legislative proceedings still require explicit, purpose-bound consent. Disclosures to designated supports, employers, regulators, sponsors, family members, or other non-TPO recipients each require their own consent, scoped to the specific disclosure and the specific recipient.
The two regimes coexist inside a single workflow. A program coordinator at a physician health monitoring program may, on a single afternoon, send a treatment update to a primary care physician under TPO consent, send a compliance letter to the state medical board under non-TPO consent, and refuse a request from a malpractice attorney that lacks the specific judicial order Part 2 requires.
Software that treats consent as a single binary, either you have consent or you do not, cannot run this workflow. The coordinator has to either operate around the software or stop using it for anything that matters.
What architectural-grade consent looks like in software
The phrase “consent architecture” has a precise meaning. Consent is not a record in a database. Consent is the structure that determines what data flows are permissible, between which parties, for what purpose, under what time horizon, and on what evidentiary basis.
A platform that treats consent as architecture has six properties.
Consent records are scoped. Every consent record carries the enrollment it belongs to, the recipients it authorizes, the data categories it covers, the purposes it permits, the effective date, the expiration, and the revocation state. Consent is not “on” or “off” at the participant level. It is a structured, multi-dimensional record evaluated per disclosure.
Consent is separate from disclosure. The record of what a participant has consented to is not the same as the record of what has actually been disclosed. The two are linked but kept as separate concepts. A consent can exist without ever being acted on. A disclosure cannot exist without a corresponding consent that authorized it.
Disclosure is separate from access. Inside the program, role-based access governs what staff can see in the platform. Disclosure governs what leaves the platform to a third party. The two are different questions. Conflating them produces either workflows that are too restrictive (staff blocked from doing their work) or too permissive (data leaving the program without scoped authorization).
Consent is revocable, and revocation is enforced. A participant can revoke a non-TPO consent. The platform has to honor revocation forward in time, log the revocation event, and prevent further disclosures under the revoked consent without manual intervention. Revocation is a workflow primitive, not a support ticket.
Every disclosure carries audit-trail evidence. When a disclosure leaves the platform, the audit record captures who initiated it, what consent authorized it, what data categories were included, what recipient received it, and what purpose was stated. The record is structured, queryable, and tamper-evident. This is what makes the platform defensible in regulatory or evidentiary review.
The boundary between covered and uncovered is explicit. Some data on the platform is governed by Part 2. Other data is governed by HIPAA alone. The platform tracks which records carry Part 2 protection and applies the correct disclosure rules accordingly. Mixing the two regimes is one of the ways programs get into trouble.
These six properties are not features that can be added to an existing platform without disturbing the rest of the system. They are foundational. A platform either has them as the substrate everything else sits on, or it does not.
The QSOA and BAA contracting posture
Software architecture is not enough on its own. The platform vendor’s contracting posture has to match.
A program covered by Part 2 cannot lawfully share its records with a software vendor under a HIPAA Business Associate Agreement (BAA) alone. Part 2 requires a separate contracting instrument: the Qualified Service Organization Agreement (QSOA). The QSOA places the vendor inside the Part 2 regulatory perimeter, binds the vendor to Part 2’s restrictions on redisclosure, and establishes the legal basis for the vendor to handle Part 2 records on the program’s behalf.
Reweave Solutions, LLC executes a QSOA with every Part 2-covered program it serves. It also executes a BAA, because most clinical organizations operating Part 2 programs also handle HIPAA-protected records that are not Part 2 records. The two agreements work together. The QSOA covers the Part 2 records. The BAA covers the HIPAA records. Programs do not have to choose between regulatory coverage of one regime at the expense of the other.
This contracting posture is the legal counterpart to the architectural posture. Without both, a software vendor cannot credibly serve a Part 2-covered program.
Why this matters for buyers in regulated programs
Healthcare technology buyers evaluating platforms for regulated, multi-stakeholder programs are right to ask the consent question first.
Three diagnostic questions distinguish architectural-grade consent from the bolted-on alternative.
One. Show me the consent record. Ask the vendor to display the structure of a consent record in the platform. If the answer is a single boolean flag on a participant profile, the platform is not equipped for Part 2 work. If the answer is a structured record with enrollment, recipients, categories, purposes, dates, and revocation state, the platform is.
Two. Show me a disclosure with its provenance. Ask the vendor to display a disclosure event and trace it back through the consent that authorized it. If the connection is implicit or inferred, the audit posture is weak. If the connection is explicit and queryable, the audit posture is strong.
Three. Show me how the platform handles revocation. Ask what happens when a participant revokes a non-TPO consent. If revocation is a manual operation that requires staff to remember to reconfigure access, the platform is not enforcing the rules; the staff is. If revocation propagates automatically through the disclosure layer, the platform is doing the work.
The vendors that can answer these three questions cleanly are the ones built for the regulated, multi-stakeholder reality. The vendors that cannot are the ones that adapted general-purpose software to a specialized domain it was not designed for.
The Final Rule has tightened the difference. Programs that ran for years on consent-as-feature software are facing a posture shift that exposes the gap. Programs adopting platforms now have the chance to choose architectural-grade consent from the start.
Where Reweave Health stands on this
Reweave Care, the first platform under the Reweave Health umbrella, is built to operate as a substance use disorder program of record under Part 2. Consent is not a feature on the roadmap. It is the substrate the rest of the platform is built on. Disclosure boundaries are the architecture, not a convenience. Audit-trail rigor is the discipline, not a marketing line.
The clinical organizations and program administrators we partner with do not have to convince their counsel that the platform’s posture matches their regulatory obligations. The posture was the starting point.
If the consent question is the question your program is trying to answer, we should talk.