Causality APIs 26: When Prior Authorization Becomes An API

A clinic submits a prior authorization request electronically and expects the process to feel different. The form is no longer faxed. The transaction has an API endpoint. The patient still waits because the necessary chart details, attachment rules, payer readiness, and denial-feedback loop may not be ready for the same electronic path.

Share: Prior authorization can become an API and still delay care if data, attachments, criteria, payer readiness, and resubmission loops are not aligned. #Causality #Healthcare #PriorAuthorization

The Problem Is Not Always One Thing

The danger is assuming that an API is the intervention by itself. An electronic request can move faster, but it can also become a faster way to discover missing data, unclear criteria, or a case that still requires manual review. In a real workflow, the useful question is not whether the request was digital. It is whether the digital path removed the work that used to create delay.

Why The Obvious Explanation Can Mislead

The obvious answer is that electronic prior authorization should fix the delay. It can, but only if the rest of the path is ready. If criteria are unclear, data are missing from the EHR, attachments are still manual, or the payer cannot respond clearly, the API may expose the bottleneck rather than remove it.

The Question For This Example

This example asks whether a care-delay risk is mostly learned from observing a weak electronic workflow, and what changes if the provider workflow, payer readiness, and attachment automation are set to favorable states.

The target outcome is CareDelayFromAuthorization, which means care delay from authorization in this teaching model.

A Small Model Of The Situation

The model treats prior authorization as a path from criteria and data availability to request completeness, review need, response timeliness, resubmission speed, and care delay. It leaves out plan-specific legal requirements, real denial rates, clinical appropriateness, appeals, and patient outcomes.

The graph has 16 nodes:

• PatientUrgency: Patient urgency (low / high)
• CoverageCriteriaClarity: Coverage criteria clarity (clear / unclear)
• EHRDataAvailability: EHR data availability (complete / missing)
• ProviderApiWorkflow: Provider API workflow (automated / manual)
• PayerApiReadiness: Payer API readiness (ready / not ready)
• DrugBenefitChannel: Drug benefit channel (clear / unclear)
• AttachmentAutomation: Attachment automation (automated / manual)
• RequestCompleteness: Request completeness (complete / missing)
• ManualReviewNeed: Manual review need (no / yes)
• ExceptionComplexity: Exception complexity (simple / complex)
• PayerStaffingCapacity: Payer staffing capacity (adequate / low)
• PeerToPeerNeed: Peer-to-peer need (no / yes)
• DenialReasonClarity: Denial reason clarity (clear / unclear)
• ResubmissionSpeed: Resubmission speed (fast / slow)
• DecisionTimeliness: Decision timeliness (timely / late)
• CareDelayFromAuthorization: Care delay from authorization (no / yes)

What Is Sourced And What Is Synthetic

CMS’s final rule and fact sheets support the structure: APIs, documentation requirements, request and response behavior, denial reasons, and operational timelines all belong in the model. The drug authorization proposed rule supports keeping drug-specific authorization distinct from the broader services rule. The probabilities are synthetic.

Prior authorization API requirements

CMS describes a Prior Authorization API that identifies documentation requirements and supports request and response behavior.

Denial reasons and status communication

CMS materials describe response states such as approval, denial with reason, or requests for more information.

Drug authorization boundary

CMS’s 2026 proposed rule materials motivate separating drug prior authorization from other covered item and service workflows.

The Query The Graph Cannot Show By Itself

The visual graph is the best way to inspect the structure. The code-backed query is there for a narrower reason: we want to separate what is learned by observing a messy case from what changes if one condition is set differently.

Using the Darkstar Python SDK, a subscribed SDK user can load the same BBN JSON, ask for the target probability after evidence is entered, then run the action query by setting a node before querying again. The download includes this as illustrative SDK code, while the standalone query_example.py reproduces the article numbers without shipping the SDK.

import json

from darkstar import DiscreteModel

TARGET = "CareDelayFromAuthorization"
OBSERVED_EVIDENCE = {
    "CoverageCriteriaClarity": "unclear",
    "EHRDataAvailability": "missing",
    "ProviderApiWorkflow": "manual",
    "PayerApiReadiness": "not_ready"
}
INTERVENTION_CONTEXT = {
    "CoverageCriteriaClarity": "unclear",
    "EHRDataAvailability": "missing"
}
INTERVENTION = {
    "ProviderApiWorkflow": "automated",
    "PayerApiReadiness": "ready",
    "AttachmentAutomation": "automated"
}


def probability_after_observing(model, evidence):
    query = {"nodes": [TARGET], "evidence": evidence}
    result = json.loads(model.pquery(json.dumps(query)))
    return result[TARGET]["yes"]


def probability_after_setting(model, setting, evidence):
    changed_model = model.intervene(json.dumps(setting))
    return probability_after_observing(changed_model, evidence)


with DiscreteModel(model_json) as model:
    observed = probability_after_observing(model, OBSERVED_EVIDENCE)
    acted = probability_after_setting(model, INTERVENTION, INTERVENTION_CONTEXT)

That is the article’s main modeling distinction. Observing a pattern is not the same as setting one part of the system differently.

The standalone query code gives this synthetic result:

Baseline care delay from authorization: 18.9%
Observed scenario (unclear criteria and immature API workflow): 24.2%
Action scenario (ready payer API and automated attachments): 18.6%
Same context with the action left unfavorable: 24.6%
Synthetic reduction versus the observed scenario: 5.6 percentage points

What We Learn By Observing The Situation

The observed scenario sets:

• Coverage criteria clarity = unclear
• EHR data availability = missing
• Provider API workflow = manual
• Payer API readiness = not ready

The observed scenario combines unclear criteria, missing EHR data, a manual provider workflow, and a payer API that is not ready. In the synthetic model, that combination lifts delay risk because it creates downstream manual review, late decisions, unclear denial reasons, and slow resubmission.

What Changes If We Set One Condition Differently

The action scenario sets:

• Provider API workflow = automated
• Payer API readiness = ready
• Attachment automation = automated

The action query sets the provider workflow, payer readiness, and attachment automation to favorable states. The model still leaves patient urgency and benefit-channel complexity in place. That keeps the result honest: a better API path helps, but it does not make every authorization simple.

What This Example Cannot Prove

This model cannot validate compliance with a final rule, predict a payer’s operational readiness, or estimate a plan’s authorization turnaround. It only illustrates why a digital transaction and a faster care decision are related but not identical.

Try The Model

Open the companion Darkstar model: Open Prior Authorization API Delay BBN

In the shared model, leave the provider workflow automated but set CoverageCriteriaClarity back to unclear. Then compare that with a case where criteria are clear but payer readiness is not ready. The target moves for different reasons.

Download the teaching package: Prior Authorization API Delay BBN ZIP

The package includes synthetic model JSON and reader code. The SDK example is intentionally illustrative and requires separate Darkstar Python SDK access; no SDK package or native runtime is included.

Sources

1. CMS Interoperability and Prior Authorization Final Rule CMS-0057-F
2. CMS Interoperability and Prior Authorization Final Rule Policy Page
3. 2026 CMS Interoperability Standards and Prior Authorization for Drugs Proposed Rule