Facets data, ready for the FHIR APIs CMS expects in January 2027.
The 2027 API deadlines under CMS-0057-F depend on member, provider, claims and prior authorization data that mostly lives in TriZetto Facets. We work on the Facets side and the API side, and on the data quality problems between them.
Matching and data qualitymember and provider keysSource-to-FHIR mappingPatient · Claim · Coverage
03 · FHIR APIs
FHIR serverUS Core · CARIN · Da VinciMember and provider identityOAuth 2.0 · SMART on FHIR
04 · Consumers
Member appsPatient Access APIIn-network providersProvider Access · Prior Auth APIOther payersPayer-to-Payer API
TriZetto FacetsAuth0OktaMicrosoft Entra ID
in short·15-second read
A payer platform is the core administration system behind a health plan's enrollment, claims, billing and benefits.
We work on TriZetto Facets, on configuration, integration and data. For impacted payers we also prepare the member, provider and prior authorization data that feeds the FHIR APIs required by CMS-0057-F, generally from 1 January 2027.
you probably need this if
Your plan is impacted by CMS-0057-F and the January 2027 API dates are close.
Look up one member in Facets, the portal and the data warehouse and you get three different identifiers.
Provider network and affiliation data is too inconsistent to show treatment relationships.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Healthcare Payer Platforms, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · healthcare payer platforms3 open
openYour plan is impacted by CMS-0057-F and the January 2027 API dates are close.
recurringLook up one member in Facets, the portal and the data warehouse and you get three different identifiers.
blockedProvider network and affiliation data is too inconsistent to show treatment relationships.
exposure
Member and enrollment dataProvider dataCMS-0057-F API readinessPrior authorization data and…Facets integrationIdentity for members and providers
startrehearsehandover
Assessment
Data design
Build and test
Operate
we are here
ready to hand over
Query the API as a provider and you see only the members you actually treat.
The metrics come out of a repeatable pipeline now, not a spreadsheet.
The same member resolves to the same record in every system, and third-party apps get…
CMS-0057-F requirement-by-requirement gap analysis
chapter 01 · where it hurts
Why teams reach out
Your plan is impacted by CMS-0057-F and the January 2027 API dates are close.
Look up one member in Facets, the portal and the data warehouse and you get three different identifiers.
Provider network and affiliation data is too inconsistent to show treatment relationships.
chapter 02 · what we change
How we solve it
Member and enrollment data
Provider data
CMS-0057-F API readiness
Prior authorization data and metrics
Facets integration
Identity for members and providers
chapter 03 · how it runs
Our approach
Assessment
Data design
Build and test
Operate
chapter 04 · where you end up
What changes
Query the API as a provider and you see only the members you actually treat.
The metrics come out of a repeatable pipeline now, not a spreadsheet.
The same member resolves to the same record in every system, and third-party apps get complete data for members whose coverage changed during the year.
CMS-0057-F requirement-by-requirement gap analysis
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
We reconcile enrollment feeds, eligibility spans and member IDs across Facets and downstream systems. Otherwise one member shows up as two in API responses.
Provider, network and affiliation data cleaned and mapped, since the Provider Access API depends on knowing which in-network providers have a treatment relationship with which members.
Data mapping and gap analysis for the Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs, built on FHIR, with the opt-in and opt-out rules each one carries.
Prior authorization requests, decisions and timing sit in Facets and in utilization management systems. We extract them for two uses, the API and the metrics CMS requires payers to post publicly.
Review every interface in and out, along with extracts and batch jobs. Document them. Move them toward APIs where that lowers the risk.
Member and provider portal sign-in, consent and third-party app authorization designed with your CIAM platform, so API access rests on identities you can audit.
capability 01 / 06in production
Member and enrollment data
We reconcile enrollment feeds, eligibility spans and member IDs across Facets and downstream systems. Otherwise one member shows up as two in API responses.
Provider, network and affiliation data cleaned and mapped, since the Provider Access API depends on knowing which in-network providers have a treatment relationship with which members.
Data mapping and gap analysis for the Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs, built on FHIR, with the opt-in and opt-out rules each one carries.
Prior authorization requests, decisions and timing sit in Facets and in utilization management systems. We extract them for two uses, the API and the metrics CMS requires payers to post publicly.
Member and provider portal sign-in, consent and third-party app authorization designed with your CIAM platform, so API access rests on identities you can audit.
We pieced these together from Healthcare Payer Platforms situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Provider Access API with attribution data outside Facets
composite · not a client story
Beforethe situation
An impacted payer needs the Provider Access API by January 2027. Facets holds provider records, but member-to-provider attribution lives in a separate value-based care system, and NPIs don't line up between the two.
What we dothe work
Provider records come out of Facets and the attribution system and get profiled. We build NPI and TIN matching rules, with manual review for conflicts, and map the result to the FHIR resources the API needs. Member opt-out handling goes in before any provider can query.
Afterwhere you end up
Query the API as a provider and you see only the members you actually treat. Opt-outs are honored. The matching rules are written down for auditors.
case file 02
Prior authorization timestamps that live in the UM system, not Facets
composite · not a client story
Beforethe situation
Utilization management runs in a separate system. Facets sees the authorization number but not request and decision timestamps, so the 2026 timeframe tracking and public metrics were assembled by hand in a spreadsheet.
What we dothe work
Requests, decisions and denial reasons come out of the UM system and into the warehouse, with consistent timestamps. We join them to Facets claims and member data and write the metric calculations as code. The Prior Authorization API design uses that same data.
Afterwhere you end up
The metrics come out of a repeatable pipeline now, not a spreadsheet. And the API work starts from data that already reconciles with Facets.
case file 03
Three identifiers for the same member across Facets, portal and warehouse
composite · not a client story
Beforethe situation
A member has one ID in Facets, another in the member portal's CIAM tenant and a third surrogate key in the warehouse. Patient Access API responses come back incomplete for members who changed plans mid-year.
What we dothe work
Build a member crosswalk keyed on the Facets member identifier, with rules for re-enrollment, dependents and plan changes. Carry the Facets ID as a claim in the CIAM token so authorized third-party apps reach the right record, then test with members whose coverage changed.
Afterwhere you end up
The same member resolves to the same record in every system, and third-party apps get complete data for members whose coverage changed during the year.
How Facets data reaches the FHIR APIs CMS-0057-F requires
Member, provider, claims and prior authorization data is extracted from Facets and utilization management systems, matched and mapped to FHIR resources. The FHIR server exposes the Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs, with access authorized through your CIAM platform.
01 · Core admin
TriZetto Facetsenrollment · claims · providers → Matching and data quality · member and claims extracts
Utilization managementprior auth requests · decisions → Matching and data quality · prior auth data
02 · Data layer
Matching and data qualitymember and provider keys → Source-to-FHIR mapping · matched records
Member and provider identity → FHIR server: access token
FHIR server → Member apps: FHIR API
FHIR server → In-network providers: FHIR API
FHIR server → Other payers: FHIR API with opt-in
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Assessment
Take every CMS-0057-F requirement for your lines of business and check your data sources, interfaces and current API coverage against it.
step 02
Data design
Operations and compliance sign off on the source-to-FHIR mappings, identity matching rules and data quality checks before we build.
step 03
Build and test
We build the extracts, transformations and API integrations, then test them with realistic member and provider scenarios.
step 04
Operate
We set up monitoring and data quality reporting, and write runbooks for the teams who field API and audit questions.
you keep
What you're left with
We write these for your Healthcare Payer Platforms 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
yours to keep
inventory02
Source-to-FHIR data mappings from Facets and adjacent systems
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
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Facets configuration analyst
Facets claims subject matter expert
Facets technical developer
EDI developer (834, 837, 835)
Payer data engineer
Facets QA analyst
due diligence · healthcare payer platforms (facets)
Questions to ask any partner, including us.
Put these to anyone bidding on your Healthcare Payer Platforms (Facets) work. The ones who've done it answer differently from the ones who've read about it.
Q1
For each line of business, which CMS-0057-F requirements apply to us, and starting when?
Scope differs for Medicare Advantage, Medicaid, CHIP and federal exchange QHPs, and some dates follow rating periods or plan years. Don't assume 1 January 2027 works for every line.
Q2
How will members be matched across Facets, the portal and the FHIR server?
API responses are only as complete as member matching. Ask for the rules covering re-enrollment, dependents and plan changes, and the test cases behind them.
Q3
Where do our prior authorization request and decision timestamps come from?
Decision timeframes and public metrics depend on times that often live outside Facets. If the source isn't settled, the reported numbers can't be defended.
Q4
How will opt-out and opt-in be enforced in the Provider Access and Payer-to-Payer APIs?
Under CMS-0057-F, members can opt out of Provider Access, and Payer-to-Payer exchange needs their opt-in. That has to be enforced in code before data leaves, and it needs an audit trail.
Q5
Which Facets extracts will feed the APIs, and who maintains them?
Batch extracts written years ago often end up feeding the new APIs. If only one person understands them, that's a single point of failure on a regulatory deadline.
01Which CMS-0057-F deadlines apply to us?
It depends on what kind of payer you are. Covered payers are Medicare Advantage organizations, Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the federal exchanges. For most of them the operational provisions started on 1 January 2026. The API requirements generally start on 1 January 2027. Some dates follow rating periods or plan years instead.
02What did CMS require starting in 2026?
For most impacted payers, prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests, specific reasons for denials, and an initial set of prior authorization metrics posted publicly by 31 March 2026. QHP issuers on the federal exchanges are excluded from the decision timeframes.
03Does Facets provide the FHIR APIs for us?
That depends on your Facets version, hosting and the products you license from Cognizant or other vendors. Most payers combine Facets data with a FHIR server or interoperability platform. We assess what you have before recommending what to add.
04Do you also work on QNXT?
Facets is our focus. But the data and API work for CMS rules is similar on other core administration platforms, so tell us about yours.
05Can you work with our existing FHIR server or interoperability vendor?
Yes. Most payers already have a FHIR server or vendor platform. We focus on the data feeding it from Facets and adjacent systems, and on the identity and consent design around it.
related
Often paired with
Projects on Healthcare Payer Platforms (Facets) usually end up touching one of these, so they're worth a look.
