How to Build an AI Prior Authorization Workflow
Key Takeaways
- CMS now requires impacted payers to decide expedited prior authorization requests in 72 hours and standard requests in 7 calendar days, with a specific reason on every denial.
- The API requirements under CMS-0057-F land January 1, 2027, so 2026 is the build year, not the planning year.
- Use the three Da Vinci guides as the workflow spine: CRD answers “is auth required,” DTR gathers the payer’s exact documentation, PAS carries the request and the decision.
- Keep AI in the document layer. Coverage rules, authorization status and final decisions belong in deterministic records a reviewer can inspect.
- A production provider-side build with CRD, DTR, PAS and an EHR integration runs $150K–$350K over 6–9 months; a single-specialty pilot starts near $60K.
Prior authorization is often seen as a paperwork problem. But if you follow a request through a provider’s office, it becomes clear that the bigger problem is getting different people and systems to work together before the patient can get an answer. The provider needs to check if authorization is required, the payer needs the correct clinical evidence, and staff on both sides need to keep track of the request without losing information. When this process fails, teams often go back to portals, phone calls, and fax.
One of the main challenges is that provider and payer systems still use a mix of modern standards and older interfaces to exchange information. Understanding the practical difference between HL7 v2 and FHIR helps to explain why information that exists in one system does not always arrive in a form another system can use.
AI can help with the unstructured parts of this process. It can sort incoming documents, pull supporting evidence from clinical notes, identify missing information and prepare a case for review. Coverage rules and final decisions need a different treatment. They should remain explicit, traceable and open to review by the people accountable for the outcome.
The timing matters. Under the CMS Interoperability and Prior Authorization Final Rule, impacted payers already face shorter decision windows and public-reporting requirements. Expedited requests generally require a decision within 72 hours, while standard requests require one within seven calendar days. A denial must include a specific reason. CMS also makes clear that the API does not turn every request into an instant automated decision. Some cases will continue to need clinical review. The CMS Prior Authorization API FAQ sets out those requirements.
For product and engineering teams, the goal is to reduce manual work without making the process difficult to understand or track. This requires good interoperability, security, and workflow design, just like any well-built healthcare software development project.
What Should AI Do in a Prior Authorization Workflow?
An AI prior authorization workflow is most useful in five main areas.
- Classifying incoming requests and attachments. The system recognizes forms, clinical notes, lab results, imaging reports and other supporting documents without a human sorting the packet first.
- Extracting evidence. It pulls diagnoses, procedure codes, medications, dates, and failed therapies that a coverage policy asks for.
- Finding what’s missing. It compares submitted evidence against the payer’s documented requirements and flags the gap before submission, not two weeks later.
- Drafting structured summaries. A 60-page packet becomes a short evidence summary a reviewer can work from.
- Routing and prioritizing. Routine, incomplete, urgent, and clinically complex cases go to different queues instead of one undifferentiated inbox.
What it should not do, invent missing evidence, rewrite a coverage rule, or issue an adverse decision without an accountable review path. A language model is probabilistic. Coverage rules, authorization status and final decisions need deterministic records someone can inspect a year later during an appeal.
So the architecture separates three concerns:
- Interoperability includes moving requests and responses between provider, payer, and EHR systems.
- Decision logic for applying explicit coverage and documentation rules.
- AI assistance for interpreting unstructured material and helping people finish the workflow.
Keep those layers apart and the system stays testable, auditable and changeable. If you blend them, you get a product nobody can explain to a compliance reviewer.
How the Da Vinci Standards Structure Electronic Prior Authorization
FHIR provides the basic data model, but electronic prior authorization needs more than just a standard FHIR endpoint. The main prior authorization standards come from the HL7 Da Vinci project. It includes three connected implementation guides that fit the way the process already works.
| Guide | Question it answers | Where it runs |
|---|---|---|
| CRD (Coverage Requirements Discovery) | Is prior authorization required, and which rules apply? | Inside the ordering workflow, while the clinician is placing the order |
| DTR (Documentation Templates and Rules) | What exactly does this payer need documented? | Questionnaires and rules in the provider system, prepopulated from the chart |
| PAS (Prior Authorization Support) | Submit the request, return the decision | Provider-to-payer transaction, mapped to the X12 278 behind the scenes |
CRD works while the clinician is ordering the service. It shows whether prior authorization is needed, what documents the payer requires, and what the next step is. This timing is important because finding out about the requirement after the patient has already left can lead to extra phone calls and delays of a week or more.
DTR is where AI assistance fits most naturally. A model locates supporting facts in the notes and proposes answers, but every extracted fact keeps a pointer to its source. Whoever reviews the form should be able to open the original note, see the passage the answer came from, and correct it in place.
PAS handles submission and response. The HL7 Da Vinci PAS implementation guide covers the electronic prior authorization request and response between provider and payer systems. Together with CRD and DTR, it’s meant to cut unnecessary requests, incomplete submissions and avoidable delay.
What Does an AI Prior Authorization Architecture Look Like?
There are seven layers where you can test each job independently.
1. Intake and normalization
Accept requests from EHRs, payer portals, APIs, and other systems already being used. Convert the incoming clinical and administrative information into one standard format, keep the original data, and give each request a correlation ID so every action can be traced back to it.
Don’t plan for clean FHIR resources. Real traffic includes PDFs, scanned forms, free-text notes and older X12 transactions, which is why EHR integration work usually takes longer than the estimate. The normalization layer identifies each format, validates required fields and quarantines anything unreadable.
2. Identity, eligibility and coverage checks
Confirm the patient, provider, plan, and requested service before sending the case to an AI model. The AI should never have to guess if two similar names belong to the same patient or if the patient’s coverage was active on the date of service.
Deterministic matching, eligibility services, explicit exception queues. Any ambiguous match stops automated processing and goes to a person.
3. Requirements discovery
Call the coverage requirements service and store the version of the rule that came back. Policies change frequently. If a request gets disputed six months later, your team has to show which requirement set applied at that moment.
The output is a machine-readable checklist that has required fields, required evidence, permitted values, and the conditions that force manual review.
4. Document intelligence
OCR, clinical NLP and LLMs add the most value here, and they also fail here. The pipeline classifies documents, extracts facts and maps evidence to the checklist. Every extracted item carries:
- Source document and page or section
- The exact supporting text
- A normalized value where one applies
- A confidence score
- Model, prompt and extraction version
- Whether a person confirmed or corrected it
Never let the generated summary become the only retained record. Reviewers need the source, not the model’s reading of it. Most of what goes wrong at this layer traces back to the same data quality issues in healthcare AI that break every other clinical model. This further leads to inconsistent formats, duplicate records and scanned pages that nobody can read. Building the extraction and review layer well is the part of AI application development that decides whether the rest of the system is trustworthy.
5. Rules and decision support
Run explicit rules against the structured evidence. The engine identifies a clearly complete request, a missing field, a policy mismatch. AI can explain the outcome in plain language, however it doesn’t get to change it.
Low-risk administrative checks can run automatically. Contradictory evidence, clinical judgment, a possible adverse outcome or a low-confidence extraction routes to a qualified reviewer. Matching the review level to the risk of the task is the same human oversight problem every HIPAA-regulated AI system runs into, and it’s worth designing before you write the routing code.
6. Submission, status and communication
Submit the package through the supported interface and maintain an explicit state machine which denotes draft, missing information, submitted, pended, approved, denied, appealed, expired.
Free-text status updates are not enough. Every status change should record who or what made the change, when it happened, and what evidence was available at that time. If the payer asks for more information, it should go back to the right provider task instead of creating a separate email thread. If the request is denied, keep the payer’s exact reason along with the related policy or evidence.
7. Audit and reporting
CMS requires impacted payers to publish aggregate prior authorization metrics starting in 2026. This includes approval and denial rates, approvals after appeal, extensions, average and median decision times. The CMS final-rule page carries the reporting template and implementation resources.
Set up the event model before launch so these numbers can be tracked from reliable records. Trying to work them out later from application logs can turn into a huge and unnecessary problem. The same discipline applies to logging AI-generated medical summaries, where the log is the only proof of what the model said and who signed off.
Which Guardrails Keep AI Prior Authorization Accountable?
“Human in the loop” is a slogan until you name the controls.
Require source-grounded extraction. Every clinical claim in a generated summary points to submitted evidence. Unsupported claims get blocked or clearly marked.
Set field-level confidence thresholds. One request can hold a high-confidence patient name and a low-confidence failed-therapy history. Route on the risky field, never on an average.
Prohibit silent completion. The system never fills a missing fact with a plausible value. “Not found” is a valid and important output.
Separate recommendation from decision. Store the AI suggestion, the rule result and the reviewer’s final action as three distinct records.
Log overrides and corrections. If reviewers keep fixing the same extraction, that’s product feedback and a monitoring signal, not noise.
Test for unequal error rates. Check whether extraction, missing-information flags, and routing behave differently across specialties, facilities, languages, and patient groups.
Prepare a fallback. If a model provider goes down or a new model version fails validation, the workflow continues through deterministic and manual paths.
None of this is optional decoration. It’s the evidence trail a regulator or a plaintiff’s attorney asks for, and it’s why HIPAA-compliant software development practices need to be in the architecture from day one rather than bolted on before launch.
What to Test Before an AI Prior Authorization System Goes Live
Build an evaluation set from representative, appropriately governed cases with clean submissions, incomplete packets, bad scans, conflicting notes, unusual terminology, urgent requests, and cases that genuinely need clinical judgment.
Measure the components separately.
- Document-classification accuracy
- Field-level precision and recall
- Unsupported-fact rate
- Missing-evidence detection
- Source-citation accuracy
- False routing between automated and manual queues
- Turnaround time by request type
- Reviewer correction and override rates
- Performance across specialties and patient groups
Don’t release the system just because the overall extraction results look good. Set clear errors that would block a release from the start, such as linking evidence to the wrong patient, making up a failed treatment, or sending a high-risk case away from clinical review. Even one of these errors should be enough to stop the release, no matter how good the overall results are.
For sequencing the whole rollout, our 90-day plan for launching an AI feature puts data mapping, risk definition and structured testing ahead of production traffic.
What Does Prior Authorization Automation Cost and How Long Does It Take?
Off-the-shelf prior authorization software works well for most common payer processes. A custom solution becomes more worthwhile when your specialties, EHR, or reviewer workflow does not match what the software was designed for. The cost ranges below are based on real US builds with a working reviewer interface and proper audit trails, not just a demo.
| Build tier | Scope | Typical cost | Timeline |
|---|---|---|---|
| Single-specialty pilot | One payer, one service line, DTR prepopulation and document extraction, manual submission | $60K–$120K | 3–4 months |
| Production provider-side workflow | CRD, DTR and PAS against 2–3 payers, EHR integration, reviewer queue, full audit trail | $150K–$350K | 6–9 months |
| Payer-side or multi-payer platform | PAS endpoints, coverage rules engine, CMS metrics reporting, appeals handling | $400K+ | 9–18 months |
Two line items get underestimated on almost every project. The first is payer-specific behavior. This is where two plans implementing the same guide will still differ in required fields, response timing and error handling, and each one costs integration time.
The second is the reviewer interface. Teams spend months on extraction quality and then hand clinical staff a screen that makes verification slower than reading the original packet. We hit both on a HIPAA-compliant healthcare claims platform build, where the queue design ended up mattering as much as the extraction pipeline.
Building for the CMS Deadline vs. Building for the Prior Authorization Workflow
The API deadline is real, and an endpoint alone removes almost no burden. The product has to work inside provider and payer operations in order to retain evidence, explain every transition, and give reviewers an interface they’d choose over the portal they use now.
This is also why AI should be used as an assistant rather than as the main system of record. It can help read documents, find evidence, and reduce repetitive work. However, coverage rules should remain clear, original sources should be kept, and important decisions should always be open for review. The same logic applies to adjacent revenue cycle work, which is why AI in medical billing tends to succeed in the extraction and validation layers and fail when it’s pointed at the determination itself.
Teams building this need healthcare interoperability, AI engineering and compliance aware product design at the same table, which is rarer than it sounds. Tech Exactly’s healthcare app development company team covers the clinical integration and workflow side of that.
The goal isn’t a faster decision for its own sake. It’s a workflow that’s faster because the evidence is complete, the rules are visible, and the right person can step in before an error reaches a patient.
Frequently Asked Questions
Impacted payers have to decide expedited requests within 72 hours and standard requests within seven calendar days. These are the maximum time limits, not the expected turnaround time. Requests with complete information and the right evidence can be processed much faster. This is why automating the documentation step makes more sense than automating the actual decision.
Some administrative steps and straightforward cases can be fully automated. CMS does not require real-time automated decisions, and plenty of requests still need clinical review. High impact or ambiguous cases should always have a defined human review path with a named accountable reviewer.
Impacted payers had to implement certain operational provisions by January 1, 2026. The principal API requirements are due primarily by January 1, 2027. Verify the rule and any program specific requirements that apply to your organization before you scope the build.
Electronic prior authorization is the standards based exchange itself which is carried over FHIR and the Da Vinci guides, or over NCPDP SCRIPT for pharmacy. AI prior authorization is the part that reads documents, finds the important evidence, and helps the people handling the transactions. The first one is the system that moves the information, while the other helps make sense of what is inside it.
FHIR and the Da Vinci guides help organise how the information is exchanged. AI can read unstructured documents, pick out important facts, find missing evidence, and prepare summaries. However, it should not replace the official transaction, coverage rules, or the person responsible for reviewing the case.
The payer’s response should clearly explain why the claim was denied. A model can help make the explanation easier to understand, but it must be based on the actual decision, policy and evidence. It should never generate a reason on its own.
