<< Click to Display Table of Contents >> Change Requests |
![]() ![]() ![]() |
The Change Request alerts the user that a Change Request has been sent from the Pharmacy. Change Requests may be Matched or Unmatched.
Select Web Client > Application Drawer > Tasks > Electronic Prescriptions
Change Request
Once the Change Request has been accessed, the user will be taken to the prescription change screen. If a pharmacy hasn't received a response from a Refill or Change request, they may send a follow-up request. In this case, the initial request will be removed so that only one request will display in the Electronic Prescriptions folder.
Select Web Client > Application Drawer > Tasks > Electronic Prescriptions > Change Request
Change Request Information
The top half of the screen will list the original prescribed medication information from the XML in the following order:
•Prescribed by: (name) Entered by: (name) On: (date entered)
•Medication Name
•Dispense as written/Generic Subs: Dispense qty/units: (# unit) Refills: (#) Start: (date) Days Supply: (#)
•Sig line:
•Note to Pharmacist:
•Delivery: Status:
•Associated Problems:
The bottom half of the Change Request screen will list the Change Request type and the medication details sent from the Pharmacy. This will show the medication name, Sig line, dispense, refill, Dispense As Written/Generic Sub, and Note from Pharmacy.
•The Change Request type will be shown in BOLD
oG = Generic Substitution
oP = Prior Authorization Required
oT = Therapeutic Interchange/Substitution
oD = Drug Use Evaluation
oS = Script Clarification
oOS = Pharmacy is Out of Stock
oU = Prescriber Authorization
•An Action drop-down will have the following options available for selection based off the Change Request type:
oFor Generic Substitution, Therapeutic Interchange/Substitution, Drug Use Evaluation, Script Clarification or Pharmacy is Out of Stock:
▪Approve: For Generic Substitution: This will take the user to the Medication Edit screen, most of the screen will be locked down, but the user can edit the dispense quantity and unit before Processing the prescription. For Therapeutic Interchange/Substitution, Drug Use Evaluation, Script Clarification or Pharmacy is Out of Stock: This will take the user to the Medication Edit screen, where the user can edit the prescription before Processing.
▪Deny: Selecting the Deny option will require the user to also address a Denial reason before processing.
▪Replace: Selecting the Replace option will take the user to the Medication Search screen, defaulting to the 'All Meds' radio button, with the original medication name in the 'Name:' search field. If needed, the user can search for a different medication name. After selecting a medication from the list, the user will be taken to the Medication Edit screen to review and edit the prescription before Processing.
oFor Prior Authorization Required
▪Approve: Selecting Approve and Process will send the Change Response back to the Pharmacy. When Approve is selected for Prior Authorization, a Note with the response should be sent. (e.g. If a prior authorization number is needed, this should be entered in the Note field.)
▪Deny: Selecting the Deny option will require the user to also address a Denial reason before processing.
oFor Prescriber Authorization
▪Validate: Selecting the Validate option will send a Change Response back to the Pharmacy, validating the requested information such as (but not limited to) the providers DEA number.
▪Deny: Selecting the Deny option will require the user to also address a Denial reason before processing.
NOTE: For Change Responses that get stuck, an option for 'Clear' will display in the dropdown within the alert after 48 hours has passed.
For an Unmatched Change Request, the workflow is slightly different:
Select Web Client > Tasks > EScribe
Escribe
The Unmatched Change Request will need to be addressed. Potential Matches may be listed based on certain demographics. The Search option may also be used to locate the correct patient name. If the matched patient is selected, the Medication List for that patient will display. A match may be selected from the list and then Accept Match may be selected.
Select Web Client > Tasks > EScribe > Pending Change Request - Unmatched
Escribe - Unmatched Change Request
Select Web Client > EScribe > Pending Change Request - Unmatched > Match Patient > Accept Match
Escribe
Change Requests for Controlled Substances
•A prescription Change XML message will not be sent to DrFirst.
•Prescription Change Response messages will include the same validation logic as a new prescription. It must require a sourcePrescriptionId and unique messageID.
•If the Prescription Change request is only for Prior Authorization, the Prescription Change Response message will not need to go to EPCS Gold or need a digital signature.
•Any Denied Prescription Change Response XML messages should go directly to the intermediary and not to DrFirst.
•No more than 5 refills may be given for Controlled Substance classes 3-5.
Quantity Unit of Measure Code within Change Requests
•If a Generic Substitution (G) ChangeRequest, a Therapuetic Interchange/Subsitution (T) ChangeRequest, a Drug Use Evaluation (D) ChangeRequest, Script Clarification (S) ChangeRequest, or Out of Stock (OS) ChangeRequest is received that references a sunset Quantity Unit of Measure code, the prescriber should send either an Replace or Denied ResponseType. This will check the MedicationRequested section of the ChangeRequest and compare the QuantityUnitOfMeasure code to what is current. This will need to be based on the selected medication from the MedicationRequested section.
▪If the code is sunset, display the following message: "The Quantity Unit of Measure code has been sunset by NCPDP. The Quantity of Unit Measure code will need to be updated or the request should be denied.
•If Approve is selected, then when the user is taken to the rx_edit.xml, the current logic of auto-populating the Dispense Unit should still be present. If no match is found, the Dispense Unit should be blank. The Dispense Quantity and Dispense Unit fields will be red to indicate there is required information.
•If Deny is selected, then the normal denial logic should follow. The sunset code may be sent in the ChangeResponse.
•If a Prior Authorization (P) ChangeRequest is received that references a sunset Quantity Unit of Measure code, the prescriber should send an Approved or Denied ResponseType. This will check the MedicationRequested section of the ChangeRequest and compare the QuantityUnitOfMeasure code to what is current.
▪If the code is sunset, display the following message: "The Quantity Unit of Measure code has been sunset by NCPDP. The Quantity of Unit Measure code will need to be updated or the request should be denied.
•If Approve is selected, then when the user is taken to the rx_edit.xml, the current logic of auto-populating the Dispense Unit should still be present. If no match is found, the Dispense Unit should be blank. The Dispense Quantity and Dispense Unit fields will be red to indicate there is required information.
•If Deny is selected, then the normal denial logic should follow. The sunset code may be sent in the ChangeResponse.
•If a Prescriber Authorization (U) Change request is received that references a sunset Quantity Unit of Measure code, the prescriber should send a Validated or Denied Response Type. This will check the MedicationRequested section of the ChangeRequest and compare the QuantityUnitOfMeasure code to what is current. This will need to be based on the selected medication from the MedicationRequested section.
▪If the code is sunset, display the following message: "The Quantity Unit of Measure code has been sunset by NCPDP. The Quantity of Unit Measure code will need to be updated or the request should be denied.
•If Validate is selected, then when the user is taken to the rx.edit.xml, the current logic of auto-populating the Dispense Unit should still be present. If no match is found, the Dispense Unit should be blank. The Dispense Quantity and Dispense Unit fields will be red to indicate there is required information.
•If Deny is selected, then the normal denial logic should follow. The sunset code may be sent in the ChangeResponse.
▪If the MessageRequestSubCode F is part of the request, it will display as a text field to document the provider's NADEAN number. This complies with the latest NCPDP standard. The returned Reason Code in the XML response will display as GM.