Practical architecture and implementation guidance for health plans preparing for CMS-0057-F.
Explore FHIR APIs, CRD, DTR, PAS, terminology services, prior authorization, and modernization strategies for QNXT, Facets, HealthEdge, and other payer core administration platforms.
The foundational article for this series — how Cloud Health Office implements CRD, DTR, PAS, and terminology alongside a legacy core, and how the same architecture can eventually become the payer core backend.
How health plans can meet modern FHIR prior-authorization requirements without a rip-and-replace core transformation — and how the same architecture can eventually replace the legacy core when the payer is ready.
Read the architecture article →
Coverage Requirements Discovery through CDS Hooks — what the payer requires at order-select and order-sign.
Documentation Templates & Rules — Questionnaire and QuestionnaireResponse workflows to collect what a provider must supply.
Prior Authorization Support — FHIR Claim/$submit with validation, provider verification, and decisioning.
FHIR-native SNOMED CT, CPT, HCPCS, and ICD-10-CM translation via ConceptMap/$translate.
Why QNXT, Facets, and HealthEdge adapters are payer-specific onboarding integrations, not universal preconfigured connectors.
Run beside the core, move domains over time, or operate as the payer core backend — behind a stable FHIR contract.
This series builds on the CMS-0057-F readiness overview and the platform's implementation documentation.
Scope, system of record, Da Vinci coverage, policy digitization, integration pattern, interface ownership, identity, test evidence, exclusions, and the support boundary — with what a good answer to each sounds like.
Read the questions → Definition of DoneThe scenarios Cloud Health Office proves — CRD, DTR, PAS, Patient and Provider Access, Payer-to-Payer, security, consent, and prior-auth metrics — with an honest status for each and the QNXT, Facets, or HealthEdge touch points.
See what's proven → Evidence HubExecutable evidence for these workflows: Payer-to-Payer, CRD/DTR/PAS, Provider Access security, and exchanges performed against an independently developed HL7 Da Vinci implementation.
Open the Evidence Hub → Implementation PillarThe end-to-end architecture — FHIR APIs, CRD/DTR/PAS, security, terminology, and core integration — for implementing CMS-0057-F in a real health plan.
See the architecture → Readiness OverviewThe vendor-neutral readiness layer, the four required FHIR APIs, and what CMS-0057-F actually requires of impacted payers.
Explore readiness → Implementation GuideHow CRD, DTR, and PAS come together into an end-to-end FHIR prior authorization workflow.
Read the guide → Implementation GuideFHIR-native SNOMED CT to ICD-10-CM and CPT translation with ConceptMap/$translate.
How the services fit together — FHIR surface, terminology, rule engine, and payer integration.
See the architecture →See how Cloud Health Office fits alongside your existing core — or becomes it — on your CMS-0057-F timeline.