Prior authorization submission packets and payer decisions for PA automation AI

What a usable prior authorization record contains

A usable record joins three things: the request as submitted, the evidence attached, and the payer's status history through final determination. Public work on PA automation treats past requests paired with payer decisions as the core ground truth; one patent application describes training a language model on prior responses with the payer decision as the label [1]. Industry analyses of PA triage list the same inputs: eligibility and benefits, claims history, past requests with decisions, appeals and outcomes, and EHR elements [2].

The request side should carry the service codes (CPT, HCPCS, units, modifiers), diagnosis codes, site of service, rendering and ordering provider (NPI replaced with a stable pseudonym), payer, line of business and plan type, requested dates of service, and the payer-specific questionnaire answers. The decision side should carry every status change with a timestamp, the authorization number format (tokenized), approved units and date span, the denial or pend reason as stated, and any peer-to-peer or appeal result. Partial approvals matter: a request for 12 physical therapy visits approved for 6 is a different training signal from a full denial.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "request_id": "pa_7f3c91",
  "submitted_at": "2026-03-04T14:12:00Z",
  "channel": "payer_portal",
  "payer": { "pseudonym": "payer_014", "line_of_business": "commercial", "plan_type": "PPO" },
  "service": { "cpt_hcpcs": ["72148"], "units": 1, "site_of_service": "outpatient_imaging" },
  "diagnoses_icd10cm": ["M54.16", "M51.26"],
  "ordering_provider": { "pseudonym": "prov_221", "specialty": "orthopedic_surgery" },
  "questionnaire": { "conservative_therapy_weeks": 6, "red_flag_symptoms": false },
  "attachments": [
    { "type": "progress_note", "pages": 3, "format": "pdf_text", "deid_method": "expert_determination" },
    { "type": "pt_discharge_summary", "pages": 2, "format": "fax_tiff_ocr" }
  ],
  "criteria_reference": { "criteria_set_id": "payer_014_imaging_v12", "text_included": false },
  "status_history": [
    { "status": "pended_info", "at": "2026-03-05T09:40:00Z", "reason": "missing PT notes" },
    { "status": "info_submitted", "at": "2026-03-05T16:02:00Z" },
    { "status": "approved", "at": "2026-03-07T11:15:00Z", "approved_units": 1 }
  ],
  "peer_to_peer": null,
  "appeal": null
}

Why channel and screen activity belong in an agent dataset

An agent that submits prior authorizations needs the channel the request actually traveled, because portal, fax, X12 278 and FHIR submissions fail in different ways. HL7's Da Vinci Prior Authorization Support (PAS) guide defines FHIR requests and responses designed to map to the X12 278, and it exists in several published versions, so record which version and intermediary handled each request. Much provider-side work still runs through payer portals and fax, which means realistic training data includes portal screen sequences (field order, dropdown values, upload steps, session timeouts) and fax cover sheets with OCR output.

For computer-use agents, ask for action logs aligned to the record: the field filled, the value entered, the validation error returned, and the screen state when the agent or human stopped. Data-services vendors already market tool-use trajectories for agentic PA (EHR queries, payer calls, letter generation), which signals that buyers expect step-level traces rather than final packets alone [3]. See our owner page on training data for computer-use agents for the trace formats that matter.

How CMS-0057-F changes the labels you should expect

As of October 2026, CMS-0057-F requires Medicare Advantage, Medicaid and CHIP payers to issue decisions within 72 hours for expedited and 7 calendar days for standard requests and to give a specific reason for denials (marketplace QHP issuers fall under the rule's API provisions but not these timeframes), with FHIR prior authorization API requirements following later; confirm the details in the rule text. For a dataset, that splits history into eras. Requests decided before the rule's operational dates may carry vague denial text ("not medically necessary") while later ones should carry more specific reasons, so a model trained across both eras learns inconsistent label semantics.

Ask suppliers to tag each record with the payer category (Medicare Advantage, Medicaid, CHIP, marketplace QHP or commercial outside the rule) and the decision date. Then you can evaluate time-to-decision and reason-specificity features only where the rule applies, and treat commercial plans outside its scope separately. Check exact applicability dates against the Federal Register text before building features on them.

Clinical attachments, PHI and criteria text

Clinical attachments carry the densest protected health information in a PA packet, so specify which attachments you need in full text and which can arrive as structured summaries. HIPAA offers two de-identification routes: Safe Harbor removal of 18 identifier types, or Expert Determination by a person with appropriate statistical and scientific expertise [4]. Free-text progress notes, operative reports and imaging reports often hold dates, provider names and rare-condition details that Safe Harbor's date rules strip, which can destroy the timeline your agent needs; Expert Determination may preserve date offsets with documented risk analysis [5]. Our guide to HIPAA Safe Harbor vs Expert Determination for AI training covers the trade-off in depth.

Behavioral health and substance use requests add another layer. The 42 CFR Part 2 final rule had a compliance date of February 16, 2026, and Part 2 records may sit in the same PA queue as other requests [6]. Ask the supplier to flag or exclude Part 2 records explicitly rather than relying on generic PHI filters.

Payer clinical criteria are frequently licensed products. Ask for a criteria set identifier and version on each record, not the criteria text, and confirm your own license to any criteria content you plan to match against.

Buyer request checklist for PA submission data

A precise request names the services, payers, channels and outcome mix you need, and states how attachments and identifiers must be handled. Use the checklist below when you write your specification or answer a supplier's questions.

Illustrative example: invented to show structure; it does not describe an available dataset.

For evaluation splits, hold out by payer and by month rather than at random, because packets for the same patient episode leak across random splits. The outcome-labeled evaluation data guide explains why real decisions make stronger ground truth than annotator labels, and the data provider due diligence questionnaire gives the rights and provenance questions to send.

How this differs from neighboring datasets

Provider-side PA packets are distinct from payer-side utilization management review, pharmacy ePA and phone-based follow-up, and each has different holders and rules. Payer reviewers' rationale and criteria application belong on utilization management review records. Drug requests through NCPDP-based ePA belong on pharmacy prior authorization and formulary exception records. Status calls to payers are covered by provider-to-payer phone calls for revenue-cycle voice agents, and the wider landscape sits in our industry-specific operational data hub.

PA records often live with revenue-cycle vendors or management service organizations acting for providers, so the holder may not be the covered entity that owns the data. Confirm that authority before you license; the client data held by service providers guide lists what to ask. For adjacent revenue-cycle sources, see healthcare revenue cycle datasets and healthcare administration AI training data.

Where SourceX fits

SourceX sources operational datasets from US companies on request, including document and workflow records of the kind described here, and manages licensing and ongoing purchases. Nothing is held in stock: you describe the data, SourceX looks for US businesses that hold it, and every release is approved by the supplying company. Every dataset is rights-reviewed for ownership and consents, health records require HIPAA de-identification by Safe Harbor or Expert Determination, and delivery runs through private, access-controlled workflows after an executed agreement. Teams can describe their prior authorization data needs to SourceX, and the healthcare administration buyer page shows related requests.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Request prior authorization training data

Describe the services, payers, channels and outcome labels your PA agent needs, and SourceX will assess whether US businesses holding that data can license it; a request does not guarantee a match. Pricing and allowed uses are agreed per deal in a license, and personal details are removed or replaced before delivery with the method recorded. Start a buyer request.