$TXT Created by at CLN2G2.AAC.DOMAIN.EXT (KIDS) on Wednesday, 04/07/21 at 14:13 ============================================================================= Run Date: JUN 03, 2021 Designation: PSO*7*631 Package : PSO - OUTPATIENT PHARMACY Priority: Mandatory Version : 7 SEQ #525 Status: Released Compliance Date: JUL 04, 2021 ============================================================================= Associated patches: (v)PSO*7*282 <<= must be installed BEFORE `PSO*7*631' (v)PSO*7*581 <<= must be installed BEFORE `PSO*7*631' Subject: ERX LOWER CASE MED INSTR/STUCK RXN RECORDS/CRN AND RRN RECORDS NOT EXPIRING Category: - Routine Description: ============ This patch will address the following issues: 1. INC13163644 - Assist with deleting eRx order on inbound eRx queue Duplicates: ----------- INC15788594 - RxRenewal Response was assigned wrong status flag INC15794278 - RxRenewal Response - Processing Error (RXE) message is not INC15788861 - RxRenewal Response - Approved failed to generate renewed order INC15788649 - RxRenewal Response - Replace status get assigned wrong status code 2. INC12814745 - Rx Sig Not Upper-cased when processing inbound eRX 3. INC16106925 - Pharmacy messages not assigned appropriate status by software Defect Tracking System Ticket(s) & Overview: -------------------------------------------- 1. INC13163644 - Assist with deleting eRx order on inbound eRx queue Problem: -------- The Fresno VA Medical Center reported that 'Denied' incoming eRx response records were sitting in their eRx Holding Queue (Complete Orders from eRx [PSO ERX FINISH] option) for months because they do not have any way to remove them. This issue usually happens when the sites manually renews a prescription after placing an eRx refill/renewal request for the eRx prescription. Once the incoming response is received the software is unable to process the renewal because the eRx is already renewed and files the record with an RXN (RXRENEWAL RESPONSE - NEW) status instead of assigning it a more appropriate status such as RXF RXN (RXRENEWAL RESPONSE - FAILED), which is removed from the eRx Holding Queue once the user acknowledges it. Resolution: ----------- The eRx incoming response processing code was changed to automatically assign a status of RXF to an incoming renewal eRx response if the prescription has already been manually renewed. This will allow users to successfully remove such records from their by using the hidden action ACK (Acknowledge). Technical Resolution: --------------------- The line of code below was inserted at REFRESP+24 in the PSOERXA5 routine. .D UPDSTAT^PSOERXU1(ERXIEN,"RXF","eRx already Renewed.") It will ensure that when an Denied incoming eRx response is received for an already renewed prescription the status will be set to RXF instead of RXN. Furthermore, another potential code for leaving records in the RXN was identified in the use of the API $$FIND1^DIC because it did not require an exact match of the related eRx when the incoming eRx response arrived. The third parameter was changed to include "O", which will force an exact match in order to identify the related eRx record. 2. INC12814745 - Rx Sig Not Upper-cased when processing inbound eRX Problem: -------- The Tucson VA Medical Center reported that when using the eRx Holding Queue (Complete Orders from eRx [PSO ERX FINISH] option) the user added a patient instruction (code) with a lower case text to the eRx and the medication instruction expanded as expected however it did not convert to upper case in the Inbound ERX Holding queue. The text was appended to the SIG and remained in lower case through the finishing process in the Patient Prescription Processing [PSO LM BACKDOOR ORDERS] option. Resolution: ----------- It was confirmed that the eRx Holding Queue was not converting the medication instruction text to upper case when it was retrieved from the MEDICATION INSTRUCTION file (#51). This patch addresses this problem by always converting the medication instruction text to upper case. Technical Resolution: --------------------- The line tag LSIG in the routines PSOERXU6 and PSOQUTIL was modified to always convert the medication instruction text to upper case before returning it to the calling routine. 3. INC16106925 - Pharmacy messages not assigned appropriate status by software patch PSO*7*581 Problem: ------- The VA Health Administration Center Denver reported that the CRN (RXCHANGE REQUEST - NEW) status of some old (older than 14 days) RxChange request records without a response were not being assigned the appropriate status CRX (RXCHANGE REQUEST EXPIRED) as described in the user manual. Resolution: ---------- After some research it was determined that the functionality for automatically marking the records mentioned above as expired worked when the user selected RX (PRESCRIPTION RECEIVED DATE) in the prompt below when entering the eRx Holding queue (Complete Orders from eRx [PSO ERX FINISH] option). However, if they select PT (PATIENT(Grouped)) the software did NOT check for records CRN elegible for expiration to mark them as expired. Furthermore, the issue also seem affect RRN (RENEWAL REQUEST - NEW) records which are also supposed to be marked with the RRX (RXRENEWAL REQUEST EXPIRED) status after 14 days without a response. ... Select one of the following: PT PATIENT(Grouped) RX PRESCRIPTION RECEIVED DATE E EXIT Select By: (PT/RX): PT// RX PRESCRIPTION RECEIVED DATE ... Technical Resolution: -------------------- The functionality responsible for the auto expiration of CRN and RRN records in the PSOERX routine lines BLDITEM+11 thru BLDITEM+14 for the RX view were copied over to the PSOERXC1 routine which is used by the PT view. This way no matter which way the user enters the option it will always check and mark eligible CRN and RRN records as expired. Test Sites: ----------- Tuscon VAMC, Tucson AZ HEALTH ADMINISTRATION CENTER STATE: COLORADO (#741) Documentation Retrieval Instructions: ------------------------------------- N/A (No documentation changes) Installation Instructions: -------------------------- This patch may be installed with users on the system although it is recommended that it be installed during non-peak hours to minimize potential disruption to users. Staff should not be processing prescriptions while patch is being installed. This patch should take less than 5 minutes to install. 1. Choose the PackMan message containing this build. Then select the INSTALL/CHECK MESSAGE PackMan option to load the build. 2. From the Kernel Installation and Distribution System Menu, select the Installation Menu. From this menu, A. Select the Verify Checksums in Transport Global option to confirm the integrity of the routines that are in the transport global. When prompted for the INSTALL NAME enter PSO*7.0*631 NOTE: Using will not bring up a Multi-Package build even if it was loaded immediately before this step. It will only bring up the last patch in the build. B. Select the Backup a Transport Global option to create a backup message. You must use this option and specify what to backup; the entire Build or just Routines. The backup message can be used to restore the routines and components of the build to the pre-patch condition. i. At the Installation option menu, select Backup a Transport Global ii. At the Select INSTALL NAME prompt, enter your build PSO*7.0*631 iii. When prompted for the following, enter "R" for Routines or "B" for Build. Select one of the following: B Build R Routines Enter response: Build ****************************NOTE*************************************** For this install choose Build. By doing so, the entire Build (files/fields, options, protocols, templates, routines, etc.) will be backed up and a new build message is created (PSO*7.0*631b). iv. When prompted "Do you wish to secure your build? NO//", press and take the default response of "NO". v. When prompted with, "Send mail to: Last name, First Name", press to take default recipient. Add any additional recipients. vi. When prompted with "Select basket to send to: IN//", press and take the default IN mailbox or select a different mailbox. C. You may also elect to use the following options: i. Print Transport Global - This option will allow you to view the components of the KIDS build. ii. Compare Transport Global to Current System - This option will allow you to view all changes that will be made when this patch is installed. It compares all of the components of this patch, such as routines, DDs, templates, etc. D. Select the Install Package(s) option and choose the patch to install. i. If prompted 'Want KIDS to Rebuild Menu Trees Upon Completion of Install? NO//', answer NO ii. When prompted 'Want KIDS to INHIBIT LOGONs during the install? NO//', answer NO iii. When prompted 'Want to DISABLE Scheduled Options, Menu Options, and Protocols? NO//', answer NO Post Installation Instructions: ------------------------------- None. Installation Verification: -------------------------- Successful installation can be verified by reviewing the first 2 lines of the routines contained in the patch. The second line will contain the patch number (631) in the [PATCH LIST] section. ;;7.0;OUTPATIENT PHARMACY;**[Patch List]**;DEC 1997 The option Calculate and Show Checksum Values [XTSUMBLD-CHECK] can be run to compare the routine checksums to what is documented in the patch description. Back-out/Rollback Strategy: --------------------------- Back-out will be done only with the concurrence and participation of development team and appropriate VA site/region personnel. The decision to back-out or rollback software will be a joint decision between development team, VA site/region personnel and other appropriate VA personnel. Prior to installing an updated KIDS package, the site/region should have saved a backup of the Build in a mail message using the Backup a Transport Global [XPD BACKUP] menu option (this is done at time of install). The message containing the backed-up Build can be loaded with the "Xtract PackMan" function at the Message Action prompt. From the Kernel Installation and Distribution System Menu, select the Installation Menu. Select the Install Package(s) option and choose the backup build PSO*7.0*631. Validation of Back-out Procedure --------------------------------- The Back-out Procedure can be verified by printing the first 2 lines of the PSO Routines contained in this patch using the option First Line Routine Print [XU FIRST LINE PRINT]. Once the routines contained in the PSO*7.0*631 patch have been rolled back, the first two lines of the Routines will no longer contain the designation of patch PSO*7.0*631 in the patch list section on line 2. Routine Information: ==================== The second line of each of these routines now looks like: ;;7.0;OUTPATIENT PHARMACY;**[Patch List]**;DEC 1997;Build 5 The checksums below are new checksums, and can be checked with CHECK1^XTSUMBLD. Routine Name: PSOERXA5 Before: B67783943 After: B71429258 **508,581,631** Routine Name: PSOERXC1 Before:B106435535 After:B109912416 **508,551,567,581,631** Routine Name: PSOERXU2 Before: B61412991 After: B61501050 **508,598,581,631** Routine Name: PSOERXU6 Before:B120358979 After:B120600986 **508,551,581,631** Routine Name: PSOQUTIL Before: B2614810 After: B2669755 **294,282,631** Routine list of preceding patches: 282, 581 ============================================================================= User Information: Entered By : Date Entered : DEC 18, 2020 Completed By: Date Completed: JUN 03, 2021 Released By : Date Released : JUN 03, 2021 ============================================================================= Packman Mail Message: ===================== $END TXT