Electronic prior authorization engineering
We build prior authorization automation for providers, payers and health tech products: coverage discovery at order entry with Da Vinci CRD, documentation that fills itself from the chart with DTR, submission and status with PAS and the X12 278, and a work queue for the payers that still run on portals and fax. Our own CRD, DTR and PAS servers are public on GitHub with their Inferno results, and every build is aimed at the CMS-0057-F dates: January 1, 2026 for decision timeframes and January 1, 2027 for the Prior Authorization API.
Scope your prior authorization automationFor provider groups, health systems, payers, utilization management vendors and health tech companies automating prior authorization. Updated September 26, 2026.
CDS Hooks at order-sign returns whether authorization is needed
Payer questionnaire pre-filled from the chart with CQL, clinician completes the rest
FHIR Claim bundle or 278 request with attachments, tracked to a response
Approved, pended, more information or denied with a specific reason, owned in a queue
Illustrative workflow · scope tailored to your environment
The short answer
Prior authorization automation software moves a request from order to payer decision with as little manual work as possible. It asks the payer whether authorization is needed while the clinician is still ordering (Da Vinci CRD over CDS Hooks), pulls the payer's documentation questions and pre-fills them from the chart (Da Vinci DTR), submits the request and tracks the response (Da Vinci PAS, which maps to the HIPAA X12 278), and routes everything that cannot go electronically to a work queue for portals and fax. CMS-0057-F requires impacted payers to answer within 72 hours for expedited and 7 calendar days for standard requests from January 1, 2026, and to run a FHIR Prior Authorization API by January 1, 2027.
Read CMS-0057-F requirements explainedStart with the real problem
Staff look up whether a service needs authorization, find the right payer form, copy notes from the chart into a portal, attach documents, then call or check back until a decision arrives. Each payer has its own list, its own portal and its own documentation rules, and requests stall on a missing field nobody saw. Electronic standards now cover each step, but payers and EHRs adopt them at different speeds. A working system uses CRD, DTR and PAS where the payer supports them, the X12 278 where it does not, and a well-run queue for everything else.
What we build
Providers usually need the queue and the EHR connection first; payers need the three Da Vinci services and the 278 bridge. We scope around your side of the transaction.
A CDS Hooks service or client that tells the ordering clinician whether prior authorization is required, which documentation is needed and whether the service is covered, before the order is signed.
Da Vinci CRD explainedPayer questionnaires delivered to the EHR or a SMART app, pre-filled from the chart, completed by the clinician and stored as a QuestionnaireResponse with the request.
Da Vinci DTR implementation guideRequests submitted as a FHIR Claim bundle and tracked to a ClaimResponse, with pended decisions delivered by subscription, and an intermediary that converts to and from the X12 278 where the payer requires it.
Da Vinci PAS and the X12 278One queue for every request, whatever the channel: status, due dates against the 72-hour and 7-day timeframes, missing documents, payer portal tasks and fax follow-up, each with an owner.
Prior authorization workflow engineModels that read the chart against the payer's criteria, suggest answers and attach the supporting notes, with a clinician confirming every answer before submission.
Building an AI prior authorization agentFor payers and their delegated utilization management vendors: CRD, DTR and PAS services connected to the UM system, with decision timeframes, denial reasons and public reporting metrics built in.
CMS-0057-F interoperability suiteYour starting point
Your staff work across many payer portals and fax. We connect the EHR to a single work queue, add CRD and DTR where your payers support them, submit through PAS or the 278, and track every request to a decision.
You need a FHIR Prior Authorization API by January 1, 2027 and decision timeframes and denial reasons from January 1, 2026. We build CRD, DTR and PAS on your UM system and test them with Inferno.
Your product serves specialty practices, pharmacies or care management teams and customers want prior authorization inside it. We build the request model, payer connections and queue as a module you own.
The Engineering Engagement
Workstreams are selected around your priorities. Each comes with an output your team can inspect, test and own.
For each payer and service line, record whether authorization is needed and which channel works: CRD, DTR and PAS, the X12 278 through a clearinghouse, a portal or fax.
Connect to Epic, Oracle Health, athenahealth or your EHR through CDS Hooks, SMART on FHIR and FHIR APIs, or HL7 v2 orders where FHIR is not available.
Build or connect the three Da Vinci services, with the versions your counterparties support (2.0.1 or 2.2.x), SMART Backend Services auth and test data.
Create and read 278 requests and responses, send supporting documents as 275 attachments or through the payer's route, and match every response to its request.
Show each request's status, due date, owner and next action, with portal tasks and fax follow-up in the same queue and denial reasons stored as data.
Report volumes, approval, pend and denial rates, turnaround by payer and service, and keep a full history of each request and its documents.
Compare your options
Each works for some organizations. The choice depends on your side of the transaction and how many payers and EHRs you connect.
| Custom prior authorization automation | Prior auth SaaS vendor | EHR native prior auth features | |
|---|---|---|---|
| Best for | Payers, UM vendors, health tech products and multi-EHR provider groups | Provider groups that want a service quickly | Health systems standardized on one EHR |
| Standards | CRD, DTR, PAS and X12 278, versions chosen per counterparty | Vendor's supported set | What the EHR release supports |
| Payer coverage | Every payer, with portal and fax tasks for the rest | Vendor's payer network | Payers connected to the EHR |
| CMS-0057-F payer API | Built and tested with Inferno | Offered by some vendors | Not a payer product |
| Data and rules | Owned by you | Held by the vendor | In the EHR |
| Cost shape | Build cost, then hosting and support | Per-request or subscription fees | EHR license and configuration |
Payers usually build or extend; providers often combine EHR features with a custom queue for the payers the EHR does not reach.
Expertise is in the decisions
From January 1, 2026, Medicare Advantage, Medicaid and CHIP payers must decide within 72 hours for expedited and 7 calendar days for standard requests and give a specific denial reason, with the first public metrics posted by March 31, 2026. By January 1, 2027 impacted payers, including QHP issuers on the federal exchanges, must run the Prior Authorization, Provider Access and Payer-to-Payer APIs.
HIPAA still names the X12 278 as the standard transaction. CMS allows a FHIR-based Prior Authorization API under enforcement discretion, and PAS defines the mapping to the 278. Most programs run both until every counterparty moves.
CMS recommends CRD, DTR and PAS 2.0.1, and newer 2.2.x versions are published. Payers and EHRs adopt them at different times, so the service must negotiate the version with each partner.
CMS-0057-F covers items and services, not drugs. Pharmacy prior authorization runs on NCPDP SCRIPT ePA transactions, so drug requests need their own route in the queue.
The software prepares, submits and tracks requests; the payer's clinical review decides. Every request keeps a clear record of what was sent and what came back.
Pre-filled and AI-suggested answers are shown with their source, and a clinician confirms them before submission.
Timeline
The schedule depends on how many payers and EHRs you connect and which side of the transaction you are on.
Map payers, services, channels, EHRs and current volumes with your utilization or access team.
The request ledger, queue and EHR integration for one service line.
CRD, DTR and PAS or the 278 for the payers that support them, tested with Inferno and payer test environments.
More payers, service lines and AI-assisted documentation, with reporting.
Delivered work
Our Da Vinci servers are public, with Go and .NET implementations and their Inferno results. CMS runs no certification program for these APIs, so Inferno results are the conformance evidence.
Coverage Requirements Discovery on CDS Hooks. Inferno CRD test kit: 136 passed, 0 failed (v2.2.1) and 86 passed, 0 failed (v2.0.1).
Prior Authorization Support with $submit, $inquire and subscriptions. Inferno PAS test kit: 84 of 84 (v2.2.1) and 68 of 68 (v2.0.1).
Documentation Templates and Rules with questionnaire packages and adaptive questionnaires. Every test passes apart from two Inferno test-kit issues (one open, one fixed upstream and awaiting deployment): 43 passed, 2 failed (v2.2.0) and 17 passed, 2 failed (v2.0.1).
Payer, plan, copay and prior authorization needs read from the eligibility response before each visit for a US wound care group, with claims scrubbed before submission.
A test clearinghouse covering 270/271, 278, 837, 999 and 277CA, 835 and 276/277, used to test 278 flows before a live payer connection.
From discussion to delivery
Payers, services, channels, EHRs and deadlines agreed in writing.
Request model, queue, payer rules and documentation flow reviewed with your access or UM team.
Working software every two weeks, tested with Inferno, payer test environments and our clearinghouse simulator.
Payers switched on one at a time, with request volumes and turnaround tracked from day one.
We agree the scope, dependencies, acceptance criteria and commercial model before implementation. Your existing team can stay involved throughout.
Find the right starting point ↓Before you commit
It is software that moves a prior authorization request from order to payer decision with little manual work. It checks whether authorization is needed at order entry, collects and pre-fills the payer's documentation from the chart, submits the request electronically, tracks the response and routes anything that cannot go electronically to a work queue.
From January 1, 2026, impacted payers must decide prior authorization requests within 72 hours for expedited and 7 calendar days for standard requests (QHP issuers on the federal exchanges are excluded from these timeframes), give a specific reason for denials, and publish prior authorization metrics, first by March 31, 2026. By January 1, 2027 they must run a FHIR Prior Authorization API along with Provider Access and Payer-to-Payer APIs.
They are HL7 FHIR implementation guides for electronic prior authorization. CRD (Coverage Requirements Discovery) tells the clinician at order entry whether authorization is needed. DTR (Documentation Templates and Rules) delivers the payer's questions and pre-fills them from the chart. PAS (Prior Authorization Support) submits the request and returns the decision.
Yes, for many payers. HIPAA names the X12 278 as the standard prior authorization transaction, and CMS allows FHIR-based APIs under enforcement discretion. PAS defines how a FHIR request maps to the 278, so we build both paths and choose per payer.
Yes. Epic supports CDS Hooks, SMART on FHIR apps and payer connections for electronic prior authorization. We connect CRD, DTR and PAS services to Epic, and where a payer is not connected we route the request to the work queue so staff see every request in one place.
Any system built on CDS Hooks and SMART on FHIR can integrate with Oracle Health, which supports both. We build and test the Oracle Health connection per client, using its FHIR APIs for orders, coverage and documents and HL7 v2 where an interface is already in place.
AI can read the chart against payer criteria, suggest answers to documentation questions and attach supporting notes, which removes much of the manual work. A clinician confirms each answer before submission, and the payer's review decides the request. We keep a full record of what the model suggested and what was sent.
Ask for Inferno results against the Da Vinci CRD, DTR and PAS test kits for the versions you need, support for the X12 278 alongside FHIR, SMART Backend Services auth, and reporting for the metrics CMS requires. CMS runs no certification program for these APIs, so Inferno results are the conformance evidence.
No. The rule covers items and services. Drug prior authorization runs on NCPDP SCRIPT electronic prior authorization transactions through the pharmacy benefit, and CMS has proposed separate rules for drugs. We build that route into the queue when you need it.
They become tasks in the same queue: the request, the payer's portal link, required documents and a due date, with fax intake that classifies incoming responses and attaches them to the right request. Every request has an owner whatever the channel.
Cost depends on your side of the transaction, the number of payers and EHRs, the Da Vinci versions required, whether the X12 278 is in scope, and AI-assisted documentation. We give a fixed-scope estimate after discovery, broken down by module and integration.
Yes. We sign BAAs and we are ISO 27001:2022 certified. Requests, documents and model outputs are stored with role-based access, full audit logs and encryption in transit and at rest.
A useful first conversation
Tell us what exists today, who uses it and where the workflow breaks. We’ll discuss the scope, access dependencies and the next practical step.
A product overview and a de-identified workflow are enough to start. No patient records or credentials are needed.
These are independent reference sources, not endorsements. Applicability, platform access and current requirements are confirmed for your project.
From our YouTube channel
Explore the workflows and decisions behind this service. Demonstrations and recorded discussions have the scope described in each video.
Explore the prior authorization rule and API workflows. Confirm current requirements with official sources.
