US20130012877A1 - Security features for a medical infusion pump - Google Patents

Abstract

Various security features for a medical infusion pump are disclosed. The security features include providing dual verification for standing orders, allowing multiple levels of access rights to features of the medical infusion pump, and incorporating a security touch screen in the medical infusion pump. Methods of use and operation of these features are disclosed as well.

Description

RELATED APPLICATIONS
• This application is a division of application Ser. No. 12/416,584 filed Apr. 1, 2009, which claims the benefit of U.S. Provisional Application No. 61/041,475 filed Apr. 1, 2008, each of which is hereby fully incorporated herein by reference.
TECHNICAL FIELD
• The present disclosure relates to use of medical infusion pumps. In particular, the present disclosure relates to security and safety features used in conjunction with medical infusion pumps.
BACKGROUND
• Patients at hospitals and other care centers regularly require controlled drug intake as a part of the patient's prescribed therapy. One form of controlled drug intake is accomplished by infusing fluidic drugs with a medical infusion pump.
• Medical infusion pumps, in general, provide regulated drug delivery to a patient. These pumps are used to deliver a selected drug or other therapeutic agent to a patient at a predetermined rate that is programmed into the pump. A doctor, nurse, or other healthcare professional typically programs each medical infusion pump in accordance with a prescribed dosage of a drug or therapeutic agent. Once the medical infusion pump is programmed, it will execute that program regardless of any human errors introduced during the programming of the pump or creation of the pump protocol. Introduction of additional redundancies in verifying the programming of pumps can reduce errors in drug delivery to a patient.
• Furthermore, medical infusion pumps can include a variety of functionality related to fluidic drug delivery. For example, medical infusion pumps can alter rates of drug delivery, can deliver boluses (additional drugs beyond the prescribed amount), and can accept reprogramming in accordance with different therapies, drugs, or patients. However, certain aspects of this functionality may be intended for use by a doctor, while other functionality may be intended for use by a nurse, and still further functionality may be intended for use by a patient. However, all of these settings and systems are generally available to all users of the medical infusion pump
SUMMARY
• In a first aspect, a method of verifying a standing order in a medical infusion pump is disclosed. The method includes selecting a protocol for execution of a standing order in a medical infusion pump, and verifying the protocol in the medical infusion pump. The method also includes receiving confirmation of the protocol from a system external to the medical infusion pump, and, upon receiving confirmation of the protocol, allowing operation of the medical infusion pump in accordance with the protocol.
• In a second aspect, a medical infusion pump is disclosed. The medical infusion pump includes a pump mechanism, a memory, and a programmable circuit arranged to control the pump mechanism and operatively connected to the memory. The programmable circuit is programmed to select a protocol for execution of a standing order in a medical infusion pump, and verify the protocol in the medical infusion pump. The programmable circuit is also programmed to receive confirmation of the protocol from a system external to the medical infusion pump, and upon receiving confirmation of the protocol, allow operation of the medical infusion pump in accordance with the protocol.
• In a third aspect, an infusion pump network is disclosed. The infusion pump network includes a medical infusion pump and a computing system communicatively connected to the medical infusion pump. The infusion pump network is configured to execute program instructions to select a protocol for execution of a standing order in a medical infusion pump and verify the protocol in the medical infusion pump. The infusion pump network is also configured to execute program instructions to transmit confirmation of the protocol from the computing system to the medical infusion pump, and upon receiving confirmation of the protocol in the medical infusion pump, allow operation of the medical infusion pump in accordance with the protocol.
• In a fourth aspect, a medical infusion pump is disclosed. The medical infusion pump includes a pump mechanism, a memory, and a programmable circuit arranged to control the pump mechanism and operatively connected to the memory. The programmable circuit is programmed to receive security data from a user and determine one or more access rights for the user based on the security data. The programmable circuit is also programmed to allow access to the medical infusion pump in accordance with the one or more access rights.
• In a fifth aspect, a method of managing access to features in a medical infusion pump is disclosed. The method includes receiving security data from a user and determining one or more access rights for the user based on the security data. The method also includes allowing access to the medical infusion pump in accordance with the one or more access rights.
• In a sixth aspect, a method of managing access to features in a medical infusion pump is disclosed. The method includes associating a user with a user class, the user class assigned one or more access rights in a medical infusion pump. The method further includes associating security data with the user, receiving the security data from the user, and determining the one or more access rights for the user based on the security data. The method also includes allowing access to one or more systems in the medical infusion pump in accordance with the one or more access rights.
• In a seventh aspect, a medical infusion pump is disclosed. The medical infusion pump includes a pump mechanism, a memory, a display, and a programmable circuit arranged to control the pump mechanism and operatively connected to the memory and the display. The programmable circuit is programmed to receive a signal from the display, the signal corresponding to user interaction with the display of the medical infusion pump. The programmable circuit is also programmed to evaluate the signal and allow access to one or more settings incorporated into the medical infusion pump in response to evaluating the signal.
• In an eighth aspect, a method of authenticating a user to use a medical infusion pump is disclosed. The method includes receiving a signal from a display of the medical infusion pump, the signal corresponding to user interaction with the display. The method also includes evaluating the signal and allowing access to one or more settings incorporated into the medical infusion pump in response to evaluating the signal.
• In a ninth aspect, a medical infusion pump is disclosed. The medical infusion pump includes a pump mechanism, a memory, a touch screen display, and a programmable circuit arranged to control the pump mechanism and operatively connected to the memory and the display. The programmable circuit is programmed to associate a stored biometric signal with one or more user profiles stored in the medical infusion pump. The programmable circuit is also programmed to receive a biometric signal from the touch screen display, the biometric signal corresponding to user interaction with the display. The programmable circuit is further programmed to evaluate the received biometric signal based on the stored biometric signal, and upon evaluating the biometric signal, allow access to one or more settings incorporated into the medical infusion pump.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates a pump-computer communication system according to a possible embodiment of the present disclosure;
• FIG. 2 illustrates an infusion pump network according to a possible embodiment of the present disclosure;
• FIG. 3 illustrates the architecture of a computing system that can be used to implement aspects of the present disclosure;
• FIG. 4 illustrates the architecture of a pump that can be used to implement aspects of the present disclosure;
• FIG. 5 illustrates the architecture of a pump peripheral device that can be used to implement aspects of the present disclosure;
• FIG. 6 illustrates a possible layout of a medical care network incorporating medical infusion pumps, according to a possible embodiment of the present disclosure;
• FIG. 7 is a further example infusion pump network according to a possible embodiment of the present disclosure;
• FIG. 8 illustrates a flowchart of methods and systems for verifying a standing order in a medical infusion pump, according to a possible embodiment of the present disclosure;
• FIG. 9 is a schematic view of an infusion pump network configured for dual confirmation of a standing order, according to a possible embodiment of the present disclosure;
• FIG. 10 illustrates a flowchart of methods and systems for managing access to features in a medical infusion pump, according to a possible embodiment of the present disclosure;
• FIG. 11 illustrates a user access record for managing user rights in a medical infusion pump, according to a possible embodiment of the present disclosure;
• FIG. 12 illustrates a user class association record useable in a medical infusion pump, according to a possible embodiment of the present disclosure;
• FIG. 13 illustrates a flowchart of methods and systems for authenticating a user in a medical infusion pump, according to a possible embodiment of the present disclosure;
• FIG. 14 illustrates a touch screen user authentication record useable in a medical infusion pump, according to a possible embodiment of the present disclosure; and
• FIG. 15 illustrates a medical infusion pump having a touch screen useable for user authentication, according to a possible embodiment of the present disclosure.
DETAILED DESCRIPTION
• Various embodiments will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the appended claims.
• The present disclosure relates generally to fluid delivery in a medical infusion pump, and management of pumps configured to deliver fluids to a patient. The present disclosure describes features of a medical infusion pump, as well as interactions that the medical infusion pump can have with users such as healthcare providers or others having physical or communicative access to the pump. Specifically, the present disclosure relates to safety and security features used in conjunction with a medical infusion pump to ensure that patients are treated with the correct drug or other therapeutic fluid, and receive the correct therapy using that drug/fluid. This can be accomplished, in general, by requiring multiple confirmations of each drug delivery, and by restricting access to certain settings or functionality in a medical infusion pump to those users (e.g. healthcare professionals) qualified to operate those aspects of the medical infusion pump.
• The logical operations of the various embodiments of the present disclosure described herein are implemented as: (1) a sequence of computer implemented operations running on a computing system; and/or (2) interconnected machine modules within the computing system. Modules represent functions executed by program code such as commonly available programming languages or as the code found in a dynamic-link library (DLL). The implementation used is a matter of choice dependent on the performance requirements of the medical infusion pump and the computing systems with which it interfaces. Accordingly, the logical operations making up the embodiments of the present disclosure can be referred to alternatively as operations, modules, and the like.
I. Computing Environment Incorporating a Medical Infusion Pump
• The following discussion is intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. Although not required, the invention will be described in the general context of computer-executable instructions being executed by a computer, for example, a hand held computer, a personal computing system, or a medical infusion pump.
• FIG. 1 illustrates an exemplary embodiment of aninfusion pump network100 having amedical infusion pump102, acomputing system104, and acommunications link106. Themedical infusion pump102 is configured to deliver therapeutic fluids, such as drugs, saline, or nutrition to a patient. Examples of medical infusion pumps102 include ambulatory pumps, stationary pumps, and pole mounted pumps.
• Thecomputing system104 is configured to execute computer-readable instructions, such as computer software. Thecomputing system104 can be located in a variety of locations such as the point of care (POC) where a patient is being treated, in a healthcare facility at a location remote from the POC, or even at an off-site location remote from the healthcare facility itself. In further embodiments, the medical infusion pump102 acts as thecomputing system104.
• In the exemplary embodiment, thecomputing system104 is programmed to generate and store pump protocols for execution in the context of a pump application program. Each pump protocol includes a series of pump parameters. Pump parameters refer to settings that define an operational aspect of a medical infusion pump. The pump parameters dictate the control of the pump.
• By way of reference, pump protocols are collections of these pump parameters defining the variable operational characteristics of a medical infusion pump during application of a specific therapy, qualifier, and drug. The pump protocol includes a listing of operational parameters to be included in the pump, and correlates to an index for referring to a specific protocol containing a specific set of pump parameters. The index can be associated with a therapy, qualifier, and drug, and is either contained within the protocol or associated with a specific protocol. The pump protocol includes patient specific pump parameters and non-patient specific pump parameters. Patient specific pump parameters refer to those parameters which are set on a patient-by-patient basis, and for example include the basal delivery rate or bolus amount. Non-patient specific pump parameters refer to those parameters which are set for the pump to perform specific tasks, and do not account for the specific patient to which they are applied. These parameters are generally related to the pump, the infusion pump network, or the medical care to be provided by the pump and/or pump network. Non-patient specific pump parameters can include, for example, a range of permissible values for basal delivery, a range of values and patterns for basal delivery, a range of permissible values for boluses, a range of values and patterns for extended boluses, a starting value within a particular range of values, alarm values, protocols for data communication, and various flag settings. An example of a library of pump parameters accessible to a medical infusion pump is described below in conjunction withFIG. 7.
• Also by way of reference, a pump application program is a program having instructions (e.g., executable code, rules, and/or data) that control operation of the pump for a specific therapy or type of delivery (e.g., continuous delivery, intermittent delivery, pain control, chemotherapy, total parenteral nutrition, etc.). For example, a pump application program might contain instructions that define operation of a pump to accomplish various of the pump parameters.
• The communications link106 connects thepump102 andcomputing system104. In various embodiments, the communications link106 can include serial or parallel connections, wired or wireless connections, and a direct or networked connection to a computer. Additionally, thepump102 and thecomputing system104 can communicate using any protocol appropriate for data communication. Examples of network connections to a computer include Intranet, Internet, and LAN (e.g., Ethernet). Examples of wired connections to a computer include USB, RS-232, Firewire, and power-line modem connection. Examples of wireless connections include Bluetooth, 802.11a/b/g, infrared (IR), and radio frequency (RF).
• Further details regarding use of pump parameters and protocols in the context of an infusion pump network are discussed in U.S. patent application Ser. Nos. 11/499,248, 11/499,240, 11/499,255, and 11/499,893, all filed Aug. 3, 2006, as well as U.S. patent application Ser. Nos. 11/702,922 and 11/702,925 filed Feb. 5, 2007. Each of these patent applications is hereby incorporated by reference in its entirety.
• FIG. 2 illustrates an exemplary embodiment of aninfusion pump network200 having aserver206 networked with a plurality of computing systems104₁-104_n. Thenetwork200 can be any wired or wireless network that enables data communication between the server, computing systems, and medical infusion pumps. Examples of networks include the Internet, Intranets, and LANs. Eachcomputing system104 can communicate with a medical infusion pump102₁-102_nthrough acommunication link106.
• In the exemplary embodiment, theindividual computing systems104_nexecute software for generating and managing pump application programs and sets of pump operating parameters, and store information related to the associatedmedical infusion pump102_n. The pump application programs and sets of pump operating parameters can be stored on theserver206 and accessed by otherindividual computing systems104_n. Theindividual computing systems104_1-nare also programmed to retrieve previously created pump application programs and sets of pump operating parameters that are stored on theserver206 for viewing, editing, and downloading to medical infusion pumps102_1-n. These pump application programs and pump operating parameters can be used to determine various fluid delivery algorithms, such as those described in greater detail herein.
• Theindividual computing systems104_1-n, are also programmed to communicate various information between the medical infusion pumps102_1-nand theserver206. In certain embodiments, theindividual computing systems104_1-nare programmed to communicate pump events to the server for storage and later processing, such as cost and operational history data tracked in the medical infusion pumps102_1-n. In further embodiments, theindividual computing systems104_1-nare programmed to communicate messages generated in the pumps to external computing systems, including theserver206 and other devices, for notification of third-party caregivers of certain occurrences (e.g. exceptions or alarms) in the pump.
• In alternative embodiments, the medical infusion pumps102_1-ncan directly communicate with the server to retrieve pump application programs and sets of pump operating parameters and to provide data relating to operation of the pump. For example, the medical infusion pumps102_1-ncan be loaded with client software such as a web browser and communicate directly with thenetwork200, either through a wired or wireless connection as described herein.
• In other alternative embodiments, one or more of the computing systems (e.g.104_1-n) is not configured to communicate directly with one of themedical infusion pump102_1-n, but rather provides administrative access to theserver206 for generating, viewing, and editing pump application programs and sets of pump operating parameters, and for communicating data from the pump to the server. Additionally, servers, workstations, and other computing systems unaffiliated with the medical infusion pumps102_1-ncan be included in thenetwork200.
• In yet other alternative embodiments, certain aspects of the software described herein execute in theserver206. For example, in certain embodiments the server functions as an application service provider that communicates user interface and other data entries in mark-up language such as HTML or some other language or protocol that allows a user to execute software from a remote location. In these embodiments, theserver206 can function as an application service provider in which the server provides access to the software for generating and storing pump application programs and pump protocols that a user can create and download to a medical infusion pump, as well as for managing user databases, pump histories, message and alarm distribution, and other events. For example, theserver206 could be located at a pump manufacture, pharmaceutical manufacture, pharmacist, or some other third party separate from the user. Theserver206 in such an embodiment can be accessed either from anindividual computing system104 or by amedical infusion pump102 that has networking capabilities and client software.
• Example embodiments of aserver206 and amedical infusion pump102 having a web browser are disclosed in U.S. patent application Ser. No. 11/066,425, which was filed on Feb. 22, 2005 and is entitled Server for Medical Device, the entire disclosure of which is hereby incorporated by reference.
• FIG. 3 illustrates an exemplary architecture that can be used to implement aspects of the present disclosure, including thecomputing systems104 or theserver206. The computing system architecture includes a general purpose computing device in the form of acomputing system300. Thecomputing system300 can be used, for example, as the computing system or server ofFIG. 2, and can execute program modules included in the administrative software or user software disclosed below.
• Thecomputing system300 includes at least oneprocessing system302. A variety of processing units are available from a variety of manufacturers, for example, Intel or Advanced Micro Devices. Thecomputing system300 also includes asystem memory304, and asystem bus306 that couples various system components including thesystem memory304 to theprocessing unit302. Thesystem bus306 may be any of a number of types of bus structures including a memory bus, or memory controller; a peripheral bus; and a local bus using any of a variety of bus architectures.
• Thesystem memory304 can include read only memory (ROM)308 and random access memory (RAM)310. A basic input/output system312 (BIOS), containing the basic routines that help transfer information between elements within thecomputing system300, such as during start up, is typically stored in theROM308.
• Thecomputing system300 can also include asecondary storage device313, such as a hard disk drive, for reading from and writing to a hard disk (not shown), and/or acompact flash card314.
• Thehard disk drive313 andcompact flash card314 are connected to thesystem bus306 by a harddisk drive interface320 and a compactflash card interface322, respectively. The drives and cards and their associated computer readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for thecomputing system300.
• Although the exemplary environment described herein employs ahard disk drive313 and acompact flash card314, other types of computer-readable media, capable of storing data, can be used in the exemplary system. Examples of these other types of computer-readable mediums include magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, CD ROMS, DVD ROMS, random access memories (RAMs), or read only memories (ROMs).
• A number of program modules may be stored on thehard disk313,compact flash card314,ROM308, orRAM310, including anoperating system326, one ormore application programs328,other program modules330, and program data332. A user may enter commands and information into thecomputing system300 through aninput device334. Examples of input devices might include a keyboard, mouse, microphone, joystick, game pad, satellite dish, scanner, digital camera, touch screen, and a telephone. These and other input devices are often connected to theprocessing unit302 through aninterface340 that is coupled to thesystem bus306. These input devices also might be connected by any number of interfaces, such as a parallel port, serial port, game port, or a universal serial bus (USB). Wireless communication between input devices and interfaces340 is possible as well, and can include infrared, Bluetooth, 802.11a/b/g, cellular, or other radio frequency communication systems. Adisplay device342, such as a monitor or touch screen LCD panel, is also connected to thesystem bus306 via an interface, such as avideo adapter344. Thedisplay device342 might be internal or external. In addition to thedisplay device342, computing systems, in general, typically include other peripheral devices (not shown), such as speakers, printers, and palm devices.
• When used in a LAN networking environment, thecomputing system300 is connected to the local network through a network interface oradapter352. When used in a WAN networking environment, such as the Internet, thecomputing system300 typically includes amodem354 or other communications type, such as a direct connection, for establishing communications over the wide area network. Themodem354, which can be internal or external, is connected to thesystem bus306 via theinterface340. In a networked environment, program modules depicted relative to thecomputing system300, or portions thereof, may be stored in a remote memory storage device. It will be appreciated that the network connections shown are exemplary and other methods of establishing a communications link between the computing systems may be used.
• Thecomputing system300 might also include arecorder360 connected to thememory304. Therecorder360 includes a microphone for receiving sound input and is in communication with thememory304 for buffering and storing the sound input. Therecorder360 also can include arecord button361 for activating the microphone and communicating the sound input to thememory304. The computing system can also include adatabase390 for storage of data. Thedatabase390 can be accessible via the memory304 (either integrated therein or external to) and can be formed as any of a number of types of databases, such as a hierarchical or relational database.
• A computing device, such ascomputing system300, typically includes at least some form of computer-readable media. Computer readable media can be any available media that can be accessed by thecomputing system300. By way of example, and not limitation, computer-readable media might comprise computer storage media and communication media.
• Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by thecomputing system300.
• Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media. Computer-readable media may also be referred to as computer program product.
• FIG. 4 illustrates the architecture of amedical infusion pump400 that can be used to implement aspects of the present disclosure. In general, themedical infusion pump400 is a programmable pump configured to deliver fluids (e.g. fluidic drugs) to patient, such as through use of an infusion set. Themedical infusion pump400 executes one or more application programs, as described above in conjunction withFIG. 1, to accomplish fluid delivery to a patient.
• In themedical infusion pump400, amicroprocessor402 is in electrical communication with and controls apump motor404, ascreen406, anaudible alarm408, and avibratory alarm410. Other embodiments can use a microcomputer, or any other type of programmable circuit, in place of the microprocessor.
• Thepump motor404 drives adrive mechanism412. Thedrive mechanism412 delivers the therapeutic fluid to a patient. The drive mechanism can be connected to a plunger system, a peristaltic drive mechanism, or another type of fluid delivery system.
• Thescreen406 can have many different configurations such as an LCD screen. Thescreen406 displays a user interface that presents various items of information useful to a patient or caregiver. In certain embodiments, thescreen406 is a touch screen display, such as a multi-touch display or other display accepting a signal based on pressure, heat, or other stimulus applied to the screen by a user. For example, thescreen406 can be a resistive touch screen panel, a surface acoustic wave panel, a capacitive touch screen panel, or any other types of touch-sensitive panels. In such embodiments, one or more buttons or other input regions can be displayed on thescreen406 to prompt input by a user, such as touching the screen with a finger, keycard, or other object. This input can be used for a variety of purposes, including to validate the identity of the user or to select/confirm options presented to the user. In certain embodiments, thescreen406 can include biometric capture capabilities, such as a fingerprint reader. One possible application of a display able to capture a signal from a user includes user authentication, and is discussed below in conjunction withFIGS. 13-15.
• An alarm provides actual alarms, warnings, and reminders in the pump. Theaudible alarm408 can be a beeper or otherwise provide audible notifications. Similar to other portable electronic devices such as a cellular telephone, thevibratory alarm410 provides an alarm to either supplement the audio alarms or replace the audio alarm when an audible beep would be disruptive or not heard. A user can selectively enable or disable the audible408 and vibratory410 alarms. In one possible embodiment, however, both the audible408 and vibratory410 alarms cannot be disabled at the same time.
• Themicroprocessor402 is in electrical communication with a random access memory (RAM)416 and a read only memory (ROM)418, which are onboard thepump400 but external to themicroprocessor402 itself. In one possible embodiment, themicroprocessor402 includes internal memory as well. TheRAM416 is a static RAM stores that data that can change over time such as pump settings and a historical log of events experienced by themedical infusion pump400. TheROM418 stores code for the operating system and the application programs. TheROM418 can be any type of programmable ROM such as an EPROM.
• An infrared (IR)port420 is in electrical communication with the microprocessor. As explained in more detail below, theIR port420 provides data communication with an external device such as a computer for programming an application program, programming pump settings, and downloading historical data logs. Themedical infusion pump400 can include other types of communication ports in place of or in addition to theIR port420. Examples of other possible communication ports include a radio frequency (RF) port or a port that provides a hard-wired data communication link such as an RS-232 port, a USB port, or the like.
• Optionally, an additional nonvolatile memory can be incorporated into the pump and interfaced with themicroprocessor402, such as a flash memory. This additional nonvolatile memory can be configured to store data collected by the pump, such as a history of events in the medical infusion pump, alarm and message information, user records for healthcare personnel authorized to operate the pump, and other information.
• A real-time clock422 provides a clock signal to themicroprocessor402. An advantage of having a real-time clock422 is that it provides the program with the actual time in real-time so that the programs executed by the medical infusion pump can track and control the actual time of day that drug delivery and other events occur. Various durations described here are used for alerts, alarms, reminders, and other functions. In one possible embodiment, the timers are formed by the real-time clock422 and software executed by themicroprocessor402.
• Akeypad424 also provides input to themicroprocessor402. Although other possible types of keypads are possible, one type of keypad has four buttons and is a membrane-type of keypad, which provides resistance to water and other environmental conditions. Thekeypad424 contains soft keys for which the function of the keys can change as a user executes different menu selections and commands.
• An audio bolus button425 optionally provides input to themicroprocessor402. The audio bolus button425 can program thepump400 to audibly administer a bolus of drugs or other therapeutic fluids without requiring visual confirmation using the pump. In an example embodiment, the audio bolus button425 can be pressed a series of times to trigger bolus delivery of a selected volume, based on a preprogrammed trigger granularity. A single button press can represent a bolus of 5 grams, as selected by a user, and subsequent presses of the audio bolus button can represent multiples thereof.
• Other inputs into themicroprocessor402 can include anocclusion sensor426, which is sensitive to occlusions in the therapeutic fluid delivery line; acartridge sensor428, which is sensitive to the presence of a therapeutic fluid cartridge; and amotion detector430, which detects motion of a gear (not shown) in thedrive mechanism412. In an exemplary embodiment, thecartridge sensor428 includes one or more sensors configured to detect insertion of a therapeutic fluid cartridge. Thepump400 can detect the type of cartridge present via a mechanical interface, and can include in the pump software instructions regarding operation in conjunction with the cartridge. Examples of cassette sensing features are described, for example, in U.S. Pat. No. 5,531,697, filed on Apr. 15, 1994, issued on Jul. 2, 1996, and entitled “Systems and Methods for Cassette Identification for Drug Pumps.”
• Aperipheral interface432 allows additional systems to be added to thepump400, such as various communication and functional systems. Example systems that can be interfaced with the pump include a bar code reader or a communication module, or other devices such as those devices described below in conjunction withFIG. 5.
• FIG. 5 illustrates aperipheral device500 that can interface with the medical infusion pump described inFIG. 4. Theperipheral device500 generally provides extended functionality to themedical infusion pump400. In the embodiment shown, theperipheral device500 provides extended communication and computation functionality to the medical infusion pump, thereby offloading a number of tasks from that system and freeing resources used for delivering fluids to the patient.
• Theperipheral device500 includes aprogrammable circuit502, which is configured to execute program instructions as directed by themicroprocessor402 of themedical infusion pump400 and also as received from external computing systems. Theprogrammable circuit502 also optionally includes various additional operational logic configured to access memory, and to respond to the various interfaces to the programmable circuit. In one embodiment, theprogrammable circuit502 includes a microcontroller. The microcontroller can be programmable in any of a number of programming languages, such as assembly language, C, or other low-level language. In alternate embodiments, theprogrammable circuit502 includes a programmable logic device (PLD) such as a field programmable gate array (FPGA), Complex Programmable Logic Device (CPLD), or Power ASIC (Application Specific Integrated Circuit). In these embodiments, a hardware description language such as Verilog, ABEL, or VHDL defines operation of the programmable circuit.
• Theperipheral device500 also includes anelectrical interface504 communicatively interfaced with the programmable circuit. Theelectrical interface504 provides an electrical and data connection between theprogrammable circuit502 and connecting circuitry of a medical infusion pump (e.g. theperipheral interface432 of the medical infusion pump ofFIG. 4). In the embodiment shown, theelectrical interface502 can be a serial or parallel interface, such as a USB interface, which allows the peripheral device to both (1) transmit and receive data along the interface, and (2) receive/transmit electrical power, such as to power either themedical infusion pump400 orperipheral device500.
• A variety of additional interfaces also connect to theprogrammable circuit502, including anetwork interface506, aninfrared interface508, and awireless interface510. Each of these interfaces provides data communications connections with corresponding computing systems external to the medical infusion pump. Thenetwork interface506 provides a wired connection to a packet-based, IP-addressable network, such as the Internet or a Local Area Network. Theinfrared interface508 provides a direct device-to-device connection allowing data communication with nearby handheld or portable devices, and allowing theperipheral device500 to receive data from such devices. Thewireless interface510 also provides a data connection to external computing systems, and can use any of a number of wireless communication protocols or networks, such as 802.11a/b/g/n, mesh networking, or some proprietary RF communication protocol. Other interfaces can be integrated into theperipheral device500 or themedical infusion pump400 as well, depending upon the particular implementation and desired communication systems used with the medical infusion pump.
• Theperipheral device500 also includes abattery512 andpower input514 interfaced to theprogrammable circuit502. Thebattery512 provides a power source to the circuitry in theperipheral device500, and can also provide power to themedical infusion pump400 via thepump interface504. In certain embodiments, the battery is a rechargeable Lithium-ion battery pack that is rechargeable via thepower input514. Thepower input514 receives power from an external source (e.g. an external AC plug), and converts that for use in the peripheral device (as distributed by the programmable circuit502) and for recharging thebattery512.
• The peripheral device also includes various types of memory communicatively interfaced to the programmable circuit, including aRAM516 and aROM518. TheRAM516 andROM518 are used to execute program instructions provided to the peripheral device, such as for managing data input/output for the medical infusion pump. Additional memory types, such as a flash memory, can be used as well.
• In certain embodiments, theperipheral device500 can be incorporated into themedical infusion pump400 ofFIG. 4. In such embodiments, theprogrammable circuit502 can be eliminated, with the various units interfaced thereto directly connecting to themicroprocessor402 of that system. In other embodiments, the peripheral device is separate from the medical infusion pump, requiringinterface circuitry504 and432 for forming a connection therebetween.
• Additional functionality can be included in theperipheral device500 as well, based on the specific functionality desired for use with the medical infusion pump. Example additional functionality can include input/output devices, such as a bar code reader, fingerprint scanner, or other biometric reader.
• Referring now toFIG. 6, a possible layout of amedical care network600 is shown in which medical infusion pumps and infusion pump networks are used, according to a possible embodiment of the present disclosure. Themedical care network600 relates patients and healthcare professionals to each other using a variety of computing systems and medical devices, such as servers, medical infusion pumps, and other computing systems. As such, the medical care network illustrates one possible example of thenetwork100 illustrated inFIG. 1.
• In the embodiment shown, the medical care network includes one or more medical infusion pumps, one or more computing systems that can be communicatively connected to those medical infusion pumps, one or more servers managing data relating to the medical infusion pumps, and other computing systems used by patients or healthcare professionals (e.g. nurses, doctors, pharmacists, or other clinicians). Details regarding thespecific network600 shown are described below; however, thenetwork600 is intended as exemplary, and various additional systems and devices can be included which are not currently shown.
• In the embodiment shown, themedical care network600 includes and interconnects a number of different physical entities/locations, including a home orremote location602, ahealthcare facility604, and anexternal healthcare provider606. The home orremote location602 corresponds to a location outside of a healthcare facility at which a user may want to use a medical infusion pump, and may need to communicate data with a healthcare professional or with a server, such as for monitoring the status of the medical infusion pump. Each location can include, for example, aninfusion pump network608, such as the network described above in conjunction withFIG. 1.
• Thehealthcare facility604 corresponds generally to a hospital or clinic at which a number of patients may reside, as well as entities related to the facility (e.g. affiliated clinics or other institutions). In the embodiment shown, thehealthcare facility604 is arranged to accommodate a number of patients, by providing those patients with a medical infusion pump and a computing system for data communications with the pump. In the embodiment shown, the various patients can each be associated with aninfusion pump network608 such as shown inFIG. 1. Theinfusion pump networks608 within thehealthcare facility604 can correspond to networks present in patient rooms, or computing networks surrounding a patient at the facility. Other possibilities for the configuration of theinfusion pump networks608 can exist as well.
• Thehealthcare facility604 further includes ahealthcare data server610 and a plurality ofcomputing systems612 not directly associated with the medical infusion pumps orinfusion pump networks608. Thehealthcare data server610 andcomputing systems612 are typically used by healthcare professionals for patient monitoring and care management, billing, and other purposes.
• Each of the computing systems at thehealthcare facility604, including those interfaced with medical infusion pumps, are communicatively interconnected, allowing communication among the variousinfusion pump networks608 and with thehealthcare data server610 andcomputing systems612. The systems can be communicatively connected by any of a variety of communicative connections, including various wired and wireless Local Area Network connections.
• Theexternal healthcare provider606 can correspond to various remote healthcare providers or healthcare-related entities, such as remote physicians, remote specialists, health insurance companies, or other entities. Theexternal healthcare provider606 generally receives a certain subset of the data related to one or more patients within thenetwork600, such as test information, billing information, diagnosis information, or other information.
• Each of the entities within thenetwork600 are communicatively interconnected by a network614, which represents a communication network in which data can be transferred, such as the Internet or some other Wide Area Network (LAN or WAN). The network614 interconnects the various locations and computing systems at those locations, allowing data communication among the various locations. Through use of the network614, remote locations can store or access information from other locations and/or systems. For example, theexternal healthcare provider606 can access information stored on thehealthcare data server610 at thehealthcare facility604. Or, data can be uploaded to the healthcare facility from one of the local (at the facility)infusion pump networks608, or remoteinfusion pump networks608 at one of theremote locations602. Other examples of data sharing and data communications are possible as well.
• FIG. 7 illustrates a schematic architecture of a medicalinfusion pump network700 according to an exemplary embodiment. In certain embodiments, the medicalinfusion pump network700 can be implemented within themedical care network600 ofFIG. 6, using components discussed above inFIG. 2. The various aspects of the medicalinfusion pump network700 can be located at a healthcare facility, a remote facility, or at a patient's location (within or remote from the healthcare facility).
• The medicalinfusion pump network700 includes anadministrator computer702 communicatively connected to theserver206 ofFIG. 2, which includes adatabase704. The medicalinfusion pump network700 also includes one or more medical infusion pumps102 andcomputing systems104.
• Theadministrator computer702 andcomputing systems104 are systems such as those described above in conjunction withFIG. 3. Theadministrator computer702 includes administrative software installed on or accessible to the computer for generating one ormore libraries708 ofpump protocols710 for use in the medical infusion pumps102.
• In the present disclosure, libraries refer to collections of pump protocols generated using the administrative software described herein. Libraries can be stored in files, databases, or other data structures. Libraries contain pump protocols as well as indices pointing to the protocols, and are loaded in user software to select a specific pump protocol for operation of a medical infusion pump.
• Thecomputing systems104 include user software for accessing one ormore libraries708 ofprotocols710 and programming amedical infusion pump102 with aprotocol710 or alibrary708. In one possible embodiment, thecomputing systems104 are optional in that the user software resides directly on the medical infusion pumps102. An exemplary embodiment of the user software is described below inFIGS. 26-41.
• The medical infusion pumps102 connect either to acomputing system104 or directly to theserver206, and are described above in conjunction withFIGS. 4-5. In a first embodiment, the medical infusion pumps102 are configured to accept a pump protocol from theserver206 or thecomputing system104. In a second embodiment, the medical infusion pumps102 are configured to accept alibrary708 ofpump protocols710 directly from theserver206 or from thecomputing system104.
• Thedatabase704 containspump protocol data706 and log files716. Thepump protocol data706 forms a plurality oflibraries708 which in turn each include a number ofprotocols710. Eachprotocol710 is stored as a data record, and includes a set of parameters, including patientspecific pump parameters712aand non-patientspecific pump parameters712b,as described above. Eachlibrary708 can contain one ormore pump protocols710.
• The log files716 include log data regarding access and usage of thelibraries708, and can include information related to theadministrator computer702, the medical infusion pumps102, or thecomputing systems104 authorized to connect to theserver206. In one possible embodiment, the log files include access records, which record instances in which medical infusion pumps102 access alibrary708 on theserver206.
• B. Programmable Features Incorporated into a Medical Infusion Pump Network
• FIGS. 1-7, above, describe certain aspects of medical infusion pumps and networks including medical infusion pumps, including various types of computing systems and communicative connections used in management and operation of the pumps. Now referring toFIGS. 8-15, applications of specific features incorporated into a medical infusion pump or a network including a medical infusion pump are described.
• The applications and features described herein can be implemented, at least in part, in software, programmable hardware, and user interfaces integrated into the medical infusion pump, or a computing system interfaced with one or more medical infusion pumps. For example, one or more features are implemented in a pump application program able to be loaded onto and execute on a medical infusion pump. These programmable features relate to confirmation of pump protocols and user authentication for accessing features in the medical infusion pump.
1. Dual Verification of Standing Orders in a Medical Infusion Pump
• Now referring toFIGS. 8-9, systems and methods for verifying a standing order in a medical infusion pump are described. Generally, caregivers administer only those medications for which the physician has written and signed an order. The physician's order directs caregivers to provide care to a patient in accordance with the generalized instructions provided. Nurses and other caregivers providing drugs or other therapies to a patient are expected to do so accurately. The accuracy standard is expressed as “five rights” for patient care; that is, that the right patient receives the right drug, at the right dose, by the right route, and at the right time.
• The systems and methods described are intended to improve safety in delivering fluids to a user using a medical infusion pump. Fluid delivery in a pump is likewise intended to be error-free, and consistent with a standing order. A standing order in a medical infusion pump corresponds to the generally prescribed use of a medical infusion pump to delivery fluids to a user at a specified rate and in accordance with a proper therapy, qualifier and drug (as explained above inFIGS. 1 and 7). By following the standing order associated with a patient, the medical infusion pump is ensured to deliver drugs and other fluids according to the correct pump protocols and to the right patient.
• FIG. 8 illustrates a flowchart of aprocess800 for verifying a standing order in a medical infusion pump, according to a possible embodiment of the present disclosure. The process provides additional verification of a standing order, as reflected in a programmed pump protocol, and identified by the therapy, qualifier, drug, and other patient information relevant to fluid delivery, to improve error rates and improve the “five rights” accuracy of the medical infusion pump. For example, the medical infusion pump can require a check of the accuracy of the pump protocol (e.g. by comparing the pump protocol to the sensed cartridge inserted in the pump), and can request independent verification of the protocol (e.g. the standing order) from an external computing system.
• Theprocess800 is instantiated at astart operation802, which corresponds to initializing a medical infusion pump for operation. Thestart operation802 includes, for example, associating the medical infusion pump with a patient and powering on the pump. In certain embodiments, thestart operation802 includes communicatively connecting the medical infusion pump with computing systems in an infusion pump network.
• Aprotocol selection module804 selects a protocol for use in a medical infusion pump. Theprotocol selection module804 selects the protocol from among a number of protocols, such as could be found in a library of protocols, as described in conjunction withFIG. 7, above. Theprotocol selection module804 can execute on either the medical infusion pump or a computing system communicatively connected to the medical infusion pump in an infusion pump network, such as thenetwork100 ofFIG. 1 or thenetwork600 ofFIG. 6.
• In some embodiments, theprotocol selection module804 prompts a user (e.g. a nurse, a physician or other clinician) to select a protocol for use in conjunction with a prescribed therapy, or a qualifier for that therapy, or a drug to be delivered to a patient, or all three of these aspects. In other embodiments, theprotocol selection module804 identifies possible protocols for use in conjunction with a drug or therapy, and prompts a user for selection from among a group of possible protocols useable in the medical infusion pump.
• Theprotocol selection module804 results in selection of a protocol useable by the medical infusion pump to accomplish execution of the standing order in accordance with physician direction. However, additional verification of the protocol is required to ensure that a correct protocol has been selected.
• Apump verification module806 verifies that the selected protocol is appropriate based on information available at the pump. Thepump verification module806 verifies a standing order (e.g. a particular use of a pump protocol selected via the protocol selection module804) by displaying for review various aspects of the pump protocol and other information. For example, thepump verification module806 allows a user to view and verify various aspects of a pump protocol, including the various parameters encompassed by the pump protocol and the therapy, qualifier, and/or drug used to select the protocol. Examples of the parameters that are verifiable by a user include a range of permissible basal delivery rates, a bolus amount, a fluid delivery amount, a range of values and patterns for extended boluses, alarm values, or protocols for data communication. Other information can be displayed for verification as well.
• Thepump verification module806 also optionally requires verification that the patient with which the pump is associated is properly associated with the standing order (e.g. a child patient is not being administered an adult dosage, or vice versa), and that the cartridge installed into the medical infusion pump corresponds to the drug and fluid delivery parameters in the pump protocol. Other verification procedures can be performed as well.
• Thepump verification module806 preferably requires a user, such as a healthcare professional, to verify the protocol on the pump in accordance with the standing order. The verification can be performed by visual inspection of the pump parameters, drugs used, and other aspects of the standing order displayed on the medical infusion pump, as is shown in the example display ofFIG. 9. In an alternative embodiment, one or more of the parameters incorporated into the pump protocol can be verified by the medical infusion pump (e.g. the drug, by comparing the protocol to the cartridge inserted into the pump).
• Adisplay module808 displays the protocol to a healthcare professional, such as the nurse, doctor, or other clinician, on a computing system separate from the medical infusion pump. Thedisplay module808 displays a variety of information relevant to the protocol, including various parameters and other information about the patient and manner of delivery. As described in conjunction with thepump verification module806, this information can optionally include the patient's name, as well as a therapy, a qualifier, and a drug to be delivered by the medical infusion pump, as well as parameters for use of that therapy qualifier and drug. These pump parameters can include, in various embodiments, a delivery rate, allowed adjustments to the delivery rate (e.g. hard and soft limits on the rate), allowed refills of the fluid cartridge associated with the pump, the name of the ordering doctor, and other information that is typically included within a standing order for use of a protocol. In certain embodiments, thedisplay module808 displays analogous information to that displayed on the medical infusion pump by theverification module806.
• In a possible embodiment, thedisplay module808 causes the protocol information to be displayed on a display of a computing system communicatively connected to the medical infusion pump, such as a local computing system that is part of an infusion pump network (e.g. the infusion pump network ofFIG. 1). In other embodiments, thedisplay module808 causes the protocol information to be displayed on a display of a computing system remotely located from the medical infusion pump, and requires independent confirmation of at least one aspect of the protocol by another clinician, nurse, doctor, or other healthcare provider (separate from the healthcare provider initializing the pump locally).
• Generally, the computing system displaying the protocol and other information related to programming the medical infusion pump receives a copy of the protocol from the medical infusion pump, and displays the same information as is displayed on the medical infusion pump. However, in certain embodiments, more or less information can be displayed, with sufficient consistency such that the caregiver viewing the protocol on the computing system can determine that the same protocol is referenced on both the computing system and the medical infusion pump. For example, various pump parameters in a named pump protocol could be displayed on the medical infusion pump, but only the name (and possibly a subset of those pump parameters) might be displayed on the computing system. Other arrangements are possible as well.
• Aprompt module810 requests that a healthcare provider confirm the displayed elements of the protocol on the external computing system to again verify that the patient's “five rights” are followed in accordance with the standing order. Theprompt module810 requires an analogous confirmation from a healthcare provider that the protocol programmed into the medical infusion pump is appropriate based on the planned treatment of that patient (e.g. based on the standing order). Aconfirmation receipt module812 corresponds to the medical infusion pump receiving confirmation of the protocol from the external computing system. In one embodiment, the confirmation received from the external computing system is a confirmation message indicating that the protocol is correct; in other embodiments, additional messages, amendments to the protocol, and other operations may be included in the communication to the medical infusion pump.
• Anoperation module814 allows the medical infusion pump to commence operation using the protocol, in accordance with the standing order. In theprocess800, although various of the modules can be executed in different orders, theoperation module814 is reached only after theconfirmation receipt module812 and thepump verification module806. So, two independent confirmations are required of the protocol by a nurse or other caregiver prior to allowing operation of the medical infusion pump. Requiring separate, independent confirmation of pump parameters on the medical infusion pump and on separate computing systems and pumps reduces the likelihood of errors occurring in programming the medical infusion pump, thereby improving patient care. Operational flow in the process terminates at anend operation816, which corresponds to completion of theprocess800 and allowance of the medical infusion pump to initiate or continue operation in accordance with the verified protocol (i.e. in accordance with the standing order).
• FIG. 9 is a schematic view of aninfusion pump network900 configured for dual confirmation of a standing order, according to a possible embodiment of the present disclosure. Theinfusion pump network900 generally corresponds to theinfusion pump network100 ofFIG. 1, but illustrates an embodiment in which confirmation of pump protocols are required prior to operation of a medical infusion pump in accordance with the pump protocol (and associated standing order).
• Theinfusion pump network900 includes amedical infusion pump902 communicatively connected to acomputing system904 via acommunication link906. Themedical infusion pump902 can be any of a variety of medical infusion pumps, such as the one described in conjunction withFIGS. 4-5. Likewise, the computing system can be any of a number of general or specific use computing systems, such as the system described inFIG. 3. Thecommunication link906 can be any of the communication link types described inFIG. 1.
• As illustrated, themedical infusion pump902 includes adisplay908 and a keypad909, and thecomputing system904 also includes adisplay910 and keyboard911. This allows each of these systems to (1) display a pump protocol selected for use in the medical infusion pump and (2) receive confirmation inputs from a user which indicate that the protocol is/is not correct in view of the standing order.
• As shown inFIG. 9, information relating to the protocol is displayed on adisplay908 of thepump902 and adisplay910 of thecomputing system904. The information, as shown, includes a name of the therapy, qualifier, and drug used in selecting the protocol, as well as a duration of operation of the protocol, the name of the patient, and a confirmation prompt. Additional information can be displayed on one or both of the displays, such as information about the pump parameters included in the pump protocol. As previously mentioned, these pump parameters include, for example, a range of permissible basal delivery rates, a bolus amount, a fluid delivery amount, a range of values and patterns for extended boluses, alarm values, or protocols for data communication.
2. Security for Select Features
• Referring now toFIGS. 10-12, systems and methods are disclosed for managing access to various features that can be included in a medical infusion pump. The systems and methods disclosed in these figures operate in conjunction with a medical infusion pump such as is disclosed inFIG. 4-5, as well as any peripheral equipment providing extended functionality to the pump (e.g. a bar code scanner or other peripheral device). By managing access to the various hardware and software features and settings of the medical infusion pump, the pump provides enhanced safety and security, preventing unauthorized users from altering settings of the pump or using the pump in an unauthorized or unsafe manner. Settings managed in the medical infusion pump can include, for example, settings related to pump protocols, pump therapies, qualifiers relating to pump therapies, pump communications settings, user access privileges, security settings, and history data settings. Other settings may be protected and managed using the security systems and access rights protections of the present disclosure.
• FIG. 10 illustrates a flowchart of aprocess1000 for managing access to features in a medical infusion pump, according to a possible embodiment of the present disclosure. Theprocess1000 is instantiated at astart operation1002, which corresponds to initial use of a pump in an infusion pump network.
• Auser association module1004 associates a user with the medical infusion pump, providing access to one or more functional aspects of the medical infusion pump for the user. Theuser association module1004 establishes the user's ability to log in to the medical infusion pump, and grants that user at least default access rights to view screens relating to the current operational status of the pump.
• Theuser association module1004 optionally grants additional access rights to one or more systems and settings in a medical infusion pump to the user. The systems and settings in the medical infusion pump can include to settings in a pump and the user's right to view or modify those settings; the systems and settings can also include various modular hardware or software unrelated to protocol selection. In one possible example of settings modifiable in the pump, theuser association module1004 allows the user to view or modify pump protocols or pump parameters, such as the range of acceptable basal delivery rates, drug delivery patterns, bolus delivery times or frequencies, bolus amounts, or other variables related to fluid delivery to a patient. The user can also be allowed to view and modify other pump parameters. In a possible example of accessible systems in the pump, the access rights granted to the user can relate to a bar code scanner, a drug cartridge, a battery compartment, or certain input keys of the pump.
• In some embodiments, theuser association module1004 operates at least in part on a computing system communicatively interconnected with a plurality of medical infusion pumps. In such embodiments, theuser association module1004 can associate the user with more than one medical infusion pump, thereby allowing the user to establish a single access rights record used by all pumps. In other embodiments, theuser association module1004 operates in each medical infusion pump, and the user is required to establish a usage rights record in each pump.
• Theuser association module1004 optionally associates the user with a user class, with the user class having one or more sets of predetermined access privileges. Each user class is configurable to have different access privileges to functionality in a medical infusion pump, and by associating a user with the user class, that user is afforded the access rights given to that class.
• In certain embodiments, user classes include an administrative user class, a physician user class, a nurse user class, a pharmacist user class, a patient user class, and other user classes. The administrative user class is granted access to all of the functionality available to the medical infusion pump. The other user classes are granted varying access rights, with the patient class generally provided the least access privileges. For example, while the administrative user class or the physician user class has access to modify pump protocols by modifying one or more of the pump parameters, a patient user class will generally not be given such an access right. The access privileges of the user classes are also optionally modifiable in the medical infusion pump (or a computing system interconnected to the medical infusion pump), such as via user access records and user class association records, for example the records ofFIGS. 11-12, below.
• A securitydata association module1006 associates security data with user who is associated with the medical infusion pump. The securitydata association module1006 stores security data that will be used during subsequent use of the medical infusion pump to access functionality by the user. The securitydata association module1006 can associate one or more types of security data with each user, allowing the user to gain access to functionality of the medical infusion pump by providing at least one of those types of security data. Security data is data associated with the user that the user can supply to prove his/her identity to the medical infusion pump. In various embodiments, the security data includes a password, an access code, an answer to a security question, an account number, or biometric data, such as a fingerprint pattern, retina scan, or other authorization data.
• In certain embodiments, one of which is described in greater detail in part B.3, below, the security data is embodied on an access card useable to gain access to functionality in the medical infusion pump. A user can swipe, scan, or press the access card against a portion of the pump capable of reading the security data (e.g. a magnetic card reader, a touch screen, or an optical scanner) to provide security data to the pump.
• In some embodiments, more than one type of security data is accepted. In these embodiments, features of the pump requiring higher security may require multiple types of security data prior to granting access to functionality. For example, a user can be required to enter a password and provide a thumbprint scan to gain access to certain functionality in the medical infusion pump. Other possibilities regarding functionality or combinations of security data are possible as well.
• A securitydata receipt module1008 receives security data from the user on a subsequent access attempt in the medical infusion pump. The securitydata receipt module1008 receives security data of a number of forms, corresponding to the security data associated with the user by the securitydata association module1006. The securitydata receipt module1008 also compares the received security data to the stored security data associated with the user to determine whether a match exists. If a match between the security data exists, operational flow in theprocess1000 proceeds to an accessrights determination module1010. If no match exists, no access rights are afforded to the user.
• The accessrights determination module1010 determines the particular functionality accessible to the user, based on the rights established in theuser association module1004. These access rights correspond to the functionality in the medical infusion pump, relating both to mechanical or electrical systems and software settings incorporated into the pump, as previously described. The securitydata receipt module1008 and the accessrights determination module1010 can, in certain embodiments, determine access rights based on information in a user access record or user class association record, an example of which is described in conjunction withFIGS. 11-12. In such an embodiment, theuser access record1100 is accessed by the securitydata receipt module1008 to determine a match between the one or more types of security data provided by the user and the security data previously associated with the user. Once that match is determined, access rights are established by the accessrights determination module1010, either by reviewing specific access rights granted to the user in theuser access record1100 or by reviewing access rights granted to a user class (of which the user is a part) in the userclass association record1200.
• Anaccess module1012 operates following the accessrights determination module1010 to allow access to a user in accordance with the access rights associated with that user. Theaccess module1012 only allows access to the various systems and settings in the medical infusion pump that are associated with access rights granted to the user (e.g. through listing in a user access record or a user class association record as inFIGS. 11-12). An optionalaccess denial module1014 denies access to the user relating to one or more software or hardware/mechanical systems with which that user's usage rights are not associated.
• In an example of operation of theaccess module1012 and theaccess denial module1014, a patient will generally be afforded access rights to certain pump menus and pump settings, allowing the user to administer a bolus or to view operational status of the medical infusion pump with which that patient is associated. The patient can have personalized security data (e.g. an access code or password) or can use a generalized patient login access account. That patient will not be able to access functionality related to certain aspects of the medical infusion pump, such as to edit pump protocols, to use a bar code scanner, or other systems, based on operation of the access denial module. These access rights, however, may be afforded to other users, such as nurses, doctors, or pharmacists. Theprocess1000 terminates at andend operation1016, which corresponds to continued operation in accordance with the determined access rights for the user of the pump.
• Now referring toFIGS. 11-12, additional details regarding the contents of theuser access record1100 and userclass association record1200 are described, in accordance with an example embodiment of the present disclosure.FIG. 11 illustrates example contents of auser access record1100 that is used to store and validate security data received from and associated with a user having an account to log in to a medical infusion pump.
• Theuser access record1100 includes one ormore user entries1102, each of which corresponds to a separate individual having a right to log in to and access information on a medical infusion pump. Eachuser entry1102 includes auser name field1104, one or more security data fields1106 associated with that user, and one or more accessright fields1108 associated with theuser entry1102. Theuser name field1104 corresponds to the name of the individual logging in to the pump, while thesecurity data fields1106 include the various security data associated with that user, such as an access code, password, bar code, or biometric data.
• The accessright fields1108 define the access rights available to a user. The various listed access rights allow different levels or combinations of access rights to settings and systems in the medical infusion pump. In the example shown, various named access rights are listed in the user access record, including an administrative access right, a program access right, a bolus access right, and other access rights. The administrative access right (shown as associated with a user having the name “John Doe”) provides full access to view and amend pump protocols, and access to all of the hardware and mechanical features of the medical infusion pump. The program access right allows a user to view the various software features in the medical infusion pump, and to initiate use of a new pump program or protocol in the medical infusion pump. This right may be given, for example, to a nurse who will be required to program the medical infusion pump in accordance with a doctor's order. The program access right may not allow the nurse or other user to alter the parameters included in pump protocols (as would be allowed to a user having an administrative access right), but would allow the user to select a pump protocol for programming the pump. The bolus access level allows a user to administer boluses of the drug or other therapeutic fluid delivered by the pump. This access right can be given, for example, to a patient for management of bolus delivery, without allowing the patient an access right to program the medical infusion pump or alter the pump protocol operating on the medical infusion pump (as would be included in the program access right and the administrative access right).
• Theuser entry1102 also optionally includes one or moreuser class fields1110 which list the user classes to which the user entry (and corresponding user) belongs. Theuser class fields1110 provide a reference link within the user access record to a user class association record, such as therecord1200 ofFIG. 12. By associating a user with a user class, that user is afforded the access rights of the class with which they are associated.
• A user can be associated with more than one access right or class in theuser access record1100. If any of the access rights or classes in the user access record allow the user to perform an action (e.g. altering pump protocols, programming the pump), that user is allowed to perform that action in the medical infusion pump.
• FIG. 12 shows an example configuration of a userclass association record1200, which includes one or moreuser class entries1202. Each of theuser class entries1202 corresponds to a separate user class associated with one or more access rights. Theuser classes1202 listed in the userclass association record1200 allow common combinations of access rights granted to be grouped into a record for ease of use and assignment to users. For example, all doctors will typically be afforded equal access rights to medical infusion pumps. Similarly, patients will all be afforded similar access rights, but those access rights will be different from (more restrictive) than those afforded to doctors. Similar access right distinctions can be made for nurses, pharmacists, or other clinicians.
• Eachuser class entry1202 is associated with one or more member entries1204 and one or moreaccess rights entries1206. The member entries1204 correspond to users who are members of the class and are designated to receive the access rights of the class; for example, the member entries can correspond to theuser entries1102 of theuser access record1100. Theaccess rights entries1206 define the access rights associated with theuser class entry1202, and by reference each user identified in the member entries1204.
• Referring now toFIGS. 11-12 generally, in one embodiment, theuser access record1100 and userclass association record1200 can be stored on and managed by a medical infusion pump. In a further embodiment, theuser access record1100 and userclass association record1200 are stored on a computing system communicatively interconnected to one or more medical infusion pumps, as is described in conjunction with the networks ofFIGS. 1-2 and6-7, above.
• The access rights afforded to users of the medical infusion pump are optionally definable by editing therecords1100,1200 using the medical infusion pump or a computing system on which the records reside. Therecords1100,1200 are generally editable by users having administrative access to the pump; certain user entries may also be editable by the user identified by that entry.
• Theuser access record1100 and userclass association record1200 are depicted as text files that can be stored in a memory of the medical infusion pump or a computing device. However, these records can be configured in a number of alternative formats to that depicted inFIGS. 11-12. In one alternative embodiment, one or both records are stored in a relational database, and can be interrelated to other user records, stored security data (e.g. fingerprint profile files), or other information relevant to access of systems and settings in a medical infusion pump. In a further embodiment, the records are stored as a text file or spreadsheet file, and maintained within a single record file. Other storage configurations are possible as well.
3. Touch Screen User Authentication
• Referring now toFIGS. 13-15, a system for user authentication is described, using a touch screen display integrated into the medical infusion pump. The touch screen display in the medical infusion pump can be, for example, any display described above in conjunction with thedisplay406 ofFIG. 4. The systems described herein can be used in conjunction with the security features of part B.2, above, to authenticate a user in conjunction with security data relating to an input signal received from the touch screen display.
• FIG. 13 illustrates a flowchart of aprocess1300 for authenticating a user in a medical infusion pump using a touch screen display. The process generally allows a user to touch a display of a medical infusion pump with a hand, keyed card, or other object to validate the identity of the user and allow the user access to various features in the medical infusion pump. Theprocess1300 is instantiated at astart operation1302.
• Asignal association module1304 associates a signal with a user or user class, and stores a representation of that signal for comparison and authentication of signals received from a user seeking access to features of the medical infusion pump. The signal is generally an analog or digital electrical signal received from a touch screen display of a medical infusion pump. The signal can, in various embodiments, corresponds to a pattern or sequence of touches or motions by a user, or by an object carried by the user. In one example embodiment, the signal corresponds to a digital or analog signal received from a touch-sensitive display based on contact with a keyed, shaped access card, as shown inFIG. 15, below. In a further example embodiment, the signal corresponds to a signal generated in response to a biometric scan, such as a scan or capture of an image of the user, a fingerprint of the user, or other biometric scan information.
• The user or user class can be any user or class registrable in the medical infusion pump, such as those described above inFIGS. 10-12. Example users or classes of users include doctors, nurses, patients, pharmacists, technicians, or and clinicians who use, program, repair, or otherwise interact with the medical infusion pump.
• In a possible embodiment, thesignal association module1300 associates a generalized signal, such as a known touch action on a touch screen display, with a generalized or default access account on the medical infusion pump (e.g. a default account created in user records as described above inFIGS. 10-12). In such an embodiment, a user touching the display will cause the display to generate the generalized signal and receive access to the medical infusion pump in accordance with the access rights assigned to that generalized or default access account.
• Asignal receipt module1306 corresponds to receiving a signal in the medical infusion pump from a display. In some embodiments of the present disclosure, thesignal receipt module1306 receives a signal from a touch screen display, such as a multi-touch display or other type of display described in conjunction withFIG. 4. Thesignal receipt module1306 generally receives an analog signal from the display (e.g. based on contact with a touch screen display) and optionally converts that analog signal to a digital signal for comparison with a stored value associated with the user by thesignal association module1304.
• Asignal evaluation module1308 compares the signal received by thesignal receipt module1306 with a stored signal associated with a user or a generalized access account to authenticate the user. Thesignal evaluation module1308 verifies the identity of the user based on the signal. For example, thesignal evaluation module1308 can compare digital values generated based on a signal with a stored digital value based on a prior signal, as discussed in conjunction withFIGS. 14-15. If the user is recognized by thesignal evaluation module1308, access rights are granted to that user in accordance with the access rights and user record associated with the signal. In certain embodiments, if the user is not recognized by thesignal evaluation module1308, access is denied to the user.
• Anaccess module1310 grants access to a user in accordance with one or more access rights associated with a user record. Examples of access rights and user records are described above in conjunction withFIGS. 10-12. Theprocess1300 terminates at an end operation1312, which corresponds to generalized operation of the medical infusion pump by the user, in accordance with the authorized access rights afforded to that user.
• FIG. 14 illustrates a touch screenuser authentication record1400 useable in a medical infusion pump, according to a possible embodiment of the present disclosure. The touch screenuser authentication record1400 generally corresponds to the user access record ofFIG. 11, but includes information relating to touch screen user authentication systems useable in the medical infusion pump. The touch screenuser authentication record1400 includes a plurality ofuser records1402, each of which includes auser field1404, one or morekey fields1406, and optionally one ormore association fields1408 or one or more user rights fields1410. Eachuser record1402 corresponds to access methods associated with a user, for use in a medical infusion pump having a touch screen authentication system.
• Theuser field1404 corresponds to the name of the user, and can be used as the name of the user record as well. Thekey fields1406 correspond to the signals receivable by the system that would be recognized as a user attempting to use the medical infusion pump. In the embodiment shown, the signals are illustrated as being stored as two types: digitized codes and images of biometric scans. Other types of signals, such as analog signals, could be captured as well by storing certain signature characteristics of those signals. In a possible embodiment of a medical infusion pump using a keyed access card pressed against the touch screen for user validation (e.g. the system ofFIG. 15), the digitized codes in thekey fields1406 correspond to the key ridge codes of the access card. An example of an access card and corresponding touch screen digitized code is shown inFIG. 15.
• The association fields1408 generally correspond to the user class fields described above in conjunction withFIGS. 10-11, but can also include common authentication data used by groups of users. In certain embodiments, the association fields refer to groups of users sharing at least one common key field. Using that common key field, users in the user class can access settings and systems in the medical infusion pump according to the common access rights of that user class.
• Theuser rights fields1410 correspond generally to the access rights described in the records ofFIGS. 10-11, and define access rights for one or more users associated with information in the key fields of thesame user record1402. Alternatively to including theuser rights fields1410 in the touch screenuser authentication record1400, the system can link to user rights in a user access record or user class association record, such as are described above in conjunction withFIGS. 10-11.
• Theuser authentication record1400 as described herein is intended as an example embodiment of a data structure in which access rights and security data can be managed. As with therecords1000,1100, the touch screenuser authentication record1400 can include various other information, or can be embodied in a variety of other formats of databases or other data structures.
• FIG. 15 illustrates amedical infusion pump1500 having a touch screen operable for user authentication, according to a possible embodiment of the present disclosure. Themedical infusion pump1500 generally corresponds to the medical infusion pumps described in FIGS.1 and4-5, and includes a touchscreen user interface1502, and soft keys1504a-d. The touchscreen user interface1502 is any of a variety of types of touch-sensitive interfaces such as those described above in conjunction with thedisplay406 ofFIG. 4.
• In the embodiment shown, the touchscreen user interface1502 includes one or more regions1506a-bconfigured to accept a touch from a user, access card, or other keyed access method applied to the display, and generate a signal in response to that touch for the purposes of user authentication. Specifically shown are afingerprint region1506aand a keyedaccess contact region1506b;however, other regions can be included as well. Thefingerprint region1506aacts as a fingerprint reader for the medical infusion pump, and can be integrated into thedisplay1502 or a separate display region. Thefingerprint region1506areceives a fingerprint and generates an analog signal or captures an image of the fingerprint (based, for example, on pressure or imaging) for authentication using a key in a touch screen user authentication record, such as therecord1400 ofFIG. 14. The keyedaccess contact region1506baccepts contact with akeyed access card1510, which includes akeyed pattern1512 on at least one edge of the card. Thekeyed pattern1512 corresponds to a digital code stored in an authentication record (e.g. therecord1400 ofFIG. 14) to authenticate a user who is a holder of thekeyed access card1510. When thekeyed pattern1512 is depressed against the keyedaccess contact region1506b,a signal is generated by the display representative of a code identifying the user, thereby authenticating that user's access to the systems and settings of the medical infusion pump.
• The soft keys1504a-dprovide an alternative method of controlling the pump, allowing a user to key in an access code or other options (e.g. confirming the touch access) during the authentication process, as required.
• The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Claims (25)

