PBM/Payer Development and Integration
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 ElementsPAInitiationRequest element table 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.