Prior authorization is a high-volume healthcare workflow where the fax machine still sits on the critical path. A single authorization request arrives as a multi-document bundle — request form, chart notes, labs, imaging reports — flattened into one low-resolution scan. This cookbook walks through turning those packets into structured, auditable data with Reducto's APIs: which endpoints to use, in what order, and how to keep a human reviewer in the loop. For the broader solution and compliance picture, see our companion page on HIPAA-compliant prior authorization document processing.

Why prior authorization still means fax packets

Despite decades of EDI standards, most prior authorization volume never touches a fully electronic rail. According to the 2023 CAQH Index, 37% of medical prior authorization volume was conducted fully manually — by phone, fax, mail, or email — while only 31% was fully electronic via the X12 278 transaction. The 2024 CAQH Index update showed fully electronic adoption rising to 35%, with fully manual falling from 37% to 22% and portal-based submission at 43% — but 65% of volume still isn't fully electronic, which is the operative point.

The practical consequence: payers, utilization management teams, and healthcare AI companies building on top of them all inherit an intake queue where a substantial share of requests still arrives as faxed document bundles. Whoever can get a faxed packet into structured, reviewable data fastest — without sacrificing accuracy on the fields that drive the decision — controls turnaround time for the whole workflow.

The regulatory clock on intake speed

CMS-0057-F, the CMS Interoperability and Prior Authorization Final Rule, puts hard deadlines on how fast impacted payers must decide. To be clear about scope: the rule regulates payers' decision timelines and API obligations — it is not a mandate to buy document AI. But it changes the economics of slow intake:

• Decision timelines. Impacted payers must decide expedited prior authorization requests within 72 hours and standard requests within 7 calendar days. Two scope carve-outs apply: the decision-timeframe requirement excludes QHP issuers on the Federally Facilitated Exchanges, and the rule's prior-authorization provisions do not apply to drugs.

• Specific denial reasons. Denials must include a specific reason, which requires structured, traceable data behind each decision.

• Public metrics. Impacted payers must publicly report prior authorization metrics beginning January 1, 2026 — turnaround performance is now visible.

• FHIR prior authorization APIs. Impacted payers must implement a Prior Authorization API by January 1, 2027, which will move some volume off fax over time — but the fax backlog is the reality of the transition years.

When the decision clock starts at receipt and the packet arrives as a 40-page fax, every hour spent manually keying codes and demographics is an hour taken from clinical review. That is the problem this pipeline solves.

What's in a PA packet

A typical prior authorization fax packet bundles several distinct document types:

• Patient demographics and member ID — usually on the payer's request form, sometimes repeated inconsistently across attachments.

• Diagnosis and procedure codes — ICD-10 diagnosis codes plus CPT/HCPCS codes for the requested service, drug, or device.

• Provider identification — requesting and servicing provider names, NPIs, and contact details.

• Clinical documentation of medical necessity — chart notes, lab results, imaging reports, and prior treatment history supporting the request.

The request form is structured (per payer); the material behind it is largely free-form clinical documentation. An extraction pipeline has to handle both in one pass.

Why fax packets are hard to parse

Three properties make PA faxes among the hardest document inputs:

• Fax-degraded scans. Low DPI, skew, compression artifacts, faded stamps and handwriting, plus cover sheets and transmission confirmation pages interleaved with the content that matters.

• Heterogeneous bundles with no delimiters. A request form, six pages of chart notes, and two lab reports arrive as one continuous scan. Nothing in the file says where one document ends and the next begins.

• Payer-specific request forms. Payers (and often individual plans or states) use their own form layouts, so template-based extraction breaks down as the mix of payers changes.

Generic OCR gives you a wall of noisy text — and the failure is architectural, not incidental. Traditional intake OCR assumes one clean, homogeneous document per file, so a single pass over a PA packet produces one undifferentiated text stream with no document boundaries: request form, chart notes, and labs blur together. Per-payer template libraries don't rescue it — every payer, plan, and state form variant adds another template to build and maintain. The job requires classification and splitting before any extraction, plus OCR that can actually recover degraded fax scans — the failure modes the pipeline below is designed around.

Building the pipeline with Reducto

