Cloud Health Office can be the core, or sit in front of yours.
The FHIR and Da Vinci boundary is identical in both deployment patterns. What changes is which system owns the record — and that is exactly why the evidence scores product capability and external-core integration capability on two separate axes.
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.
Can a payer meet CMS-0057-F without replacing its core administration system?
Yes — and the choice is a deployment decision, not a different product. Cloud Health Office runs in two materially different patterns behind the same FHIR and Da Vinci boundary. What changes between them is who owns the record, and therefore what the evidence can honestly say.
Replace — Cloud Health Office is the backend
Cloud Health Office is the authoritative system of record for the workflow. Authorizations,
consent records, member history and prior-auth rules live in Cloud Health Office's own stores.
This is the default: Cms0057:Authorization:OperatingMode = "Replace".
Augment — Cloud Health Office in front of your core
Cloud Health Office provides the interoperability and API layer; the existing core administration platform stays authoritative. The FHIR surface external callers see is identical. What differs is where the answer comes from behind it.
A core gap is not a product gap
CMS-0057-F readiness has two independent dimensions, and collapsing them into one number is how compliance claims stop meaning anything. The acceptance suite scores them separately.
| Axis | The question it answers | Proven in |
|---|---|---|
| Product capability | Can Cloud Health Office itself perform the workflow?
Scored against the CHO-native backend, on synthetic data, at a named revision. |
Replace mode |
| Integration capability | Can Cloud Health Office perform the workflow against a specific external core right now?
Requires a live adapter for that core. The adapters in this repository are documented stubs. |
Augment mode |
So a scenario reads, for example, PAS-03 → CHO Replace: Passable; QNXT Augment: Gap. The Gap is real and is published rather than hidden — it says an adapter for that core has not been built in this repository, not that the prior-authorization workflow does not work.
Mode selection never falls back silently
A deployment configured for Augment does not quietly serve requests from the Cloud Health Office
backend when the external adapter is missing. AuthorizationBackendSelector fails loudly if
the configured backend is not registered, and GET /api/authorizations/backend-status
reports the mode and backend actually in force. A silent downgrade is the failure nobody notices,
because everything keeps working and the answers simply come from the wrong system.
Demo is a third thing, and is not a synonym for either
Demo is synthetic demonstration data. Replace is Cloud Health Office operating as the system of record. The FHIR projection layer defaults to Demo with synthetic data precisely so a deployment can never accidentally look live. The three are kept distinct in configuration so that no environment is ambiguous about which one it is in.
Implementation evidence
- Scenario axes
- Every scenario carries both a
replacestatus and a per-coreintegrationsstatus - Selector
src/engines/CloudHealthOffice.OperatingMode·AuthorizationBackendSelector- Adapter seam
IAuthorizationBackend—ChoAuthorizationBackend(Replace) andQnxtAuthorizationBackend(Augment, documented stub)- Documentation
- CMS0057-ACCEPTANCE-INVENTORY.md · OPERATING-MODE.md
- Pull requests
- #1144 made Cloud Health Office the native CMS-0057-F backend and introduced the Replace/Augment split
Every scenario, on both axes
The Replace column is product capability. Each Augment column is integration capability against one named external core, and is reported separately so the two can never be summed.
Loading the latest published CMS-0057-F acceptance evidence. It is generated in CI from the acceptance suite at a named source revision and committed to this repository, so the status shown here is the tested status rather than a claim typed into a page.
What is, and is not, evidenced for QNXT, Facets and HealthEdge
These names appear on this site because payers ask about them, and because Augment mode exists to sit in front of them. It is worth being exact about what that does and does not mean today.
Evidenced
- The seam exists: a single domain interface every backend implements, selected by explicit configuration.
- Augment is a scored dimension in the acceptance evidence, not an assertion in prose.
- Where an adapter is absent, the scenario reads Gap in that core's column, and the suite asserts the stub rather than papering over it.
- The FHIR and Da Vinci surface external callers see is the same in both modes.
Not evidenced
- No production integration with QNXT, Facets or HealthEdge is claimed or shown.
- The external-core adapters in this repository are documented stubs. Binding a customer's system of record is engagement work.
- Nothing here has been exercised against a licensed core administration platform.
- A Passable Replace status says nothing about how a specific core behaves behind an adapter.
For the workflow-level view of how CRD, DTR and PAS map onto an existing core, see CMS-0057-F with QNXT, Facets or HealthEdge. For the reference architecture behind both patterns, see CMS-0057-F implementation architecture. If you need the regulatory text itself rather than the implementation, the CMS-0057-F and QNXT guide on our sister reference site covers the requirement side.
Deciding which pattern fits a specific plan is an architecture question rather than a product one. Core administration advisory and the CMS-0057-F readiness and architecture assessment exist for exactly that decision, and neither requires licensing or deploying Cloud Health Office. Where the software runs is a separate decision again — see deployment and operating models.
What this page does not claim
- No production QNXT, Facets or HealthEdge integration is claimed. The adapters in this repository throw rather than pretend, and the acceptance suite asserts that they do.
- Augment evidence is separate from Replace capability and must not be read as either supporting or undermining it.
- An adapter built for one engagement is not evidence for another. Core administration deployments differ per plan, and a working integration is specific to the system it was built against.
- Replace-mode Passable is not CMS certification and does not establish production readiness for a particular payer deployment.
Work out which pattern your plan needs.
Replace and Augment start from the same FHIR boundary. Which one you deploy depends on what your core still owns.