The January 2027 Prior Authorization Reckoning: FHIR API Mandates, the Two Year MIPS Attestation Ramp, ONC Certification Gates, and Why the Real Money Sits Between the Payer Endpoint and the Order
🎧 Part I Podcast free on Spotify.
🎧 Part II Podcast episode for paid subscribers only. Also available on Spotify.
To listen to paid episodes in Apple or Spotify, link your Substack subscription via the show settings on those platforms (instructions inside the Substack app under Subscriptions → Podcast).
Abstract
Part 4 covers the interoperability half of the story: the 2024 CMS Interoperability and Prior Authorization final rule hitting its January 1, 2027 API compliance date, and the 2027 proposed rule’s rework of the clinician side attestations. Key mechanics:
Impacted payers, meaning MA organizations, state Medicaid and CHIP fee for service programs, Medicaid and CHIP managed care entities, and QHP issuers on the federally facilitated exchanges, must implement enhanced FHIR APIs by January 1, 2027: Patient Access, Provider Access, Payer to Payer, and Prior Authorization
The Prior Authorization API must publish covered items and services, surface documentation requirements, accept requests, and return approvals with expiration terms, denials with specific reasons, or requests for more information
Decision clocks of 72 hours expedited and 7 calendar days standard, plus specific denial reasons and public PA metrics, already operational since the beginning of 2026
The MIPS Electronic Prior Authorization measure flips from required in 2027 to optional and bonus eligible in 2027, then mandatory in 2028 with CEHRT modules certified to all three ONC electronic prior authorization criteria
A new Electronic Prior Authorization for Prescription Drugs measure required starting 2028, aligned with the CMS 0062 P drug prior auth proposed rule
CMS seeking comment on extending ePA measures to Shared Savings Program ACOs in future years
The build list: requirement discovery and documentation assembly middleware, payer rules and outcomes graphs built from structured denials, appeal automation with human control, drug ePA as a parallel transaction stack, and payer side implementation tooling
Table of Contents
Why prior auth got a federal plumbing mandate
What the 2024 final rule actually requires by January 2027
The four APIs, briefly and honestly
The attestation ramp: rehearsal in 2027, mandate in 2028
Certification is the distribution gate
The workflow gap is where the product value lives
Denial reasons as training data
Drug prior auth is a neighboring country with its own customs
The payer side is also a market
What this means for ACOs and the Part 1 data layer
The build list and the series thesis
Why prior auth got a federal plumbing mandate
Prior authorization is the one healthcare administrative process that unites physicians, patients, hospitals, and late night comedians in shared contempt. The current state involves phone trees, proprietary portals, faxes that refuse to die, and the genuinely absurd preliminary ritual of contacting a payer to ask whether a service requires permission before beginning the process of asking for permission. The costs are measured in staff hours, abandoned care, and delayed treatment, and everyone has known this for twenty years. What changed is that CMS decided the fix was infrastructure rather than exhortation. The 2024 Interoperability and Prior Authorization final rule, CMS 0057 F, mandated standardized FHIR interfaces and, in the same rulemaking, set prior authorization decision timelines that take effect beginning January 1, 2026, across most federally regulated coverage, and the operational deadlines are no longer abstract. The timeline and transparency requirements went live at the start of 2026. The API requirements land January 1, 2027, which at this point is a countdown measured in months, not rulemaking cycles. The 2027 proposed rule then adjusts how clinicians get scored for actually using the new plumbing, and the adjustment is more interesting than it looks.
What the 2024 final rule actually requires by January 2027
The rule applies to what CMS calls impacted payers: Medicare Advantage organizations, state Medicaid and CHIP fee for service programs, Medicaid and CHIP managed care plans, and Qualified Health Plan issuers on the federally facilitated exchanges. Notably absent are employer sponsored commercial plans and traditional Medicare itself, so the mandate covers a large share of covered lives while leaving the commercial book to follow voluntarily or not at all, which matters for anyone modeling market coverage of a product built on these rails.
Two requirement families are already in force. Since the start of 2026, impacted payers must issue prior authorization decisions within 72 hours for expedited requests and 7 calendar days for standard requests and must provide specific reasons when denying; however, the public reporting of prior authorization metrics including approval, denial, and appeal outcomes applies beginning with the initial reporting due March 31, 2026 for 2025 data, not at the start of 2026 itself. The specific denial reason requirement is quietly the most commercially important sentence in the rule, and the reason gets its own section below. The second family is the January 1, 2027 API compliance date, which requires the payer to stand up and enhance a set of FHIR based interfaces that turn prior authorization and payer data exchange from portal archaeology into machine readable transactions.
The four APIs, briefly and honestly
The Patient Access API, which predates this rule, gets enhanced to include prior authorization information, so a beneficiary’s app can see what has been requested, approved, and denied. The Provider Access API requires payers to share claims, encounter, specified clinical data, and non drug prior authorization information with in network providers who have a treatment relationship with the patient, subject to attribution processes and patient opt out. The Payer to Payer API moves the same data classes between plans when a patient switches coverage, addressing the eternal problem of every new plan pretending the patient’s history began at enrollment. And the Prior Authorization API is the centerpiece: it must let a provider’s system discover whether a given item or service requires prior authorization, identify the documentation requirements, submit the request electronically, and receive a decision that is an approval with its expiration conditions, a denial with specific reasons, or a request for more information. In implementation terms this maps to the FHIR Da Vinci pattern the industry has been piloting for years, coverage requirements discovery, documentation templates and rules, and prior authorization support, and the three ONC electronic prior authorization certification criteria referenced by the 2027 rule align to exactly those functions.
The honest assessment is that the APIs solve transport and discovery, which is real, and solve nothing else. Knowing that a lumbar MRI requires authorization and that the payer wants six weeks of documented conservative therapy does not locate the conservative therapy in the chart, judge whether the physical therapy notes are recent enough, or fix the request when the payer bounces it back. Those are workflow and content problems, and the rule deliberately leaves them to the market.
The attestation ramp: rehearsal in 2027, mandate in 2028
The 2024 rule originally required MIPS clinicians to attest for the 2027 performance period that they used a Prior Authorization API via CEHRT for at least one hospital discharge and medical item or service (excluding drugs). The 2027 proposed rule softens then hardens this. For 2027, the Electronic Prior Authorization measure becomes optional and available for bonus scoring if finalized as proposed. For 2028, it becomes required, and the CEHRT must include health IT modules certified to all three ONC electronic prior authorization criteria. Separately, a brand new measure, Electronic Prior Authorization for Prescription Drugs, arrives as a 2028 requirement, aligned with the CMS 0062 P proposed rule covering drug prior authorization standards.
Read as sequencing rather than retreat, this is smart regulatory design. The payer APIs go live January 2027, and requiring every MIPS clinician to transact against them in the same year the endpoints are being debugged would have produced a mutual failure spiral, with clinicians blaming payer endpoints and payers blaming provider systems while CMS adjudicated the finger pointing. Instead, 2027 becomes a rehearsal year with a carrot: early adopters collect bonus points in a program where the performance threshold sits at 75, vendors get twelve months of production traffic against real payer endpoints before failure carries penalties, and the payers get a year of load below mandate volume. Then 2028 is proposed to arrive with two mandatory measures, medical and drug, and the entire MIPS eligible population would need certified ePA capability at once if the proposal is finalized. For anyone selling into this market, that is the demand curve drawn in advance: a thin early adopter market in 2027 that determines reference customers and integration lessons, followed by a compressed compliance driven buying wave through 2028. The companies that treat 2027 as the product hardening year win the 2028 stampede. The companies that wait for the stampede will be doing implementations at gunpoint.
Certification is the distribution gate
The 2028 requirement that CEHRT include modules certified to all three ONC electronic prior authorization criteria turns certification into the market’s bouncer. A startup with an excellent prior auth workflow has three routes past the rope. It can partner with an incumbent certified EHR vendor and live inside someone else’s roadmap, which is fast to market and slow to everything afterward. It can license or white label a certified module, trading margin for speed. Or it can pursue ONC certification for its own module, which costs real money and quarters of effort but yields control of the integration surface and a moat measured in regulatory friction. Each route reshapes the sales cycle, because the buyer’s question shifts from does this work to does this count, and the answer to does this count is a certificate number, not a demo.
There is also a structural consequence worth naming: the certification requirement quietly favors the large EHR vendors, who will certify their native modules and bundle them at marginal prices, exactly as they did with prior certification waves. The independent vendor’s survivable position is not competing on the certified transaction, which becomes a commodity checkbox, but on everything the checkbox does not do, which is the next section.
The workflow gap is where the product value lives
Picture the transaction from inside the clinic. A clinician orders a procedure. The useful system asks the payer’s coverage requirements discovery endpoint whether authorization is needed and what evidence is required, then goes hunting in the chart: the diagnosis codes, the relevant labs and imaging, the medication history showing the failed conservative therapy, the notes documenting duration and severity. It assembles the documentation package against the payer’s rules, shows the clinician or staff exactly what is present and what is missing before submission, submits through the Prior Authorization API, tracks the transaction state against the 72 hour and 7 day clocks, handles the request for more information loop without anyone opening a separate portal, and writes the final status, including the approval’s expiration conditions, back onto the order where the scheduling team can see it. Then it retains the whole evidentiary trail, because an approval that cannot be reproduced during a payment dispute is a rumor.
Every clause in that paragraph is a place the generic FHIR connector does nothing and the workflow product earns its keep. The chart retrieval problem alone, finding and judging the sufficiency of clinical evidence, is a genuine language model application with actual economic stakes, and it is bounded enough to do responsibly: the model proposes the evidence package, the human approves the submission, and the audit trail records both. Fully autonomous submission is the place to not get cute, both because payers will treat automated volume adversarially and because the liability for a fabricated clinical assertion lands on the practice, not the vendor. The design principle is automation of assembly, human ownership of attestation.
Denial reasons as training data
The requirement that denials carry specific reasons, combined with machine readable transactions and the public reporting of payer level prior authorization metrics, converts an infuriating outcome into a strategic dataset. Every denial now arrives as structured feedback: this payer, this plan, this service, this diagnosis, this site of care, this documentation package, this result. Accumulate that across a customer base and the system stops being a submission pipe and becomes a predictive rules engine. It can warn before submission that the conservative therapy documentation is missing or stale, that this payer routinely bounces this service at this site of care, that the imaging result is older than the plan’s lookback tolerance. It can rank which requests to expedite, draft appeals against the stated denial reason with the responsive evidence attached, and tell a medical group which payers’ real world behavior diverges from their published policies, which is negotiation ammunition at contracting time.
The defensible asset, then, is not the transaction capability everyone will have by 2028. It is a continuously updated policy and outcomes graph, payer by payer, tied to source documents and transaction history. That graph compounds with volume, which means the market has increasing returns to scale and the early network of high volume customers is worth subsidizing. It also, inevitably, invites the arms race question, since payers can watch approval optimizing behavior and adjust. The stable equilibrium is the one where the tool raises first pass approval rates by making submissions genuinely complete and appropriate, which saves the payer review cost too, rather than by gaming criteria, which invites the criteria to mutate. Vendors get to choose which business they are in, and the choice will show up in their renewal rates.
Drug prior auth is a neighboring country with its own customs
The proposed 2028 prescription drug ePA measure, and the CMS-0062-P proposed rule it aligns with, extend the campaign into pharmacy, and anyone planning to copy and paste their medical ePA product into drugs is going to have a bad time. Drug prior authorization runs through pharmacy benefit managers rather than medical plans, speaks NCPDP transaction standards alongside the FHIR world, and lives inside e prescribing flows with their own formulary and benefit files, step therapy protocols, quantity limits, and specialty pharmacy routing. The clinical logic differs too: medical necessity for a procedure is an evidence narrative, while drug authorization is more often a criteria checklist about tried and failed alternatives, diagnosis codes, and lab thresholds, with the specialty drug tier adding hub services, financial assistance, and site of care fights.
The unified product opportunity is real but sits above the transaction layer: shared patient context, shared identity, one work queue for staff who currently juggle both worlds, and combined analytics on time to therapy and abandonment. Underneath, the transaction stacks stay separate, and pretending otherwise is how demos die in implementation. The commercial pitch on the drug side is measurable: prescription abandonment at the pharmacy counter is heavily driven by authorization friction, so the proof points are time to therapy, first fill rates, and staff touches per script, measured across the ugly long tail of plans rather than the one friendly PBM in the pilot. For pharma, faster authorization is faster revenue, which is why hub services and manufacturer funded access programs are an adjacent buyer category for the same infrastructure, with all the usual compliance chaperones that come with manufacturer money.
The payer side is also a market
The conversation defaults to provider side products, but somebody has to build the payer half, and January 2027 is close. Every impacted payer needs the four APIs live, needs its prior authorization criteria translated from PDF medical policies into machine executable requirement rules, needs its utilization management workflow rewired to consume structured submissions and emit structured decisions inside the regulatory clocks, and needs the public reporting pipeline for its PA metrics. The national carriers will build or buy at scale, but the market’s long tail, regional MA plans, Medicaid managed care organizations, and state fee for service programs, mostly cannot build this and will buy it as a service. Medicaid agencies in particular sit under the mandate with procurement cycles that move like continental drift, which paradoxically makes them durable customers once landed. The policy digitization work, converting clinical criteria documents into executable rules with version control and audit trails, is its own product category, and it has a second buyer in the provider side vendors who need the same rules from the other direction. A company that becomes the neutral rules translation layer, selling executable policy to both sides, occupies an enviably annoying to displace position.
What this means for ACOs and the Part 1 data layer
Two threads connect this part back to the beginning of the series. First, the Provider Access API is an underappreciated gift to accountable care. An ACO’s chronic problem is seeing what happens to its beneficiaries inside Medicare Advantage adjacent and cross payer contexts, and a standardized in network provider feed of claims, encounters, and clinical data, however imperfect the attribution mechanics, is a new pipe into the four ledger operating system Part 1 described. The enablement platforms that industrialize Provider Access API ingestion across many payers will have a data advantage that shows up directly in benchmark and utilization modeling. Second, the 2027 rule explicitly seeks comment on applying electronic prior authorization measures to Shared Savings Program ACOs in future years, and the new MSSP CEHRT attestation options already include a FHIR API based quality data pathway. The direction is unsubtle: CMS intends the accountable care population to run on the same standardized rails, and ACOs that build their data infrastructure FHIR native now are pre complying with rules that have not been written yet, which is the cheapest compliance there is.
The build list and the series thesis
Part 4’s products: requirement discovery and documentation assembly middleware sitting between the EHR and the payer endpoint, with human controlled submission and audit grade evidence retention; the payer rules and outcomes graph built from structured denials, sold as pre submission intelligence and appeal automation; a parallel drug ePA stack sharing context but not transactions with the medical side; payer side API implementation and policy digitization for the long tail of plans; and Provider Access API ingestion as a data feed business for the accountable care world.
Across four parts, one thesis kept surfacing. This rule cycle is CMS replacing trust based payment with verification based payment. Benchmarks get guardrails instead of projections, QP status attaches to the entity where the work actually happened, quality reporting demands attestation evidence instead of measure shopping, remote monitoring demands employed humans and initiating visits instead of contractor arbitrage, practice expense moves to auditable cost data instead of 2007 surveys, and prior authorization becomes a structured transaction instead of a fax based hostage negotiation. Every one of those substitutions creates demand for systems that produce, retain, and defend evidence. The last decade of healthcare software sold visibility. The next one sells proof. The comment period closes in September, the final rules land in the fall, and the entrepreneurs who read the preamble instead of the press release are, as usual, going to be the ones who saw it coming
.