In brief: A payer building the four CMS-0057-F APIs is building six shared layers: a FHIR data plane, identity and trust, matching and consent, bulk export, a prior authorization workflow plane, and a metrics plane. This post lays out a reference layout, the composition rules we propose for delegated review vendors behind a single endpoint, how the three access APIs share plumbing, an illustrative two-track pilot schedule, and CMS's own cost estimates next to what the WEDI surveys report.
The first four posts in this series explained the rule and the three prior-authorization guides one at a time. Real plans do not build them one at a time. They have a utilization-management system, a claims system, an enrollment feed, a pharmacy benefit manager, a handful of delegated review vendors, a FHIR server that was stood up for the 2021 Patient Access deadline, and a deadline of 1 January 2027 for four APIs that all touch the same data.
Our earlier posts on architecting a prior-auth workflow engine, build, buy or partner for CMS-0057-F, the Payer-to-Payer API and the Patient Access API cover pieces of this. This post is the architecture we use when we scope the whole: six planes, a reference layout of components, the composition rules that let delegated vendors sit behind a single endpoint, how the three access APIs ride on the same plumbing as prior authorization, a two-track delivery plan, and what it costs against CMS's own estimates.
The six planes
Every obligation in CMS-0057-F lands on one of six layers. Naming them keeps the program honest about what is shared and what is new.
- FHIR R4 data plane. US Core 6.1, CARIN Blue Button 2.1, PDex 2.1 and Plan-Net 1.2 profiles, populated by ETL from 837 claims, 834 eligibility, clinical feeds and utilization-management cases, refreshed within one business day. Most plans have a version of this from 2021; almost none have prior-authorization data in it yet, and the rule requires it in Patient Access from 2027.
- Identity and trust plane. SMART App Launch 2.0 for members' apps; SMART Backend Services, and increasingly UDAP, for providers and other payers; mutual TLS and dynamic client registration between payers.
- Matching and consent plane.
$member-matchfor Payer-to-Payer,$provider-member-matchfor attribution-based Provider Access,$bulk-member-matchfor the bulk flows; Consent profiles; opt-out (Provider Access) and opt-in (Payer-to-Payer) registries checked at request time. - Bulk export plane.
$exportand$davinci-data-export, Group management, NDJSON manifests, throttling. Provider Access and Payer-to-Payer both need it. - Prior-auth plane. A workflow engine that wears CRD, DTR and PAS on the outside and is bridged to the utilization-management system and the X12 278 path on the inside.
- Metrics plane. The nine public prior-authorization measures, the Patient Access usage reports to CMS, and the additions proposed in CMS-0062-P, all from one data mart that every decision writes to.
The planes are ordered by how much of each already exists. Planes one and two are usually partially built. Planes three to six are usually new.
The reference layout
Reading left to right:
- Edge. An API gateway that terminates TLS, validates tokens against the identity plane, rate-limits per client, and routes by path:
/cds-servicesto CRD,/Questionnaire/$questionnaire-packageto DTR,/Claim/$submitto PAS,/Patient/$member-matchto matching,/Group/*/$exportto bulk. - Facade services. One service per guide, each stateless, each speaking the guide's exact interface, each proven on the Inferno kit. This is the "one door" the EHR sees.
- Workflow engine. Owns the state of every prior-authorization request: received, acknowledged, routed, pended, decided, notified, retained. Talks to the requirement matrix and eligibility cache for CRD, the questionnaire packages for DTR, and the adjudication rules for PAS. Owns the fifteen-second acknowledgement and the subscription notifications.
- Policy content store. The catalog, questionnaires, CQL libraries and value sets from the DTR pipeline, versioned, keyed by code and product.
- Adapters. To the utilization-management system (case create, status, decision), to the X12 278 path through the clearinghouse, to each delegated vendor and the PBM, to the claims and enrollment systems for the caches.
- FHIR server and data mart. The R4 store for the access APIs, plus the metrics mart every decision writes to.
Nothing in this layout is exotic. What makes it work is the discipline that the facades speak only the guides, the engine owns state, and adapters absorb every legacy peculiarity.
Composition rules for delegated vendors
The rule regulates the plan, not its vendors. An EHR must see one CDS service, one DTR endpoint and one $submit, whoever decides.
These are the rules we propose. The token rule follows the CRD guide's privacy guidance; the others are design choices that CMS does not mandate, and a conformant external API can also be served by per-vendor adapters:
- Same specification, no bespoke contracts. Each vendor implements CRD, DTR and PAS exactly and proves it on Inferno. The plan's facade aggregates and routes; it does not translate. Bespoke per-vendor contracts multiply maintenance; there is no CMS certification either way, so the argument is operational rather than regulatory.
- Route by plan, product, and category. A routing table decides which vendor owns a request: imaging, genetic testing, DME, behavioral health, home health, drugs with the PBM. The plan answers for categories no vendor covers.
- Namespaced discovery. The aggregated
/cds-serviceslist carries each vendor's services with prefetch keys prefixed (vendor1_p1, vendor2_e1); the facade strips the prefix when routing so each vendor gets exactly what it declared. - Never forward the EHR token. The CRD guide says access tokens should not be forwarded to organizations outside the plan's audit boundary. The plan resolves what it needs from the EHR and hands vendors data, not credentials.
- Stateless what-if all the way down. A what-if hook makes no ledger entry at the plan or the vendor.
- The plan owns the ledger, subscriptions, retention and metrics. Vendors decide; the plan records. This is what keeps the public metrics correct and the six-month retention rule met when a vendor changes.
- Drugs are a special case. CMS-0062-P proposes drug prior authorization from 1 October 2027 on two rails: FHIR for the medical benefit, NCPDP SCRIPT for the pharmacy benefit. The PBM adapter has to speak both.
In this illustrative design, the payer routes work to appropriate reviewers and coordinates status, audit records and notifications. The diagram shows one representative return path; every reviewer response must be reconciled through the payer.
The access APIs on the same plumbing
The prior-auth plane gets the attention; the three access APIs are where most of the data work is.
- Patient Access (extended). Already live since 2021; from 2027 it must add prior-authorization requests and decisions, with status, dates, items, reasons and supporting documents, within one business day of any change, and the plan must report usage metrics to CMS. The workflow engine writes every state change into the FHIR store; that is the core of the integration, alongside the supporting-document requirements and the excluded elements (drug prior authorizations, provider remittances and enrollee cost-sharing) that differ by API.
- Provider Access. In-network providers with a treatment relationship pull claims, encounters, USCDI clinical data and prior-auth data in bulk, within one business day of request, with member opt-out honored. PDex 2.2.0 offers two attribution models: version one attribution lists maintained by the plan, and version two attestation through
$provider-member-match, followed by Group membership and$davinci-data-export. Consent is checked at execution, not at registration. - Payer-to-Payer. With member opt-in, the new plan requests five years of data from the old one: mutual TLS, dynamic registration,
$member-matchwith a Consent resource in the parameters (422 on a non-compliant consent), a member-scoped token, then export.$bulk-member-matchhandles enrollment season. PDex fixes the floor at five years (§pdex-130), requires prior authorizations with their unstructured documents (§pdex-133 and §pdex-134), per-member consent (§pdex-154a) and_typeFilteron export (§pdex-180d).
All three depend on the same FHIR store, the same identity plane, the same consent registry and the same bulk export service. Build those once.
Authenticate the caller, match the member, evaluate the applicable access policy and filter the permitted data before exporting. Consent and access rules differ by API and payer context.
An illustrative two-track pilot schedule
The program splits cleanly into a data track and a prior-auth track, with a shared foundation. The eight-week schedule below is an illustrative pilot plan: it assumes an existing FHIR data plane, staff on both tracks, an inventory of policies to start from and sandbox access already granted. Production readiness needs a scope-specific estimate.
- Weeks 1 and 2, foundation. Gateway, identity plane, consent registry, metrics mart schema, Inferno kits self-hosted, Foundry bundle running, VSAC and X12 licenses obtained, Epic and Oracle Health sandbox registrations filed. Policy catalog inventory started with the utilization-management team.
- Weeks 3 to 5, data track. Prior-auth data into the FHIR store; Patient Access extension; bulk export service; Provider Access attribution or attestation;
$member-matchand Payer-to-Payer sequence against a second sandbox payer. - Weeks 3 to 5, prior-auth track. CRD facade with requirement matrix and eligibility cache; delegate routing; first ten questionnaires and CQL libraries through the pipeline; PAS
$submitwith the workflow engine owning acknowledgement. - Weeks 6 and 7, integration. Subscriptions; updates, cancels,
$inquire; X12 278 adapter through the clearinghouse; vendor onboarding on the same specification; end-to-end runs on Acentra's sandbox and Epic's template apps. - Week 8, evidence. Inferno reports for all kits, connectathon results, the metrics mart producing the nine measures from test traffic, the endpoint publication ready for CMS's proposed sixty-day requirement.
Eight weeks covers the engineering of a pilot, not production hardening. Policy digitization runs alongside and continues after go-live; its pace is set by the utilization-management team, not by developers.
What it costs, against CMS's own numbers
CMS's regulatory impact analysis in the final rule estimated per-payer costs, and they are the reference point every buyer already has.
| Item | CMS estimate per payer (2024 RIA) |
|---|---|
| Prior Authorization API | about $1.14M |
| Provider Access API | about $270k |
| Payer-to-Payer API | about $96k |
| Total across impacted payers | about $1.56B |
WEDI's March 2026 readiness survey (linked in the Sources) found a quarter of responding payers expecting to spend over $5M, a tenth not yet started, and confidence in meeting the deadline falling from 69% to 47% in a year. The gap between the CMS estimate and the survey is mostly two things the RIA priced lightly: policy digitization, and integrating delegated vendors and the utilization-management system. Engineering the facades is the smaller share.
That is also why the platform-versus-build question is less important than it sounds. A FHIR server product covers plane one and part of plane two. Everything from the consent registry to the workflow engine to the policy pipeline is integration work whichever product sits underneath, and it is the work that determines whether the plan's public metrics improve or merely get published.
Decisions to make in week one
The architecture above leaves a dozen choices to the plan. These are the ones that cost the most to change later, so make them first.
- One engine or two. Whether prior-authorization state lives in a new workflow engine or in the existing utilization-management system. The engine wins where the UM system cannot acknowledge in fifteen seconds or expose subscriptions, which is almost always.
- Attribution or attestation for Provider Access. Version one attribution lists are simpler for the plan and harder for providers; version two attestation through
$provider-member-matchis what the 2.2 guide favors. - Native DTR, hosted DTR, or both. Publish packages that work in any client regardless; decide whether to also host a DTR service for delegated-vendor routing.
- Where consent is enforced. At the gateway per request, or in the export service per member. The guides require it at execution, so the export service is the safer place.
- Which FHIR server product, if any. Choose on bulk export throughput, R5-backport subscription support, and
_typeFilter, not on the profile count in the brochure. - The vendor content format. Questionnaires, CQL and routing rules in a format every delegate can deliver, decided before the first vendor is onboarded.
- Retention and audit. Six months minimum for PAS; the plan's own record-retention policy usually says longer; the metrics mart needs every decision for the calendar year.
- Identity for providers. SMART Backend Services alone, or UDAP as well. UDAP is where Payer-to-Payer and provider-facing exchange are heading.
- Endpoint publication. The public list, its format, and who owns keeping it current within the sixty days CMS-0062-P proposes.
- What is manual on day one. Which categories fall to a human queue while a vendor finishes, and how those requests still enter the engine so metrics stay correct.
- Drug prior authorization. Whether the PBM adapter is in scope for 2027 or held to the proposed October 2027 date.
- Who owns policy content. A named utilization-management lead with time allocated, or the program will stall on questionnaires while engineering waits.
How the design changes by payer type
The six planes are the same everywhere; the weight of each changes with who the payer is.
- A regional Medicare Advantage plan with an outsourced UM vendor and a FHIR server bought in 2021. The prior-auth plane is mostly the vendor's; the plan's work is the facade, the ledger, the metrics mart and the Patient Access extension. A short pilot is plausible if the vendor is engaged early.
- A Medicaid managed-care organization across several states. Each state contract carries its own prior-auth rules and, from CMS-0062-P, twenty-four-hour drug decisions. The routing table and the policy catalog are per state; the consent plane must reflect state law. Plan for content volume, not endpoint count.
- A qualified health plan issuer on the federal exchange. Exempt from the 2026 decision clocks but not from the 2027 APIs. Often shares platforms with a commercial book that is not impacted; the architecture should make the impacted lines a configuration, not a separate build.
- A UM or delegated-review vendor. Builds the prior-auth plane once and exposes it to many plans; needs multi-tenant routing, per-plan content, and Inferno reports it can hand to each client. The access APIs are not its problem.
- A clearinghouse. Owns the intermediary path and the hub; needs PAS pass-through, 278 and 275 translation, and subscriptions on behalf of thousands of providers, with the translator's end date in view.
If you want a second opinion on this architecture for your plan, we can review your platform choices, delegated-vendor plan and version matrix against the 2027 dates and the CMS-0062-P proposals. See our CMS-0057-F interoperability suite and healthcare interoperability pages, or talk to our team.
Explore the CMS-0057-F series
- CMS-0057-F Explained: Requirements and 2027 API Deadlines
- Da Vinci CRD Explained: Coverage Requirements Discovery
- Da Vinci DTR Explained: Questionnaires, CQL and Prior Authorization
- Da Vinci PAS Explained: FHIR Prior Authorization and X12 278
- CMS-0057-F Payer Architecture for Delegated Vendors (this article)
- CMS-0057-F API Testing: Inferno, Sandboxes and Evidence
Sources
- CMS-0057-F final rule, 89 FR 8758 (8 February 2024)
- CMS-0057-F rule text (PDF)
- CMS-0062-P proposed rule, Federal Register 2026-07205 (14 April 2026)
- CMS standards and implementation guides by API (updated 14 April 2026)
- CMS Prior Authorization API FAQs
- CMS Provider Access API FAQs
- CMS Patient Access API FAQs
- HL7 Da Vinci CRD 2.2.1 (current) and 2.1.0
- HL7 Da Vinci DTR 2.2.0 (current) and 2.1.0
- HL7 Da Vinci PAS 2.2.1 (current) and 2.1.0
- HL7 Da Vinci PDex 2.2.0
- PDex payer-to-payer exchange
- PDex Provider Access API v2
- HL7 Subscriptions R5 Backport
- WEDI survey, March 2026
- WEDI survey, December 2025
- Medblocks, CMS-0057-F Explained (Sidharth Ramesh, YouTube)
- UnitedHealthcare payer-to-payer API page
- HL7 US Core 6.1.0, SMART App Launch 2.0.0, Bulk Data Access 2.0.0, UDAP Security 1.0 (hl7.org).
- HL7 Da Vinci, WEDI and AHIP recorded sessions, 2025 to 2026.