The pattern is Split → Classify → Parse → Extract, with webhooks to feed your intake queue. No templates required. It's also a production-proven pattern in exactly this domain: Anterior, which builds AI for prior authorization and utilization management, runs its document processing on Reducto — per the case study, accelerating prior authorization with 99%+ extraction accuracy.

1. Split the bundle into documents

Use the Split API to partition the fax into its constituent documents — request form, chart notes, labs, imaging — using natural-language descriptions of each section type. This is where cover sheets and confirmation pages get separated from clinical content so they can be dropped or archived rather than extracted.

For the hardest intakes — long bundles or taxonomies with many section types — Reducto's agentic Deep Split mode (available in the API and Studio at 4 credits/page) handles documents running to thousands of pages and 150+ categories.

2. Classify each section

Classification labels each split with its document type, so downstream extraction can apply the right schema: demographic and code fields from the request form, clinical findings from chart notes, values from lab reports. Classification is also your routing signal — a packet missing clinical documentation entirely can be flagged before it wastes reviewer time.

3. Parse with OCR settings tuned for degraded scans

Parse each document with OCR settings matched to fax input: force OCR-based extraction for scanned pages rather than trusting embedded text, and enable agentic text enhancement for the hardest inputs — Reducto's docs recommend combining the standard OCR system with agentic text mode for maximum accuracy on handwriting, faded text, and poor scans. Parsed output preserves layout and reading order, so tables in lab reports stay tables — the same parsing flow Reducto's healthcare document parsing cookbook demonstrates on messy healthcare inputs like handwritten forms, scanned charts, and lab reports.

4. Extract fields with citations

Run Extract against each classified section with a schema for the fields your workflow needs: member ID, patient demographics, ICD-10 and CPT/HCPCS codes, provider NPIs, service dates, urgency indicators. Enable citations so every extracted value carries a pointer to its exact source location in the original scan — this is the foundation of reviewer validation below.

5. Deliver results by webhook

Wire completion events into your intake queue with Svix-backed webhooks, so packets flow to reviewers or your UM system as soon as processing finishes rather than on a polling loop.

Reviewer-in-the-loop validation

Prior authorization is a clinical and financial decision; extraction should accelerate reviewers, not replace them. Two mechanisms keep the pipeline honest:

• Citation-backed review. Because every extracted field cites its source region in the scan, a reviewer verifies a value by looking at the highlighted snippet — seconds per field instead of re-reading the packet. Low-confidence fields can be routed for mandatory review while clean extractions pass through.

• Code-field validation. ICD-10 and CPT/HCPCS codes have strict formats and finite code sets. Validate extracted codes downstream against format rules and your code tables, and route mismatches back to the review queue automatically.

Compliance and deployment

PA packets are PHI end to end, so the deployment envelope matters as much as extraction quality. Reducto offers a HIPAA-compliant pipeline with a BAA on Growth and Enterprise tiers, Zero Data Retention on Growth and above, and VPC or on-premise deployment for teams that need processing inside their own boundary — with over 4 billion pages processed on the platform. See enterprise readiness for the security and deployment details, and reducto.ai/industries/healthcare for the healthcare-specific picture.

FAQ

Can it read handwritten chart notes?

Reducto is built to handle handwriting in healthcare documents — intake forms, consent documents, and questionnaires with checkboxes and handwritten entries; the patient intake form cookbook demonstrates extracting demographics, insurance, and medication data from exactly those forms — and its OCR documentation recommends agentic text mode for maximum accuracy on handwriting and faded text. As with any handwritten clinical input, pair extraction with citation-backed review for decision-critical fields.

How do cover sheets and confirmation pages get filtered?

The Split step separates them from clinical content using descriptions of each section type, so they never reach extraction. Classification provides a second check that only relevant document types feed your schemas.

Does CMS-0057-F require providers or payers to adopt document AI?

No. The rule sets decision timelines, denial-reason and reporting requirements, and API obligations for impacted payers. It doesn't prescribe how intake gets done — it just makes slow, manual intake measurably costly once decision clocks and public metrics apply.

Do I need a different pipeline per payer form?

No. Extraction is schema-driven rather than template-driven: you define the fields you need once, and the same pipeline handles varying payer form layouts and unstructured clinical attachments. Reducto is one-shot, meaning it can process documents it's never seen before without a template.