CMS-0057-F requires payers to support FHIR-based electronic prior authorization by January 1, 2027, but faster exchange won’t shorten the process if providers still assemble medical necessity documentation by hand from narrative notes. The real bottleneck is terminology: clinical detail has to be captured as coded concepts that map to ICD-10, CPT®, SNOMED CT®, LOINC® and RxNorm, so one record can answer PA requests, claims, risk adjustment and quality measures. Medicomp’s Quippe and MEDCIN clinical terminology capture that detail once at the point of care, either natively or through APIs alongside any EHR or ambient AI scribe, and populate payer questionnaires and FHIR® bundles from data already in the chart.
Federal deadlines under the Centers for Medicare & Medicaid Services Interoperability and Prior Authorization Final Rule (CMS-0057-F) are compressing how long payers have to respond to a prior authorization (PA) request, and requiring implementation of the Fast Healthcare Interoperability Resources (FHIR®) Prior Authorization application programing interface (API) by January 2027. The rule places obligations on payers, but they still depend on providers, who hold the clinical data.
In our experience, provider-side work is where much of the PA delay occurs. The bottleneck has more to do with how clinical detail is recorded than with how the software connects. The detail a payer wants usually exists somewhere in the chart, though it sits in narrative text instead of coded data a PA request can use. Health systems that capture it in structured form at the point of care can supply it on demand.
| Deadline | Requirement | Rule | Status |
|---|---|---|---|
| January 1, 2026 | Impacted payers must decide non-drug PA requests within 72 hours (expedited) or 7 calendar days (standard), give a specific reason for every denial, and publicly report PA metrics annually | CMS-0057-F | In effect |
| January 1, 2027 | Payers must support electronic prior authorization through a FHIR-based Prior Authorization API, alongside the Provider Access, Payer-to-Payer and enhanced Patient Access APIs | CMS-0057-F | Final |
| October 1, 2027 | Would extend electronic PA, decision timeframes and denial reasons to drugs through the Prior Authorization API, pharmacy-benefit drugs through three NCPDP standards | CMS-0062-P | Proposed; comments closed June 15, 2026 |
Dates reflect general compliance; exact dates vary by payer type.
A Diffuse Process
Since January 1, 2026, affected payers have had to answer standard requests within seven calendar days and expedited requests within 72 hours. That turnaround means little unless the provider side can assemble its documentation just as quickly.
We regularly hear about requests that take three to five days to assemble, moving between patient access, revenue cycle and whichever clinician can speak to medical necessity, all accessing the same chart. Add a fast payer decision, and the total cycle time can still run past ten days, since the payer’s clock does not start until the request arrives.
Payers must also now supply a specific reason for every denial, regardless of the submission method. A denial tied to thin or mismapped clinical detail used to arrive as a generic rejection, but the reason is now specified, which lets a health system count how many of its denials trace to its own clinical documentation.
One Crosswalk Does Not Cover the Rest
In July 2026, the American Medical Association (AMA) announced an initiative to develop and deploy SNOMED CT to Current Procedural Terminology (CPT) mappings to support electronic prior authorization ahead of the 2027 deadline, and is making the maps royalty-free for that use. We read the move as recognition that prior authorization is a terminology problem more than a data exchange problem. A request can be sent electronically in seconds, but that matters little when a nurse or coder still assembles the clinical justification behind it by hand.
The initiative also looks early, covering two code sets and one use case, with the AMA still recruiting participants for testing and pilot projects. Prior authorization is a reasonable place to begin, though it is one of several processes competing for the same clinical detail.
For example, billing needs ICD-10 and CPT, risk adjustment needs diagnoses specific enough to support a Hierarchical Condition Category, laboratory exchange needs LOINC, medication reconciliation needs RxNorm, and clinical interoperability needs SNOMED CT.
The underlying clinical detail is largely the same in each case, but the destination format changes.
Mapping SNOMED CT to CPT in isolation solves the PA case alone, while mapping from one clinical foundation into all of those code sets keeps the other processes working from the same record. The underlying clinical detail is largely the same in each case, but the destination format changes.
Why Guessing at Codes Backfires
Some organizations hope general-purpose AI can read the clinical narrative and produce the right codes on its own, though the current benchmarks make that appear unlikely. Independent testing places general-purpose large language models at 50% to 59% accuracy on medical coding, and when researchers ran one clinical transcript through a model three times, only 52.9% of data elements came back consistent across all three notes. Essentially, AI coding is, at best, a coin toss.
A nonspecific code now triggers a specific denial reason tied to a specific code, which the organization must overturn on appeal using documentation that may be incomplete or nonexistent. Rework, delayed reimbursement and staff hours follow, undermining the efficiencies electronic prior authorization was meant to deliver.
What Mapping-Ready Documentation Requires
The Prior Authorization API supports providers by enabling them to see, inside the electronic health record, whether a payer requires authorization for an order and what documentation that payer expects. The supporting implementation guides allow those questionnaires to be populated from data already in the chart, so the payer’s criteria now arrive electronically, though whether the chart can answer them is a separate question.
The payer’s criteria now arrive electronically, though whether the chart can answer them is a separate question.
When a clinician records the diagnosis and supporting findings as coded clinical concepts, the required code set follows by lookup. The finding and the code stay attached, which is typically what an appeal or audit asks to see.
How Quippe Prepares Clinical Data for Prior Authorization
Quippe® and its MEDCIN® clinical terminology perform those duties beneath the workflow, capturing a concept once, at the point of care. The mappings to SNOMED CT, ICD-10, CPT, LOINC and RxNorm are already built, so a prior authorization request, a claim and a quality measure can draw on the same clinical record.
With the payer’s criteria in hand, Quippe can take on assembly tasks that otherwise fall to staff:
- Link the diagnosis code, current labs and prior therapies to the order
- Flag gaps between what the payer asks for and what the record contains
- Populate the payer’s question set from coded values already captured, including diagnoses, lab values, therapies tried and failed, and the dates that establish sequence
- Assemble the FHIR bundle of requested documentation for submission
Quippe sits underneath whatever an organization already runs, whether that is an electronic health record, an ambient AI scribe or both, adding to that stack without replacing it, so clinicians keep documenting the way they already do.
Quippe-Native Systems Not Required
Your electronic health record (EHR) and practice management (PM) systems do not need to be Quippe-native to implement the solution. Simple Quippe APIs can be layered into any system, or other intermediate health technology, allowing extraction of the above-mentioned codes/coding systems from clinical notes and conversions into FHIR-ready, structured, data-rich payloads for prior authorization computing.
Preparing for January and Beyond
On January 1, 2027, affected payers must support electronic prior authorization through FHIR-based APIs, which should make the exchange itself faster. Whether it improves prior authorization will still depend on the data each request carries.
For health systems planning past January, the compliance scope looks likely to widen further. In April 2026, CMS proposed the Interoperability Standards and Prior Authorization for Drugs rule (CMS-0062-P), which would extend much of CMS-0057-F to prior authorization for drugs and require impacted payers to support three National Council for Prescription Drug Programs standards beginning October 1, 2027. The rule is not yet final, though the direction is clear enough to plan around.
Each new rule tends to add another code set or standard a health system must satisfy. Medicomp Systems maintains the mappings between MEDCIN concepts and the standard terminologies as those standards are revised, so an organization that captures clinical detail once does not have to rebuild its mappings.
For anyone reviewing readiness this fall, the question worth asking is whether a payer’s medical necessity request can be answered from structured data already in the record. Quippe can have that answer waiting before the request is made, coded and mapped to the required terminology, which puts a health system in a stronger position on January 1 and on every request that follows.
Can your chart answer a payer’s medical necessity question before it’s asked? See how Quippe turns point-of-care documentation into coded, mapped, PA-ready data inside the EHR you already run. Request a demo →
Updated September 29, 2026