Challenge
Which systems see patient data
Agnotic approach
Models run only in environments covered by a business associate agreement, with no PHI used for vendor training.
AI in Healthcare / Prior Authorization
Prior authorization automation with AI and FHIR
Prior authorization still runs on portals, faxes and phone calls, and every delay holds up care and payment. Agnotic Technologies builds prior authorization automation for payers and providers: FHIR Da Vinci workflows, AI that gathers documentation, and people who make the decisions.
Da Vinci CRD, DTR, PASCMS-0057-FHuman reviewAudit logged
Trusted by global innovators
What is prior authorization automation software?
Prior authorization automation software checks whether a service needs approval, gathers the clinical documentation and submits the request electronically, so staff stop chasing it by fax and phone. Agnotic Technologies builds it for payers and providers using HL7 FHIR Da Vinci workflows, with AI preparing the request and qualified people making the decision.
Electronic prior authorization (ePA) is the standards-based version of this process: requests and decisions move between EHR and payer systems as structured data, through FHIR APIs or the HIPAA X12 278 transaction.
What does an automated prior authorization request look like?
From the provider's side: the requirement check at ordering, the documentation pulled from the chart, the submitted request and the payer's decision, all tracked in one place.
Protecting PHI
How is PHI protected in an AI prior authorization workflow?
AI adds new places where patient data can go. We treat each one as an engineering decision.
Challenge
Who can see what
Agnotic approach
Role-based access for staff, reviewers and the AI service, with minimum necessary data for each step.
Challenge
What happened and why
Agnotic approach
An audit log of every read, AI output, edit and decision, so a reviewer can trace any request.
Challenge
Whether the AI is still right
Agnotic approach
Monitoring of AI accuracy against reviewer decisions, with a process to pause or roll back, following the NIST AI RMF.
What do we build for prior authorization?
The components a payer or provider program usually needs.
FHIR Prior Authorization API
Payer-side CRD, DTR and PAS endpoints built to the Da Vinci implementation guides.
EHR integration
CDS Hooks, SMART on FHIR and EHR APIs so requirement checks and questionnaires appear in the clinician's workflow.
Documentation assistant
AI that finds and summarizes the chart evidence a request needs, for clinician review.
Request tracker
One queue for requests, deadlines, payer responses and requests for more information.
Decision workflow
Payer review queues with timeframe tracking, denial reason capture and audit history.
X12 278 bridge
Translation between FHIR PAS and the X12 278 for payers and clearinghouses that need it.
Payer or provider
Are you building on the payer side or the provider side?
Both sides of a prior authorization need software, and many projects touch both.
Payer IT teams
The Prior Authorization API, rules for CRD and DTR, intake of PAS requests, decision workflow, timeframe tracking and denial reasons.
Provider revenue cycle teams
Requirement checks at ordering, documentation gathering, request submission and status tracking across payers.
Health IT vendors
Adding CRD, DTR and PAS support to an EHR, practice management or utilization management product.
Both sides together
Integration between a payer's API and a provider's EHR, tested end to end.
CMS-0057-F
What does CMS-0057-F require from payers?
The CMS Interoperability and Prior Authorization Final Rule applies to Medicare Advantage organizations, Medicaid and CHIP programs and plans, and QHP issuers on the federally facilitated exchanges. Exact dates vary by payer type, so confirm yours against the rule.
- Decision timeframes from 2026 for Medicare Advantage, Medicaid and CHIP: 72 hours for expedited requests and 7 calendar days for standard requests
- A specific reason for every denied prior authorization, from 2026
- Public reporting of prior authorization metrics, starting in 2026
- A FHIR Prior Authorization API, with compliance dates generally beginning January 1, 2027
- Provider Access and Payer-to-Payer FHIR APIs, and prior authorization data in the Patient Access API, generally from January 1, 2027
Reference architecture
How do the systems connect?
The layout we start from for a payer or provider program, adjusted to your systems.
Provider EHR
- CDS Hooks (CRD)
- SMART on FHIR app (DTR)
- Order and chart data
Prior authorization services
- Requirement rules
- Questionnaires
- PAS request and response
AI services
- Documentation search and summary
- Criteria matching
- Model monitoring
Payer systems
- Utilization management
- Human review queue
- X12 278 bridge
Security and audit
- BAA-covered hosting
- Role-based access
- Audit log of every step
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Compliance and security
What compliance and security requirements apply to prior authorization automation?
Each requirement is an engineering decision. Agnotic claims no certification; we build so your program can meet the rules and pass your reviews.
| Requirement | Who sets it | What it means for the build |
|---|---|---|
| CMS-0057-F | CMS | Decision timeframes, denial reasons, metrics and FHIR APIs, with dates that depend on payer type |
| X12 278 transaction | HHS and CMS (HIPAA Administrative Simplification) | Requests mapped to the HIPAA standard where payers and clearinghouses still use it |
| Da Vinci CRD, DTR and PAS | HL7 International | Payer and provider endpoints built to the published FHIR implementation guides |
| HIPAA Security Rule and Business Associate Agreement (BAA) | HHS | AI and hosting only in BAA-covered environments, with access control, audit logs and encryption |
| Certified EHR APIs | ONC (ASTP) | Provider-side apps use the FHIR APIs that ONC certification requires EHRs to offer |
| AI risk management | NIST AI RMF (voluntary) | Documented review steps, monitoring and a way to pause the AI |
Da Vinci workflow
How do Da Vinci CRD, DTR and PAS fit together?
The HL7 Da Vinci implementation guides split electronic prior authorization into three steps that run between the provider's EHR and the payer.
1.
CRD: Coverage Requirements Discovery
When the clinician orders a service, the EHR asks the payer, through CDS Hooks, whether prior authorization or documentation is required.
At ordering2.
DTR: Documentation Templates and Rules
The payer supplies a questionnaire. Answers are pre-filled from the chart, and the clinician completes what is missing.
Pre-filled from the chart3.
PAS: Prior Authorization Support
The request is submitted as FHIR, mapped to the X12 278 where the payer needs it, and the decision is returned to the EHR.
Submit and trackBuild or buy
Should you build or buy prior authorization automation?
The right answer depends on how much of the workflow is yours to control.
Buy a packaged ePA product
Works when your EHR, payers and services are well covered by the vendor and you can accept its workflow.
Build on standards
Build CRD, DTR and PAS to the Da Vinci guides when you are a payer meeting CMS-0057-F, or need automation across EHRs and payers a product does not cover.
Extend what you have
Add AI documentation support and request tracking to your existing EHR or utilization management system.
How we work
How does a prior authorization engagement with Agnotic work?
Three stages, each with a clear output.
Scoping call
We agree whether you are building for payer, provider or both, which rules and payers are in scope, and what the first release must do.
Fixed-scope first release
One service line or one payer connection working end to end, with weekly demos.
Scale and support
More services, payers and automation, then ongoing releases and support under agreed terms.
Human in the loop
Where does AI help, and where must people decide?
AI is useful for the slow, repetitive parts of prior authorization. Clinical decisions stay with qualified people, and every AI step is logged.
| Step | What AI does | What people do |
|---|---|---|
| Requirement check | Matches the order against payer rules and flags likely requirements | Staff confirm edge cases the rules do not cover |
| Documentation | Finds the notes, results and history the criteria ask for and drafts answers | The clinician reviews and signs the documentation |
| Criteria matching | Compares the record to the payer's criteria and lists what is met or missing | Reviewers check the summary, not just the score |
| Decision | Never approves or denies on its own | A qualified reviewer decides, especially for any denial |
| Follow-up | Tracks status, deadlines and requests for more information | Staff handle appeals and peer-to-peer reviews |
We design the review steps, audit trail and model monitoring with your compliance and clinical leads.
Facts and sources
Which rules and facts shape a prior authorization build?
Short facts we design around, each linked to its primary source.
Under the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), Medicare Advantage, Medicaid and CHIP payers must decide prior authorization requests within 72 hours for expedited requests and 7 calendar days for standard requests, starting in 2026.
Source: Federal Register, February 8, 2024 (CMS-0057-F)CMS-0057-F requires impacted payers to build a FHIR-based Prior Authorization API, along with Provider Access and Payer-to-Payer APIs, with compliance dates generally beginning January 1, 2027.
Source: Federal Register, February 8, 2024 (CMS-0057-F)The HL7 Da Vinci Prior Authorization Support (PAS) implementation guide defines how to submit prior authorization requests and receive decisions using FHIR, with a mapping to the HIPAA X12 278 transaction.
Source: HL7 International (Da Vinci PAS)A HIPAA covered entity may share protected health information with a business associate, such as a software vendor, only under a business associate agreement that commits the vendor to safeguard it.
Source: 45 CFR 164.502(e) and 164.504(e) (eCFR)
Scope and effort
What drives the scope, timeline and cost of prior authorization automation?
We do not quote before we understand these. They are what a scoping call works through.
Payer or provider side
A payer API and review workflow is a different build from provider-side automation; many projects need both.
Services and payers in scope
Each service line and each payer's rules add requirement logic and testing.
EHR and system access
Which EHRs, utilization management and clearinghouse systems must be connected.
How much AI
Documentation search only, or criteria matching too, and the review steps each needs.
Frequently Asked Questions
It requires impacted payers to meet prior authorization decision timeframes, give specific denial reasons and report metrics from 2026, and to build FHIR APIs, including a Prior Authorization API, with compliance dates generally beginning January 1, 2027.
AI can prepare a request and, within rules you set, submit it after a person has reviewed the documentation. It should not approve or deny requests. We design the review steps and audit trail so a qualified person is responsible for every decision.
Both. For payers we build the Prior Authorization API and review workflow; for providers we build requirement checks, documentation gathering and request tracking inside the EHR. Many projects connect the two.
Often, yes. HIPAA names the X12 278 as the standard for prior authorization, and many payers and clearinghouses still use it. The Da Vinci PAS guide maps FHIR requests to the 278, and we build that bridge where it is needed.
Related Solutions
AI in healthcare software developmentSoftware development for health plans and payersAI medical scribe developmentAI denial management softwareInsurance eligibility verification automationLicensed vs internal UM criteriaHIPAA requirements for software teamsUtilization management software development