Blog

A guide to CMS Prior Authorization Regulations for Health Plans and Providers

Health plans face a January 2026 deadline to meet CMS’s new prior authorization mandates. GenHealth outlines a faster, more affordable alternative using FHIR DocumentReference + Binaries and AI—achieving >95% accuracy, 10x lower costs, and real-time turnaround without relying on outdated Da Vinci standards.

Ricky Sahu
Ricky Sahu2025-07-30

Report on meeting CMS 0057-F Requirements: A faster, more effective path to achieve compliance and meet the government’s prior authorization goals with FHIR DocumentReference, Binaries, and AI

Executive Summary (TLDR)

Health plans have 6 months to meet CMS Prior auth regulations. Use FHIR DocumentReference + Binaries and AI to achieve compliance and meet the government’s goals. This path will be faster (4 mins), better (>95% accuracy without any human review), and cheaper (10x less time and cost) than the 0057-F Reg’s “recommended” approach and still meet the “requirements” in the rule. Jump to the Recommended Path to Meet the Prior Auth Regulations to see how we recommend plans achieve compliance by Jan 1, 2026.

Detailing the rationale above, this guide covers the background of prior auth, requirements of the rule, shortcomings in the specification for both plans and providers, and a path to meet the regs while reducing both capital and operational costs 10x using AI to achieve the government’s goals.

Background

