Framing the problem
Facets (a Cognizant TriZetto core administration platform) runs enrollment, benefits, provider contracting, claims and related operations for many Medicare Advantage, Medicaid and commercial plans. CMS-0057-F doesn't ask you to replace it. It asks for four FHIR APIs — Patient Access, Provider Access, Payer-to-Payer and Prior Authorization — live by the 2027 compliance date that applies to the payer type: January 1, 2027 for Medicare Advantage and state Medicaid/CHIP fee-for-service; the first rating period or plan year beginning on or after that date for Medicaid/CHIP managed care and QHP issuers (see the compliance timeline), built largely on data that lives in Facets today. Facets installations also tend to be heavily configured and extended, so two Facets plans rarely look the same underneath. The engineering question is what sits between Facets and the four APIs, and who owns it.
Why the CMS APIs are not "expose the core database"
Pointing a FHIR façade straight at the core database is the tempting shortcut, and the one to avoid. The CMS APIs require conformant FHIR profiles (US Core, CARIN Blue Button, Da Vinci PDex and PAS), standard terminology, consent and opt-out enforcement, Provenance, and scoping rules (for example, leaving remittances and cost-sharing out of provider and payer-to-payer payloads). A raw database projection meets none of these reliably and ties your public API to an internal schema. The API should be a governed projection of core data, produced by an interoperability layer.
For Facets in particular, plan-specific configuration, user-defined fields and custom extensions carry meaning only inside the plan. They need translating, not passing through.
Reference architecture
The adapter layer
The adapter is the seam between standard FHIR and the interfaces the plan actually has. For Facets, its jobs are:
- Read projection — members, coverage, claims and EOB data, providers and authorization records, from the integration interfaces the plan has licensed, from extracts, or from the plan's data warehouse. Many Facets plans already keep a reporting copy or warehouse, and it is often the practical source for the five-year Payer-to-Payer history.
- Write/orchestration — a PAS request must reach the plan's authorization system of record and return a decision. Cognizant lists Facets UM and CareAdvance among the systems its TriZetto Unify integrates with, but which UM system a given Facets plan uses, and how it can be reached (a vendor interface, the UM product's own integration, or an X12 278 bridge), is plan-specific and should be confirmed during onboarding. See CRD, DTR & PAS explained.
- Terminology normalization — map plan-specific service codes and custom code sets to CPT, HCPCS, ICD-10 and SNOMED CT.
- Scoping & consent — apply Provider Access opt-out and Payer-to-Payer permission before any data leaves. Most plans will track these outside the core.
Budget for adapter work explicitly. Facets versions, extensions and configuration differ enough between plans that a drop-in connector is the exception, not the rule.
API-by-API considerations
| API | Primary Facets-side data | Adapter emphasis |
|---|---|---|
| Patient Access | Coverage, claims (EOB), PA status | Member-scoped auth; EOB shaping to CARIN Blue Button |
| Provider Access | Attributed members' claims, clinical data, PA | Attribution logic + opt-out enforcement |
| Payer-to-Payer | Up to 5 years of claims, encounters, PA | Consent, Provenance, de-duplication on intake |
| Prior Authorization | UM rules, medical policy, authorization records | CRD/DTR rule content; PAS ↔ Facets UM, CareAdvance or X12 278 |
Build, overlay, or the vendor's own offering
Facets plans have three broad options for the interoperability layer:
- Build it internally — maximum control, highest engineering and maintenance cost, and you own conformance as the specifications evolve.
- Adopt Cognizant's offering — Cognizant markets TriZetto Unify, which it describes as automating CRD, DTR and PAS and integrating with Facets, QNXT, CareAdvance, Facets UM and QNXT UM. In May 2026 Cognizant announced headless, agent-ready APIs for its electronic prior authorization service. The published material centers on prior authorization, so confirm how Patient Access, Provider Access and Payer-to-Payer would be covered.
- Add a vendor-neutral interoperability layer — an overlay provides all four APIs, mapping, terminology and orchestration in front of Facets, typically in the plan's own cloud, and keeps the API boundary independent of the core vendor.
These aren't mutually exclusive. A modern payer platform such as CloudHealthOffice can serve as either an interoperability layer integrated with Facets or, depending on the implementation model, as part of the core backend itself. The point of the architecture is that the backend is an adapter concern behind a stable FHIR boundary — you can change it without changing the public API.
Onboarding checklist
- Inventory the Facets version, configuration, custom extensions and warehouse, and where each required data class lives.
- Confirm which integration interfaces and extracts your Facets license and hosting model give you.
- 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.
- Wire the Prior Authorization API into Facets UM, CareAdvance or the X12 278 path.
- Add Provenance, audit logging, and the CMS prior authorization metrics you must report.
- Conformance-test each API before onboarding trading partners.