Framing the problem
QNXT (a TriZetto/Cognizant core administration platform) manages enrollment, benefits, claims adjudication, and related payer operations for many plans. CMS-0057-F does not ask you to replace it. It asks you to expose FHIR APIs — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization — whose data largely originates in systems like QNXT. The engineering question is how to connect the two without turning your core platform into a public FHIR server.
Why the CMS APIs are not "expose the core database"
It is tempting to point a FHIR façade straight at the core administration database. Resist it. The CMS APIs require conformant FHIR profiles (US Core, CARIN Blue Button, Da Vinci PDex/PAS), consistent standard terminology, consent and opt-out enforcement, provenance, and scoping rules (for example, excluding remittances and cost-sharing from provider and payer-to-payer payloads). A raw database projection satisfies none of these reliably, couples your public API to an internal schema, and creates a security and performance liability. The API should be a governed projection of core data, produced by an interoperability layer — not a direct window into the core.
Reference architecture
The adapter layer
The adapter is the seam between standard FHIR and a platform's native interfaces. Its jobs:
- Read projection — pull members, coverage, claims/encounters, and PA records from QNXT (via its supported integration interfaces, extracts, or data warehouse) and hand them to the mapping layer.
- Write/orchestration — for the Prior Authorization API, route a PAS request into the authorization/UM workflow and return the decision. This is where a CRD/DTR/PAS flow meets the core.
- Terminology normalization — translate internal or legacy codes to the standard code systems providers expect.
- Scoping & consent — apply opt-out (Provider Access) and permission (Payer-to-Payer) before any data leaves.
Adapters are an onboarding/integration concern: each core platform, and sometimes each plan's configuration, needs its own mapping work. Budget for it explicitly rather than assuming a drop-in connector exists.
API-by-API considerations
| API | Primary core data | Adapter emphasis |
|---|---|---|
| Patient Access | Coverage, claims (EOB), clinical, PA status | Read projection + member-scoped auth |
| Provider Access | Attributed-member claims/clinical/PA | Attribution + opt-out enforcement |
| Payer-to-Payer | Up to 5 years of claims/clinical/PA | Consent, Provenance, reconciliation on ingest |
| Prior Authorization | UM rules, medical policy, auth records | PAS ↔ UM/X12 orchestration (read + write) |
Build internally, overlay, or adopt a modern backend
There are three broad ways to obtain the interoperability layer above:
- Build it internally — maximum control, highest engineering and maintenance cost, and you own conformance as the specifications evolve.
- Add an interoperability layer in front of QNXT — an overlay provides the FHIR APIs, mapping, terminology, and orchestration while the core platform stays in place. This is the most common path for payers with a heavy existing core investment.
- Use a broader modern payer platform — where a plan is already modernizing, a modern backend can provide these capabilities natively rather than as an overlay.
These are not mutually exclusive, and the right answer depends on your modernization roadmap. A modern payer platform such as CloudHealthOffice can serve as either an interoperability layer integrated with an existing core administration system like QNXT or, depending on the implementation model, as part of the core backend itself. The point of the architecture is that the choice of backend is an adapter concern behind a stable FHIR boundary — you can change it without changing the public API.
Onboarding checklist
- Inventory where each required data class lives in QNXT (or your core) today.
- Choose the integration interface for read projection (supported APIs, extracts, or warehouse).
- Stand up the FHIR gateway + OAuth (SMART App Launch and Backend Services).
- Build the mapping/terminology layer to conformant US Core / CARIN / PDex / PAS profiles.
- Implement consent (Payer-to-Payer) and opt-out (Provider Access) enforcement.
- Orchestrate the Prior Authorization API into your UM engine and any X12 278 path.
- Add Provenance, audit logging, and the CMS usage metrics you must report.
- Conformance-test each API before onboarding trading partners.