 |
Description  |
|
|
FIELD OF THE INVENTION
This invention relates to systems for infusing fluids into a patient and
more particularly to systems for managing and analysis of prescribed
infusion programs.
BACKGROUND
Intravenous infusion therapy is often necessary to administer medications
or other fluids directly into the circulatory system of a patient.
Epstein, et al., U.S. Pat. No. 4,696,671, assigned to the current assignee
and incorporated herein by reference, discloses an infusion pumping system
capable of administering multiple infusates at individually programmable
rates, volumes, and sequences. This system uses one or more single pump
systems each of which pumps all plural fluids through one or more fluid
input ports and one outlet port. This pump system increases the ability to
administer complex programs of infusion therapies and reduces the time and
labor required by nurses or other health practitioners in setting up and
monitoring infusions while improving the reliability of proper infusion.
One or more infusions to be administered to a patient are prescribed by the
patient's physician. A pharmacy, generally located within the patient's
hospital or clinic, makes up the infusion according to the physician's
prescription. The pharmacist places the infusion solution in a bag,
bottle, syringe, or other container and labels the container. The label
contains data to identify the patient, physician, medications prescribed,
and a control number. The label is generally typed or printed in human
readable characters only. The container is transported to the patient's
location. A nurse or other health practitioner hangs the container from a
rack. The nurse runs a tube from the container to the infusion pumping
system, such as that disclosed by Epstein, et al. for pumping or gravity
feeding the infusion solution to the patient. The nurse then enters all
data regarding the infusion program manually, generally through a
keyboard, into the pumping system. The data includes, for example, the
rate of infusion, the total volume to be infused, and which of the plural
lines the infusion is to use.
Hospitals maintain a large inventory of drugs that are kept up to date in
volume and availability and size scaling. In addition, each hospital may
develop its own vocabulary of drug identification and relies on pharmacist
expertise to prevent incompatible drug administration. Manual treatment of
this type of infusion system data is disadvantageous because it is labor
and time consuming and the possibility for incorrect data treatment is
greater.
SUMMARY OF THE INVENTION
The infusion system of the present invention contemplates a system for
managing the infusion of one or more drug formulations to a patient from
the make up of the infusion in the pharmacy to the generation of a report
for hospital records and analysis after the infusion is complete.
The infusion management system of the present invention provides a
computer-based pharmacy management system, located in a hospital or
clinic's pharmacy, remote from the infusion pumping system. All
prescriptions for intravenous infusions are entered into the system when
the pharmacist makes up the prescribed formulation. The system prompts the
pharmacist or other user for the necessary patient identification data and
prescription data, such as the drug to be infused, the carrier solution if
any, the concentration of the drug in the carrier solution, and the
infusion regimen (continuous, maintenance, or intermittent and rate,
volume and infusion frequency). The data entered can be subsequently
edited. After all data has been correctly entered, the system makes a bar
code readable label which is applied to the outside of the container in
which the infusion solution is placed.
The pharmacy management system also includes a drug database which stores
drugs by name, mnemonic, and I.D. number. The database also includes a
matrix of drug incompatibility. If two incompatible drugs are to be mixed
in a single solution, the system alerts the user.
The management system also produces reports to be included on the patient's
record or chart. Further, the management system tracks the inventory of
drugs by monitoring the precise amount of drugs used and the nature of
this drug source. This data may be transferred to the hospital's existing
drug inventory control system for more accurate monitoring and ordering of
drugs.
The labeled container containing the infusion formulation is transferred to
the patient by usual methods either within the hospital or to the
patient's home in the case of remote infusion control. The user, a nurse
or other health practitioner, using a bar code reader associated with each
pump system, enters the data from the formulation container label into the
infusion pumping system where it is displayed and accepted. The pumps
serial port may be used for this purpose. Data can also be entered
manually in addition to or in lieu of entry by bar code reader. The
pumping system prompts the user for any necessary data that is missing
from the read label but required by the pumping system before the infusion
program can begin. To accommodate emergency situations, the pumping system
allows an overrider. After entering the data on the solution container,
the user completes the infusion programming by entering the start time. A
delayed start time provides flexibility in administration. Preprogramming
of functions is useful when the user is expecting a patient to arrive
from, for example, an operating room and wants to get the infusion up in
advance. Alternatively, an advance set-up reduces the risk of error due to
setting up an infusion too quickly and allows the patient to be connected
to the infusion system more rapidly upon arrival.
The infusion pumping system has several input lines for infusing more than
one formulation. A similar procedure is used to program each line on the
pumping system and the pump itself can identify inappropriately scheduled
drugs.
The infusion pumping system performs several checks to ensure the data is
correct. It verifies that the patient identification is correct and that
the patient is not allergic to any of the medications in the solutions and
allows the user to confirm that all data is correct. The user can override
the data on the bar code label by manually entering different data.
The infusion pumping system of the present invention also contemplates an
improved alarm handler system. During operation, the pumping system can
generate a variety of alarm conditions of varying severity. Some alarm
conditions, such as various pump failures, unlocked cassette, and patient
line occlusion require stopping all pumping immediately. Other alarms,
such as air in a secondary input line merely require temporarily holding
the pumping on that line until the alarm condition has been cleared while
other lines continue to infuse. Finally, alarms such as an empty bottle on
one of the input lines do not effect pumping at all. Also, several alarms
can exist simultaneously if, for example, a second alarm occurs before a
first alarm has been cleared.
The present invention provides an alarm handler capable of dealing with
many alarms at once. The alarm handler ranks the alarms by degree of
urgency. The alarms are stored in a stack with the most urgent presented
to the user for clearing first. Alarms of the same degree of urgency are
stored in reverse chronological order. An audible tone alerts the user to
the existence of one or more alarm conditions. The system, upon prompting
by the user, presents the alarms to the user for action.
The infusion pumping system is also responsive to remote or biofeedback
instructions to alter a planned infusion program.
DESCRIPTION OF THE DRAWINGS
FIG. 1 shows a schematic block diagram of the fluid management and pumping
system of the present invention;
FIG. 1A shows a bar coded label of the present fluid management system;
FIGS. 2-29, are flow charts illustrating the pharmacy management system of
the present invention;
FIGS. 30-34 are flow charts illustrating data entry into the fluid pumping
system of the present invention;
FIG. 35 is a diagram showing the state of the pumping system after various
alarm conditions;
FIG. 36 is an alarm priority table;
FIG. 37 is a schematic block diagram of the biofeedback remote programming
system of the present invention;
FIG. 38 is a flow chart illustrating the biofeedback/remote programming
system; and
FIGS. 38-42 are flow charts illustrating the biofeedback/remote programming
system.
DETAILED DESCRIPTION OF THE INVENTION
The present invention is shown generally in block diagram format in FIG. 1.
A pharmacy management system 20 includes a computer keyboard 20-1 for
input, bar code reader 20-2, database 20-3 and a printer 20-4 for
generating a bar coded label to be placed on the container for an
intravenous solution made up by the pharmacy of a hospital or clinic.
Since the pharmacy management system 20 accurately tracks the quantities
of drugs used, it may communicate through an interface 22 with the
hospital's existing computer based pharmacy inventory control system 24
for the exchange of hospital specific inventory and drug labelling data.
A hospital typically has a pre-existing computerized administration system
26. The pharmacy management system 20 communicates through interface 28
with this pre-existing hospital administration system 26. The hospital
administration system also communicates through an interface 30 with the
hospital's pre-existing inventory control system 24.
Labels 32 for infusion formulation generated by the pharmacy management
system 20 from keyboard bar code input of prescriptions are transported to
the appropriate patient 34 infusion pumping systems 38 and 40 (as shown in
the above referenced patent) as shown by the dotted lines in FIG. 1. While
only two patients 34, 36 and associated pumping systems 38 and 40 are
shown in FIG. 1, each hospital will generally have many such patients.
Each infusion pumping system 38, 40 includes a bar code reader 38-1 and
40-1 coupled into the database of the pump through a parallel data port or
an RS-232 serial port shown in Epstein, et al. The label is read by the
bar code reader and all the information on the label is transferred to the
infusion pumping system in the same manner as manual data entry occurs.
The infusion management system also includes a remote/biofeedback control
system 42 which operates through an interface 44. In biofeedback
applications information is sensed by patient sensors 34-1 and 36-2, such
as blood pressure or glucose levels, and instructions are sent to the
infusion pumping systems 38, 40 to alter the planned program of infusion
in response to the sensed information. With the remote capabilities of
control system 42, a patient may remain at home. Instructions for
programming an infusion pumping system are sent over a phone line
communication path 42-1 to a home system 42-2 of pumping systems by the
control system 42.
The pharmacy management system 20 may be described with more detail by
reference to the flow charts of FIGS. 2-29. Specifically, the pharmacy
management system provides a program for encoding infusion delivery
instructions for intravenous solutions in a bar code format. The system
takes the operator through a series of screens and menus which request the
information necessary to program the infusion pumping system. A final
screen summarizes all the data that has been entered, requests
confirmation from the operator, and provides the option for making a
label. The delivery instructions are printed in bar code format as well as
in human readable format on the label.
The system can be run on commercially available computers. Preferably, the
system includes a monitor 20-5 for displaying the data screens and a
keyboard 20-1 for entering the data.
The flow chart of FIG. 2 shows the overall operation of entering data for
each intravenous solution to be infused into a patient. The encoding
program is initialized in step 102 by booting up the computer with the
pharmacy management system installed in the computer's memory and typing
an appropriate command including calendar entry. The system invokes a
system menu processing routine in step 104, which gives the user a choice
of several tasks to perform. The system menu processing routine is
described in greater detail by reference to the flow chart of FIG. 3. The
system displays the main menu 106. The main menu displayed to the user
allows the choice of editing previous labels, all on specific patient
scripts, processing new entries, printing all on a range of labels,
generating a report, archiving the database, batch delete or restoring the
database. The user makes a selection 108 and the system returns the
selection in step 109 and returns processing to the main program. The
user's selection is then processed in step 112 in FIG. 2. After the user's
selection has been processed, the system gives the user the option of
quitting or performing another task. If the user wants to perform another
task, the system returns to the step of invoking the system menu
processing in step 104 to allow the user another selection. If the user
quits, the system invokes system termination, as shown by block 116.
The task of processing previous entries is shown in the flow chart of FIG.
4. This task allows the user to call up infusions that have been
previously entered and are due to expire on a specified date. The user
then determines whether the infusion should be renewed. If the infusion is
to be renewed, the system saves the patient's records. As shown by the
flow chart of FIG. 4, this routine retrieves the date from the system in
step 120. It clears the screen in step 122 and a work space in RAM, as
shown by steps 124 and 126. The system then executes a patient scan 128,
in which it searches for infusions due to expire that date. It displays
each infusion record on the screen and provides the user with the option
of renewing the infusion by printing a bar coded label. After the scan is
complete, and all bar coded labels printed, the routine sets return status
to "OK," enabling processing to return to the routine of FIG. 2.
The processing of new infusion entries is shown by the flow charts of FIGS.
5-17. The system's first step is to put all existing records, including
records saved in the "processing previous entries" routine, in a workspace
in RAM 20-3 in step 132. The system then calls a routine to process a
patient record 134, shown in more detail in FIGS. 6 and 7. The system will
display a screen asking for patient identification data in step 150 and
will set the data mode to allow input in step 152. The patient may be
identified by name or identification number. If the patient has previously
been recorded in the system, entering one of the patient's name or
identification number will cause any other patient data in the patient's
record stored in RAM 20-3 to appear on the screen. The patient
identification screen also contains data fields requesting or displaying
data on the patient's room number or other location identifier, total
number of intravenous solution labels required by the patient, the
patient's physician, and physician identification number. Once all the
patient identification data corresponding to label fields in a typical
label as shown in FIG. 1A has been correctly provided, the special
function key may be depressed to enter this data and display the next
screen 154. The patient data remains displayed in a window at the top of
the monitor while the remaining infusion data on the subsequent screens is
entered. If the system includes a color monitor, the patient
identification screen may change to a different color in step 156, to
indicate that it has been entered.
Each patient can receive a number of different drug regimens. Each regimen
refers to the delivery instructions for a solution of drugs contained in
one intravenous container. As in step 158, the system sets the regimen
count to zero. The system then increments the regimen count, in step 160.
For the first drug regimen, the regimen count is 1. The system clears a
work space in RAM, in step 162. The system then makes a control number, in
step 164. The control number is for the pharmacy's use in keeping track of
all the intravenous solutions it formulates. The next step 166 initializes
a default prescription (or script) 166. For example, certain data such as
the keep vein open (KVO) rate is often the same regardless of the drug. In
addition, the expiration date is usually set for one day later but can be
adjusted by a higher level of authorization. This data is placed into the
system as default data, but it can be changed by the user during the next
step of processing the script in step 168.
The procedure involved in processing each prescription is shown with more
detail in FIGS. 8-16. As shown in FIG. 8, the first step 122 initializes
the script causing the drug entry screen to appear. The system accepts
entry of data in each of the data fields in the screen. The data fields
include the drug regimen number, the prescription date, the expiration
date, the prescription number, the pharmacy control number, and the drug
name, drug nmemonic, and drug identification number, and the drug
concentration in a carrier solution. These correspond to fields shown in a
sample label in FIG. 1A. When the user enters a drug either by name,
mnemonic or number, the remaining unentered data previously set up as
default data, will automatically be supplied by the system.
The system then displays a screen asking the user if additives are desired
in step 178. If the user selects additives, the additives are processed in
step 180 as shown by the flow charts of FIGS. 9 and 10. The system
initializes the additives by displaying an additive screen in step 182.
User input in step 184 allows the user to enter the additives desired. The
system builds an additive list in step 186 simply by adding a new additive
to the list in the routine as shown in FIG. 10. The system then updates
the script in step 188 to include all the additives. Once all the
additives have been processed, the system returns to the routine of FIG.
8, displays the data in a window of a different color to show that all the
prescription medication data has been entered in step 190, and continues
to the step of processing the infusion in step 194.
The steps of processing the infusion are shown in FIG. 11. The system
displays a menu in step 110 for choosing the type of infusion. The
infusion types are continuous, maintenance, and intermittent. If
continuous infusion is selected, the screen will display data fields for
the dose rate and the dose volume and a menu for the selection of the
appropriate units. If maintenance infusion is selected, the screen will
display data fields for the maintenance rate and total volume and a menu
for the selection of the appropriate units. If intermittent infusion is
selected, the screen will display data fields for the volume per dose, the
time per dose, the dose rate, the dose frequency, the total number of
doses, and whether a dilution or a syringe is desired. Again, the screen
will also allow the selection of the desired units. If dilution is
selected, the screen will display data fields for the entry of the
dilution rate per dose and volume per dose. After all this data has been
entered, the user hits a special function key which allows the system to
update the script and store the data in step 116. This data may also be
displayed in a red window in step 118.
At this point, all the necessary data for the infusion has been entered
into the system. The next step is to generate a label containing the data
in both bar code readable and human readable format. The system gets the
label instructions in step 196, as shown in FIG. 8 and in flow charts of
FIGS. 12-17. The first step of the flow chart of FIG. 12 is to display an
option menu in step 202. The options are to make a label, skip making a
label, edit a label, or terminate. After a menu option is selected, the
processor moves on to the next step of finishing the regimen in step 204.
If the terminate option is selected, the system, as shown in FIG. 13 clears
the screen in step 206, sets the data mode to input in step 208, allowing
the user to start on a new patient or prescription, and sets the system to
terminate the present infusion entry in step 210. Processing is returned
to step 198 in FIG. 8. Since termination has been selected, the system
quits in step 200. Processing then returns to step 168 in FIG. 6. Since
"quit" has been selected, processing returns as shown in FIG. 7 to the
main program of FIG. 2 and finally terminates in steps 114, 116.
If, instead, the option to skip making the label is selected, then the
system as shown in FIG. 14 clears the screen in step 212 and sets the data
mode to input in step 214. This allows the user to continue inputting data
on the same patient. If the user elects to edit the data, as shown in FIG.
15, the system clears the screen in step 216, redisplays the patient
screen in step 218, and sets the data mode to edit in step 220, allowing
the user to edit the data relating to the current patient or prescription.
This allows the user to make any changes that may be necessary.
If all the data has been correctly entered, the user can make a label, as
shown in FIG. 16. The system displays a screen in step 222 to allow the
user to set the number of copies. The system then generates labels in step
224, as shown in FIG. 17. The system formats the data in step 226 in bar
code readable and human readable form. The system then prints the label in
step 228. A conventional bar code printer may be used. The bar code
symbology preferably is three of nine (39), an alpha/numeric encoding
system with a high reliability rate (internal check character) as
recommended by the Health Industry Business Communications Counsel.
The system then makes a log entry and a label in step 230 and prints an
additional label in step 240, for example, to attach to the patient's
chart. The system then clears the screen in step 242, as shown in FIG. 16,
sets the data mode to input in step 244 to allow further input of data,
and updates the prescription database in step 246 by storing the completed
prescription in the database. Processing is then returned to step 198 of
FIG. 8, where the user is given the option of terminating the input on the
present patient or continuing with the present patient by processing a
further prescription.
If the user selects termination, in step 198, quit is set to yes in step
200. Processing is returned to step 170, as shown in FIG. 6 and the
patient screen is redisplayed. If quit, as shown in step 250 of FIG. 7 is
selected, the screen is cleared in step 252. Processing returns to the
routine shown by the flow chart in FIG. 2. If the user does not select
termination, in step 250 processing returns to step 160 of FIG. 6. The
regiment count is incremented by one. This allows the user to process a
second prescription for the same patient. The system then goes through the
identical steps for any desired number of prescriptions for the particular
patient. If the user has finished processing scripts for the patient, the
system sets a "return" status, which allows processing to return to the
main menu.
A further user selection allowed by the system in the routine shown in the
flow chart of FIG. 2 is the making of a patient report. The flow charts of
FIGS. 18 and 19 describe this routine. When this option is selected, a
report menu is displayed in step 260. The system gets the user selection
in step 262 and processes the report in step 264, as shown more fully in
FIG. 19. The system displays an input screen in step 266, gets the user's
data in step 268 and loops through the database in step 270, applying the
search criteria input by the user in the previous step 268 to the patient
script records. The system then prints the report in step 272.
Alternatively, the system could interface with the hospital administration
system 26, as shown in FIG. 1, and send the report to the hospital
administration system.
Typical examples of report generation include a summary over a specified
time of all drugs labelled for a patient. Two other options provided in
the menu of FIG. 2 are to archive the database or to restore the database.
Archiving the database is shown in the flow chart of FIG. 20. The system
executes a backup in step 280, generally by storing the database on a
floppy disk and returns in step 282 to the main menu. The opposite
procedure, shown in FIG. 22, is the restoring of the database to the
system. In this routine, the system executes a restore in step 284,
generally reading the database from the floppy disk into the storage on
the system and returns in step 286 to the main menu.
The system also includes a stored drug table in RAM 20-3. The drug table
includes a list of all the drugs used or prescribed for patients in the
hospital. The drugs may be stored by drug name, nmemonic, and
identification number. The drug table may also include incompatibility
data for the drugs. For example, if a solution containing a mixture of two
drugs were to cause particles to precipitate, the drugs would be
incompatible, since a solution with precipitates would not be suitable for
infusion into a patient. The system checks the drug table upon entering
new prescriptions for each patient. The drug table supplies some of the
drug data to be included on the label. The drug table may be edited to
change data on the drugs included in the database, or to add or delete
drugs to and from the database.
FIGS. 23-29 show the flow charts for the routines which allow entry,
deletion, and editing of the data in the drug database. FIG. 23 shows the
flow chart for the main routine. The first step 302 is to initialize the
system, generally by typing an appropriate command on the keyboard. The
system then invokes the system menu processing in step 304. The user can
select from the choices of loading the drug file, saving the drug file,
printing a drug table, entering drug data, editing drug data, and deleting
drug data. After the user makes a selection, the system processes the user
selection in step 306.
To work on the database, the user must first load the drug file, as shown
by the routine of FIG. 24. The system loads the database in step 312. The
system then returns and asks the user whether the user wishes to quit or
continue, as shown by step 308. If the user wishes to continue, the system
menu processing is once again invoked in step 304 allowing the user to
make a further selection.
New drug data is entered by the routine shown by the flow chart in FIG. 27.
The system displays a drug entry screen in step 322. The user enters data
in step 324, and the system puts the entered drug data into the database
in step 326. If the user selected the option of editing the drug data, the
routine shown in FIG. 28 is followed. The system displays a drug edit
screen in step 328. The drug edit screen requests the user to specify a
particular drug and the system displays the data contained for this drug
in step 330. The user may then edit the data regarding the specified drug
in step 332. After the user has completed editing, the system updates the
internal database by storing the edited data. If the user selects the
option of deleting a drug from the database, the routine shown in FIG. 29
is followed. The system displays a delete drug screen in step 336. The
user selects a drug to be deleted. The display shows the drug specified by
the user in step 338. The system then asks for verification that the drug
is to be deleted in step 340. If the user chooses no, the drug will not be
deleted. If the user chooses yes, the drug will be deleted from the
database in step 342.
The flow chart of FIG. 25 allows the archiving of a drug database that has
been recently changed. If this option is selected, the system deletes the
old copy of the drug database in step 314. The new copy of the drug
database is saved in step 316. The user can also print the drug database,
as shown by FIG. 26. If the user selects this option, the system redirects
the output to a printer in step 318. The system then loops through the
drug database, formatting and printing each entry in step 320.
After each prescription label has been generated by the pharmacy management
system, the label is placed on the bag containing the solution to be
infused. The bag is carried or transported by the hospital's usual method
to the patient's location. The delivery instructions printed on the label
on the medication container must be inputted to the infusion pumping
system. The flow charts of FIGS. 30-34 describe the process used to enter
the data on the labeled medications by bar code reading.
The infusion pumping system generally is a system similar to that described
in the above-referenced patent to Epstein, et al. The system contains a
housing in which is placed a disposable cassette containing plural input
ports and a single patient output port. The medications are hung from a
rack and tubing is run from the medication container to one of the input
ports. In the prior art system, a nurse or other health practitioner
programs the infusion pumping system with the necessary delivery
instructions such as dose rate, to | | |
