RxChange

rxchange overview an rxchangerequest message is originated by the pharmacy to request a change to a new or fillable prescription response types for rxchangerequests are approved, approvedwithchanges, denied, validated, and pending an rxchangerequest may be sent with the following messagerequestcode(s) "g" (generic substitution), may be used to request a prescriber allow the dispensing of a generic medication when substitution is not allowed by prescriber or regulations "p" (prior authorization required), may be used to request a prescriber review the drug requested and obtain a prior authorization from the payer for the existing prescription note the priorauthorization rxchangeresponse, unlike the other responses, is not considered a fillable message, cannot be used for medication changes, and does not have to be digitally signed "t" (therapeutic interchange/substitution), may be used to request a prescriber authorize a therapy change to the original prescription this includes the workflow where a pharmacy requests a 30 to 90 day quantity or a formulary change "d" (due – drug use evaluation), may be used to request a prescriber authorize a change to the patient's current medication therapy, such as a dosing regimen change or an alternative medication that will have fewer, or no, adverse effects than the original prescription "s" (script clarification), may be used to request a prescriber clarify the original prescription including, but not limited to drugdescription, sigtext, dayssupply, etc "os" (out of stock), may be used to request a prescriber authorize a change to the original prescription due to the pharmacy being out of stock of the requested medication “rm” (rems), may be used when the pharmacy needs additional information from the prescriber about the rems requirements (this is currently not supported by surescripts) "u" (prescriber authorization), may be used to request prescriber authorization information, such as confirming their dea number or enrollment with the prescription benefit plan denied and validated are the only acceptable rxchangeresponse types for this workflow use the elements in the validated response type to return the requested information rxchange requirements an rxchangeresponse must be validated or denied when the rxchangerequest has a messagecoderequest of "u" (prescriber authorization) medicationprescribed must be present when an rxchangeresponse is approved, approvedwithchanges, or validated an rxchangeresponse must not be an approvedwithchanges when the rxchangerequest has a messagerequestcode of "p" (prior authorization) in the rxchange prescriber authorization (u) workflow, at least one messagerequestsubcode must be sent rxchange best practices matching a request back to an original message is strongly recommended, but not required to present the rxchangerequest to the prescriber see the message linkage docid\ z6fpm0mwoma78wtdrn5dk section for more details when prohibitrenewalrequest is set to “true” in an rxchangeresponse, rxrenewalrequests should not be sent back to the originating prescriber the medicationrequested segment contains discrete elements to provide the requested changes and the note field should only be used when the additional information cannot be captured discretely rxchangerequests should not be sent for a controlled substance medication other than "p" or "u" however, the prescribing system should be able to process and respond to any rxchangerequest received for a controlled substance the rxchangeresponse types have slightly different meaning than the response types for rxrenewal the response type is determined by the changes being made and the appropriate response types should be used approved response type should be used when a medicationrequested occurrence from the rxchangerequest is returned in medicationprescribed of the rxchangeresponse and no other changes are made the approved response (except the priorauthorization (p) use case) is considered a new fillable prescription and indicates to the pharmacy that the in process prescription should no longer be dispensed and should be cancelled rxchangeresponse optional elements that are not part of the rxchangerequest schema can be added on approvedwithchanges rxchange for priorauthorization (p) pharmacies should assess the priorauthorizationstatus element of the related prescription from the sender to determine if an rxchangerequest for priorauthorization (p) is necessary prescribing vendors utilizing surescripts prior authorization workflows should refer to the supplemental information in alternate rxchange workflows for prior authorization docid\ l3s6vkubx5ercsnnjmpgf the messagerequestcode and messagerequestsubcodes sent on the rxchangerequest should be returned back on the rxchangeresponse for each messagerequestsubcode sent, the corresponding responsereasoncode should also be sent in the validated response rxchange prescriber best practices prescribers should review and respond to all requests within 48 hours when using a pending response, the provider should populate the reason code and expectedpendedresponsedate so the pharmacy knows when to expect an approval or denial to the request if a message is received with a requestexpirationdate, the receiving system should not send a response after that date for use cases g, t, s, and os the pharmacy may provide suggestions in the medicationrequested segment prescribers should review the requested medication(s) and be allowed to modify it as they see fit if a prescriber location does not use a particular rxchange use case, then a specific error message should be returned indicating that workflow is not supported example “the prescriber location does not support the rxchange use case of pa ” rxchange pharmacy best practices at least one occurrence of medicationrequested should be sent, unless the use cases are for priorauthorization (p) or prescriberauthorization (u) when a pending response is received, a pharmacy should not send follow up requests until the day after the expectedpendedresponsedate if the prescriber has not responded within 48 hours the followuprequest workflow should be utilized if request is no longer necessary, then a subsequent message with the retraction/withdrawal indicator included in the header should be used for more information, see the messageindicatorflag element in the message header elements docid\ czdkqc3 xhkcw1b ejddx section if a response will not be accepted by a pharmacy after a specific time limit, then that date should be populated in the requestexpirationdate for rxchange routing retain the original sending spi for the electronically received newrx or affirmative rxrenewalresponse evaluate this spi (e g , has rxchange service level), and send rxchangerequest to this record rxchange requests should only be routed back to the spi that sent the original prescription do not send requests to a prescriber location that does not have the rxchange service level rxchange ltpac best practices ltpac settings and services do not always have prescribers available to approve or deny changes when initiated by a pharmacy in many cases, facilities and pharmacies have contracts that apply to generic and therapeutic substitutions rxfill is used in many cases to communicate when substitutions are made if there is a pharmacy requested change to a prescribed therapy that is beyond trading partner agreement and rxchange is not supported, an alternative method of communication is recommended the prescriber initiated change process is used for prescribers to alter existing therapies and utilizes a newrx > cancelrx > newrx process with appropriate message linking and messagerequestcode field indicators this process is outlined in the cancelrx section appropriate message linking and field population is also outlined in the cancelrx section