(By Bruce Clutcher)

1. If you have a normalized dose on the med review screen, and branch from the screen to the Pharmacy Info screen to key in a new dose, CHPPRX51 runs again to recalculate a new normalized dose. However, if you key in a new dose that cannot be normalized, CHPPRX51 does not clear out the old dose. Your new dose number/unit will not match the old normalized dose. To avoid this dilemma, you should $D=C1316 (normalized dose) when you PF15 (Pharmacy Info) to leave the med review screen. CHPPRX51 will re-normalize the dose (even if you don't change the old dose). If CHPPRX51 cannot normalize the dose, then the normalized dose field will remain blank (and at least it won't be inappropriately valued with the old, incorrect normalized dose).

2. If you depend on normalized dose always being valued (e.g. your MAR only contains the normalized dose and not dose #/unit), try using the following technique to assure the field gets valued either automatically, or by user input when CHPPRX51 cannot calculate a normalized dose. Include the condition, "WHERE ALL OF C1284 IS VAL THEN REQ" behind the normalized dose field on the review screen. This way, if the dose number (C1284) is valued (sometimes it is appropriate not to have a dose - e.g. with an ointment), normalized dose should also be valued. CHPPRX51 should see to that most of the time. For the instances where CHPPRX51 is unable to oblige, the user will be forced to key in a normalized dose.

3. Have you ever encountered the problem (usually during your LIVE week) where the user decides to increase initial supply because they feel they need to send more doses up than the system calculated? If they do this, CHPPO190 will "steal" the extra occurrence from tomorrow's cart. By flipping tomorrow's occurrence to dispense, you will be short a dose on tomorrow's cart. There should be no reason for the user to increase the calculated initial supply. "But I need to cover the last administration because the nurse gave the first dose before I got the order to enter" - well, back time the order to pick up the earlier dose if the extra dose is to cover a past administration. If you are charting online, you should back time anyway to pick up that earlier occurrence to chart against. You could default '%SYSTIME -2' to back up the defaulted Order Start Time by, say, two hours to cover the delay in when the dose may have been written/given and when pharmacy inputs the order. "Well, it wasn't actually an earlier, scheduled dose - the nurse may have given the first dose when the order was written". Then use the Now and Routine priority. To assure the user does not increase initial supply, I recommend you upgrade the warning, W3767 ("INCREASING INITIAL SUPPLY WILL SET OCCURRENCES TO DISPENSE IN THE NEXT CART") to an error to permanently edit against this problem.

4. Have you ever had this related problem: The user lets CHPPO190 run to calculate initial supply (e.g. for a TID order initial supply calculates to '3'), then the user decides to change the frequency (e.g. to QID) or back up the start D/T. When CHPPO190 goes to run again it notices that %RXINSPY is already valued and doesn't bother to recalculate initial supply. However, because the user either picked a new frequency with more occurrences/24 hrs or moved the start D/T back, more occurrences should be set to dispense as initial supply. However, CHPPO190 will only set the number of occurrences to dispense as specified in %RXINSPY. Since %RXINSPY is already valued (with an inappropriately low value), one or more occurrences will not be flipped to dispensed. Your initial supply will be low and your charges will be off. I have tried two techniques to remedy this situation:

o To get the occurrence(s) to flip to dispense, all you have to do is shift the order ahead by one minute, starting with the first verified occurrence. Shifting a verified occurrence in an acknowledged cart window will flip the occurrence to dispense and charge for the dose (med or IV). Remember to shift the order back to the original times.

o The only way to prevent this scenario from ruining your day (again, this usually happens the first week of LIVE!), is to $D=%RXINSPY whenever the user leaves the review screen to change either the frequency or start D/T. Although CHPPO190 appears to correctly recalculate initial supply, based on the new frequency or start D/T, %RXINSPY does not get valued until after you leave the review screen for the final time. I would be interested in knowing if any of you have a better way to solve this problem, or have any other insight into what happens to %RXINSPY when it is deleted.

5. Speaking of initial supply - did you know if you are entering an IV or unit dose med for an OP "like in a bed" (i.e. the OP is not in a bed on the system but the Visit Bed Indicator is valued and therefore the order is being processed like an IP order - see related article below), initial supply will not be calculated. Since the patient is not in a bed on the system, he is therefore not associated with any cart. No cart association - no initial supply calculation. Fortunately these patients usually don't get recurring orders requiring daily cart filling. But if the initial dose or two doesn't get flipped to dispense, you won't get labels or charges either. To resolve this, place a condition behind the initial supply key in field: "WHERE C0822 IS UNVALUED THEN REQ" where C0822 is the bed (thanks, Pat Simone). If there is no bed valued, then force the user to key in initial supply. If initial supply is keying in, the occurrence(s) is flipped to dispensed.

6. When your pharmacist gets a Dup/Interaction, they only have two options on screen, RXGEDI01 - to accept or reject the order. But what if they don't have enough information to make that decision and simply want to skip out. Model does not support that option. To accommodate this, add a !SKIP ORDER probe to screen, RXGEDI01 that DVA's %RESP='RETN' (or whatever) and a conditional stack command behind the screen that evaluates "WHERE ALL OF %RESP IS VAL AND %RESP EQ 'RETN' THEN $GO=ORFUNCTN (thanks, Faith Thompson).

MULTIPLE MISCELLANEOUS CHARGE ENTRY

(by Tom Campbell)

As most of you know, when the Pharmacy Department enters ancillary charges using "Misc. Charge" they can only process one charge at a time. This is because the update program, CHPPO251, will not accept multiple charges. A way around this is to have a series of TCLs that move pound-sign components into the base components and then rerun the program. I have implemented the following at three accounts and it works well:

1. When "Enter Miscellaneous Charge" is probed on $S=RXFFUN03, a department select screen appears allowing the Pharmacists to select the ancillary for charging. (ER, Cath Lab, Anesthesiology, etc.).

2. After selecting the desired ancillary, a select screen appears that contains all the medications used by the ancillary. For ease of selecting, these are arranged in the same order as the department's "Charge Ticket".

3. The Pharmacists may at this point select up to 15 items to charge. The number allowed depends on how many TCLs you want to build! Actually, it is based on the maximum number of medications the Pharmacy has ever seen on one charge ticket. The selections are stored in "S" components.

4. After all selections are made, they press "Enter" and the "Charge Information" screen appears (RXGEMD04) containing the information on the first medication selected.

5. As the user presses "Enter" on this screen, the quantity and date default and the next drug selected appears and so forth until all selected drugs have been processed.

6. Within the pathway, a series of TCLs are stacked after each charge which look for the lowest numeric pound-sign components, and if found, moves them into the base components. The moved pound-sign components and all billing detail components are deleted, screen (RXGEMD04) re-stacked, and the charge programs rerun. This continues until there are no more pound-sign components at which point the function is complete.

If anyone would like copies of the print-definitions of the screens and TCLs, leave me a voicemail message (#12169) and I'll send them out.

Customer Memos

(By Bruce Clutcher)

The latest customer memos (that I found, that is) for Invision Pharmacy, Med/IV Charting and related areas include:

1. #296 (12/31/91) - Med/IV Orders Enhancement - Process By (IV) Rate

2. #301 (1/24/92) - Enhanced MAR/IVAR - introduces the Summary MAR/IVAR reports

3. #345 (??/??/92) - Display Orders Function - options to display an order's end D/T on first level displays, sorts orders by Ord Sts Proc D/T, display active PRN orders, and exclude D/C'd orders from display of active orders

4. #451 (10/16/92) - General Availability - OAS Graphical User Interface Release 21.1

5. #528 (3/5/93) - OAS Screen Building Feature - explains the use of '&' for immediate pen-detectable fields to process key-in data.

6. #529 (3/19/93) - Pharmacy Service Master NDDF Drug Interaction, Allergy, AHFS and Warning Label Code Updates

7. #585 (10/1/93) - Display Orders Enhancements - includes new sort by Order # and Order Stop Date, display by Ordering Party Code (C1209) and new processing to unload specific Med Solution data for multiple orders from the display screen.

8. #590 (8/6/93) - Clinical Observation and Results (COR) and Clinical Documentation (CDOC) Program Enhancement (this program will unload COR data into your AUDA).

OP IN A BED PROCESSING

(By Bruce Clutcher)

Five years ago things were simple. Outpatients were outpatients and inpatients were inpatients. In INVISION (or more accurately, Independence) terms, outpatients were a Pt Sts No greater than or equal to 20 and Inpatients were less than 20. But somewhere along the line things got complicated. Our clients needed to process OPs like IPs, especially for pharmacy orders. Thus OP In A Bed processing was born. Support for this feature gave significant advantages over our competitors, including our own Unity Pharmacy product. There are some rules and features you should be aware of when taking advantage of this feature:

o Processing of IPs has not changed, only patients with a Pt Sts No >= 20 are affected by OP In A Bed processing.

o An OP becomes an OP In A Bed when the Visit Bed Indicator (C0321) is valued (usually to a '1'). There are two ways C0321 gets valued:

- if the OP is placed in a bed on the system, or

- %OMBEDID=1 is in the AUDA when the OP visit gets created.

o Once C0321 is valued, it never becomes unvalued for that visit. What this means practically is, if you place an OP in a bed (which values C0321) and then take him out of the bed (on the system), he will continue to process "like In A Bed", i.e. you will get IP order processing for subsequent Rx orders placed against this visit.

o If an OP visit exists with a Rx order under it, and the Visit Bed Ind is unvalued (therefore the Rx order is a "true" OP retail Rx order), and then the patient is placed in a bed (valuing the Visit Bed Ind) a second visit gets created automatically. This is known as linked visits. This extra visit creation is a safeguard to prevent IP and true OP Rx orders to be placed under the same visit. The first visit contains the existing true OP Rx order. The new visit, created after the patient was placed in a bed, will hold any OP In A Bed (i.e. IP-like) Rx orders, if any are ever entered for this patient.

What I have been recommending at most of my Rx installs is to unconditionally valued %OMBEDID=1 for all OP visit creations. If any Rx orders are placed against this visit, IP processing will occur, whether the patient is in a bed or not. Even though only a small percentage of OP visits may have Rx orders placed against them, the visits that do will automatically be set up to process the order like an IP order. This recommendation assumes the client is not going to do "true" OP Rx processing (i.e. retail-type prescription processing with refills, etc.). For the larger percentage of visits that never see a Rx order, the non Rx orders will process normally, and are therefore otherwise unaffected by the %OMBEDID=1 processing.