CMS-0057-F on January 1, 2027: what health plans on Facets, QNXT and HealthRules need live
If you sell Medicare Advantage, Medicaid, CHIP or exchange plans, three new APIs and prior auth data in Patient Access are due from January 2027. We go through which date applies to which contract, and what usually breaks in testing.
part 4 of 5 · Running enterprise platforms wellthe ideaThe faster prior auth clocks came first. Now the APIs are due, starting in January.
after reading, you can- Find each contract's actual CMS-0057-F date. Medicaid managed care and exchange plans don't all start January 1
- Map prior auth data from the core platform and UM tool into the API within one business day
- Spot the consent, retention and IG version gaps that usually fail testing late
Starting January 1, 2027, most health plans that sell Medicare Advantage, Medicaid, CHIP or federal exchange coverage have to run three new FHIRdefinitionFast Healthcare Interoperability Resources, HL7's standard for health data over web APIs. CMS requires Release 4.0.1 here, so that's the version your server has to speak. APIs and add prior authorization data to the one members already use. With about two months left, find out which lines of business are in scope and when each one's date really falls, then test the data feeds coming out of Facets, QNXT or HealthRules against real members.
Health plans now owe doctors, other plans and members their data, by API and on a clock
CMS, the agency behind Medicare and Medicaid, wrote CMS-0057-F for the health plans that sell those programs and for plans on the federal marketplace. The first part already applies. Since January 2026, plans have had to decide prior authorizations faster and give a real reason for every no. The second part starts in January 2027, and it's technical. Doctors' systems will pull a patient's claims history straight from the plan. A new plan will fetch five years of records from the old one. Providers will check whether a service needs approval and send the request electronically. All of that runs over APIs, the standard connections computer systems use to talk to each other. For most plans the data already exists, spread across the claims system and the utilization management tool. Getting it out cleanly, every time, is where the effort goes.
Think of a medical records office that used to answer only by fax and phone. The rule makes it put in a service window with set opening hours, a standard request form and a clock on every answer. The files in the back room don't change, but somebody has to sort them so the window clerk can find them.
- Medicare Advantage plans
- Medicaid and CHIP managed care plans
- State Medicaid and CHIP agencies
- Most issuers on the federal exchanges
- IT teams running Facets, QNXT or HealthRules
- Provider groups that request prior auths
Why it matters to you
Miss the date and your Medicare Advantage, Medicaid or exchange business is out of compliance with CMS. The gaps are visible from outside, because providers will try to call your Provider Access and Prior Authorization endpoints from their EHRs, and members' apps already call your Patient Access API. An endpoint that's missing, or one that returns half a member's history, is easy to spot from outside.
The rule is also stricter than a lot of project plans assume. Prior authorization status has to show up within one business day and stay visible for at least a year after it last changes. If your utilization management tool was never set up to keep or expose data that way, that's where testing will fail.
-
01 Data sits in core and UM
Claims, enrollment and providers live in Facets, QNXT or HealthRules. Prior auth requests and decisions often sit in a separate UM tool.
-
02 Feeds load a FHIR layer
Nightly or near-real-time feeds map that data to FHIR resources on the server that hosts your APIs.
-
03 Someone asks
Usually it's a provider's EHR asking about a patient it treats. It can also be another payer or the member's own app.
-
04 Checks before release
You check who's calling and whether that provider really treats this member. Then you look up the member's opt-out or opt-in before you send anything.
-
05 Answer inside the clock
Answer inside one business day. A prior auth request comes back approved, denied with a specific reason, or with a list of what else you need.
For engineers: the three new APIs reuse the security and conformance rules of the Patient Access API that's been required since 2021, so the FHIR server and app vetting are mostly in place. What's new is system-to-system traffic. CMS points Provider Access and Payer-to-Payer at SMART Backend Services authorization and Bulk DatadefinitionExporting many patients' data as one background job instead of one request per patient. Provider Access and Payer-to-Payer lean on it for group exports. export, so you're registering partner systems and running large asynchronous exports instead of serving one member on a phone.
What the rule requires, API by API
The 2026 changes were about process: decision clocks, denial reasons and public metrics. The 2027 changes are all technology. The features below are the parts that turn into tickets.
What has to be live from January 2027
Members' apps must show each prior auth's status, dates, approved items and any denial reason, plus structured documentation the provider sent. Drugs are left out.
In-network providers who treat a member can pull claims, encounters, USCDI clinical data and prior auth details back to 2016. Remittances and cost-sharing stay out.
Someone has to decide how members get linked to their providers, and members need a way to opt out of provider sharing. Tell them before launch and again every year.
With the member's opt-in, a new plan asks the old one for five years of data. Denied prior auths, remittances and cost-sharing are excluded. Documentation behind prior auths is included.
Dual coverage gets its own rule. With the member's opt-in, each plan asks the other for data at least quarterly, for as long as the overlap lasts.
Think of it as the electronic front desk for prior auth. A provider's system checks whether something needs approval and what you'll want to see, then files the request. You approve, deny with a specific reason, or ask for more.
You can drop X12 278 for prior auth if the whole flow runs in FHIR, and HHS says it won't enforce against you. Staying X12-only doesn't work. It can't do what the rest of the rule asks.
If your Patient Access build still runs US Core 3.1.1, SMART 1.0.0 or USCDI v1, it's on versions CMS lists as expired since January 1, 2026. Newer IG versions are allowed, provided nobody loses access.
MIPS clinicians and hospitals start attesting to an Electronic Prior Authorization measure for 2027, so expect their EHR vendors to start calling your endpoints.
Every prior auth API and metric excludes drugs. CMS proposed bringing drugs under the medical benefit into scope from October 2027, but that's still a proposal.
Two details catch teams late. The Payer-to-Payer request has to go out within a week of you knowing the member's previous plan and having their opt-in, so it belongs in the enrollment workflow and can't wait for a monthly batch. And the rule's preamble says you also answer payers the rule doesn't cover, as long as they ask through a conformant API. Plan capacity for that traffic too.
| Line of business | API compliance date | Extension or exception? |
|---|---|---|
| Medicare Advantage organizations | January 1, 2027 | None offered |
| State Medicaid and CHIP fee-for-service | January 1, 2027 | One-time, one-year extension for Provider Access, Payer-to-Payer and Prior Authorization; exemption if 90% or more of Medicaid (or separate CHIP) members are in managed care organizations |
| Medicaid managed care plans and CHIP managed care entities | Rating period beginning on or after January 1, 2027 | None offered to plans |
| QHP issuers on the federally facilitated exchanges | Plan years beginning on or after January 1, 2027 | The exchange may grant an exception |
Read the managed care row carefully. A Medicaid contract whose rating perioddefinitionA state's Medicaid managed care contract period, the one payment rates are set for. Plans comply from the first that starts on or after January 1, 2027, so a July contract means a July date. starts on July 1 has a compliance date of July 1, 2027, so a plan with several state contracts can face more than one date. Map each contract's rating period before you set the project plan, or you'll put work on the critical path that could have waited.
Every CMS-0057-F date so far, plus two that are only proposed
- Feb 8, 2024Final rule published
Released in January 2024. CMS moved most API dates out to 2027 after public comments, so plans got an extra year.
- Jan 1, 2026Decision clocks and denial reasons
72 hours for expedited and seven calendar days for standard requests, with a specific reason on every denial. Exchange plans are excluded from the clocks.
- Mar 31, 2026First public prior auth metrics
Approval and denial rates and average and median decision times for the year before, posted on the plan's website, and every March 31 after that.
- Apr 10, 2026CMS-0062-P proposed
It would add drugs and require newer IG versions. Proposed only.
- Jan 1, 2027APIs live
This is the hard date for MA and state fee-for-service. Patient Access gains prior auth data, and Provider Access, Payer-to-Payer and Prior Authorization go live.
- Oct 1, 2027Proposed: drugs and new IGs
Only if CMS finalizes CMS-0062-P as written. Then drugs under a medical benefit come into scope and newer IG versions become required on this date.
- Jan 1, 2028Proposed: older versions expire
CMS-0062-P would retire CRD, DTR and PAS 2.0.1 and CARIN Blue Button 2.0.0. Plan the move to the 2.2 releases now, so it doesn't land as a surprise.
Where Facets, QNXT and HealthRules fit
None of the three core platforms meets the rule on its own. They're the system of record. The APIs run on a FHIR server, and the hard part is the mapping in between: member identifiers that differ by system, provider records that don't line up with the directory, and prior auth data split between the core platform and a UM tool.
Cognizant sells add-ons for this to TriZetto clients. Its TriZetto Connected Interoperability Solution is a hosted FHIR environment that runs Patient Access, Provider Access and Payer-to-Payer as a managed service, with a consent engine built in. For prior auth there's TriZetto Payer Electronic Prior Authorization, built on the Da Vinci guides, which Cognizant says plugs into Facets, QNXT and CareAdvance. On the HealthEdge side, HealthRules Edge (it used to be HealthRules Payer) is the claims engine, and you'll still need a FHIR layer and feeds next to it.
- Quickest when the core vendor already runs the feeds for you
- The vendor runs the APIs day to day, upgrades included
- Consent and opt-out handling often comes with it
- You still own data quality, attribution and member notices
- Less control over when IG versions change
- You decide the mapping, the versions and when releases go out
- Fits plans running more than one core platform
- Uptime and security testing are on you, and so is Bulk Data speed when a big group exports
- Prior auth API logic and UM integration are yours to build
- Hard to finish from scratch in two months
This close to the date, most plans that haven't started will end up with a hosted layer for January and decide on the long-term setup afterwards. That's a reasonable call. Just don't let the contract hide who owns each data feed, because CMS holds the plan responsible either way.
Before: Patient Access only, prior auth data stuck in UM
The core claims platform feeds a FHIR server that answers member apps. Prior authorization requests and decisions live in a separate UM tool that the FHIR server never sees, and providers still fax or use a portal.
After: four APIs fed from both core and UM
This is what you're aiming for by January. Core and UM both feed the FHIR layer, prior auth status lands within a business day, and every API checks identity and consent before it answers. Providers stay in their EHRs. Other payers use Payer-to-Payer.
What to do in the next two months
What to do before January 1, by who you are
- Ask for one list: every contract and line of business, its API compliance date and the owner of each API.
- Check every Medicaid contract's rating period. A July start means a July date, so that contract needs its own line in the plan.
- Agree in writing who owns each data feed if a vendor hosts the APIs.
- Confirm member notices about provider data sharing and opt-out are scheduled to go out before launch.
- List which prior auth fields live in Facets, QNXT or HealthRules and which live only in the UM tool.
- Confirm the UM tool keeps closed authorizations for at least a year after their last change.
- Measure how long a status change takes to reach the FHIR server today. The limit is one business day.
- Stand up SMART Backend Services clients for provider and payer partners, and load-test Bulk Data exports on a large provider group.
- Run conformance tests against each API, with real member records in a lower environment.
- Wire the Payer-to-Payer request into enrollment so it goes out within a week of opt-in.
- Build the denial-reason and documentation-list responses for the Prior Authorization API from the UM rules, not by hand.
- Put plain-language instructions on your website telling providers how to request data and use attribution. The rule requires it.
- Ask your largest provider groups which EHR vendors will call your endpoints, and test with one of them first.
Getting from where you are to live, in order
- 01Scope by contract
Write down each contract's date, using rating periods for Medicaid managed care and plan years for exchange plans. Only MA and state fee-for-service are fixed at January 1.
- 02Map every data element to a source
Trace each FHIR resource back to the core platform, the UM tool or the provider directory. Fields with no clear source go on a gap list with an owner.
- 03Fix identity and attribution
Pick the member identifier the APIs will use and decide how a provider gets linked to a member, from claims, PCP assignment or a provider attestation.
- 04Build consent before data flows
Provider Access is opt-out and Payer-to-Payer is opt-in. Store both choices with dates and check them on every request, with an audit trail.
- 05Test with real records
Run conformance tests, then compare API output against the core system for a sample of members. Include members with prior auths, coordination of benefits and terminated coverage.
- 06Rehearse with one partner
Run a live exchange with one provider group's EHR and one other payer before January. Fix what breaks, then open it up.
- 07Freeze and watch
Freeze feed changes in mid-December. In January, watch response times against the one-business-day limit every day.
Make the next CMS deadline smaller
CMS has already proposed the next round, with drugs, newer IG versions and decision-clock changes from October 2027. Plans that treat January as a one-off project will be back at it within a year. A few habits keep the second round short.
Habits that keep the API estate easy to change
- 01Keep the mapping in code
Store core-to-FHIR mappings in version control with tests, so an IG upgrade is a change request rather than a rediscovery.
- 02Put prior auth data in one place
Feed UM decisions and timestamps into one store that serves the API, the public metrics and audits. Three copies drift.
- 03Treat partners like privileged users
Every provider and payer client gets its own credentials, narrow scopes and logging. Review them like any other privileged access.
- 04Track the proposed rule
Assign someone to follow CMS-0062-P to a final rule, and budget for drugs under the medical benefit in 2027 planning.
- 05Monitor the clocks
Alert when a status change hasn't reached the API within a business day, or a payer request hasn't been answered. Those are the failures CMS can see.
If go-live goes wrong
If something breaks or data leaks after go-live, here's the order we'd work in
Expect most launch problems to be feed problems: stale prior auth status, a member mapped to the wrong record, or exports timing out. A wrong-member response is different. Treat it as a possible privacy incident from the first minute.
- 01Containfirst hour
- If data reached the wrong provider, payer or app, switch off that endpoint or client and keep the logs.
- If it's only slow or stale, keep the API up, pause the failing feed and post a status note for partners.
- 02Find the causefirst day
- Pull the affected members and compare what the API sent with the core system and the UM tool. The difference usually points at the feed.
- Check the last feed run, identifier matching and consent flags. Look hard at recent member merges and duplicate IDs, a common source of wrong-member answers.
- 03Fix and backfillfirst days
- Fix the mapping or feed, rerun it for the affected period and confirm prior auth records match source.
- Anyone who got an incomplete answer needs the full data re-sent. They won't know to ask again.
- 04Reportas required
- If health data went to the wrong party, start your HIPAA breach assessment the same day. That assessment tells you who has to be notified.
- Let CMS or the state Medicaid agency know what happened and what you fixed. Your contract says how and when.
- 05Learnwithin a month
- Add the failing case to the regression set so the next feed change catches it.
- Review whether alerting would have caught it sooner, and tighten the thresholds.
What it looks like for different plans
Some plan setups you might recognise, and what we'd do in each
- the setup
- The plan runs Patient Access on a hosted FHIR server. Prior auths live in a separate UM tool that archives closed cases after 90 days. Provider Access and Prior Authorization haven't started.
- what happens
- There's no extension for an MA plan, so January 1 holds. And members lose sight of their prior auths after 90 days, when the rule says a year.
- what to do
- Change UM retention first. Then add the UM feed to the FHIR layer, and launch Provider Access for the largest provider groups with attribution from PCP assignment.
- the setup
- One state contract's rating period starts January 1, the other's on July 1. The project plan treats both as January 1.
- what happens
- The team squeezes both states into one launch. Testing for the July state crowds out the January state, which actually has the hard date.
- what to do
- Split the plan by contract. Finish the January state's APIs and member notices first, and run the July state as a second wave reusing the same feeds.
- the setup
- The plan sells Medicare Advantage and exchange plans whose plan year starts January 1. The FHIR layer is built in-house, and the Payer-to-Payer request runs as a monthly batch.
- what happens
- New members' previous-payer requests go out weeks late, past the one-week limit. Both lines are due on the same day.
- what to do
- Move the request into the enrollment workflow, triggered when the opt-in and previous-payer details arrive. Check backend client registration with two or three likely partner payers early.
These are illustrations of common setups, not Cohash client stories. Your own estate will mix them.
How Cohash helps
We map Facets, QNXT and HealthRules data to the FHIR resources each API needs and list the gaps with owners. Then we build and test the feeds, and put identity and consent checks in front of the API layer. If January is already tight, we start with the line of business that has the hard date. See our TriZetto Facets practice, our QNXT and HealthEdge pages, hire Facets specialists, or start with an assessment.
What to take from this
- 01
Medicare Advantage and state fee-for-service programs need the four APIs on January 1, 2027. Medicaid managed care follows each contract's rating period, and exchange plans follow the plan year.
- 02
Facets, QNXT and HealthRules hold the data, but none of them runs the APIs for you. Most of the work is mapping and feeds into a FHIR layer.
- 03
Prior auth data has to reach the API within a business day and stay there at least a year after its last change. Check your UM tool's retention.
- 04
Provider Access is opt-out, Payer-to-Payer is opt-in. Store each choice with a date, and have every request check it before data goes out.
- 05
CMS has proposed drugs and 2.2 IG releases from October 2027. Expect one more IG upgrade, and keep mappings in code so it stays small.
- How Cohash delivers TriZetto Facets: scope, roles and architecture
- How Cohash delivers TriZetto QNXT: scope, roles and architecture
- How Cohash delivers HealthEdge HealthRules Edge: scope, roles and architecture
- Hire vetted TriZetto Facets engineers
- Healthcare payer platforms
- Book a 30-minute working session with a senior engineer
01Does CMS-0057-F apply to our commercial group business?
No. The rule covers Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care, and QHP issuers on the federally facilitated exchanges, apart from stand-alone dental and FF-SHOP-only issuers. A practitioner on Hacker News noted that many payers are rolling the same prior auth APIs out across every line anyway. The 2025 industry pledge on prior auth also covers commercial plans, though it's voluntary.
02Is the deadline January 1, 2027 for every plan?
Only for Medicare Advantage and state Medicaid and CHIP fee-for-service. Medicaid and CHIP managed care plans comply from the first rating period starting on or after January 1, 2027, and exchange issuers from plan years starting on or after that date.
03Can we get an extension?
Probably not, unless you're a state. A state can ask CMS for a one-time, one-year extension for its fee-for-service program, but only for the Provider Access, Payer-to-Payer and Prior Authorization APIs. A state with 90% or more of its Medicaid members (or, for a separate CHIP, its CHIP members) in managed care organizations can ask for an exemption from those APIs instead. The exchange can grant QHP issuers an exception. Medicare Advantage and Medicaid managed care plans get no extension option in the rule.
04Does Facets or QNXT provide these APIs out of the box?
The core platforms hold the data. Cognizant sells separate TriZetto products for the FHIR APIs and electronic prior authorization, which it says integrate with Facets and QNXT. Either way, the plan still owns data quality, attribution, consent and member notices.
05Do we still have to support the X12 278 transaction?
HHS won't take HIPAA enforcement action against covered entities that run prior authorization through an all-FHIR Prior Authorization API without X12 278. You can keep X12 278 alongside FHIR, but X12 alone can't meet the rule's other API requirements.
06Which implementation guide versions should we build on?
Start with what CMS recommends today: the Da Vinci CRD, DTR and PAS guides for prior auth, at 2.1.0. Version 2.0.1 is still listed, but CMS footnotes it as based on standards that expired on January 1, 2026. Its proposed follow-up rule would move them to 2.2 releases from October 2027 and retire 2.0.1 on January 1, 2028. So whatever you launch on, budget for one more IG upgrade and keep the mapping easy to change.
07Are drugs included?
Not under CMS-0057-F. Its prior authorization APIs and metrics exclude drugs. CMS proposed in April 2026 to add drugs under the medical benefit from October 1, 2027, but that rule hasn't been finalized.
Three questions, about a minute
Pick an answer and we'll tell you if it's right, and why it is or isn't. The score stays in this browser.
-
Q1A Medicaid managed care plan's state contract has a rating period starting July 1. When must its CMS-0057-F APIs be live?
show the answer
B. On July 1, 2027, when that contract's next rating period begins Medicaid managed care plans go by the first rating period starting on or after January 1, 2027, so a July contract has a July date. Only MA and state fee-for-service are fixed at January 1, and only states can ask for the one-year extension.
-
Q2Your UM tool archives closed prior authorizations after 90 days. Which CMS-0057-F requirement does that put at risk?
show the answer
D. Keeping prior auth data in the Patient Access API for a year after its last change Prior auth information must stay accessible while the authorization is active and at least a year after its last status change. A 90-day archive drops records the API still has to show.
-
Q3A new member opts in and names their previous plan. The team plans to send the Payer-to-Payer request in next month's batch. What's wrong?
show the answer
A. It has to go out within a week of getting the details and the opt-in The new plan has to request the data no later than a week after it has enough information about the previous payer and the member's opt-in. A monthly batch misses that window.