Pharmacy prior authorization and formulary exception records for ePA AI

What a pharmacy PA record contains: the SCRIPT ePA transaction chain

A usable record is one ePA case reconstructed across its message pairs, not a single request. The NCPDP SCRIPT ePA set pairs PAInitiationRequest/Response, PARequest/Response, PAAppealRequest/Response and PACancelRequest/Response. In the usual flow, the prescriber submits a PARequest and the PBM returns a PAResponse that approves, denies or asks for more information, and a denial can lead to a PAAppealRequest.

That structure gives you three distinct training signals. The question set returned in PAInitiationResponse varies by drug, plan and criteria version, so it teaches a model what each PBM asks. The answers in PARequest (coded choices, free text, attached chart notes and lab values) are the inputs. The PAResponse status and denial reason are the label.

Ask suppliers which SCRIPT version each record follows and whether the version changed during the collection window, because field names and code lists shift between releases. As of October 2026, confirm the version Part D sponsors must support against current CMS e-prescribing rules rather than relying on older proposals.

Formulary, tiering and step therapy exceptions are separate labels

Exception requests are not interchangeable with ordinary PA, and a dataset that merges them will teach the wrong decision boundary. Under the Part D exceptions rule (42 CFR 423.578) [8], tiering exceptions ask for preferred cost-sharing, while formulary exceptions cover non-formulary drugs or utilization-management requirements such as step therapy and quantity limits. Each turns on medical necessity evidence from the prescriber.

For model work, keep an exception_type field with values such as formulary, tiering, step_therapy, quantity_limit and PA_criteria. Add an indication_status flag (labeled, compendia-supported, off-label) for specialty drugs, since off-label requests are where PBM reviewers disagree most. Record the step therapy history the reviewer saw: prior drugs tried, duration and reason for discontinuation.

Part D timeframes turn determinations into time-labeled events

Part D coverage determinations carry regulatory clocks, so timestamps are labels in their own right. Standard and expedited determinations have different deadlines under 42 CFR 423.568 and 423.572 [9], and payment requests have a longer one; confirm the current values against eCFR as of October 2026 before you encode them. A prescriber's statement that the standard timeframe may seriously jeopardize the enrollee's health is what typically triggers expediting.

Exceptions add a wrinkle: the clock generally starts when the sponsor receives the prescriber's supporting statement, not the initial request [9], and a missed deadline is treated as an adverse determination that is forwarded to the independent review entity (IRE). Ask for received_at, supporting_statement_at, decided_at, notified_at and expedited_requested / expedited_granted as separate fields. Without them, you cannot train a model that flags at-risk cases or audit whether outcomes were auto-forwards rather than clinical decisions.

Linking ePA records to claim rejects, appeals and final outcomes

The most valuable pharmacy PA records are joined to what happened before and after the ePA exchange. Many cases start with an NCPDP Telecommunication claim reject for prior authorization required at the pharmacy counter, covered in our guide to pharmacy claim reject and resolution data. Rejected Part D claims have long been studied as a record type in their own right, for example in long-term care pharmacy data [3]. Downstream, a denial can move to redetermination, IRE reconsideration and further appeal levels. CMS requires plans to track appeal and grievance activity in a standardized form, though its public instructions cover Medicare Advantage (Part C) appeals rather than Part D redeterminations specifically [4].

McKinsey's model for PA triage draws on eligibility and benefits, clinical and pharmacy claims, historical authorization requests and decisions, appeals and outcomes, and EHR elements [1]. The practical point for buyers: a PAResponse denial overturned on appeal is a different label from a denial that stood. If the supplier cannot link the two, use the initial determination as the label and say so in your data card.

Request template for pharmacy PA records

The template below is a field-level scope a PBM, specialty pharmacy or ePA vendor team can hand to a supplier.

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

De-identification and rights checks specific to pharmacy PA

Pharmacy PA records are protected health information, so de-identification is a precondition, not a cleanup step. HIPAA allows Safe Harbor removal of 18 identifiers or an Expert Determination that re-identification risk is very small [5][6]. Free-text answers and attached chart notes are where names, dates and record numbers leak, so test those fields specifically.

Rare drugs create a second risk: an orphan-drug request in a small state can identify a patient even without names, which is why Expert Determination often fits better than Safe Harbor for specialty data. Also confirm whether records touch substance use disorder treatment programs, which carry separate federal rules. On SourceX, health records require HIPAA de-identification under Safe Harbor or Expert Determination, personal details are removed or replaced before delivery with the method recorded and a sample checked, and no method is perfect.

How pharmacy PA differs from medical PA and payer UM data

Pharmacy-benefit PA runs on SCRIPT ePA messages, PBM criteria and Part D exception rules, while medical PA runs on clinical packets, X12 278 transactions and payer utilization management. If your model handles imaging, procedures or inpatient stays, see prior authorization submission packets and payer decisions and utilization management review records. Pharmacy-side buyer interest is real but early: pharmacy executives place prior authorization support among top AI opportunities [2].

For broader context on healthcare administration data, see healthcare administration AI training data, what AI companies build with pharmacy data and the healthcare administration buyer page. The full set of operational categories sits in the industry-specific operational data hub.

Evaluation splits and failure modes for determination models

Split pharmacy PA data by plan, drug and criteria version over time, never randomly by message. Random splits leak the same question set and near-identical answers into train and test, inflating accuracy. Hold out at least one PBM criteria revision and one new specialty drug to test generalization.

Watch these failure modes:

• Label drift: criteria for a drug change mid-year, so old approvals contradict new denials.
• Auto-forward noise: missed-clock adverse determinations look like clinical denials.
• Missing pended outcomes: requests that ended in "more information needed" and were never resubmitted.
• Reviewer disagreement: off-label and step therapy cases where reviewers split; even public benchmarks average at least 3.3% label errors in test sets [7].

Rare outcomes, such as expedited exceptions overturned at IRE, belong in a dedicated slice; see long-tail and edge-case coverage and building a golden evaluation dataset from business records. Agent builders should also review exception handling records.

If you want help finding a US supplier that holds this kind of record, describe the data on the SourceX buyers page; it is sourced on request, not held in stock, and a request does not guarantee a match.

Source pharmacy prior authorization data through SourceX

SourceX sources operational datasets from US companies on request and manages the commercial process from Find and Assess through licensing and ongoing purchases. Every dataset is rights-reviewed and delivered under a license defining records, uses, term and delivery, and every release is approved by the supplying company. Describe the pharmacy PA records you need at https://sourcex.si/buyers.