Messages Overview

message descriptions the prior authorization messages are not dependent on a particular workflow there are two possible prior authorization message flows solicited and unsolicited in the solicited model, the provider vendor notifies the pbm/payer that they wish to start the prior authorization process to determine if an authorization is needed for the patient and desired medication in the unsolicited model, the provider vendor presumes that an authorization is needed and submits the information they anticipate the pbm/payer needs provider vendors and pbm/payers are required to support all message types outlined below painitiationrequest in the solicited model, this message is used by the provider vendor to initiate the prior authorization process by notifying the pbm/payer of the patient and the medication for which prior authorization is being requested, along with the provider vendor’s information and other related details provider vendors are encouraged to include any available relevant information when populating the painitiationrequest to receive the timeliest decision possible the more detail provided up front, the less the pbm/payer must come back and ask for later painitiationresponse in the solicited model, the pbm/payer returns a painitiationresponse after receiving the painitiationrequest this message could contain either a set of questions established by the pbm/payer for the prior authorization or a request for information sent in lieu of the question set if no pa is required, the pbm/payer sends a closed painitiationresponse without a question set a painitiationresponse should be returned for each painitiationrequest for prior authorization renewal requests (unsolicited painitiationresponse), the pbm/payer does not receive a painitiationrequest before sending the painitiationresponse the pbm/payer sends the painitiationresponse to electronic prior authorization initiate (epaini) and surescripts performs a provider lookup to identify the receiving surescripts provider identification (spi) the painitiationresponse from the payer should identify all information required to complete the pa determination this allows a determination to be made in one exchange of the parequest and response messages the painitiationresponse is for the medication (name, strength, and dosage form) indicated in the painitiationrequest when responding, the pbm/payer should not alter the values indicated in the painitiationrequest (e g , replying with a generic product equivalent to brand product) with the availability of the prior authorization renewal request (also known as the unsolicited painitiationresponse), this allows pbm/payers to send a question set for an expiring pa case if the ehr is not certified to receive this, surescripts will attempt to deliver the question set to a pa gateway worklist if this option is also not available, surescripts will send a pdf notification of the renewal via clinical direct message or fax parequest the provider vendor presents questions for the provider to answer and/or extracts information from the patient’s electronic medical record, then sends the information to the pbm/payer in the parequest message paresponse the pbm/payer determines whether authorization can be granted and provides the determination to the provider vendor in the paresponse message in some cases, the paresponse message may indicate that the pbm/payer needs additional information in order to make a determination the payer will also indicate whether it supports electronic appeals for this case provider vendors implementing an epa solution should ensure that they have determined how they will support all possible response statuses paappealrequest the paappealrequest message enables the provider vendor to obtain the information required to submit an appeal the paappealrequest message also enables the provider vendor to submit the appeal information for a prior authorization determination the paappealrequest button will only be available when the iseappealsupported flag is set to "1" in the paresponse paappealresponse the paappealresponse message provides information from the pbm/payer to the provider vendor on what is needed for an appeal the paappealresponse message is also used by the pbm/payer to indicate the outcome of an appeal in some cases, the paappealresponse message may indicate that the pbm/payer needs additional information in order to make a determination pacancelrequest the provider vendor sends the pacancelrequest to a pbm/payer to indicate that they are no longer pursuing their most recent request this can be sent any time after the painitiationresponse with the pacaseid is received by the provider vendor the provider vendor should ensure that, if changes are permitted to a prescription with an associated pa, the prescription and pa remain in sync if a prescription changes, the original pa should be cancelled a determination should be made as to whether a new pa is needed based on the new prescription details pacancelrequest messages should only be sent for pa cases that are still considered open and valid at the pbm/payer if a closed painitiationresponse, paresponse, or paappealresponse determination has been returned to the provider vendor, a pacancelrequest should not be sent to the pbm/payer pacancelresponse the pbm/payer sends the pacancelresponse to a provider vendor to indicate whether the parequest was canceled this is only sent if a pacancelrequest is sent by the provider vendor to the pbm/payer acknowledgement messages the terms "free standing" and "asynchronous" are interchangeable status (required) a status message is used to indicate to the sender that the message was accepted for processing this is always a synchronous response status (code 010) indicates that message processing is complete and was successful status (code 000) indicates that the final response is pending and the process is not complete a subsequent acknowledgment message (error or verify) should be expected error (required) this ncpdp script message transmits that an error has occurred, indicating the request was terminated an error can be generated when there is a communication problem or when the message actually had an error (e g a formatting problem) verify (required) this ncpdp script message is returned only as an asynchronous response as a follow up to status (code 000) the verify message confirms that the receiver successfully received and accepted the message the process is complete and a subsequent acknowledgment message should not be expected message type code meaning(s) as sender as receiver status 000 the transmission has been accepted for processing but has not yet reached its final status there should be a final verify (010) or error forthcoming follow with an asynchronous (free standing) verify or error to complete the message flow while an asynchronous verify or error is expected to follow a status 000, if it is not received, no assumption should be made as to whether the original message has been received successfully or not the recommendation is to wait 24 hours before following a manual process or sending a duplicate message status 010 confirms successful delivery and acceptance of a message to its final destination the final acknowledgment message to close the transaction workflow no further acknowledgment message should follow synchronous response indicates that message processing is complete subsequent acknowledgment message should not be expected verify 010 asynchronous message that confirms successful delivery and acceptance of a message to its final destination the final acknowledgment message to close the transaction workflow no further acknowledgment message should follow send only if the original message was responded to with a status 000 subsequent acknowledgment message should not be expected do not respond to a free standing error or verify with a new free standing error or verify error for a full list of ncpdp error codes and their descriptions, see the ncpdp external code list or schema can be generated when there is a communication problem or when an error occurs during the processing of the message closes the transaction workflow subsequent acknowledgment messages should not be expected could be synchronous or asynchronous a synchronous error is sent in response to a message an asynchronous error (also called free standing error) is initiated as a new message after the status (code 000) is sent send to acknowledge that the transaction failed do not send if a transaction workflow has already been closed (status/verify code 010) send as soon as possible after a status (code 000) has been sent customers may create and return unique error descriptions which may further indicate why failure has occurred after receiving an error, do not expect subsequent acknowledgment messages do not respond to a free standing error or verify with a new free standing error or verify detailed electronic prior authorization message scenarios the following diagrams depict various scenarios where verify, error, and status messages are sent in response to a prior authorization message this applies to any of the epa messages for all scenarios surescripts detailed electronic prior authorization message flow scenarios in the following scenarios, if surescripts routes the painitiationrequest to a third party processor, an error returned to the provider vendor will be sent from a different party than where the request was originally addressed for example, a painitiationrequest sent to epaini could result in an error from the pbm/payer scenario 1 surescripts cannot recognize message 1a) a pa message is sent to surescripts 1b) surescripts cannot recognize the message and sends error text back to the provider vendor scenario 2 surescripts recognized message format but errors found 2a) a pa message is sent to surescripts 2b) surescripts recognizes the format as ncpdp but finds errors in the message surescripts returns an error message