RXPert Contents

3Q93 Pages 1 & 2

August 1993 7th Edition
Written by Bruce Clutcher and Faith Thompson
Edited by Bruce Clutcher Published by Faith Thompson

INTERIM SOLUTION FOR SUPPORTING FRACTIONAL (DECIMAL) IV RATES (by Bruce Clutcher)

Background of Issue:

INVISION Pharmacy's IV Rate field (C1165) is defined as 3 characters integer. Because of this design, and until a data file change can be instituted, model will not support a decimal rate (e.g. 2.5 ml/hr). However, some clients require this support, especially for a pediatric IV (e.g. TPN solutions).

Ultimate Solution:

INVISION Pharmacy Product Planning has researched the issue and proposes to change the rate field from three characters integer ('999') to four/two characters decimal ('9999.99'). This will not only address the issue of decimal rates but also a related issue of supporting rates greater than 999 ml/hr (common in some adult oncology IV orders). This data file change and the corresponding programming adaptations to support the new field constitute a project reserved for major release boundaries. The next release has not been defined in any immediate development projects.

Interim Solution:

At least one client has successfully used an OAS adaptation to support decimal rates. The pediatric TPN example below coincided with a hospital policy to replace the IV bottle every 24 hours with a new bottle, even if the old bottle contained fluid to infuse. Whether this interim solution will meet your institution's needs should be evaluated in light of your current situation. Below is a brief description of the solution. Note there are several scenarios depending if you are processing a TPN/ALT TPN/ALT LVP (which cannot be processed as intermittent Ivs) or non TPN/ ALT TPN/ALT LVP:

1. TPN/ALT TPN/ALT LVP type Ivs:

• Provide instructions on the IV Rate/Run-In screen to allow user to key the ordered/ clinical decimal rate into an Additional Direction (text) field (e.g. C1286).
• Let the user pick (or otherwise default) a 24 hour Run-In time (see user-specific pediatric TPN caveat described above).
• After CHPPRX53 (Bottle AUDA Validate Program) runs and calculates a (mathematically correct but clinically incorrect) rate based on the IV volume and 24 hour run-in (e.g. 240 ml with a 24 hour run-in will calculate out a rate of 10 ml/hr), and places this rate in C1163 (IV Rate), clear out the calculated rate ($D=C1163). C1163 must be cleared out every time CHPPRX53 runs for this type of order.
• One occurrence will be built every 24 hours. The order will contain the correct volume (e.g. 240 ml) and the clinically correct decimal rate (stored in Additional Directions). C1163 will not contain a confusing (and clinically incorrect) rate. The IV label, MAR, worklists, display orders, etc. will all reflect the correct information.

2. Non TPN/ALT TPN/ALT LVP Continuous type IVs:

• Provide instructions on the IV Rate/Run-In screen to allow the user to key the ordered/clinical decimal rate into an Additional Direction (text) field (e.g. C1286).
• Switch the continuous IV to an intermittent IV (C1396=6, %RXMSG4='INTER-MITTENT IV') and default a Q24HR frequency (C1215=Q24HRS, C1219=DAILY) (see user-specific 24 hour hang time caveat described above).
• Follow the instructions below in scenario #3.

3. Non TPN/ALT TPN/ALT LVP Intermittent type IVs:

• Provide instructions on the IV Rate/Run-In screen to allow user to key the ordered/
• clinical decimal rate into an Additional Direction (text) field (e.g. C1286).
• Let the user pick (or default) a Q24HRS Daily Frequency (see user-specific 24 hour hang time policy caveat described above) or any desired frequency that would apply.
• Leave C1163 (IV Rate) and Run-In (C1165 & C1166) blank.
• One occurrence will be built every 24 hours (or at whatever frequency was chosen). The order will contain the correct volume (e.g. 240 ml) and the clinically correct decimal rate (stored in Additional Directions). C1163 will not contain a confusing (and clinically incorrect) rate. The IV label, MAR, worklists, display orders, etc. will all reflect the correct information.

IV BOTTLE AUDA DATA FIELDS

(by Faith Thompson)

When entering an order for an IV method type of TPN, Alternating TPN or Alternating LVP, the system uses more than one AUDA to hold all of the data for the order.

Currently, the programs which unload data from the Active Database into the Bottle Auda(s) DO NOT unload all Case and Visit data for the patient, but rather a subset of the data (see the attached list of data fields). Since the Bottle AUDA contents are used for printing IV labels, only the data subset which is unloaded into the Bottle AUDA is available for printing.

For example, Patient Birthdate (C0813), is NOT in the Bottle AUDA data list. Therefore, if the client wants to see the birthdate printed on TPN, ALT TPN, or ALT LVP labels, they would have to utilize one of the Bottle AUDA data fields to store birthdate. This would be accomplished by changing the admission/registration flow to DVA the birthdate (C0813) into a Bottle AUDA user-date field (C0744, C0745 or C0746).

Development is planning to change the programming logic so that all Case and Visit data components are available in the Bottle AUDA. This change is anticipated for 4Q93.

PREVENTING THE LOSS OF YOUR MED/IV CARTS

(by Bruce Clutcher)

All INVISION Rx Install Personnel need to be aware of a situation where you may lose all your assigned carts from the Room Segment during your pre-live building phase. As you know, when establishing Med/IV carts on INVISION, you must first create your carts by going into 'ADD A CART' in the 'MAINTAIN CART' functions. Doing this creates Cart Segments. The next step is to use the 'SPECIFY CART ID FOR ROOM' function to assign the appropriate cart ID to each hospital room. Doing this populates the five cart related fields in the Room Segment, C0606, C0607, C0935, C0611 & C0612.

A typical Room/Bed and Patient conversion (i.e. from an existing automated hospital system - e.g. Unity to INVISION conversion) involves the following three steps:

• Test Conversion -
  • Moving the Financial system's data, including Room/Bed information, over to the clinical side. This is performed two months prior to LIVE to establish accurate billing information on the clinical side.
• Control Conversion -
  • Moving the old system's patient information over to INVISION Clinicals. This is done 3-4 weeks prior to LIVE to retest the process to simulate the LIVE conversion.
• LIVE Conversion -
  • Moving the old system's patient information over to INVISION Clinicals. This is performed to populate the new INVISION system with real patient information for LIVE.

In addition, your hospital may or may not have manually built their room beds on the clinical side prior to the Test Conversion.

If your hospital manually built the clinical Room Segment (before a Test Conversion) and you assigned your carts to the rooms prior to the Test Conversion, you will lose all cart information in the Room Segment if the File Conversions Group pulls the Room information from financials. Since the Financial system contains only financial room information and no cart information, the Test Conversion, by its nature, will overlay and lose your Room Segment cart information.

The recommendation therefore, is to either:

• wait until after the Test Conversion is completed before assigning your carts to a room, or
• if you manually built the Room Segment prior to the Test Conversion, specify that the Test Conversion pull from the clinical side and not the financial side.

---

RXPert Contents