Patent Application
20170161460
The present invention relates to medical pumps and in particular to a system for facilitating development of custom applications for medical pump hardware.
Medical pumps, such as syringe pumps or peristaltic infusion pumps, are known for computer-controlled delivery of medication or contrast agents (henceforth medicaments) to patients over a period of time. Typically the medicament is delivered in a syringe (for a syringe pump) or a flexible bag (for peristaltic infusion pump, or ambulatory pump) that may be connected to an IV line and attached to a needle inserted into the patient. When a nurse or other healthcare professional ministering to the patient receives the medicament, the healthcare professional reviews the medicament description for correctness and enters the desired dose and rate into the pump. Other pump parameters such as alarm limits and the like may also be programmed at this time. The syringe or IV line must then be mechanically connected to the pump mechanism, the needle introduced into the patient, and the mechanism activated to begin pumping.
Medical pumps provide a platform for the controlled delivery of medicaments and as such are potentially useful in a wide variety of different medical procedures.
The use of medical pumps is limited by the availability of appropriate control software and the complexity of entering operational parameters for more than a simple medicament delivery schedule (e.g., flow rate and total volume). Some medical pump applications are common enough to justify the manufacture of specialized pumps for particular procedures, hut this approach, which results in many specialized pumps, has significant drawbacks to organizations which must manage multiple pumps for a wide variety of conditions. These organizations, including hospital and outpatient healthcare provider services, often operate many different pump designs and versions.
The present invention provides a medical pump that facilitates the development of third-party application programs for medical pumps in a manner roughly analogous to the development of application programs for smart devices such as cell phones and tablets. The medical pump provides both an application loader program that simplifies the receipt and display of developed application programs, and an operating system that presents abstractions of the hardware of a medical pump to permit cross platform development encouraging the development of application program. Using this system, an individual healthcare provider may develop and/or download one or more application programs that may be certified to operate the pump correctly. Selecting a specialized application program avoids the need for complex reconfiguration of a “one-size-fits-all” pump control program with multiple manually entered parameters that vary from pump to pump.
In one embodiment, the invention provides a medical pump having a housing holding hardware elements including: (i) an electrical pump for receiving an IV line controlling a flow of liquid medicament therethrough; (ii) one or more sensors for sensing pump conditions; and (iii) an electronic user interface providing a display and keyboard.. An electronic memory holds an operating system and application loader program and an electronic computer communicating with the hardware dements and electronic memory and executing the operating system and application loader program to: (1) receive one or more application programs for loading into the electronic memory; (2) display representations of the application programs on the display for executing by user input to the keyboard; and (3) communicate between the application program and the hardware elements through the operating system, the latter providing a set of standardized hardware interfaces to the hardware elements providing identical abstractions of features of multiple different hardware elements among different medical pumps.
It is thus a feature of at least one embodiment of the invention to greatly expand the pool of available software for medical pumps in order to promote application programs that can better leverage the scarce time of healthcare professionals.
The standardized hardware interfaces may include a standard session interface exchanging information between an application program and the hardware elements to coordinate among a pump and, at least one sensor for sensing fluid flow to provide a patient treatment session for an individual patient.
It is thus a feature of at least one embodiment of the invention to provide standardized interfaces that can combine multiple hardware elements and in particular to provide a standardized hardware interface relevant to the primary functions of medical pumps to simplify the development of application programs.
The session interface may include a standard error event exchanging information between an application program and the hardware elements to coordinate a stopping of the pump in the event of a predetermined error condition related to the flow of medicament determined by a sensor.
It is thus a feature of at least one embodiment of the invention to free the application, programmer from the necessary analysis of possible error conditions such as may require specialized expertise.
The application loader program may operate to load application programs into the electronic memory only if the application programs include embedded authentication data,
It is thus a feature of at least one embodiment of the invention to provide _a balance between improving the freedom to develop application programs for pumps and needing to ensure safety in the operation of the pumps by the application programs. The authentication data permits a certificate process to be implemented.
The application loader program may operate to load multiple application programs and display the multiple application programs in a hierarchical menu structure on the display, each application program independently operable to control the medical pump for patient treatment.
It is thus a feature of at least one embodiment of the invention to permit individual pumps to be rapidly programmed by selecting among application programs.
The medical pump may include a wireless receiver and the application loader program may receive application programs wirelessly.
It is thus a feature of at least one embodiment of the invention to allow central coordination of multiple pumps at a facility through a wireless downloading process.
The application loader program may compare the standardized hardware interfaces used by the application program to standardize hardware interfaces available on the medical pump before receiving an application program.
It is thus a feature of at least one embodiment of the invention to permit the unencumbered dissemination of advanced applicable programs without concern even if those programs may not be universally able to operate on legacy medical pumps.
The standardized hardware interface may provide a plurality of software objects associated with the hardware elements, the objects providing object properties having values describing operation of the hardware elements, object methods having sequences of steps for controlling the hardware elements, and object events having test conditions receiving information from the hardware elements to trigger outputs to the application programs.
It is thus a feature of at least one embodiment of the invention to employ an object model for generation of the standard interface such as permits the use of advanced programming languages.
The software objects may include: a pump object, at least one sensor object, a data logging object, a display object, a keyboard object; and an error object.
It is thus a feature of at least one embodiment of the invention to provide fundamental building blocks for medical pump applications.
The data logger object may record the digital signature of the application program.
It is thus a feature of at least one embodiment of the invention to expand the development of application programs while preserving traceability necessary for medical devices.
The software objects may include a session object coordinating the electrical pump and the one or more sensors according to a timer.
it is thus a feature of at least one embodiment of the invention to provide a multi-hardware abstraction for the basic operation of the medical pump greatly simplifying the development of application programs.
The standardized hardware interface may limit the operating conditions of associated hardware elements independently of data received by the application programs.
It is thus a feature of at least one embodiment of the invention to use the standardized interface to free the application programmer from concern about the operating parameters of a variety of different types of hardware.
The application loader program may further operate to remove one or more application programs from the electronic memory.
It is thus a feature of at least one embodiment of the invention to simplify the addition and removal of application programs so that the application program suite may be adjusted by particular institutions to meet their needs.
It should be understood that the invention is not limited in its application to the details of construction and arrangements of the components set forth herein. The invention is capable of other embodiments and of being practiced or carried out in various ways. Variations and modifications of the foregoing are within the scope of the present invention. It also being understood that the invention disclosed and defined herein extends to all alternative combinations of two or more of the individual features mentioned or evident from the text and/or drawings. All of these different combinations constitute various alternative aspects of the present invention. The embodiments described herein explain the best modes known for practicing the invention and will enable others skilled in the art to utilize the invention.
Referring now to
The pump compartment 14 may provide a pump 23 exposing peristaltic pump elements 26 controlled by a pump element actuator 27 and through which the IV line 20 may be threaded for controllably pumping, liquid therethrough according to techniques understood in the art. Generally, each peristaltic pump element 26 may compress a short successive segment of the IV line 20 (for example, according to two or more square wave pulse pulses shifted by 90° with respect to one another) to pump fluid along the IV line 20,
A section of the IV line 20 fitting within the pump elements 26 may be specially constructed of a highly flexible silicone material. For example, the IV line 20 may be a highly compliant material that may be sterilizable and is, preferably, non-Pyrogenic, non-DEHP and latex free. One such material is silicone rubber which provides for high compliance as will be desired for pressure sensing to be described below. Another example is non-DEHP PVC material.
Also positioned within the pump compartment 14 are one or more pressure sensors 28 providing for IV line pressure before and after the pump elements 26 and before the needle 22. The sensors 28 are placed adjacent to the IV line 20 for the detection of occlusion as is generally understood in the art. A bubble sensor 29 may also be provided adjacent to the IV line 20 for the detection of bubbles within the IV line 20, and an IV line presence sensor 31 may be positioned in the pump compartment 14 for determining whether the IV line 20 is properly seated within the pump compartment 14 and received by the sensors 28, 31 and peristaltic pump elements 26.
Referring still to
In general, the processor 32 may execute the application programs 38 which communicate through a standardized interface (as will be discussed below) contained in the operating system program 36 to connect with various hardware elements of the infusion pump 10 as mediated by the processor 32. For example, the application programs 38 in this manner may control the pump dements 26 in the pump compartment 14 to provide the desired dose and delivery rate to the patient, for example, by providing successive compressing elements for peristaltically moving fluid through the IV line 20. Application programs 38 may further communicate with the pressure sensors 28 of the present invention for receiving a signal therefrom to monitor pressure in the IV line 20 for detection of upstream or downstream obstruction of the IV line 20 by monitoring a time signature of the pressure waveform from the sensor 28. Application programs 38 may also communicate with the bubble sensor 29 and IV line presence sensor 31 to detect possible error conditions under which operation of the pump should cease.
The application programs 38 may also communicate via processor 32 with a display 41, for example, an LCD display, for displaying various programming and operating parameters and a switch array/keyboard 40 for inputting data, for example, for programming or initiating or stopping of the pumping action. It will be appreciated that any keyboard may be used for the keyboard 40 including, for example, a touchscreen. In addition the processor 32 may communicate with the wireless transceiver 42 and RFID tag reader 44, the latter for confirming patient or user identities or other local information and the former used for downloading application programs 38 or communicating information to a remote site.
Referring now to
As depicted in
For example, the hardware objects 52 may include a pump object 52a uniquely associated with the pump 23, a keyboard object 52b uniquely associated with the keyboard 40, sensor objects 52c associated with a particular sensor 28, 29, or 31, and a display object 52d associate with the display 41. These hardware objects 52 will each include several standard functions. First, they will perform a range checking to make sure that the commands provided through the object 52 from the application program 38 to a hardware element, in the form of a command, are within the range of the hardware. So, for example, a flow delivery rate requested by an application program 38 for pump 23 will be checked to ensure that it can be implemented by the particular hardware of the pump 23. If not, this command will be automatically trapped as an error communicated from an error object to he discussed below, or modified to fit within the operating range of the hardware. This latter situation illustrates a second standard function provided by objects 52 which is to translate, to the extent possible, commands received from application programs 38 into usable ranges for the specific hardware of the pump 10 and, in the opposite direction, to translate signals received from hardware of the pump 10 into a standard set of ranges understood by the all application programs 38. Thus, for example, different sensors 28 may provide for a different range of voltage outputs which objects 52c can translate into a common pressure range.
The hardware objects 52 can also encapsulate standard functions usable with the hardware, for example, ramping up the pump speed and ramping down the pump speed according to set parameters, checking for pump errors, tom example, pump stall conditions or overheating, and providing the necessary events, for example, error events.
The task objects 54 generally provide interfaces with multiple hardware elements in useful combinations tailored to medical pumping applications. For example, the task interfaces 54 may include an authentication task object 54a providing method events and properties related to authenticating the patient, the pump settings, the medicament, and the supervising healthcare professional. Authentication methods may include receiving authorization codes from a user (if desired for confirmation of the patient), for example, through the REED tag reader 44, determining that current application program 38 is up to date, for example, determined through wireless transceiver 42, determining that the IV line 20 is properly installed with the door closed using sensor 31, and determining that the proper medicament has been loaded, for example, as detected by a tag read by RFID tag reader 44.
A session object 54b may provide for coordination of various hardware elements to provide a drug delivery session, for example, having a duration, a flow rate, and total flow volume. The session object 54b differs from the pump object 52 in that it may include communication with timer objects, for example, making use of hardware timers in the processor 32 as well as the sensors (for example, flow sensors 28) and control of the pump 23.
The invention may also provide a data logger object 54c that provides real-time logging of the operation of the pump 10 including values from the sensors and pump synchronized to time from the processor 32. The data logger object 54c may also log errors, as will be discussed below, and the identity of the application programs 38 for the purpose of identifying possible failures that may be linked to application programs 38 for the purpose of quality improvement.
As noted above, error task object 54d may provide for an object that handles the detection and reporting of errors in the operation of the pump 10. Importantly, the error task object 54d may generate a variety of predefined events related to hardware or operating errors that can be predefined to relieve the application programmer of this task and to eliminate the need for the application programmer to understand the various hardware error conditions that may result from certain methods. The error task object 54d may provide for standard reporting through the display 41 and wireless transceiver 42.
As with the other objects, the application programs 38 may make use of this object 54d by instantiating it, setting its properties, and trapping its events and invoking its methods as is generally understood in the art.
The invention may also include a suite object 56 that helps manage multiple application programs 38 by communicating with the application loader program 39 to register and display various application programs 38. The suite object 56 may be invoked by the user, as well as communicate with the application programs 38 to provide for management of multiple application programs 38 permitting the user to select and load individual application programs 38 from a set of application programs 38 held in the pump 10 for execution by the pump 10. By selecting application program 38, pre-defined and specialized pump operations dictated by the loaded application program 38 can be obtained.
Generally the suite object 56 will also operate to display the available application programs 38 in hierarchies and be labelled to identify each application program 38 on the display 41 or the like. In use, each pump 10 may display a range of different application programs 38 in a tree structure listing their purpose and application so that the user may quickly identify a needed application and invoke that application for a particular medical procedure. The application programs 38 when loaded may invoke the suite object 56 to install their identifications and an icon or the like.
The suite object 56 may also control the launching, of application programs 38 to be limited to particular users through, for example, authorization codes, and may further control the visibility of different application programs 38 in the hierarchy according to the user's authorization level. Generally the suite object 56 allows different pumps 10 to present different application programs 38, for example, to limit some pumps to particular applications. In this regard, suite object 56 from different pumps 10 may communicate using the wireless transceiver 42 to facilitate an institution-wide management of various application programs 38 on different pumps 10 so that different pumps 10 may present different application programs 38.
A remote object 76 may also be provided providing the ability of a programmer to make use of a remote communication protocol (for example, Bluetooth or other wireless protocols) to communicate with a remote user interface such as a cell phone or desktop computer and in this way tap into the functional resources 59 of that remote user interface when those features are not available in the pump 10. For example, the remote user interface may provide resources 59, such as a superior screen or keyboard or the ability to be mobile. In this way, legacy pumps 10 or a wider variety of pumps 12 may work with application programs that require more sophisticated user interfaces that may only be available on some pumps or relatively high-end or new pumps 12.
Referring now to
if the signature on an application program 38 being loaded by the application loader program 39 is not correct, an error condition is invoked and the user informed by error process block 64 of that error. This error condition may be displayed locally at the pump 10 and/or at the remote site controlling the downloading.
At decision block 66, if the digital signature order is correct, decision block 62 checks to see that the necessary objects needed by the application program 38 are available in the given pump 10. It should be noted that the necessary objects may be available even if the physical hardware is not available to the extent that existing physical hardware can implement the function of the missing hardware element through an object. So for example, the application program 38 may require an IV line 20 presence sensor which is not available in the pump 10 but whose function may be implemented by the pressure sensor which detects the lack of an IV line through a zero pressure level. So long as the object is available, the application program 38 can work whether or not the particular underlying hardware is available.
If the needed object is not available, as determined at decision block 66, the application loader program 39 proceeds to the error process block 64. Otherwise at process block 70, the hierarchy of application programs 38 displayed on the display 48 is updated allowing user to select the new application program 38 from among other application programs 38 on the pump 10 using the suite object 56.
Referring now to
Referring now to
In this case, the application program 38 may have a preset data table 88, for example, providing expert settings for that particular procedure associated with the application program 38. These default settings are possible because of the narrow focus of the application program 38. Thus, for example, a display 90 of the pump 10 (or of a remote device as will be discussed below) may provide a very simple hierarchy showing each of a limited number of procedures 86 that the pump 10 can implement. Each procedure 86 may be a different application program 38 or a single application program 38 nevertheless limited in purpose.
Because the procedures 86 have narrow focus, settings 92 for each procedure may be predetermined by the programmer and may be automatically loaded from the preset data table 88 when the procedure 86 is invoked. In one option, these settings 92 may be displayed in a table on the display 90 that is pre-populated with recommended values for the procedure and yet which allows adjustment by the user if desired. It is anticipated that in many cases most settings 92 of the pump 10 for the given procedure 86 can be used as presented. Some settings will be specific to the patient, for example, patient specific data such as weight, but these may be quickly entered.
Referring to
Certain terminology is used herein for purposes of reference only, and thus is not intended to be limiting. For example, terms such as “upper”, “lower”, “above”, and “below” refer to directions in the drawings to which reference is made. Terms such as “front”, “back”, “rear”, “bottom” and “side”, describe the orientation of portions of the component within a consistent but arbitrary frame of reference which is made clear by reference to the text and the associated drawings describing the component under discussion. Such terminology may include the words specifically mentioned above, derivatives thereof, and words of similar import. Similarly, the terms “first”, “second” and other such numerical terms referring to structures do not imply a sequence or order unless clearly indicated by the context.
When introducing elements or features of the present disclosure and the exemplary embodiments, the articles “a”, “an”, “the” and “said” are intended to mean that there are one or more of such elements or features. The terms “comprising”, “including” and “having” are intended to be inclusive and mean that there may be additional elements or features other than those specifically noted. It is further to be understood that the method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.
References to “a microprocessor” and “a processor” or “the microprocessor” and “the processor,” can be understood to include one or more microprocessors that can communicate in a stand-alone and/or a distributed environment(s), and can thus be configured to communicate via wired or wireless communications with other processors, where such one or more processor can be configured to operate on one or more processor-controlled devices that can be similar or different devices. Furthermore, references to memory, unless otherwise specified, can include one or more processor-readable and accessible memory elements and/or components that can be internal to the processor-controlled device, external to the processor-controlled device, and can be accessed via a wired or wireless network.
It is specifically intended that the present invention not be limited to the embodiments and illustrations contained herein and the claims should be understood to include modified forms of those embodiments including portions of the embodiments and combinations of elements of different embodiments as come within the scope of the following claims. All of the publications described herein, including patents and non-patent publications, are hereby incorporated herein by reference in their entireties.
