CMS-0057-F Acceptance Scenarios
Cloud Health Office is the claims platform you can put beside QNXT, Facets, or HealthEdge — so you hit the 2027 FHIR mandate without a core replacement.
This page is the definition of done for CMS-0057-F on Cloud Health Office: the scenarios we prove, the architecture behind them, where a QNXT, Facets, or HealthEdge integration is engagement work, and how each scenario is scored today.
CMS-0057-F, stated plainly
CMS-0057-F is the federal rule that requires Medicare Advantage, Medicaid, CHIP, and some exchange plans to offer FHIR APIs for patient access, provider access, payer-to-payer exchange, and prior authorization by January 1, 2027.
Operational rules are already live; the FHIR APIs go live in 2027
CMS-0057-F has two deadlines. The prior-authorization operating rules apply now; the four FHIR APIs are the January 1, 2027 milestone. The acceptance scenarios are grouped so a plan can see both at once.
Already live — operational rules
In effect since Jan 1, 2026- 72-hour expedited and 7-calendar-day standard decision timeframes, with received and decision timestamps that make the clock auditable.
- A specific, coded denial reason on every denial or partial — never a bare "not medically necessary."
- Public prior-authorization metrics posted by March 31 each year; the first cycle covered CY2025 and was due March 31, 2026. Metrics exclude drugs.
- QHP issuers on the federally facilitated exchanges are exempt from the decision-time clocks, but not from the specific-reason, metrics, or API obligations.
2027 go-live — FHIR APIs
Due Jan 1, 2027- Patient Access API, including prior-authorization data (drugs excluded), updated within one business day and retained at least one year after the last status change.
- Provider Access API for attributed members, with attribution enforced and patient opt-out honored.
- Payer-to-Payer exchange with a five-year date-of-service lookback, remittances and enrollee cost-sharing excluded, drugs excluded from the prior-auth slice, and opt-in required.
- Prior Authorization API built on Da Vinci CRD, DTR, and PAS.
The architecture the scenarios exercise
Cloud Health Office ships the FHIR surface, implementation-guide handling, consent and identity plumbing, the prior-authorization decision path, and the acceptance suite. A source-system integration — QNXT, Facets, or HealthEdge — is added per engagement behind the same stable FHIR boundary.
CRD
CDS Hooks order-select and order-sign return a card that says whether prior authorization is required, with the governing rule identified.
DTR
The right Questionnaire for the service; a completed QuestionnaireResponse validates and carries forward into the PAS request.
PAS
A FHIR prior-authorization request produces a decision with a tracking id, a coded reason on denial, and priority-aware decision timing.
Patient & Provider Access
US Core and CARIN projections for the member; attribution and opt-out gate what a provider can read.
Security & consent
SMART on FHIR / OAuth discovery, and a single consent registry for opt-out and opt-in lifecycle.
Source-system boundary
QNXT, Facets, or HealthEdge is integrated per engagement. Where that binding is not yet built, the scenario is scored honestly below.
Cloud Health Office as the core backend, or in front of your core
Cloud Health Office supports two patterns behind the same FHIR contract. A plan can start with either and move between them per workflow.
Cloud Health Office as the core backend
Replace mode- Cloud Health Office owns the operational record and the workflow. For prior authorization, a request is created, persisted, and tracked in Cloud Health Office — no legacy core is required.
- Prior authorization runs this way today: submission creates and stores an authorization, the decision and status history are persisted, and metrics derive from that stored record.
Cloud Health Office in front of your core
Augment mode- Cloud Health Office serves the FHIR and compliance surface while an existing core administration system — QNXT, Facets, or HealthEdge — remains the system of record, connected through an implementation-specific adapter.
- Those adapters are per-engagement work. Where an adapter is not yet built, the acceptance suite reports it as an integration gap — it is never a silent fallback to demonstration data.
These are separate questions. Whether Cloud Health Office can perform a workflow itself (product capability, proven in Replace mode) is scored independently from whether it can currently run against a specific external core (integration capability). A pending QNXT, Facets, or HealthEdge integration is not a gap in the Cloud Health Office product.
The scenario inventory, and what each one proves
These are the twenty-one scenarios the acceptance suite defines. This table says what each one proves; it deliberately carries no status column, because status belongs to the published snapshot below — generated from an actual run of the suite at a named source revision, rather than typed into a page where it can quietly fall behind the code.
| ID | What the scenario proves |
|---|---|
| PAS-01 | CRD — is prior authorization required? The order-sign CRD service answers with a coverage determination: covered, whether prior authorization is needed, and — when documentation is wanted — the questionnaire canonical to follow. |
| PAS-02 | DTR — correct documentation The questionnaire the payer named is retrieved through $questionnaire-package, and a completed response validates and is consumable by PAS. |
| PAS-03 | PAS submit — create prior authorization A prior-auth request yields a decision, an authorization number carried as preAuthRef, and the requested service detail. |
| PAS-04 | PAS inquiry / status Claim/$inquire reads the authorization record as a projection — no store and no status of its own. The authorization number alone is never sufficient: a corroborating key must match. |
| PAS-05 | PAS specific denial reason Denials and partial decisions carry a coded reason — never a bare “not medically necessary.” |
| PAS-06 | PAS decision timeframe (72h / 7 calendar days) Expedited versus standard priority is preserved, and timestamps make the 72-hour and 7-calendar-day clocks auditable. |
| PAS-07 | CDex additional-information exchange A pended A4 decision that names required documentation raises a CDex Task Attachment Request; the provider answers with $submit-attachment and the authorization returns to review. |
| PAS-08 | Drug exclusion from medical PA scope Pharmacy prior authorization stays outside the CMS-0057-F medical scope, and the exclusion is enforced rather than documented. |
| PROV-01 | Provider Access — attributed member data pull Member, claims and prior-authorization data assembled for a provider the member is attributed to. |
| PROV-02 | Provider Access — attribution enforcement A non-attributed member returns no data, and the refusal is indistinguishable from every other refusal. |
| PROV-03 | Provider Access — patient opt-out honored A member's opt-out withholds provider access, evaluated at the authorization instant rather than a caller-supplied time. |
| P2P-01 | Payer-to-Payer inbound respond Cloud Health Office serves Patient/$member-match and $member-data-export as the prior payer, gated by the member's Payer-to-Payer consent. |
| P2P-02 | Payer-to-Payer outbound initiate A coverage transition initiates an exchange against a payer resolved from configuration, and reaches Completed only once the returned package is durably ingested. |
| P2P-03 | Payer-to-Payer opt-in enforcement Payer-to-Payer has its own consent purpose. An Active consent recorded for another purpose authorizes nothing, and consent is never supplied by a caller. |
| P2P-04 | Payer-to-Payer member-match / concurrent coverage Deterministic member matching, with no match and ambiguous match both terminal, and overlapping coverage refusing rather than guessing. |
| PAT-01 | Patient Access — member claims / CARIN EOB Member claims projected to a CARIN Blue Button ExplanationOfBenefit. |
| PAT-02 | Patient Access — US Core clinical Twelve USCDI clinical resource types stored durably and served through Patient and Provider Access. This is FHIR R4 resource support, not US Core profile certification. |
| PAT-03 | Patient Access — PA data (drugs excluded) Prior-authorization data retained durably and served through Patient Access, with drug items excluded. |
| SEC-01 | SMART on FHIR / OAuth Explicit Demo versus ExternalIssuer mode with no production fallback, issuer-first trust resolution, per-issuer audience and algorithms, JWKS discovery and bounded rotation. |
| CONSENT-01 | Single consent registry One registry and one policy for both purposes, so Provider Access and Payer-to-Payer can neither imply nor widen one another. |
| METRICS-01 | Prior-authorization public metric set Decision times and coded reasons feed the CMS public prior-authorization metric set. |
Each scenario is scored on two independent dimensions: Cloud Health Office as the native backend (Replace, product capability) and integration with an external core (Augment, integration capability). A gap on one is not a gap on the other — see Replace vs Augment. For the workflows behind these scenarios, read the Payer-to-Payer implementation evidence, the CRD, DTR and PAS workflow evidence and the Provider Access security evidence. Exchanges performed against an independently developed HL7 Da Vinci implementation are reported separately, and never merged into these statuses: see Da Vinci interoperability evidence.
Latest published evidence
This snapshot is generated by CI from the acceptance suite on a specific source revision, then published here. Capability status is what the tested code supports; it is kept separate from raw test execution — a passing test that confirms a known gap is reported as a Gap, never as a pass. Cloud Health Office Replace is the product capability; the external-core column is integration capability, reported separately.
Loading the latest published evidence snapshot… If it does not appear, view the scenario scoring above or the compliance inventory in the repository.
Where a source-system integration is engagement work
Cloud Health Office ships the FHIR surface and the decision path. Reading from or writing to an existing core admin system is a per-engagement integration. Today those source-system adapters are placeholders, so the acceptance suite scores them as gaps rather than claiming them.
Benefit / auth rules
PAS-01 runs on the Cloud Health Office rule store today. Sourcing per-plan rules from the core system is engagement work.
Authorization create
PAS-03 decisions persist to the Cloud Health Office authorization store. Writing the authorization into the core system is engagement work.
Provider directory
Provider Access runs on Cloud Health Office data today. Pulling the core provider directory is engagement work.
Member claims
Patient Access projects Cloud Health Office claims to CARIN. Sourcing claims from the core system is engagement work.
The current source-system adapters are placeholders. Cloud Health Office does not claim production readiness against a specific core admin system until that integration is delivered for the engagement.
What varies by engagement
Some scenarios depend on choices a specific plan makes — the core admin system, the identity provider, the benefit configuration. Those are flagged so a readiness review starts with the right questions.
Source system
PAS-01, PAS-03, PROV-01, PAT-01, and METRICS-01 vary with the core admin system being integrated.
Identity provider
SEC-01 varies with the customer's identity provider; the SMART discovery contract stays constant.
Benefit & rules
Which services require prior authorization is a plan-specific configuration behind the same CRD and PAS contract.
Consent policy
Opt-out and opt-in policy for Provider Access and Payer-to-Payer are configured per plan on one registry.
How we know a scenario is done
A scenario is done when it is proven by an executable acceptance test against the real services, on synthetic data, with an honest status. Nothing is marked complete because a document says so.
Executable, not asserted
Every scenario is an automated test in the solution, tagged by scenario id, run in the default compliance mode.
Happy path and negative path
Prior-auth scenarios prove both a valid flow and at least one rejection — unknown member, inactive provider, unknown code, invalid response, missing consent, or attribution miss.
Gaps are tests too
A gap is a test that confirms the gap still exists, so it cannot be silently claimed as done.
Operational rules and 2027 APIs split
The already-live decision, reason, and metrics rules are proven separately from the 2027 FHIR API surface.
Synthetic data only
Scenarios run on synthetic members and providers — no protected health information.
Honest scoring
Passable, partial, and gap are used precisely, and the source-system integration is always called out as engagement work.
Versioned evidence
CI generates acceptance evidence tied to a specific source revision and publishes a sanitized snapshot — shown above under Latest published evidence — separating product capability from external-core integration capability.
Prove your CMS-0057-F readiness against real code.
Walk the acceptance scenarios against your plan's core system, identity provider, and benefit configuration on a readiness review.