Key Takeaways
- Prior authorization has become one of the most expensive and dangerous bottlenecks in American healthcare, with nearly a third of physicians reporting that their requests are often or always denied and three-quarters reporting that denial rates have climbed over the past five years.
- The financial bleed is enormous. Hospitals spent close to $18 billion in 2025 simply overturning denials, and more than half of those denials are reversed on appeal, which means providers are spending billions fighting for revenue they were already owed.
- A purpose-built prior-authorization tracking app, grounded in FHIR APIs and the new CMS interoperability mandate, turns a fragmented, fax-driven process into a transparent pipeline that catches errors before submission and shrinks preventable denials.
The Quiet Administrative Crisis Behind Every Denied Claim
If you operate in healthcare, you already know that prior authorization is the process everyone loves to hate. A clinician decides a patient needs a medication, a procedure, or an imaging study. Before that care can be delivered and paid for, the health plan has to sign off. In theory this is a cost-control mechanism. In practice it has become one of the largest sources of administrative waste, clinician burnout, and revenue loss in the entire system.
The numbers are difficult to look at. In the American Medical Association’s most recent national survey of 1,000 practicing physicians, 32% reported that prior authorization requests are often or always denied, and 74% said denials have increased over the past five years. Physicians now complete an average of 40 prior authorization requests each week, spending roughly 13 hours of physician and staff time on the process, and 40% of practices have hired staff who do nothing but prior authorization all day.
This is not just a paperwork problem. The same survey found that 95% of physicians said prior authorization delays access to necessary care, 79% reported that patients abandon treatment because of authorization friction, and 26% said the process has led to a serious adverse event for a patient in their care, including hospitalization, permanent impairment, or death. When a process designed to manage spending starts producing hospitalizations, the process itself has become the problem.
And the burden is getting heavier, not lighter. A KFF analysis of CMS data found that Medicare Advantage insurers alone received nearly 53 million prior authorization requests in 2024, up from 49.8 million the year before. Insurers fully or partially denied 4.1 million of those requests, about 7.7%, yet only 11.5% of denials were appealed, and of the ones that were, 80.7% were partially or fully overturned.
Two things follow from that pairing. The denial rate on any given request may look modest, but the volume is so large that denials number in the millions, and the overturn rate shows that the large majority of appealed denials should not have been denied in the first place. As volume climbs and more payers route decisions through automated review engines, the gap between what clinicians submit and what gets approved on the first pass keeps widening. For the organizations on the receiving end of those denials, that gap is measured in dollars, staff hours, and patient harm.
This is exactly the kind of expensive, fragmented, high-stakes workflow that well-designed software is built to fix. In this post, we will walk through why prior-authorization denials happen, what the financial and clinical stakes really are, and how to architect an automated prior-authorization tracking app that catches problems before they become denials. We will also cover the regulatory tailwind, the technical standards you need to know, and a practical implementation roadmap for organizations that want to build one.
What a Denial Actually Costs
Before designing a solution, it helps to size the problem in financial terms, because the business case for a prior-authorization tracking app lives or dies on this math.
Start with the per-transaction cost. According to CAQH, which tracks administrative efficiency across organizations representing roughly 63% of insured lives in the United States, a manually processed prior authorization costs providers dramatically more than an electronic one. A manual prior authorization runs providers around $11 per transaction, while an electronic version costs a fraction of that. Multiply that delta across tens of millions of transactions and the waste becomes structural.
CAQH estimates that fully automating administrative transactions across healthcare could save the system more than $20 billion annually, and that electronic adoption of medical prior authorization has only crept up from 31% to 40% in recent years. The majority of the process is still partially manual, which means the majority of the savings is still on the table.
Now layer in the cost of fighting denials after they happen. The American Hospital Association estimates that hospitals spent nearly $18 billion in 2025 just overturning claims denials, and a staggering $43 billion in total trying to collect payments insurers owe for care already delivered. A separate Premier national survey of hospitals and health systems put the total cost of fighting denials at $25.7 billion in 2023, roughly $18 billion of which was likely unnecessary because the claims were eventually paid anyway. In that survey, denial rates held at nearly 15% and approximately 70% of denials were ultimately overturned and paid, but only after multiple costly rounds of review.
Read that again. The large majority of denied claims should have been paid the first time. The appeal process is, in aggregate, an enormous and largely avoidable tax on provider organizations.
The pattern extends beyond prior authorization into claims more broadly. A peer-reviewed Health Affairs study analyzing 270 million Medicare Advantage claims found an initial claim denial rate of roughly 17%, with 57% of those denials ultimately overturned after appeal and resubmission. Even with most denials reversed, the study calculated a 7% net reduction in provider revenue, because a large share of denied claims are never appealed at all.
The denied dollars that do get recovered come only after staff time, delayed cash flow, and a patient whose care was held up for no durable reason. (It is worth being precise here: the 17% figure measures claim denials across the revenue cycle, a broader category than the prior authorization request denials in the KFF data above, which is why the two rates differ.)
There is a human cost embedded in every one of these figures, and it disproportionately lands on the most vulnerable patients. In its analysis of federal marketplace data, KFF found that HealthCare.gov insurers denied roughly one in five in-network claims in 2023, yet consumers appealed fewer than 1% of those denials.
Tellingly, only a small share of those denials were for lack of medical necessity. The most commonly cited reasons were administrative, the kind of preventable, information-handling failures that software is built to catch. When the appeal burden is this lopsided and the denials are this preventable, prevention is not just the cheaper strategy. It is the more equitable one.
For a provider organization, the strategic conclusion writes itself. Every denial you prevent at the point of submission is worth far more than every denial you successfully appeal after the fact. An appeal costs you staff hours, delays your revenue, and frustrates your patient. A clean first-pass submission costs you almost nothing. The entire purpose of a prior-authorization tracking app is to move as many transactions as possible from the expensive column to the cheap one.
Why Denials Happen in the First Place
You cannot prevent denials you do not understand, so it is worth being precise about where they originate. When you analyze the root causes, most preventable denials cluster into a handful of recurring failure modes.
The first and largest is incomplete or inaccurate data. In Experian Health’s 2025 State of Claims survey, providers named the same top three denial causes they have cited for three years running: missing or inaccurate data at 50%, authorization issues at 35%, and incomplete or inaccurate patient registration data at 32%.
Nearly seven in ten providers (68%) also said submitting clean claims has gotten harder than it was a year ago. A misspelled name, a transposed member ID, an expired eligibility date, or a missing referral can sink a claim that was clinically perfect. These are not medical errors. They are information-handling errors, and information-handling is precisely what software is good at.
The second is missing clinical documentation. Many payers require specific evidence, including chart notes, lab values, prior treatment history, or step-therapy records, before they will authorize a service. When that documentation is not attached, or is attached in the wrong format, the request bounces. The clinician knows the patient qualifies. The submission simply failed to prove it.
The third is process opacity. Prior authorization today is largely a black box. A request gets faxed or keyed into a portal, and then it disappears into the payer’s queue. Staff often do not know whether a request is pending, approved, denied, or stuck waiting on additional information until days later, by which point the clinical window may have closed. This lack of real-time visibility means problems are discovered late, when they are most expensive to fix.
The fourth is the growing role of automated payer-side review. Physicians are increasingly concerned that insurers’ use of artificial intelligence is pushing denial rates up. In the AMA survey, six in 10 physicians expressed concern that AI may further increase prior authorization denials, and a Senate report cited by the AMA found that AI-driven review in some settings denied claims at far higher rates than human review.
Whatever your view of payer-side automation, the practical takeaway for providers is the same. When the other side of the transaction is automated and fast, the submitting side needs to be just as automated, just as complete, and just as fast.
Notice that three of these four failure modes are addressable before a request ever leaves the building. Incomplete data, missing documentation, and process opacity are all problems of capture, validation, and visibility. That is the design brief for a prior-authorization tracking app, and it is why the right healthcare app development approach can move the denial rate so significantly.
The Regulatory Tailwind: CMS-0057-F
Anyone building in this space in 2026 is building into a favorable regulatory wind, and understanding it is essential to designing the right product.
In January 2024, CMS finalized the Interoperability and Prior Authorization final rule, known as CMS-0057-F. The rule applies to a broad set of payers, including Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, and Qualified Health Plan issuers on the federally facilitated exchanges. It is the most significant federal action on prior authorization in years, and it reshapes the technical landscape that any tracking app has to operate in.
Two threads of the rule matter most for builders. The first is the API mandate. Impacted payers must implement and maintain a set of HL7 FHIR-based application programming interfaces, and they have until compliance dates generally beginning January 1, 2027 to get them live in production.
These include a Patient Access API expanded to include prior authorization information, a Provider Access API that lets in-network providers retrieve claims, encounters, and prior authorization data, a Payer-to-Payer API, and a dedicated Prior Authorization API. In plain terms, the rule is forcing the payer side of the equation to expose standardized, queryable, digital interfaces where there used to be a fax machine.
The second thread is the operational mandate. Beginning January 1, 2026, impacted payers must meet faster prior authorization decision timeframes, specifically 72 hours for urgent requests and 7 calendar days for standard requests, and every denial must include a specific reason. Payers must also begin publicly reporting prior authorization metrics, with the first set due by March 31, 2026. CMS has projected that moving prior authorization to digital workflows will save roughly $15 billion over ten years.
For an organization building a prior-authorization tracking app, this is a gift. The historical excuse for not automating prior authorization was that there was nothing standardized to automate against. Each payer was a bespoke integration, a unique portal, or a fax line. CMS-0057-F is systematically dismantling that excuse by requiring payers to expose FHIR endpoints on a known timeline.
An app architected to speak FHIR today is an app architected for exactly the world the regulation is creating. Builders who get ahead of the 2027 deadline will have a working, integrated product precisely as the payer endpoints come online.
The Technical Foundation: FHIR and the Da Vinci Burden Reduction Guides
To build a tracking app that does more than store statuses, you need to understand the standards that make automated prior authorization actually work. The relevant body of work is a set of HL7 FHIR implementation guides developed by the Da Vinci Project, an HL7-sponsored initiative focused specifically on reducing clinician and payer burden. These guides are what turn a generic FHIR integration into a true prior authorization engine, and they map cleanly onto the three things a tracking app needs to do.
Coverage Requirements Discovery (CRD) answers the question “is authorization even required, and what will it take?” CRD uses CDS Hooks to deliver decision support to the clinician at the exact moment they are ordering a diagnostic, specifying a treatment, or making a referral.
The payer’s CRD endpoint can tell the provider’s system, in real time, whether prior authorization is required for that specific member and service, and whether there are special documentation requirements. This is the difference between discovering an authorization requirement at the point of ordering versus discovering it after a claim is denied. CRD moves the knowledge to the front of the workflow, where it is cheapest to act on.
Documentation Templates and Rules (DTR) answers “what exactly does the payer need to see?” DTR lets the provider system download smart questionnaires and computable rules, often expressed in Clinical Quality Language, and execute them through a SMART on FHIR app or directly inside the EHR.
The questionnaire pulls relevant data straight from the patient’s record and prompts the clinician only for what is genuinely missing. This is the mechanism that attacks the single largest cause of denials, incomplete or insufficient documentation, by gathering the exact required information before submission rather than guessing and getting bounced.
Prior Authorization Support (PAS) answers “submit it and tell me what happened.” PAS allows the provider system to send a prior authorization request and the payer system to receive it using FHIR, while still satisfying any regulatory requirement to carry the transaction over the legacy X12 278 standard where needed.
Notably, CMS’s National Standards Group has issued an enforcement discretion stating it will not enforce the X12 278 requirement for entities using a FHIR-based Prior Authorization API as described in CMS-0057-F. PAS also defines the operations a tracking app depends on most: checking the status of a submitted request, updating it, and canceling it.
The reason these matter together is that the greatest reduction in manual intervention comes from implementing them in concert. CRD identifies the requirement, DTR gathers the documentation, and PAS submits and tracks. Real-world pilots bear this out.
A collaboration among Humana, athenahealth, and Availity built an end-to-end automated prior authorization process on exactly these three guides and reported concrete results: over a single quarter, real-time coverage discovery flagged roughly 17,585 orders that needed no authorization at all, saving provider staff about 4,396 hours per month, no authorizations were denied for lack of documentation during the evaluation period, about 70% of submitted authorizations were auto-approved, and the average time to a decision was 26 hours against a CMS standard-request target of seven days. Your tracking app does not have to invent the workflow. It has to implement these standards well and wrap them in an interface clinicians will actually use.
Designing the App: Core Features That Drive Down Denials
With the economics, the causes, and the standards established, here is what a prior-authorization tracking app actually needs to do. Each feature below maps directly to one of the failure modes we identified, because every feature in a clinical tool should earn its place by solving a real problem.
Real-Time Status Tracking and a Single Source of Truth
The foundational feature is exactly what the category name implies: a live, accurate, shared view of every prior authorization request and its current state. Every request should carry a status that updates automatically, including draft, submitted, pending, additional information requested, approved, denied, and appealed. Staff should be able to open one dashboard and instantly see what is stuck, what is approaching a deadline, and what needs human attention right now.
This directly attacks process opacity. When a request that is waiting on additional documentation surfaces immediately rather than three days later, the clinical window stays open and the denial never happens. The tracking layer is also where the new CMS decision timeframes become an asset. Because payers now owe a decision within 72 hours for urgent and 7 days for standard requests, your app can display a countdown against each deadline and flag requests where the payer is out of compliance, turning a regulatory requirement into operational leverage.
Pre-Submission Validation
If incomplete and inaccurate intake data causes the majority of denials, then the highest-leverage feature in the entire app is a validation layer that runs before submission. Before a request leaves the building, the app should check it against payer-specific requirements: Is the member ID valid and eligibility active? Is the required clinical documentation attached? Have step-therapy or prior-treatment conditions been satisfied? Does the diagnosis code support the requested service?
This is where CRD and DTR do their work. By pulling the payer’s coverage requirements in real time and driving a smart questionnaire that gathers exactly what is needed, the app converts the submission from a hopeful guess into a verified, complete package. The goal is a hard gate. A request with missing or invalid information should not be submittable until the gaps are filled. Prevention at this gate is worth more than any downstream appeal.
EHR and FHIR Integration
A prior-authorization tracking app that forces clinicians to retype information already in the chart will fail, because duplicate data entry is one of the most reliable ways to kill adoption of any clinical tool. Deep integration is not a nice-to-have. It is the difference between a product clinicians use and one they abandon.
The app should connect to the EHR and to payer endpoints through FHIR APIs, pulling patient demographics, coverage details, diagnoses, and clinical documentation automatically. The clinician verifies rather than enters. This integration is also what positions your app for the CMS-0057-F world, where payer Provider Access and Prior Authorization APIs come online through 2027. An app that already speaks FHIR plugs into those endpoints as they appear, rather than requiring a rebuild.
Denial Analytics and Pattern Recognition
Because more than half of denials are overturned on appeal, the denials your organization receives contain enormous signal about what your payers actually want. A tracking app should capture every denial with its specific reason, now mandated under CMS-0057-F, and surface patterns over time. Which payers deny which services most often? Which documentation gaps recur? Which submitting providers or service lines have the highest denial rates?
This analytical layer turns a record-keeping tool into a continuous improvement engine. If the data shows that a particular payer denies a specific imaging study 40% of the time for missing a specific lab value, you can update your validation rules to require that lab value up front, and that denial category collapses. The app does not just track denials. It teaches the organization how to stop generating them.
Automated Appeal Support
No prevention system is perfect, so the app should also make the appeals you do have to file faster and more successful. When a denial arrives, the app should assemble the relevant documentation, populate the appeal with the specific denial reason and the supporting clinical evidence, and route it for review. Given that the majority of appeals succeed, the constraint on appeals is rarely the merits. It is the staff time required to assemble them. Reducing that time directly increases the share of legitimately owed revenue your organization actually recovers.
Notifications, Roles, and Audit Trails
Finally, the app needs the connective tissue that makes it usable in a real practice. Role-based notifications should alert the right person at the right moment: a clinician when documentation is needed, a billing specialist when a denial arrives, a manager when a deadline is at risk. Role-based access controls keep PHI visible only to those who need it. And a complete audit trail of every action on every request supports both compliance and the analytics layer above.
Security and Compliance Are Not Optional
Everything in a prior-authorization tracking app touches protected health information, which means HIPAA compliance is a foundational design requirement rather than a feature you add at the end. The most damaging mistake in healthcare app development is treating security as a finishing step instead of an architectural constraint that shapes the build from the first line of code.
For any app handling PHI in the United States, HIPAA compliance has to be designed in from the start. That means end-to-end encryption of data in transit and at rest, unique user authentication, automatic logoff, role-based access controls that enforce minimum necessary access, and comprehensive audit logging of who accessed what and when. Because a prior-authorization app exchanges data with both EHRs and external payer systems, the integration points are where security has to be most rigorous, since every connection is a potential exposure surface.
It is also worth designing with the regulatory trajectory in mind. The same interoperability rules creating the FHIR endpoints your app consumes also raise the bar on data governance and patient access. Building with strong encryption, clear consent and opt-out handling, and auditable data flows is not only the compliant choice today.
It is the durable choice as the rules continue to tighten, and it is far cheaper to build in than to retrofit. For organizations weighing the build, this is the right moment to confirm that your development partner treats compliance as architecture, not afterthought, and that your overall healthcare app architecture is engineered for secure, standards-based data exchange.
An Implementation Roadmap
Building this kind of app is a phased effort, and trying to ship everything at once is the surest way to ship nothing usable. Here is a sequence that manages risk while delivering value early.
Phase 1: Discovery and Workflow Mapping (Weeks 1-6)
Before writing code, map the actual prior authorization workflow in the target organization, end to end. Which services require authorization from which payers? Where do requests originate? Who touches each request, and where does it currently stall? Pull historical denial data and categorize it by root cause, because that analysis tells you which validation rules will deliver the most prevention. The deliverable of this phase is a precise picture of where denials come from and where in the workflow software can intercept them.
Phase 2: Core Tracking and Integration (Weeks 7-16)
Build the foundational tracking layer and the EHR and FHIR integration first, because the single source of truth and clean data flow are what everything else depends on. Establish the FHIR connections, implement real-time status tracking, and confirm that patient and coverage data flows into the app automatically without duplicate entry. Get this core loop working and trusted before layering on intelligence. A reliable tracker that clinicians believe is the version of truth is worth more than a feature-rich tool they do not trust.
Phase 3: Validation, Analytics, and Appeal Support (Weeks 17-28)
With the core working, add the features that actively drive down denials. Implement pre-submission validation using CRD and DTR, build the denial analytics layer, and add automated appeal assembly. Each of these should be measured against the denial baseline established in Phase 1, so you can demonstrate concretely that the validation gate is reducing first-pass denials and that the analytics are surfacing actionable patterns.
Phase 4: Pilot, Measure, and Expand (Weeks 29-40)
Deploy with a limited group of users and a focused set of payers and service lines. Track the metrics that matter: first-pass approval rate, denial rate by category, time from order to authorization decision, staff hours per authorization, and appeal success rate. Use the pilot data to refine validation rules and tune the workflow, then expand to additional payers and service lines as the payer FHIR endpoints come online through the CMS-0057-F timeline. This phased rollout lets the product prove its ROI before it scales, which is exactly the evidence a board needs to keep investing.
The Opportunity in Front of Builders
Step back and the strategic picture is unusually clear. The problem is enormous and quantified: tens of millions of prior authorization requests a year, denials numbering in the millions even at modest per-request rates, nearly a third of physicians reporting that their requests are often or always denied, and close to $18 billion spent annually just to overturn denials that should never have happened.
The causes are well understood and largely preventable: incomplete data, missing documentation, and process opacity. The standards exist and are maturing: FHIR, and the Da Vinci CRD, DTR, and PAS guides. And the regulation is actively forcing the payer side to expose the very endpoints a tracking app needs, on a deadline that lands in 2027.
It is rare to find a healthcare workflow where the pain, the solution pattern, the technical standards, and the regulatory tailwind all line up this neatly. Prior authorization is one of those rare cases. An organization that builds a well-architected tracking app, one that catches errors before submission, gives staff a real-time single source of truth, learns from every denial, and speaks FHIR natively, is not just reducing an administrative headache. It is recovering revenue, returning hours to clinicians, and getting patients their care faster.
The hard part is not the concept. It is the execution: clinical workflow integration, rigorous HIPAA-compliant architecture, and standards-based interoperability that actually works against real payer systems. That is the work that separates an app clinicians abandon from one that measurably moves the denial rate. If you are evaluating whether to build a prior-authorization tracking solution and want a partner who understands both the clinical workflow and the technical standards well enough to build something providers will actually use, the team at Dogtown Media can help you get from concept to a working, compliant product.
Frequently Asked Questions
What is a prior-authorization tracking app?
It is software that manages the full lifecycle of prior authorization requests, from determining whether authorization is required, through gathering the necessary documentation and submitting the request, to tracking its status in real time and supporting appeals when denials occur. The goal is to give clinicians and billing staff a single, accurate view of every request and to catch the errors that cause denials before a request is ever submitted.
How does an app actually reduce claim denials?
Most preventable denials come from incomplete or inaccurate data, missing clinical documentation, and lack of visibility into where a request stands. A tracking app attacks all three. It validates each request against payer-specific requirements before submission, pulls required documentation automatically through EHR and FHIR integration, and provides real-time status so problems surface while there is still time to fix them. Since roughly 15% of claims are denied initially and more than half are overturned on appeal, preventing denials up front is far cheaper than fighting them afterward.
What is CMS-0057-F and why does it matter for building one of these apps?
CMS-0057-F is the federal Interoperability and Prior Authorization final rule, finalized in 2024. It requires impacted payers, including Medicare Advantage, Medicaid, CHIP, and certain ACA plans, to implement FHIR-based APIs for prior authorization and data exchange, generally by January 1, 2027, and to meet faster decision timeframes and specific denial-reason requirements starting in 2026. For builders, it matters because it forces payers to expose standardized digital endpoints where fax and bespoke portals used to be, which is exactly what an automated tracking app needs to integrate with.
What are the FHIR Da Vinci guides, in plain terms?
They are a set of HL7 implementation guides that standardize automated prior authorization. Coverage Requirements Discovery (CRD) tells the clinician in real time whether authorization is required and what documentation is needed. Documentation Templates and Rules (DTR) drives a smart questionnaire that gathers exactly the required information from the patient record. Prior Authorization Support (PAS) submits the request and tracks its status. Implemented together, they produce the cleanest, most complete submissions and the biggest reduction in manual work.
Does the app have to be HIPAA compliant?
Yes, without exception. Any app handling protected health information in the United States must be HIPAA compliant, and because a prior-authorization tracking app exchanges PHI with both EHRs and payer systems, compliance has to be architected in from the start. That includes end-to-end encryption, unique user authentication, automatic logoff, role-based access controls, and complete audit logging. Treating security as a foundational design constraint rather than a late-stage feature is essential.
How long does it take to build a prior-authorization tracking app?
It depends on scope, integration complexity, and how many payers and service lines you target initially, but a phased build typically moves through discovery and workflow mapping, core tracking and integration, validation and analytics, and a measured pilot before expanding. A focused first version that delivers real value can often be delivered in a matter of months, with capabilities layered on as payer FHIR endpoints come online through the CMS-0057-F timeline.
Is it better to prevent denials or to appeal them?
Prevention, almost always. An appeal costs staff hours, delays revenue, and prolongs the patient’s wait for care, even though the majority of appeals ultimately succeed. A clean first-pass submission costs almost nothing by comparison. The entire design philosophy of a prior-authorization tracking app is to move as many requests as possible into the clean-submission column and reserve appeals for the genuine edge cases.
Sources
- American Medical Association, 2025 Prior Authorization Physician Survey and related coverage: https://www.ama-assn.org/practice-management/prior-authorization/only-1-3-doctors-trusts-insurers-prior-authorization
- American Medical Association, AMA survey: Prior authorization reform pledge falls short: https://www.ama-assn.org/press-center/ama-press-releases/ama-survey-prior-authorization-reform-pledge-falls-short-physicians
- KFF, Claims Denials and Appeals in ACA Marketplace Plans in 2023: https://www.kff.org/private-insurance/claims-denials-and-appeals-in-aca-marketplace-plans-in-2023/
- KFF analysis via Fierce Healthcare, Nearly 53M prior auth requests submitted in Medicare Advantage in 2024: https://www.fiercehealthcare.com/payers/kff-nearly-53m-prior-auth-requests-submitted-medicare-advantage-2024
- Health Affairs, Medicare Advantage Denies 17 Percent of Initial Claims; Most Denials Are Reversed: https://www.healthaffairs.org/doi/10.1377/hlthaff.2024.01485
- American Hospital Association data via Revecore, Health System Denials and Underpayments in 2026: https://revecore.com/health-system-denials-underpayments-2026/
- Premier, Claims Adjudication Costs Providers $25.7 Billion: https://premierinc.com/newsroom/policy/claims-adjudication-costs-providers-257-billion-18-billion-is-potentially-unnecessary-expense
- Experian Health, 3rd Annual State of Claims Survey (2025) via Fierce Healthcare: https://www.fiercehealthcare.com/providers/experian-study-providers-say-claims-denials-continue-rise
- CAQH Index coverage, AJMC, CAQH Index Finds $20 Billion in Cost Savings Opportunities: https://www.ajmc.com/view/caqh-index-finds-20-billion-in-cost-savings-opportunities
- CMS, Interoperability and Prior Authorization Final Rule CMS-0057-F Fact Sheet: https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-prior-authorization-final-rule-cms-0057-f
- CMS, APIs and Relevant Standards and Implementation Guides: https://www.cms.gov/priorities/burden-reduction/overview/interoperability/implementation-guides-standards/application-programming-interfaces-apis-relevant-standards-implementation-guides-igs
- HL7 Da Vinci Prior Authorization Support (PAS) FHIR IG: https://hl7.org/fhir/us/davinci-pas/STU2.1/
- Availity, End-to-End Prior Authorizations Using FHIR APIs (Humana, athenahealth, Availity): https://www.availity.com/case-studies/end-to-end-prior-authorizations-using-fhir-apis/