On June 23rd 2025, in a live announcement led by HHS Secretary Robert F. Kennedy Jr. and CMS Administrator Dr. Mehmet Oz (https://youtu.be/d99yUzpGh_w), the federal government publicly unveiled a major initiative to streamline prior authorization, building on the 0057-F CMS regulations from the previous administration.  A long-standing source of frustration in U.S. healthcare, prior auth has been seen as a mechanism of gatekeeping needed care from patients. On the flip side, however, prior auth helps limit the ballooning healthcare costs of the United States where individuals get far less years of life expectancy for each dollar spent compared to other nations. This tension has created a massive administrative burden for both providers and health plans which, if fixed, can create $MMM of value (2022 CAQH study).

These efforts to standardize and automate prior authorization are not new. The 0057-F regs were first proposed in December 2022 and finalized on January 17, 2024 with the Trump administration elevating the urgency. Related bipartisan legislation, the "Improving Seniors' Timely Access to Care Act," was introduced in Congress in 2019 and has gained significant support. This Act aims to streamline prior authorization in Medicare Advantage plans by establishing an electronic prior authorization process, requiring plans to report on their use of prior authorization, and ensuring decisions are made by qualified medical personnel. As of 2024, the bill has passed the House but continues to await Senate action before it can be signed into law. Together the regs and legislation are helping address the decades long issues associated with prior authorization.

In Oz and RFK’s speech last week, the effort to update prior authorization are guided by these goals:

  1. Timely Access to Care that ensures patients receive necessary treatments without delays caused by automating prior authorization bureaucracy.
  2. Reduce administrative waste by tens of billions of dollars and free up clinical resources through real-time electronic prior auth workflows and fewer services requiring authorization.
  3. Transparency and accountability including public dashboards to track performance on PA metrics resulting in 80% real-time approvals by 2027.
  4. The use of prior auth in accordance with the long-term vision of achieving value-based care.

Why Prior Authorization is Necessary

Ultimately prior auth serves as a check against runaway care and medical billing. Before we can improve the process, we must understand why we have it to begin with. Prior authorization emerged in the 1960s as health insurance plans sought to control rising healthcare costs and ensure appropriate utilization of services. It serves several important purposes in our healthcare system:

  • Promotes cost-effective care by ensuring expensive treatments are used only when medically necessary
  • Prevents over-utilization of services that may not benefit patients
  • Encourages adherence to evidence-based medicine and clinical guidelines
  • Helps manage limited healthcare resources across populations
  • Protects patients from unnecessary procedures and their associated risks

Over the past decade as medicare advantage plans grew to take a larger share of the elderly market where healthcare expenses are highest, the industry saw a massive growth in prior authorizations with each provider and payer having variable technologies and policies that must work together. Today's prior authorization process has now become largely manual and time-consuming, creating a significant administrative burden. Generally most think the process works like this:

  1. Check the health plan’s portal or PDFs to verify PA requirements.
  2. Log in to separate systems to confirm patient eligibility and plan-specific benefit rules.
  3. Manually interpret payer medical policies to determine what documentation is needed to demonstrate medical necessity.
  4. Collect and organize supporting materials—including clinical notes, test results, and plan-specific forms.
  5. Submit everything manually via fax, email, or a payer portal.
  6. Wait for manual review, often involving intake agents, nurses, or medical directors.
  7. Follow up frequently, with providers averaging 2–3 calls or emails per request to check status or provide missing information.
  8. Wait days or weeks for a determination, which can delay patient care.
  9. If denied, staff must process appeals, which can take anywhere from a few days to several weeks depending on the plan type and the urgency of the case.

Although this above list of steps is largely true, there are far more complexities that are accounted for in the process including state and local rules, eligibility and coverage dates, place of service, which provider is performing and their network and gold carding status, internal administrative rules that direct decisions to different team at plans, and many more nuances.

According to a 2021 AMA survey, physicians and their staff spend an average of 13 hours per week on prior authorization activities—equivalent to nearly two full workdays. This process contributes significantly to provider burnout and patient frustration while driving up administrative costs throughout the healthcare system.

Adding to the complexity, is the variability among services and requirements across health plans. Not all plans require prior authorization for the same services, they have different requirements for a given service, and various means of submitting and checking during the process. Similarly, health plans must interface with numerous provider groups and various amounts and structures of clinical records sent as support to adjudicate a prior authorization request.

Requirement

Although Oz and RFK positioned this move to reform prior authorization as a voluntary process with the backing of numerous health plans, behind it is the very direct specter of the 0057-F regulations from which most of the goals and approach is derived. Therefore it serves as the most direct template for plans to meet the administration’s goals. For providers, the mandate is largely to make use of the new electronic means of submitting prior authorizations.

CMS-0057-F — What the Final Rule Requires for Prior Auth

In January 2024, CMS finalized rule CMS-0057-F as part of its effort to overhaul the nation’s fragmented and burdensome prior authorization (PA) processes. The rule applies to Medicare Advantage (MA) organizations, state Medicaid and CHIP Fee-for-Service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plans (QHPs) on the Federally Facilitated Exchanges (FFEs). Its intent is to improve speed, transparency, and efficiency by requiring modern API-based data exchange and standardized metrics reporting.

Below is a comprehensive summary of CMS-0057-F requirements that payers must meet for prior auth:

  • Turnaround Time Enforcement (Effective January 1, 2026):
    • Urgent requests must be adjudicated within 72 hours.
    • Standard requests must be processed within 7 calendar days.
  • Public Reporting of Prior Authorization Metrics (First due March 31, 2026):
    • Volume of PA requests received.
    • Percentage of approvals, denials, and requests for additional information.
    • Average response times for both urgent and non-urgent requests.
  • FHIR API Implementation by January 1, 2027 for the following:
    • Patient Access API: Must now include prior authorization data (excluding drugs) in addition to claims and encounter data.
    • Prior Authorization API: Must support:
      • A complete list of covered services requiring authorization,
      • Document requirements,
      • Submission, approval, denial, and request-for-more-info statuses,
      • Structured reason for denials.
  • Electronic Prior Authorization Measure for Providers (Starting 2027):
    • MIPS-eligible clinicians, hospitals, and CAHs must attest to making at least one PA request through the Prior Authorization API using certified health IT.

Additional requirements for other aspects of interoperability in 0057-F are not in scope for this guide.

Standards Required (https://img.federalregister.gov/ER08FE24.013/ER08FE24.013_original_size.png)

  • HL7 FHIR R4.0.1 - FHIR (version R4) is a standardized API which defines the structure and transport of medical data. This specification is currently used for patient access APIs between health plans or EHRs and applications that patients share data with. To meet the regulations, data for prior auth can either be populated into individual attributes of the patient’s resource or sent as a document in the FHIR DocumentReference and Binary resources.
  • US Core STU 3.1.1 - This (https://build.fhir.org/ig/HL7/US-Core/Library-uscore-3.1.1-model-definition.html) specifies which resources of the above FHIR R4 data fields could be used to populate relevant information. Again, prior auth data could be populated in various locations or sent as a comprehensive document in the US Core STU3 DocumentReference.
  • SMART on FHIR App Launch Framework - This specification allows 3rd party applications to launch within an EHR (usually as an iFrame), mostly agnostic of the EHR’s underlying technology. It simplifies the context passed between the EHR and the 3rd party application and could serve as a common means of maintaining provider accessibility.

Standards Recommended

  • HL7 Da Vinci Coverage Requirements Discovery (CRD) IG - Enables providers to determine if a prior authorization is required for a specific service/item in real time and builds on top of FHIR resources.
  • HL7 Da Vinci Documentation Templates and Rules (DTR) IG - Automates and supports generation of documentation required for a prior authorization using payer rules and templates which can use Clinical Quality Language (CQL) to execute logic of the payer rules (in theory for instant determination recommendations).
  • HL7 Da Vinci Prior Authorization Support (PAS) IG - This enables submission and response to prior authorization requests through an API using a combination of FHIR and X12 278 transactions.

Together, these requirements form the most aggressive interoperability mandate CMS has ever introduced for prior authorization. Many of the individual components mirror previous Patient Access and Interoperability Rule policies.

However, while the vision is clear, the path to execution is anything but straightforward. In fact the aggregate burden for standing up these PA APIs as specified and recommended from CMS’s own calculations exceeds $600M (or $1.7M per plan) (https://img.federalregister.gov/ER08FE24.017/ER08FE24.017_original_size.png). Although we believe that price is justified by the outcome, the world has changed significantly since these standards and regs were originally written and the costs do not need to be as high anymore. As mentioned by Congressman Greg Murphy during the talk, “One thing that we know today is it’s a different age. Artificial intelligence should help this tremendously and it should take out a lot of the variances.” We agree wholeheartedly, the use of Generative AI affords possibilities we didn't even imagine 3 years ago; let alone a decade ago when many of these solutions to the problem were invented. As we discuss in the the path forward, AI can be used to both dramatically reduce the administrative burden and the cost of implementing solutions to meet the goals of the government.

As structured today, especially with the use of the “recommended” Da Vinci standards, implementing these requirements will require substantial investments not only in API development but also in clinical logic, document parsing, and operations alignment and ultimately will not be able to meet the goals without the use of AI or additional human labor. In the sections that follow, we’ll unpack why Da Vinci standards fall short, why real-time adjudication is not feasible, and why variability in payer and provider readiness poses fundamental roadblocks to CMS’s goals.

Comparison of Approaches to Achieve Automated Prior Authorization

Shortcomings in the current specification

Three years ago, the HL7 Da Vinci specification represented a significant leap forward in standardizing healthcare interoperability for Prior Auth Support. However, as we've gained deeper insights from real-world prior authorization processes at GenHealth, we recognize opportunities to further enhance its effectiveness. While the core tenets of the Da Vinci approach are valuable, incorporating modern technologies like AI will unlock greater automation and administrative burden reduction than currently possible. This refined approach seeks to build upon the standards like FHIR and Da Vinci, addressing current limitations by integrating advanced capabilities of generative AI.

The areas below highlight opportunities where we can enhance the FHIR + Da Vinci approach:

  • As a specification, structured FHIR is variable and incomplete and prior auth adjudication often requires far more detail and nuance than can be codified in rules built on top of discrete data elements.
  • Variability in implementations between EHRs and Plans will compound the problem.
  • Ultimately organizations will fall back to what works today—sending pdfs of full patient histories with text/natural language and using human logic to reason over the text of medical necessity policies.

FHIR Is Incomplete and Variable, Missing the Detail Required to Adjudicate Prior Auths

Structured FHIR data provided a promising foundation, in the real world however, different incentives are driving adoption. As we can see from the prior Patient Access APIs where I led the delivery of nearly 70 health plan customers, the usage of the FHIR APIs today (to my discontent) is minimal. Typically we see less than 2% of the plan’s active membership data used via FHIR. This is for major 2 reasons.

  1. For any medical, billing, prior auth, risk adjustment, etc usage, FHIR implementations are incomplete. This isn’t directly due to the specification lacking, but its due to the level of effort required to map what was originally text into atomic data fields. Oftentimes relevant information does not have codes that are able to maintain the specificity, and attachments that are in the medical record are not transmitted along with the rest of the attributes. As a result, FHIR is not used today for any functional healthcare use case.

    Below are some examples relevant to prior authorization that lack appropriate structure or an ability to quantify natively in FHIR.

    1. Demonstration of functional improvement after physical therapy sessions: Prior auth for certain orthopedic procedures often requires documentation showing that physical therapy was not only attempted but resulted in specific functional outcomes. This qualitative assessment doesn't have standardized codes and typically exists in narrative therapy notes.
    2. Failure of conservative management: Many surgical procedures require documentation showing that conservative treatments have been tried and failed before surgery is approved. This "failure" is often subjective and based on clinical judgment rather than discrete coded values.
    3. Medical necessity for home health services: The determination that a patient requires skilled nursing or therapy at home often depends on narrative descriptions of the home environment, caregiver availability, and patient mobility limitations that don't translate to standardized codes.
    4. Mental health treatment intensity decisions: Determinations about appropriate levels of care (outpatient vs. intensive outpatient vs. partial hospitalization) often depend on detailed behavioral assessments and safety evaluations that exist primarily in clinical notes.
    5. Duration-based requirements: Many prior auth decisions depend on time-based criteria (e.g., "symptoms persisting for at least 6 weeks") which may be mentioned in clinical notes but aren't typically represented as discrete coded data elements in standardized formats.

  2. The FHIR standard allows for a value to be mapped to different locations, which creates significant challenges for consistent interpretation and use of health data. Here are some examples of this variability:

    1. A patient's smoking status could be represented as an Observation resource, as part of a Condition resource, or embedded within a Questionnaire response.
    2. Medication information might appear in a MedicationRequest, MedicationStatement, MedicationDispense, or even as a reference within a Procedure resource.
    3. Allergies could be documented as AllergyIntolerance resources or sometimes found in Condition resources with specific coding.
    4. Laboratory results might be stored as individual Observation resources or grouped under DiagnosticReport resources with different hierarchical structures.
    5. Clinical notes and documentation could be represented as DocumentReference resources, embedded within Composition resources, or referenced through various text or note fields in other resources.

  3. This variability means that when attempting to extract specific information from FHIR resources (such as for prior authorization decisions), systems must account for multiple possible locations of the same clinical data, making standardized processing extremely difficult without additional normalization or intelligent extraction capabilities.

While structured FHIR data provides a strong foundation, prior authorization often requires nuanced clinical context that is challenging to fully codify. AI can bridge this gap by processing unstructured data from existing clinical documents. Complex prior authorization decisions frequently depend on more detailed and qualitative information than discrete data elements alone can capture. AI models are uniquely positioned to reason over comprehensive patient records.

Variability in Implementations

The healthcare adage "once you've seen one implementation of Epic, you've seen just one implementation of Epic" holds true for FHIR as well. Due to the underlying variations in EHRs and payer claims systems, the resulting FHIR APIs often exhibit variability across both provider and payer implementations. Having connected to thousands of provider APIs and dozens of payer implementations, we've observed that despite standardization efforts, values are frequently placed as extensions, in alternative resources, different attributes within a resource, or are sometimes simply missing. While direct, discrete mapping can be challenging, this variability is a reality of healthcare data. The concept of adjudicating life-altering decisions based solely on rules-based systems atop a rigidly applied standard can be disconnected from the inherent complexity of real-world clinical data.

Of the three main components in Da Vinci, CRD is most promising and will likely reduce admin burden. DTR and PAS, however, will increase it and inadvertently shift a higher share of the burden onto providers.

Coverage Requirements Discovery (CRD)

This component effectively helps providers determine if a service requires prior authorization by providing real-time information at the point of care. Its straightforward interface makes consistent execution likely, reducing initial administrative effort. To further enhance CRD, future iterations could explore integrating additional context that can be passed to AI to account for more nuanced considerations like gold carding, facility-specific rules, and state-level requirements, which currently fall outside its clear provisions.

Documentation Templates and Rules (DTR)

This component surfaces the documentation requirements needed for authorization. It utilizes the FHIR Questionnaire and other resources to standardize what information and questions must be answered to appropriately adjudicate a prior auth request. This approach stems from the right intentions to create transparency and consistency in the plans' rules which are often buried in various medical policies, and it offers providers an opportunity to answer the questions themselves. However, this interface is most fundamentally flawed as it presumes structured data can capture all necessary clinical context and that providers will always answer questions accurately given often massive patient records containing 100s of pages. This is rarely true for complex cases requiring clinical judgment which predominate the most expensive services. In addition to providers being requested to answer clinical questions specifically, the variability in medical policies between plans for the same services and questionnaires for different services will create a massive nightmare of navigation, clicking, and medical reviews on the providers’ side—currently work that is conducted at the plan level. Furthermore, the plans will still have an incentive to verify the answers and will still have to go through the full medical record to verify the answers themselves, thereby increasing the overall administrative burden.

In Da Vinici, the ability to execute the “rules” to determine whether or not the questions were correctly answered leverages the Clinical Quality Language (CQL, https://build.fhir.org/ig/HL7/davinci-dtr/). Unfortunately, CQL is an unscalable and incomplete technology that will both add unnecessary complexity and ultimately result in failed implementations lacking usage. CQL is unable to operate some of the most simple queries like whether or not services happened within inclusive date ranges in a consistent way across any two implementations. Furthermore CQL will require all data to be extracted from text to codified values, which we mentioned will not be possible for all logic needed to execute prior auth adjudications. Meanwhile LLMs and AI models can natively reason over language, and LLMs are in production in 1000s of healthcare organizations today. CQL servers will have to be implemented on the client side (in the EHR) as well as on the adjudication side (at the plans) further complicating the implementation burden.

Prior Authorization Support (PAS)

This component handles the actual submission and response. Its current proposal of combining X12 278 transactions alongside FHIR can introduce unnecessary complexity, whereas FHIR DocumentReference with attachments could accomplish the same goal more efficiently.

Real-world FHIR implementations exhibit variability across EHRs and payer systems. An AI-enhanced approach can intelligently interpret data despite these variations, improving consistency without the need for any normalization into individual data elements or questions that still require people to answer and check manually.

Fallbacks to Fax, Email, Phone

Similar to FHIR’s lack of adoption, despite the push for electronic, standardized prior authorization workflows, both health plans and providers consistently fall back to traditional communication methods like fax, email, and phone calls. This happens for several critical reasons:

  • The web forms and portals designed for prior authorizations often lack fields for crucial clinical details and context needed to justify medical necessity
  • Providers frequently need to supplement structured data with narrative explanations that describe a patient's unique circumstances, which don't fit neatly into dropdown menus or checkboxes
  • Medical necessity documentation often involves unstructured elements like clinical notes, imaging reports, and test results that contain the detailed evidence needed for approval
  • When denials occur, the back-and-forth communication to clarify requirements or provide additional information naturally gravitates toward human interaction

These fallback methods persist because they provide the flexibility and nuance that structured data exchanges currently cannot. While faxes, emails, and phone calls are inefficient, they remain the "source of truth" in prior authorization workflows precisely because they can accommodate the full narrative and contextual information needed to make accurate determinations. Any solution that aims to replace these methods must address this fundamental need for rich, detailed clinical communication.

Ultimately, while Da Vinci (the recommended path in the 0057-F regulation) was designed with good intentions to standardize prior authorization, its reliance on structured data exchange in a fundamentally unstructured clinical environment limits its effectiveness. The approach fails to acknowledge how prior authorization decisions are actually made in practice—through holistic clinical judgment applied to comprehensive medical records. Without addressing these fundamental limitations, implementing Da Vinci standards alone will create additional technical overhead without delivering the promised administrative relief. Health plans and providers need a more pragmatic approach using the technology of today and the future, not holding on to standards that were invented over a decade ago and have yet to see a single production environment.

The Da Vinci workgroups are already discussing additional data passed to augment structured FHIR. Instead of forcing data into overly granular structured fields, a robust approach should embrace the reality that full patient histories, often in PDF or natural language formats, are the current "source of truth." AI can then extract and interpret the necessary information from these comprehensive documents, reducing the need for manual data entry and complex mappings. Our proposal and working approach removes any reliance on FHIR or other structured data and leverages existing documents which could be submitted in a standardized manner through FHIR Binaries.

Recommended Path to Meet The Prior Auth Regulations

The requirements to meet the 0057-F prior auth regulations are primarily the response timelines, explanations of non-determinations and denials, and use of FHIR APIs. The response timelines can only be met through automation or additional staffing. The recommended Da Vinci APIs, although initially envisioned to be helpful with response times, due to the nature of variable implementations, will not lead to automating PAs. The Da Vinci group recently acknowledged that the specification has a “risk of non-interoperability” and will ultimately create more burden for suppliers, providers, and plans. As discussed above, FHIR does not contain the full record needed to adjudicate PA. This will necessitate additional data sent via document, FAX, or Phone, and therefore the use of FHIR no longer benefits from its data structure. Rather FHIR’s associated standardized authentication and authorization method with existing infrastructure and connectivity can still be leveraged.

Our recommendation is to leverage the strengths of FHIR but use AI, specifically Large Language Models to operate upon the natural language text contained in the patient record and medical policies.

Strengths to Build Upon

Although there are many shortcomings with current FHIR implementations, positives still exist. Largely these positives are related to consistency in connectivity, authentication, and authorization where FHIR leverages the RESTful APIs and OAuth-2 standards.

In addition to the connectivity, the FHIR DocumentReference and Binary resources which are already implemented by most FHIR servers can be used to send the full relevant medical history in any current format (PDF, CCDA, plain text, image, etc.)

Use of AI

Variable data requires a solution that can process variable data.Given the inherent variability in healthcare data and FHIR implementations discussed above, we need an approach that embraces this reality rather than fighting against it. AI, particularly Large Language Models (LLMs) and multimodal vision-language models, are uniquely positioned to handle this variability for several key reasons:

  • LLMs excel at processing unstructured text and can extract meaning regardless of where information appears in a document, eliminating the need for perfect mapping to FHIR resources
  • Vision-language models can interpret medical images, PDFs, and scanned documents that contain critical information that standardized data fields cannot capture
  • AI can identify clinical relationships and apply medical necessity criteria across different documentation formats without requiring standardized questionnaires
  • These models understand both codified data and natural language, bridging the gap between structured and unstructured information

Instead of creating additional administrative burden by forcing data into specific FHIR resources, we can leverage the existing DocumentReference and Binary resources in FHIR to transmit complete clinical information. For prior authorization requests, payers would receive the full relevant documentation (PDFs of progress notes, imaging reports, therapy histories) through standard FHIR APIs, while using AI to process and interpret this information.

Traditional approaches like CQL (Clinical Quality Language) for quality measures or rigid decision trees for prior authorization create unnecessary complexity when LLMs can handle these tasks more efficiently. Questions requiring nuanced clinical understanding (like "Could the beneficiary not be fit with a prefabricated AFO?" or "Has the patient demonstrated functional improvement after physical therapy?") are better suited for AI analysis of complete records rather than structured queries.

At GenHealth, we've proven this approach works in production - using AI we are processing thousands of prior authorizations daily from suppliers and providers submitting to health plans. This approach achieves over 95% accuracy (with AI review only) and 75% faster processing times when including human review. These results are already meeting the 2026 turnaround requirements mandated by CMS. By embracing AI's ability to handle variability while maintaining the existing interoperability implementations of FHIR without additional mapping, we can achieve both technical compliance and meaningful improvements in prior auth automation.

Our proposed approach is highly consistent with CMS which itself has recognized the value of AI in healthcare administration through its WISER (Workflow Innovation with Seamless Electronic Reporting) model (https://www.cms.gov/files/document/wiser-fact-sheet.pdf). The WISER model leverages AI and natural language processing to reduce administrative burden by automatically extracting and processing information from clinical documentation. This approach aligns perfectly with our recommendation to use AI for prior authorization processing. Like WISER, our approach allows for the analysis of both structured and unstructured data, maintains clinical context, and significantly reduces manual review time. By adopting a similar AI-powered approach for prior authorization, health plans can achieve the regulatory compliance CMS seeks while building towards the future approaches like WISER.

Costs

The costs to implement and operate prior auth automation and APIs could be significant if plans follow the "recommended" Da Vinci specification. CMS estimates $1.7M expenses for the first year to ultimately implement the Prior Auth APIs (https://img.federalregister.gov/ER08FE24.017/ER08FE24.017_original_size.png). These estimates are concurrent with our understanding of the Da Vinci standard APIs. Operational expenses for the APIs are estimated to be 25% of the cap ex, so $425,000 per year. The upfront costs to meet the prior auth timelines are estimated at a negligible $967 per plan (https://img.federalregister.gov/ER08FE24.018/ER08FE24.018_original_size.png). However, the cost for meeting the timelines does mention the ongoing operational expense of faster turn around times which we estimate to be the most significant.

The Future

The Fundamental Challenges with Prior Authorization

Current prior authorization processes suffer from rigid medical policy rules that force patients into predefined boxes of criteria. The clinical guidelines codify “research based medicine” which is often conducted on sometimes a dozen to a few hundred people at select academic medical centers. Although findings are valid for those tight populations, they are then applied to the entire US population where variations in patients were not always accounted for. These inflexible formulas therefore often fail to account for a patient's complete medical history and unique circumstances. Patients who may miss criteria by just 1% face denials, potentially leading to worse health outcomes and, ironically, higher costs through emergency visits or complications.

This approach is fundamentally flawed because:

  • It reduces complex medical decisions to only the scope of the policy without necessarily accounting for the broader patient history
  • It ignores contextual factors that may justify exceptions to standard rules
  • It creates unnecessary administrative burden as providers appeal decisions that common medical sense would override

AI: A Path to Personalized Prior Authorization

Large Medical Models trained using the same Large Language Model architecture of transformers on comprehensive medical data offer a promising alternative. Unlike rigid rule sets, these models can:

  • Process and interpret a patient's complete medical history
  • Predict potential future outcomes with and without the requested service
  • Simulate cost implications across different treatment pathways

In the near term, AI can complement existing policies by identifying cases where strict rule application would result in a denial, but where approval would likely lead to better outcomes and lower total costs. This creates a win-win-win scenario for plans (lower overall costs), providers (appropriate reimbursement), and patients (better care). This would lead to personalized care decisions truly at the individual patient level.

The Future of Prior Authorization

Looking ahead, prior authorization will likely evolve into a predictive, outcome-based process. Instead of checking boxes against static criteria, systems will simulate patient futures under different treatment pathways and recommend the approach most likely to optimize both clinical outcomes and cost-effectiveness (based on type of plan and policy).

This paradigm shift moves prior authorization from a gatekeeping function to a clinical decision support tool that aligns incentives across the healthcare ecosystem while putting patient needs at the center.