For payers
The CMS-0057-F clock is running. Consent is the hard part.
The rule's deadlines are a date on a calendar. The engineering underneath is the part that bites: who is allowed to see what, under which member consent, with substance-use data carved out and a clock on every prior-auth decision. HealthNext ships that as a first-class consent engine — not a checkbox bolted onto a data feed.
The access types the rule turns on
Three doors. One consent engine deciding who walks through.
CMS-0057-F is, underneath, an access-control problem. HealthNext models each access type as a first-class scope and resolves every request against the member's consent before any data moves.
Patient Access
A member retrieving their own coverage, claims, and clinical data. The consent engine resolves the request against the member's effective FHIR consent records before a single row is returned.
Modeled as a first-class access scope, resolved over FHIR consent semantics.
Provider Access
An in-network provider retrieving an attributed member's data for treatment. Attribution is not assumed — it is checked against a live Da Vinci attribution group at the instant of the request.
Requires a live Da Vinci member-attribution check; an unattributed provider is denied.
Payer-to-Payer
At the member's request, a prior or concurrent payer sharing data with a new payer. This one only proceeds on an explicit member opt-in — the engine refuses it without one.
Gated on an explicit member opt-in; refused by default without it.
Deny-overrides, by default
When a permit and a denial collide, the denial wins.
The consent engine implements FHIR consent semantics the HIPAA-safe way: only active consents are enforceable, the most specific matching provision wins, and a denial of equal specificity beats a permit. Across multiple active consents, any matching denial overrides any matching permit. The default when nothing matches is the consent's own default policy — not an implicit yes.
42 CFR Part 2
Substance-use data is special-protected at the gate.
Part 2 substance-use-disorder records carry protections beyond HIPAA. HealthNext treats them as a special-protection category at the fail-closed egress gate: the data is blocked to any unauthorized destination, and the block is sealed to the evidence chain — so the carve-out is provable, not just promised.
The prior-auth clock
The deadline is a property of the workflow, not a report.
Legacy tooling treats the SLA as a metric measured after the fact. HealthNext starts the clock when the request lands and routes the adverse path to a human inside the window.
- The SLA clockA prior-auth request starts the CMS-0057-F decision clock natively — 72 hours expedited, 7 days standard — and the adverse path routes to a licensed reviewer in-window, with the deadline tracked on the record.
- The human gateAn agent assembles the clinical evidence by retrieval and drafts a recommendation. It cannot issue an adverse determination — that call routes to a licensed reviewer, and the held decision is sealed before it takes effect.
What is partial — stated plainly
The consent engine and the special-protection carve-outs are real and tested. The CMS-facing prior-authorization API surface — the certified PARDD / X12-278 production endpoints a payer submits against — is carried as partial until those endpoints are certified. The demo runs the workflow end-to-end on synthetic data and is CMS-EDE-architected / readiness-mapped; it does not make live production submissions. We would rather you read this here than find it in diligence.
Bring your CMS-0057-F program. We'll run a workflow against it.
Pick one access flow — Patient, Provider, or Payer-to-Payer — and we will stand it up as governed agents in your boundary, with consent resolution and the Part 2 carve-out enforced from the first run.