Electronic Prior Authorization Message Flow

the ncpdp prior authorization messages support the electronic prescribing workflow by leveraging information through other electronic exchanges including the x12 eligibility messages and the ncpdp formulary & benefit standard in an effort to increase the number of electronic prior authorizations available to providers, surescripts will route prior authorizations to third party prior authorization processors when available while the pbm/payer is typically the prior authorization processor, there are scenarios where the health plan processes its own pas or utilizes a third party processor to process prior authorizations on its behalf in these situations, messages may go directly to the health plan/third party processor or may first be sent to the pbm/payer that provides the formulary and benefit information for the patient provider vendors do not have to use the surescripts directory to determine if a pbm/payer is epa enabled however, before submitting an epa request, the prescriber must ensure that this service level is active in their directory entry all painitiationrequests are sent from the provider vendor to epaini surescripts finds the pbm/payer or third party processor using the workflow detailed below while surescripts cannot guarantee that the provider vendor will receive a painitiationresponse with a question set or determination of coverage, sending as many of the fields in the benefits coordination structure as possible will increase the provider vendor's chances that surescripts will find a processor surescripts electronic prior authorization message flow step 1 1a) pbm/payer uploads formulary & benefit file to surescripts 1b) provider vendor retrieves formulary information from pbm/payer data (this is an ongoing process) note this is only applicable for native formulary implementations for on demand formulary (odf), the provider vendor needs to send an eligibility request before sending a formulary request as the eligibility response populates the odf step 2 2a) provider vendor sends an eligibility request to surescripts to determine patient benefit and formulary coverage the provider can initiate a prior authorization at any time based on formulary details if the epa is sent after the transmission of the newrx, use the original eligibility details do not submit a new eligibility request note please refer to the eligibility guide for additional eligibility information and requirements 2b) if a patient match is found, surescripts forwards the eligibility request on to the pbm/payer 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 2c) pbm/payer returns benefit and formulary coverage to surescripts 2d) surescripts returns benefit and formulary coverage to the provider vendor step 3 3a) the provider vendor sends a painitiationrequest to epaini, which is the surescripts identifier for epa surescripts uses the payerid in the benefitscoordination element to determine the pbm/payer and whether or not they are enabled for epa in order to maximize the potential for a positive epa response, the provider vendor should send all available fields referenced in sending prior authorization initiation requests docid\ f scglko2h5cdro le8w0 note this process does not apply for prior authorization renewal requests 3b) if enabled for epa, surescripts forwards the painitiationrequest message on to the pbm/payer if the pbm/payer referenced in the payerid of benefitscoordination is not enabled for epa, surescripts uses the iin (previously bin), pcn, and group id information to check if there is a direct epa connection to the health plan/third party processor and forwards the painitiationrequest directly to the health plan or third party processor 3c) the initial recipient (either the pbm/payer or the health plan/third party processor) returns the painitiationresponse indicating one of the following open status (a question set) closed status (see closed reason code information in message business flow response summary docid 3uozc9ejujvitelt0nr9g ) closed status indicating the initial recipient is not the pa processor (a reason code of co or cp) 3c 1) (applies when the initial recipient indicates that they are not the pa processor) in cases where the initial recipient indicates they are not the pa processor, surescripts forwards the painitiationresponse to the provider vendor and initiates a secondary search to find a different pa processor if surescripts finds a secondary recipient, it routes a secondary painitiationrequest to that processor, who returns a painitiationresponse indicating one of the following open status (a question set) closed status (see closed reason code information in message business flow response summary docid 3uozc9ejujvitelt0nr9g ) closed status indicating that recipient is not the pa processor (a reason code of co or cp) note if a connected health plan/third party processor responds to an initial painitiationrequest indicating they are not the pa processor (a reason code of co or cp) and the pbm/payer does not have an epa service level, surescripts does not perform any additional searches 3c 2) (applies if either a secondary recipient indicates that they are not the pa processor or no secondary recipient is found) if either a response from a secondary recipient indicates that they are not the pa processor or no secondary recipient is found, surescripts sends back a painitiationresponse indicating that epa is not available and the prescriber should use the contact number, if provided, in the panote field from the first painitiationresponse to continue with a manual pa process 3c 3) (applies if the pa processor indicates that epa is not supported or the patient cannot be found) if either the pa processor indicates that epa is not available for the requested health plan or product (a reason code of bx) or patient cannot be found (a reason code of cd), surescripts does one of the following sends back a painitiationresponse indicating that epa is not available and the prescriber should use the contact number, if provided, in the panote field from the first painitiationresponse to continue with a manual pa process sends back a painitiationresponse with a question set based on the ndc using a forms vendor note if the pbm/payer is enabled for epa and the health plan/third party processor responds to the initial request indicating the patient either cannot be found (a reason code of cd) or is not eligible (a reason code of ce), surescripts will route a secondary painitiationrequest to a forms vendor 3c 4) (applies if neither the pbm/payer nor health plan/third party processor are connected to surescripts for epa) if no routable entity exists for a painitiationrequest sent by the provider vendor, surescripts sends back a painitiationresponse indicating that epa is not available and the prescriber should refer to the back of the patient’s prescription benefit card to continue with a manual pa process see the message flow diagram at the bottom of this step for more details notes the provider vendor may receive up to three responses these responses may include a closed status from the pbm/payer, a closed status from the third party processor, and/or a closed status from surescripts the closed status from surescripts (epaini) will contain a by reason code, which indicates that no further painitiationresponse(s) will follow either the pbm/payer or the third party processor may return an open response with a question set if they are the processor if a reason code of co, cp, or bx is returned in the painitiationresponse, the provider vendor is required to display the panote field the panote field may include the communication number the provider should use to continue processing the prior authorization manually if provided in the painitiationresponse, the pacaseid should also be displayed third party processor provider enabled message flow diagram note the following diagram shows the high level process and does not capture all scenarios some scenarios not listed may additionally trigger pa forms provisioning processes 3d) surescripts forwards the message on to the provider vendor step 4 4a) the provider vendor sends a parequest to surescripts containing the answers to the question set 4b) surescripts forwards the message on to the pbm/payer 4c) the pbm/payer returns the paresponse indicating one of the following approval (approved status) denial (denied status) partial denial (partiallydenied status) notice that the request is in process, including the expected resolution date if known (inprocess status) a request for more information (open status) that it cannot proceed (closed status) (for example, a request was received after the deadline for reply) 4d) 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 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 step 6 6a) a pacancelrequest can be sent any time after the pbm/payer returns the painitiationresponse with a case id populated 6b) surescripts forwards the message on to the pbm/payer 6c) the pbm/payer returns the pacancelresponse indicating if it was cancelled a paresponse is not sent after the pacancelresponse is sent 6d) surescripts forwards the message on to the provider vendor note provider vendors should ensure that pacancelrequests are sent to the entity that returned the question set and/or pacaseid if the pacancelrequest is sent to the primary pbm/payer (that indicated they do not process the pa), there is no guarantee that the cancel will be processed