1. A method of verifying a standing order in a medical infusion pump, the method comprising:

selecting a protocol for execution of a standing order in a medical infusion pump;

verifying the protocol in the medical infusion pump;

receiving confirmation of the protocol from a system external to the medical infusion pump; and

upon receiving confirmation of the protocol, allowing operation of the medical infusion pump in accordance with the protocol.

2. The method ofclaim 1, wherein the protocol includes one or more pump parameters selected from the group consisting of:

a range of permissible basal delivery rates;

a bolus amount;

a fluid delivery amount;

a range of values and patterns for extended boluses;

alarm values; and

protocols for data communication.

3. The method ofclaim 1, wherein selecting the protocol further comprises selecting a therapy.

4. The method ofclaim 1, wherein selecting the protocol further comprises selecting a qualifier.

5. The method ofclaim 1, wherein selecting the protocol further comprises selecting a drug.

6. The method ofclaim 1, further comprising displaying one or more parameters associated with the protocol on a display separate from the medical infusion pump.

7. The method ofclaim 1, wherein verifying the protocol in the medical infusion pump includes receiving confirmation of the protocol from a healthcare provider.

8. The method ofclaim 1, wherein receiving confirmation of the protocol includes receiving confirmation of at least one patient-specific parameter selected from a group of parameters consisting of:

patient identity;

drug identity;

time of drug application;

dosage; and

route.

9. The method ofclaim 1, further comprising prompting a user for confirmation of the standing order on a display of the system external to the medical infusion pump.

10. A medical infusion pump comprising:

a pump mechanism;

a memory;

a programmable circuit arranged to control the pump mechanism and operatively connected to the memory, the programmable circuit programmed to:

select a protocol for execution of a standing order in a medical infusion pump;

verify the protocol in the medical infusion pump;

receive confirmation of the protocol from a system external to the medical infusion pump; and

upon receiving confirmation of the protocol, allow operation of the medical infusion pump in accordance with the protocol.

11. The medical infusion pump ofclaim 10, wherein the protocol includes one or more pump parameters selected from the group consisting of:

a range of permissible basal delivery rates;

a bolus amount;

a fluid delivery amount;

a range of values and patterns for extended boluses

alarm values; and

protocols for data communication.

12. The medical infusion pump ofclaim 10, wherein allowing operation of the medical infusion pump in accordance with the protocol comprises initiating delivery of fluids to a patient in accordance with a standing order.

13. The medical infusion pump ofclaim 10, wherein the programmable circuit is further programmed to prompt a user for confirmation of the protocol.

14. The medical infusion pump ofclaim 10, wherein the programmable circuit is programmed to receive the protocol from a computing system external to the medical infusion pump.

