---
title: PBM/Payer Development and Integration
slug: electronic-prior-auth/guide/pbmpayer-development-and-integration
docTags: 
createdAt: 2026-06-18T16:13:15.488Z
---

**Medication and Patient Matching**

The PAInitiationRequest might not include the PBM Member ID in all cases. PBM/payers must develop secondary patient-matching criteria to successfully find the patient. Unmatchable patients may go into to a manual queue for the PBM/payer, or the PAInitiationRequest may be responded to with an automated “patient not found” response.

**Work Queue**

There are several instances where prior authorizations might need to be manually worked:

- Medication cannot be matched
- Provider vendor sends an attachment
- Denials and other cases where you are contractually or regulatory obliged to send to a manual queue

**Exceptions and Medicaid Process**

PBM/payers should avoid generic prior authorization forms whenever possible. However, a generic form may be acceptable in some situations, such as for Medicaid Formulary exceptions or quantity and gender limit exceptions.

**Workflow and Internal Process**

PBM/payers should consider sending coded references (e.g. LOINC codes) along with questions in a question set. This will allow the provider vendor to extract information from the patient's record instead of manually answering each question.

**Handling Prior Authorization Priority**

With SCRIPT version 2023011 NCPDP supports a priority flag field called PAPriorityIndicator. Please see the [PAInitiationRequest Elements](docId\:JANGhwPO1ABnYsW9lVJC6) for details.

**Service Date**

As there is no discrete ServiceDate field in the PAInitiationRequest, PBM/payers should treat the PAInitiationRequest message SentTime field as the de facto service date of the message.