--- title: PAIntiationRequests After Real-Time Prescription Benefit (Real-Time Benefits Inquiry) slug: electronic-prior-auth/guide/paintiationrequests-after-real-time-prescription-benefit-real-time-benefits-inquiry docTags: createdAt: 2026-06-15T22:01:57.353Z --- Real-Time Prescription Benefit (RTPB) provides patient-specific medication coverage information directly from the patient’s PBM/payer. The type of information returned from this message (or other integrated real-time benefit check solutions) and the level of detail may vary from one PBM/payer to another and can affect whether or not a PAInitiationRequest should be sent. The need for a PA can vary between the group and patient-specific coverage details. For the most efficient workflow possible, it is recommended that RTPB is both included as part of the implementation and integrated into the prescription writing process. After determining formulary details, if the PBM/payer also supports RTPB, send a request and display the details returned from the RTPB response. If the PA determination varies between formulary and RTPB, send the PAInitiationRequest based upon the RTPB details. If the real time benefit response indicates prior authorization is required for the target medication, provider vendors should send a PAInitiationRequest if the PBM/payer: - Does not provide alternatives in their real-time response (and the prescriber wishes to continue prescribing the target medication) - Provides alternatives, but the provider does not choose one - Provides alternatives, but the provider chooses one that is flagged as needing a PA - Lists coverage limitations within their real-time benefit response Provider vendors should not send a PAInitiationRequest for a requested medication if the PBM/payer: - Indicates that the target medication does not require a PA (and the prescriber wishes to continue prescribing the target medication) - Provides alternatives AND the provider chooses one not flagged as needing a PA - Has available alternatives that do not require a PA and substitutions are indicated to be allowed in the prescription :::hint{type="info"} **Note: **Coverage limitations do not necessarily have a PA flag. Considerations should be made for coverage limitations as well as if a PA flag is present. ::: **Surescripts Electronic Prior Authorization/RTPB Message Flow** ::Image[]{src="https://api.archbee.com/api/optimize/fNEeV2bO-J-V0NK1eH_VR/mOANrnkE0fyevHAt2p8zH_messages-overview9687x489.png" position="flex-start" size="90" initialPath="../../Resources/Images/ElectronicPriorAuth/Messages Overview_9_687x489.png" githubPath="Content/Resources/Images/ElectronicPriorAuth/Messages Overview_9_687x489.png" width="687" height="489" darkWidth="687" darkHeight="489" showCaption="false"} **Step 1:** 1a) Provider vendor sends an eligibility request to Surescripts to determine patient benefit and formulary coverage. The provider initiates a prior authorization based on formulary details. Use the original eligibility details and do not submit a new eligibility request. :::hint{type="info"} **Note: **Please refer to the Eligibility Guide for additional eligibility information and requirements. ::: 1b) Surescripts forwards the eligibility request to any PBM/payer who indicates a match based on details found in the Master Patient Index (MPI). 1c) PBM/payer returns the eligibility response. If the response indicates patient is not eligible, the provider vendor can still send the PAInititationRequest when they are confident that the patient has pharmacy benefit coverage. This may require checking the Surescripts Directory to select the PBM and ensure the PayerID is included in the PAInitiationRequest. If sent to EPAINI, Surescripts will determine routing. 1d) Surescripts combines all eligibility responses into a single batch and returns it to the provider vendor. **Step 2:** Formulary and Benefit information is checked with either WebDAV or On-Demand Formulary. **Step 3:** 3a) During the prescription writing process, the provider vendor sends a RTPB Request to Surescripts to determine real-time patient benefit information for the requested medication at the selected pharmacy. 3b) Surescripts forwards the RTPB Request message on to the PBM/payer. 3c) The PBM/payer sends a RTPB Response which may include the formulary, pricing, and coverage information that is known for multiple channels. The RTPB Response may contain alternative medication information. 3d) Surescripts forwards the RTPB Response message on to the provider vendor. **Step 4:** 4a) Based on the information supplied in the RTPB Response message, the provider vendor determines if it is appropriate to continue with the ePA process. If the requested medication returned indicates needing a PA in the RTPB Response and: - If the PBM/payer returned alternatives but the provider does not choose one, the ePA process continues with a PAInitiationRequest - If the PBM/payer returned alternatives flagged as needing a PA and the provider chooses one, the ePA process continues for the newly selected medication with a PAInitiationRequest - If the PBM/payer did not return alternatives and the provider wishes to continue prescribing the current medication, the ePA process continues with a PAInitiationRequest 4b) Surescripts forwards the PAInitiationRequest message on to the PBM/payer or the health plan/third-party processor. Please see [Electronic Prior Authorization Message Flow](docId\:H5ei5SmPD3JSHeqDbPqIb) for more details on third-party processing. 4c) The PBM/payer or health plan/third-party processor returns the PAInitiationResponse indicating: - Open status (a question set), or - Closed status (see **Closed Reason Code** information in [Message Business Flow Response Summary](docId:3uOZC9EJujVitelt0nr9g)), or - Closed status indicating the initial recipient is not the PA processor (a reason code of CO or CP) 4d) Surescripts forwards the message on to the provider vendor. 4e) If PAInitiationResponse is open, the provider vendor responds with PARequest. 4f) Surescripts forwards the PARequest message on to the PBM/payer or health plan/third-party processor. 4g) The PBM/payer or health plan/third-party processor returns the PAResponse indicating: - Approval (Approved status), or - Denial (Denied status), or - Partial Denial (PartiallyDenied), or - Notice that the request is in process, including the expected resolution date if known (InProcess status), or - A request for more information (Open status), or - That it can’t proceed (Closed status) (e.g., a request was received after the deadline for reply) 4h) Surescripts forwards the message on to the provider vendor. **Step 5:** 5a) The provider vendor can send a PAAppealRequest to Surescripts to: - appeal a prior authorization determination, or - obtain the information required to submit an appeal reconsideration. :::hint{type="info"} **Note: **PAAppealRequest should only be sent when the IsEAppealSupported flag is set to “Y” in the PAResponse. ::: 5b) Surescripts forwards the message on to the PBM/payer. 5c) The PBM/payer returns the PAAppealResponse indicating: - what information is required to submit an appeal reconsideration, or - returns PAAppeal approval, denial, or a request for more information. 5d) Surescripts forwards the message on to the provider vendor.