15. The medical infusion pump ofclaim 14, wherein the programmable circuit is programmed to request the protocol from a protocol library stored on a server.

16. The medical infusion pump ofclaim 10, wherein receiving confirmation of the protocol includes receiving confirmation of at least one aspect of the pump protocol, the at least one aspect selected from a group of aspects consisting of

patient identity;

drug identity;

time of drug application;

dosage; and

route.

17. The medical infusion pump ofclaim 10, wherein the protocol is selected using protocol selection categories consisting of:

therapies;

qualifiers; and

drugs.

18. An infusion pump network comprising:

a medical infusion pump;

a computing system communicatively connected to the medical infusion pump;

wherein the infusion pump network is configured to execute program instructions to:

select a protocol for execution of a standing order in a medical infusion pump;

verify the protocol in the medical infusion pump;

transmit confirmation of the protocol from the computing system to the medical infusion pump; and

upon receiving confirmation of the protocol in the medical infusion pump, allow operation of the medical infusion pump in accordance with the protocol.

19. The infusion pump network ofclaim 18, wherein the protocol is selected using protocol selection categories consisting of:

therapies;

qualifiers; and

drugs.

20. The infusion pump network ofclaim 18, wherein the protocol includes one or more pump parameters selected from the group consisting of:

a range of permissible basal delivery rates;

a bolus amount;

a fluid delivery amount;

a range of values and patterns for extended boluses;

alarm values; and

protocols for data communication.

21. The infusion pump network ofclaim 18, wherein the computing system is configured to prompt a user for confirmation of the standing order.

22. The infusion pump network ofclaim 18, wherein medical infusion pump includes:

a pump mechanism;

a memory;

a programmable circuit arranged to control the pump mechanism and operatively connected to the memory, the programmable circuit programmed to, upon receiving confirmation of the protocol, deliver fluids to a patient via the pump mechanism according to the protocol.

23. The infusion pump network ofclaim 22, wherein the programmable circuit is further programmed to prompt a user for confirmation of the protocol.

24. The infusion pump network ofclaim 18, wherein the computing system is directly linked to the medical infusion pump.

25. The infusion pump network ofclaim 18, wherein receiving confirmation of the protocol includes receiving confirmation of at least one aspect of the pump protocol, the at least one aspect selected from a group of aspects consisting of:

patient identity;

drug identity;

time of drug application;

dosage; and

route.

Images