TriZetto Facets upgrades and CMS-0057-F interoperability APIs
Cohash keeps TriZetto Facets upgraded for health plans and builds the data feeds behind the CMS-0057-F FHIR APIs. We write regression suites from your own claims and enrollment scenarios. Facets and utilization management data get mapped to the Provider Access, Payer-to-Payer and Prior Authorization APIs, and we write the matching rules for members and providers. Identity and consent controls go in front of the API layer.
- 01Requirement and data map
- 02Upgrade regression suite
- 03Matching and source-to-FHIR mapping
- 04Consent and API identity
- 05Test with hard cases and operate
The story
Told without the client's name or anything that could identify them.
A health plan's IT group was impacted by CMS-0057-F, with the Provider Access, Payer-to-Payer and Prior Authorization APIs due generally from 1 January 2027, while a Facets upgrade competed for the same test environments. Facets regression testing was mostly manual, prior authorization timestamps lived in a UM system Facets didn't see, and the same member carried different identifiers across Facets, the portal and the warehouse. We started with a requirement-by-requirement data map, then built automated regression from the plan's own claims and enrollment scenarios so patches stopped blocking API tests. Matching rules, source-to-FHIR mappings and consent enforcement followed, tested against members who changed plans mid-year and members who opted out.
why it was urgentCMS-0057-F requires impacted payers to have the Provider Access, Payer-to-Payer and Prior Authorization APIs running, generally from 1 January 2027. They also have to add prior authorization data to the Patient Access API. Decision timeframes and public prior authorization metrics already applied in 2026. Most of that data lives in Facets, so upgrades and API work now share one calendar.
- openYour plan's in scope for CMS-0057-F. The API build keeps colliding with a Facets upgrade over the same test environments.
- recurringPrior authorization request and decision timestamps live in a UM system Facets doesn't see.
- blockedOne member shows up with three different IDs, in Facets, in the portal and in the warehouse.
- openFacets regression testing is mostly manual, so every patch delays API testing.
- recurringThe opt-in rules for Payer-to-Payer and the opt-out rules for Provider Access still don't have an owner.
The estate, before and after
Before: Facets data leaving by batch extract and hand-built reports
Facets fed portals and the warehouse through batch extracts, each with its own member identifiers. Prior authorization data sat in a UM system Facets didn't see, and Facets patches waited on manual regression testing.
Read the diagram as text
- TriZetto Facets → Batch extracts: batch files
- Provider data → Batch extracts: provider files
- UM system → Manual PA reporting: PA data
- TriZetto Facets → Manual regression: patch testing
- Batch extracts → Member portal: member data
- Batch extracts → Data warehouse: claims
After: current Facets feeding the CMS-0057-F FHIR APIs
Data from Facets, UM and provider systems goes through matching and source-to-FHIR mapping on its way to the API layer. What a provider, another payer or a member app receives is decided by OAuth 2.0 scopes and consent rules.
Read the diagram as text
- TriZetto Facets → Member and provider matching: members · claims
- Provider data → Member and provider matching: provider records
- UM system → Source-to-FHIR mapping: PA decisions
- Member and provider matching → Source-to-FHIR mapping: matched records
- Source-to-FHIR mapping → CMS-0057-F FHIR APIs: FHIR resources
- OAuth 2.0 and consent → CMS-0057-F FHIR APIs: scoped tokens · consent
- CMS-0057-F FHIR APIs → Providers: patient data
- CMS-0057-F FHIR APIs → Other payers: member history
- CMS-0057-F FHIR APIs → Member apps: claims · PA status
How we run it, phase by phase.
5 phases take you from Facets with batch extracts and manual prior auth reporting to Current Facets feeding CMS-0057-F FHIR APIs. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Requirement and data map
Work out which CMS-0057-F APIs apply to each line of business and by what date. Then trace every required data element back to Facets, UM, provider or attribution systems.
- phase 02
Upgrade regression suite
Build automated regression from your own claims, enrollment and billing scenarios. Once that exists, Facets patches and upgrades stop holding up the API test schedule.
- phase 03
Matching and source-to-FHIR mapping
Matching comes before mapping. We write member and provider rules for re-enrollment, dependents and NPI and TIN conflicts, and only then map the matched records to the FHIR resources each API returns.
- phase 04
Consent and API identity
Enforce Provider Access opt-out and Payer-to-Payer opt-in in code, and authorize apps, providers and other payers through OAuth 2.0 with scopes you can audit.
- phase 05
Test with hard cases and operate
Test with the awkward cases: members who changed plans mid-year, pended and denied authorizations, members who opted out. Then hand over the data quality checks and runbooks.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Facets patches no longer block API testing
We built regression from the plan's own claims, enrollment and billing scenarios, and it now runs automatically on every Facets patch and upgrade.
- result 02
Every required data element traces to a source
We mapped each CMS-0057-F requirement to the Facets, UM, provider or attribution system behind it, one line of business at a time.
- result 03
Members and providers match across systems
We wrote and tested matching rules for re-enrollment, dependents and NPI and TIN conflicts before mapping a single matched record to FHIR.
- result 04
Consent rules are enforced in code
Provider Access opt-out and Payer-to-Payer opt-in are checked in the API layer, and apps, providers and other payers authorize through OAuth 2.0 with scopes the plan can audit.
- result 05
API operations have checks and runbooks
We handed over data quality checks and runbooks, so the team running the APIs after go-live knows what to do with bad or missing data.
Risks we plan for
-
Upgrade and API work in the same window
If a Facets upgrade lands late in 2026, the API feed testing you've already done may not count. Put both on one release calendar with one regression suite.
-
Prior auth data outside Facets
Decision timestamps and denial reasons often sit in a separate UM tool. If the source isn't settled, the API and the public metrics can't be defended.
-
Weak member matching
API responses are only as complete as the crosswalk behind them. Members with plan changes or re-enrollment are where gaps show first.
-
Consent enforced too late
Opt-out and opt-in checks added at the API gateway after the fact are easy to bypass. They belong in the data path, with an audit trail.
Where AI helps, and where it needs guardrails
Since 28 September 2026, Cognizant's Workflow Agentic Processing for Facets and QNXT has been generally available. Its agents clear eligible routine pended claims, and it ships with more than 100 MCP tools. We'd pilot it on a single pend queue with examiners still deciding every denial. Each agent counts as a service identity, so it gets an owner and scoped access, and your IGA platform reviews it like any other.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- report01
CMS-0057-F requirement-by-requirement gap analysis per line of business
yours to keep - tests02
Facets regression suite built from your own claims and enrollment scenarios
yours to keep - inventory03
Source-to-FHIR mappings from Facets, UM and provider systems
yours to keep - tests04
Member and provider matching rules with test cases
yours to keep - design05
Consent enforcement and API authorization design
yours to keep - runbook06
Data quality checks and runbooks for API operations
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Does Facets provide the CMS-0057-F APIs for us?
That comes down to your Facets version, how it's hosted and what you already license from Cognizant or other vendors. Most plans put a FHIR server or interoperability platform next to Facets. We assess what's there first.
02Which deadlines apply to our plan?
That depends on payer type. Medicare Advantage, Medicaid, CHIP and federal exchange QHP issuers have different scopes, and some dates are tied to rating periods or plan years. For most, the API requirements start 1 January 2027.
03Should we delay our Facets upgrade until the APIs are live?
Sometimes, but not by default. It depends on what the upgrade fixes and how much test environment capacity you have. With an automated regression suite, both can run on one calendar.
04Can you work with our existing FHIR vendor?
Yes. Most plans already have a FHIR server or interoperability vendor. We focus on the Facets data feeding it, the matching rules and the identity and consent design around it.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAI pilot to production with forward deployed engineers
Taking an AI pilot into production with forward deployed engineers who work with the business team, build evals, connect real systems and hand over cleanly.
read the case studydbdcc876 - 01CMS: Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheetcms.gov ↗
- 02CMS: Interoperability and Prior Authorization Final Rule overviewcms.gov ↗
- 03Cognizant: Workflow Agentic Processing for TriZetto (28 Sep 2026)news.cognizant.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it