04 Sep
Five months. That’s what’s left before January 1, 2027, and most EHR platforms still treat FHIR as a checkbox on a sales sheet instead of a working feature.
CMS-0057-F doesn’t name EHR vendors anywhere in its text. It regulates payers: Medicare Advantage plans, state Medicaid and CHIP programs, and QHP issuers on the federal exchange. But the rule builds a relay race, and the EHR is the second leg. Payers stand up the Prior Authorization API. Providers submit through whatever system sits on their desktop. If that system can’t speak FHIR, the provider is back to fax machines and portals while their competitor down the street submits a prior auth in the time it takes to finish an office visit.
That gap is where EHR vendors either win new contracts or lose existing ones.
The deadline everyone's citing wrong
Two dates matter here, and vendors keep collapsing them into one.
January 1, 2026 already passed. That was the operational deadline: payers must now respond to urgent prior auth requests within 72 hours and standard requests within 7 calendar days, and they have to give a specific reason when they deny a claim. No API required for any of that. Just process.
January 1, 2027 is the one that changes your product roadmap. That’s when impacted payers need four production FHIR APIs running: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. CMS finalized this rule back in February 2024, giving the industry roughly three years of runway. Most of that runway is gone.
Here’s the part vendors miss: a payer can technically hit their own deadline and still leave providers stuck, if none of the EHR systems those providers use can consume the API correctly. Certification on the payer side doesn’t guarantee usability on the provider side. That’s a separate build, and it’s yours.
Where most EHR platforms actually stand right now
We’ve reviewed integration roadmaps across a handful of mid-market EHR vendors this year, and the pattern repeats almost every time.
- US Core / USCDI support exists, but it’s read-only. The EHR can export a patient summary in the right format. It can’t accept a structured request and respond with a live decision.
- SMART on FHIR is bolted on, not built in. OAuth 2.0 scopes work for a demo. They break under real launch context switching between patients, encounters, and provider roles.
- CRD hasn’t touched the order entry screen. Coverage checks still happen after the order is placed, usually by a staff member calling the payer or checking a portal.
- DTR is missing entirely. Nobody’s built the piece that pulls the payer’s specific documentation template and pre-fills it from the chart.
- PAS submission is manual or absent. Even where clinical data flows out cleanly, nothing packages it into a FHIR bundle and sends it to the payer’s Prior Authorization API.
- Provider Access consumption isn’t planned. Payers will expose patient records to in-network providers. Most EHR roadmaps haven’t scheduled the work to pull that data in.
None of this is a five-alarm failure. It’s a normal starting point for a company that built its platform before Da Vinci implementation guides existed in a usable state. But normal starting points don’t finish themselves.
The four things you need to ship, in order
Skip the temptation to build all four APIs in parallel. They depend on each other, and building them out of sequence creates rework.
- SMART on FHIR authorization, first. Every other capability rides on top of this. If your OAuth 2.0 implementation can’t handle launch context correctly, CRD and DTR will fail silently downstream.
- CRD at the point of order. This is the highest-visibility win for your provider customers. A clinician orders an MRI, and the system tells them instantly whether prior auth applies and which payer rule governs it.
- DTR to auto-populate the ask. Once CRD flags a requirement, DTR pulls the payer’s specific questionnaire and fills it using structured chart data instead of a blank PDF.
- PAS to submit and receive the decision. The completed documentation bundles into FHIR and goes to the payer’s Prior Authorization API, with a status update landing back in the same workflow the clinician started in.
Ship them in that order and each step gives you something demoable before the next one is done. Ship them out of order and you’ll spend months debugging authorization instead of shipping features.
What the Da Vinci APIs each require from your side
| API | What it does | Who calls it | What your EHR must build |
|---|---|---|---|
| CRD (Coverage Requirements Discovery) | Checks if prior auth applies, at order time | Clinician’s EHR, in real time | CDS Hooks integration at the order entry event, plus a live call to the payer’s CRD service |
| DTR (Documentation Templates and Rules) | Pulls the payer’s exact prior auth form and pre-fills it | EHR, triggered after CRD flags a requirement | SMART on FHIR app launch from within the chart, plus mapping local data fields to the payer’s questionnaire |
| PAS (Prior Authorization Support) | Packages and submits the completed request | EHR, sending to the payer | FHIR Bundle construction (Claim, Task, supporting docs) and secure transmission to the payer’s PAS endpoint |
| Provider Access API (payer side) | Gives in-network providers patient data from the payer | Your EHR, pulling from the payer | A FHIR client that authenticates, requests, and reconciles incoming payer data against the existing chart |
Notice the pattern. Three of the four rows are things your EHR sends. One is something it receives. Most vendor roadmaps we’ve seen invest almost all their early effort in the receiving side, because it looks like existing interoperability work. The sending side is where the real prior auth automation lives, and it’s also where the work is newest.
The gaps that sink go-live dates
A few specific failure points keep showing up in vendor postmortems.
- Terminology mapping between local order codes and payer-required code systems (LOINC, CPT, HCPCS) gets underestimated by months, not weeks.
- CDS Hooks implementations that work in a sandbox often break against a real payer’s CRD service because payer implementations vary more than the implementation guide suggests they should.
- Security review takes longer than the build. OAuth 2.0 with SMART on FHIR launch context needs a real security assessment, not a checklist.
- Testing against one payer’s sandbox doesn’t mean the integration works against the next payer. Every connection needs its own validation pass.
- Nobody assigned an owner for ongoing FHIR maintenance after go-live, so the first spec update after launch catches the team flat-footed.
Run a version of this checklist against a client’s roadmap, and the terminology mapping alone will add six weeks nobody had budgeted for. That’s not unusual. It’s the default.
What to do in the next 90 days
Stop treating this as one big compliance project and break it into pieces you can actually finish.
- Pick one payer partner willing to open sandbox access now, and get your SMART on FHIR authorization working against their environment first.
- Scope CRD as its own release. Don’t bundle it with DTR or PAS in the same sprint plan.
- Get a security review scheduled before the engineering team needs sign-off, not after.
- Assign a single owner for FHIR spec tracking. Implementation guides change, and someone needs to notice when they do.
- Talk to your top five provider customers about which payers they submit to most. Build against those payers first, not whichever one has the friendliest sandbox docs.
January 1, 2027 isn’t a soft deadline that quietly slides. It’s a federal compliance date tied to payer contracts, and providers using your platform will feel the consequences of a missed build before you do. The vendors who treat this as four separate, sequenced product releases will hit the date with something that actually works. The ones treating it as one giant compliance sprint will ship something in December that breaks in January.
Start with SMART on FHIR authorization this quarter. Everything else depends on getting that piece right.
FAQs
No. CMS-0057-F regulates payers, not EHR companies. But the rule only works if provider-facing software can call the payer APIs it mandates. If an EHR can't run CRD at order entry, populate DTR forms, or submit PAS bundles, the provider using that EHR gets locked out of the automated prior authorization workflow the rule creates, regardless of what the payer built.
January 1, 2027, for most impacted payers, covering Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs. Operational requirements, like 72-hour turnaround on urgent prior auth decisions, already took effect January 1, 2026. The API deadline is the harder one, and it's an engineering problem, not a policy memo.
CRD (Coverage Requirements Discovery) fires inside the EHR at order time and tells the clinician if prior auth is needed. DTR (Documentation Templates and Rules) pulls the payer's specific questionnaire and auto-fills it from the chart. PAS (Prior Authorization Support) packages that documentation into a FHIR bundle and submits it to the payer for a real-time or near-real-time decision. They're sequential steps in one workflow, not competing standards.
Waiting means shipping a compliance patch under deadline pressure instead of a tested product. Payers are already standing up sandboxes for CRD, DTR, and PAS testing well ahead of January 2027, and vendors who connect early find the mapping and terminology problems before go-live, not during it.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
