Patent Application
20180322948
Embodiments relate generally to communication and control devices, systems and methods for medical devices and, more particularly, to devices, systems, and methods providing push alerts to infusion pumps and related devices.
In the medical arts, medical devices such as infusion pumps have been useful for managing the delivery and dispensation of prescribed amounts or doses of drugs, fluids, fluid-like substances, or medicaments (hereinafter, collectively, “infusates”) to patients. Infusion pumps can provide some significant advantages over manual infusion techniques, by accurately delivering and dispensing infusates over an extended period of time. Infusion pumps are particularly useful for treating diseases and disorders that require regular pharmacological intervention, including cancer, diabetes, and vascular, neurological, and metabolic disorders. They also enhance the ability of healthcare providers to deliver anesthesia and manage pain. Infusion pumps are used in various settings, including hospitals, nursing homes, and other short-term and long-term medical facilities, as well as in residential care settings. Infusion pumps can include various constructions, modes of operation, and types. Generally, infusion pumps include portable or ambulatory pumps, large volume pumps (LVPs), patient-controlled analgesia (PCA) pumps, peristaltic pumps, elastomeric pumps, syringe pumps, enteral pumps, and insulin pumps. Depending upon their specific designs and intended uses, infusion pumps can be used to administer infusates through various delivery methods, including intravenously, intraperitoneally, intra-arterially, subcutaneously, neuraxially, and specifically into an intraoperative site, epidural space, and subarachnoid space.
In hospitals, clinics, and other medical environments, patient safety continues to be a paramount concern along with improved workflow efficiencies. This has been especially true when dealing with vulnerable patients and situations in which potent infusates capable of causing significant physiological or chemical effects are being administered. Accordingly, medical practitioners strive to ensure that patients receive safe and appropriate medical care including appropriate infusions of infusates.
Infusion pumps may be controlled locally via the programming of each individual pump. For example, a medical practitioner can configure an infusion pump to execute a delivery profile that corresponds to a patient's treatment needs, or a patient can configure an infusion pump according to their individual requirements within pre-defined limits without the involvement of a physician. Alternatively, infusion pumps may be controlled via other techniques such as by, for example, a network server that communicates with the pumps. Hospital information systems (HIS) and electronic medical record (EMR) systems may, in some circumstances, provide such network functionality.
Practitioners are increasingly responsible for attending to numerous pumps, devices, and medical care activities associated with one or several patients. For practitioners, efficiently tracking and performing tasks during their day is increasingly difficult in many respects, as treatments, medications and courses of care can be changed quickly within the care facility or environment and its associated electronic system or systems.
Accordingly, there is a need for devices, systems, and methods for alerting practitioners to changes required for infusion pumps. An infusion pump or related system providing alerts that are more efficient and effective is desired. Various new pumps, systems, methods and other arrangements could be decidedly advantageous in improving patient safety, workflow efficiency, programming, control, and operational parameters, etc., for infusion pumps and other coordinated medical devices.
Embodiments described or otherwise contemplated herein substantially provide the aforementioned advantages of providing or improving patient safety, workflow efficiency, programming, control, and operational parameters, among possible other advantages. Improvements in methods, systems, and apparatuses regarding notifications and alerts related to infusion pumps and treatments in medical environments are described.
One embodiment relates to a method of providing push alerts of infusion pump orders. The method includes receiving an infusion order for a patient in a computerized physician order entry system including a patient identifier and obtaining verification of the infusion order from a pharmacy. The method further includes sending data concerning an infusate, requested in the infusion order from the pharmacy, to a patient location and also includes updating an electronic medication administration record (EMAR) system with an approval to implement the infusion order. The method further includes providing a notification from an alert component in one or more devices associated with the patient identifier of updates to the EMAR system, without a practitioner initiated inquiry. Further, at least one of the one or more devices is an infusion pump at the patient location.
Another embodiment includes a method of providing push alerts of infusion pump orders. The method includes receiving manual programming by a practitioner of a first infusion pump order, including a patient identifier of a patient, associating a plurality of devices with the patient identifier, and receiving a second infusion pump order associated with the patient identifier. The method also includes sending a message to the plurality of devices associated with the patient identifier regarding the second infusion pump order. The method further includes providing one or more audio, visual, or tactile alert notifications regarding the second infusion pump order from an alert component of each of the plurality of devices associated with the patient identifier without requiring a practitioner action.
Another embodiment relates to an infusion pump with push alert notification. The infusion pump includes a pump housing, a pumping mechanism coupled to the pump housing that selectively delivers an infusate to a patient, and a pump control system including a processor and a memory programmable to control operation of the pumping mechanism. The infusion pump also includes an alert component, coupled with the pump housing, with audio, visual, or tactile alerts. Further, the infusion pump has an alert control engine, in operable communication with the pump control system. The alert control engine includes programming that associates a patient identifier for the patient with the infusion pump, receives an alert message from a local subnet related to an infusion order associated with the patient identifier, and instructs the alert component to provide an alert notification to a practitioner related to the infusion order without requiring an inquiry by the practitioner.
A further embodiment relates to a system of push alert notification for infusion pumps. The system includes a group of selected devices associated with a local subnet and an infusion pump. The infusion pump includes a pump housing, a pumping mechanism coupled to the pump housing that selectively delivers an infusate to a patient, and a pump control system including a processor and a memory programmable to control operation of the pumping mechanism. The infusion pump further includes an alert control engine in operable communication with the pump control system. The alert control engine includes programming that associates a patient identifier, for sending future notifications, with the group of selected devices following receipt of programming for a first order for the infusion pump for the patient. The alert control engine receives a second order for the infusion pump, generates an alert message related to the second order, and sends the alert message to the group of selected devices. Each of the group of selected devices and the infusion pump each contain an alert component that provides an audio alert, a visual alert, or a tactile alert when the alert message is sent for practitioner notification.
The foregoing summary is not necessarily intended to describe each illustrated embodiment or every implementation of the subject matter hereof. The figures and the detailed description that follow more particularly exemplify the embodiments.
Subject matter hereof may be more completely understood in consideration of the following detailed description of various embodiments of the subject matter in connection with the accompanying drawings, in which:
While embodiments are amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit subject matter hereof to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of subject matter hereof in accordance with the appended claims.
Medical devices and systems including one or more programmed infusion pumps and/or other medical devices are increasingly complex and potentially prone to errors. The need for and advantages of a simplified and less error-prone alert system for such medical devices and systems has been recognized by applicants. The following disclosure relates therefore to technology and methods of such advanced notification systems.
One area of medical care which applicants have identified for improvement relates to efficiently providing alerts to practitioners or other users of infusion pumps when new orders are placed, when orders are modified, or when activities have occurred which require attention.
Throughout this application the term “practitioner” is intended to refer to any nurse, physician, medical practitioner, hospital staff or other medical care worker responsible for operating medical equipment or devices.
Presently, in many medical care facilities, when a patient infusion order changes or a new infusion order is entered, a practitioner might not immediately know of this change. The practitioner typically must log into an electronic system to check their work list to be notified of such changes. This delay in information exchange can correspondingly cause delays in patient therapy and less than optimal efficiency and care. Accordingly, the described push alert system, where practitioners are efficiently notified of infusion pump orders and order modifications, is believed to be highly desirable in hospitals and other medical environments.
Infusion pump 100A shown in
Infusion pump 100B shown in
Infusion pump 100B generally includes a peristaltic type infusion pump mechanism that controls a flow of infusate from a reservoir (not shown in
Although not specifically identified in the figures, pumps 100A and 100B may include various alert components, such as speakers, displays or vibration components. These components may be independent features specifically designated as stand-alone alert components, or they may be components serving as alert components that share functionality with other pump components.
In general, infusion pumps 100A-B such as those disclosed are routinely operated by practitioners when in hospitals and in other medical care environments. Medical infusion pumps 100A and 100B are each examples of infusion pumps that can be suitable for use with embodiments discussed herein, though other pumps and devices can be used in various other embodiments of infusion systems utilizing subject matter hereof.
In
Processor 222 can be any programmable device that accepts digital data as input, is configured to process the input according to instructions or algorithms, and provides results as outputs. In an embodiment, processor 222 can be a central processing unit (CPU) configured to carry out the instructions of a computer program. Processor 222 can also or alternatively be an application specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). Processor 222 is therefore configured to perform arithmetical, logical, and input/output operations.
In an embodiment, memory 224 can comprise volatile or non-volatile memory as required by the coupled processor 222 to not only provide space to execute the instructions or algorithms, but to provide the space to store the instructions themselves. In embodiments, volatile memory can include random access memory (RAM), dynamic random access memory (DRAM), or static random access memory (SRAM), for example. In embodiments, non-volatile memory can include read-only memory, flash memory, ferroelectric RAM, hard disk, floppy disk, magnetic tape, or optical disc storage, for example.
In
In
For purposes of its use throughout this disclosure, the term “engine” can be defined as a real-world device, component, or arrangement of components implemented using hardware, or as a combination of hardware and software, such as by a microprocessor system and a set of particular program instructions that adapt or prompt the engine to implement the particular functionality, which (while being executed) transform a microprocessor system into a special-purpose device. A engine can also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of software-controlled hardware. In certain implementations, at least a portion, and in some cases, all, of a engine can include the processor(s) of one or more computers that execute an operating system, system programs, and application programs, while also implementing the engine using multitasking, multithreading, distributed (e.g., cluster, peer-peer, cloud, etc.) processing where appropriate, or other such techniques. In addition, an engine can itself be composed of more than one sub-engines, each of which can be regarded as an engine, whether collectively or individually.
In some embodiments, infusion pump 100 of
User inputs 242 to the system are provided by programming of a user such as a nurse, physician, or other medical practitioner. User inputs 242 can include a variety of forms and be expressed in a variety of ways. User inputs 242 can be received by user interface 234, I/O port 236 or other practitioner input mechanisms.
In
It is to be appreciated and understood generally that alert notification system 300 can be “localized” as parameters are configured and transmitted in close physical proximity and/or to a limited group of interconnected devices. In certain embodiments, communication is not performed in a system-wide, centralized manner but through local device to device interactions, via rack 302 or other intermediary structures in certain embodiments (such as in the aforementioned stacked or other physically connected embodiments) in which local transmission of information or operating parameters from one physical device to another is made possible.
In the example of
In certain embodiments, one medical device can be identified as a parent medical device such as, for example, device 410, and another or a plurality of other medical devices can be referred to as child medical devices such as, for example, 420, 430, 440 and 450. In some systems, any of the medical devices could be deemed the parent device as this function is not necessarily dictated by physical location or position. Further, while a plurality of potential child medical devices are shown in
In general, rack 402 can comprise various shapes and sizes. In some cases, rack 402 may be similar to rack 302 shown in
Each of the medical devices may include an alarm component 460. Alarm components 460 can each generate audio, visual, or tactile alarms. In some embodiments, rack 402 can include a rack alarm component 462 as well. A rack alarm component 462 could be configured to provide an alert notification to a practitioner at any time when any of the medical devices coupled to rack 402 receives an infusion alert or update and can alarm in addition to alarm components 460 in the individual medical devices 410, 420, 430, 440 and 450. In other embodiments, rack alarm component 462 can be used to replace the individual alarm notifications from the individual medical devices to reduce alarm confusion and “alarm fatigue”.
Digital communication bus 404 is shown as integrated with or on rack 402. Digital communication bus 404 enables communication of operational information and programming between the medical devices. In some embodiments, this may be between the parent medical device 410 and the plurality of child medical devices 420, 430, 440 and 450 that are coupled to the rack 402. Medical devices 410, 420, 430, 440 and 450 may be infusion pumps as shown in, for example,
In system 400 shown in
Digital communication bus 404 generally refers to a communication system that transfers data between components inside a computing device, or between computing devices. In some embodiments, bus 404 can include any or all related hardware components (wire, optical fiber, etc.) and software, including communication protocols. Bus 404 could utilize an Ethernet, SPI, CAN, RS232 or other communication architecture or method. In some embodiments, digital communication bus 404 may include a router 406. Router 406 can be configured to enable digital communications between medical devices 410, 420, 430, 440 and 450 that are physically and removably coupled to rack 402 and into a local area network (LAN) 408, in certain embodiments; and rack 402 could be, as aforementioned regarding rack 302, replaced with another arrangement of devices 410-450 such as, for example, provision of mating features that enable devices 410-450 to be physically connected to each other in, for example, a vertically-oriented stack. Although not specifically illustrated, in such a configuration stackable infusion pumps could be communicatively coupled by way of suitable electronic connections or other connectivity means between them and therefore be operative together to alert practitioners to changes required for the pumps as described herein but without use of a rack or rack-like component.
A rack 402 (or other arrangement) of medical devices 410, 420, 430, 440 and 450 can be an isolated subnet in a larger communication network. The medical devices on rack 402 can identify that only the medical devices also mounted to the same rack are viable partners or authorized for operation together. Such a configuration or association helps to prevent random medical devices in a facility from mistakenly receiving unnecessary alerts.
Using this system, it is possible to quickly and easily pass on notifications about infusion changes to practitioners. For example, when medical device 410 is an infusion pump, a change in an infusion order in or for device 410 can be passed to other medical devices 420, 430, 440 and 450 using a digital communication pathway through mounting rack 402. Changes in infusion orders can include new infusion orders, modifications to existing or pending infusion orders or other updates to a patient's treatment that potentially relate to that medical device.
Parent medical devices such as, for example, parent medical device 410 in
It is to be appreciated and understood that in some embodiments, the aforementioned parent-child arrangements of devices could also be configurable directly on designated parent devices (or any designated devices) themselves and not require external systems or protocols to establish such arrangements or relationships. It is also to be appreciated and understood that in some embodiments, the aforementioned parent-child arrangements of devices could also be configurable according and responsive to physical arrangements of the devices that have been stacked and/or racked. For example, in such a particular embodiment, a topmost or highest pump in a vertically-oriented stack or rack of pumps and other devices could be designated as the parent according to its physical position therein; and in another such embodiment, a bottom or lowest pump in a vertically-oriented stack or rack of pumps and other devices could be designated as the parent.
Next, at 504, the infusion order is checked into a pharmacy. This action can include obtaining verification of the infusion order from the pharmacy, for example. The method further can include filling the infusion order and sending it to the patient floor or location at 506. More generally, this step includes sending the infusate requested in the infusion order from the pharmacy to a patient location. At 508, the electronic medication administration record (EMAR) system is updated with an approval to complete or implement the infusion order. This may include an indication of an approval to administer the order and an indication of completed filling or implementation of the order by the pharmacy and/or request for delivery or delivery of the infusate to a patient location. As in past systems and methods, the practitioner can manually log into the electronic medical record (EMR) to check a “to do” list, as shown in 510A. In effect, a practitioner is able to inquire to “pull” this to do list from the system. In addition to this, the disclosed method also includes providing a “push” notification, as indicated at 510B. Such a “push” notification is provided from an alert component in one or more devices associated with the patient identifier of updates to the EMAR system.
As referenced in other locations, an alert component may include a variety of components capable of visually, audibly or tactically providing warnings or alert information. This notification does not require an inquiry initiated by a practitioner into an EMAR system application or otherwise opening or interacting with such an application by the practitioner. In various embodiments, the notification is provided by at least an infusion pump at the patient location or otherwise co-located with the patient, such as in a room with the patient. Other devices associated with the patient identifier providing a notification from an alert component can include additional infusion pumps proximate the patient, practitioner workstations for particular units or care areas, practitioner handheld devices, and other patient monitoring, charting, and diagnostic equipment, for example. Following notification, the practitioner then administers the ordered infusate to the patient and, accordingly, completes or implements the infusion order as indicated at 512.
A push notification, as at 510B, can also further utilize one or more alert escalation processes in some embodiments. For example, an alert escalation process can begin with generally modest initial alerts delivered by one or more visual, audible, or tactile notifications and escalate into increasingly conspicuous and difficult-to-overlook alerts. If the order or alert is not fulfilled or addressed within a predetermined amount of time, further or more concentrated alerts may be issued. These further alerts may increase one or more of: frequency, volume, brightness, degree of tactile movement, or other attention-getting characteristics. Alerts can be designed to gradually or quickly increase. This type of escalation process could be implemented in or adapted to any of the embodiments discussed throughout this disclosure. Such an escalation process is made possible by the “push” nature of the notifications and can be appropriately tailored to the urgency of the situations or types of notifications in certain embodiments.
The infusion pump 100 also includes alert features 802 including an alert component 860 and an alert control engine 870. Alert component 860 is coupled with the pump housing 810 and provides audio, visual, or tactile alerts 872 to a practitioner 880. Further, alert control engine 870 is in operable communication with the pump control system 820. The alert control engine 870 includes programming that associates a patient identifier 882 for the patient 814 with the infusion pump 100. Pump configuration inputs 884 can be received directly from a practitioner/user 880 or from a local subnet. Pump configuration inputs 884 may include an association of a patient identifier 882 during the initial manual programming by the practitioner/user 880. The alert control engine 870 is configured to receive alert messages 886 from a local subnet related to infusion orders associated with the patient identifier 882. The alert control engine 870 is also programmed to instruct the alert component(s) 860 to provide one or more alerts 872 to a practitioner/user 880 related to infusion orders without requiring user inquiry or action.
In
The infusion pump 800 shown in
The infusion pump 100 also includes an alert control engine 870 that is in operable communication with the pump control system. The alert control engine 870 includes programming that associates a patient identifier, for sending future notifications. The patient identifier can be associated with the group of selected devices 475 following receipt of programming for a first order for the infusion pump for the patient. The alert control engine 870 also includes programming for future updates. Specifically, the alert control engine 870 receives a second order for the infusion pump, generates an alert message related to the second order, and sends the alert message to the group of selected devices 475. Each device of the group of selected devices 475, and the infusion pump, can each contain an alert component 460 that provides an audio alert, a visual alert, or a tactile alert 872 when the alert message is sent.
Accordingly, based on the foregoing disclosure, pumps or medical devices in a patient room or otherwise co-located with the patient are able to notify a practitioner of an impending pump order. Pumps and/or devices are associated with the patient to advantageously push alerts to appropriate locations or care areas of a hospital and to appropriate practitioners and their electronic devices. Local subnets make associations to patient rooms and locations possible once an initial infusion is started and automatically sent through programming protocols including the patient identifier. The disclosed systems and pumps are particularly useful in medical care facilities where unused pumps and other medical devices may be located in patient rooms. By way of the novel and inventive devices, systems, and methods providing push alerts to infusion pumps and related devices hereof—as described by example or otherwise contemplated herein—it is to be appreciated and understood that such unused pumps and devices can be effectively utilized to issue relevant notifications to practitioners. In certain embodiments, racks like those described with reference herein to
It is also to be appreciated and understood that the novel and inventive devices, systems, and methods providing push alerts to infusion pumps and related devices hereof—as described by example or otherwise contemplated herein—could also be advantageously configured and employed for a plurality of pumps for a primary infusion and a secondary infusion, sometimes known in the art as “piggybacking.” For example, a first pump could be configured and commanded to administer a first infusate to a patient through a fluid line or tubing while a second pump could be configured and commanded to administer a second infusate along the same line or tubing to the patient such that the second infusate is provided concurrently or consecutively in “piggybacked” fashion with the first infusate. Such a “piggyback” system is also described in U.S. provisional patent application Ser. No. 62/158,213 filed on 7 May 2015, titled “Server Systems for Coordinating and Controlling Infusion Pumps”, with the disclosure thereof being incorporated herein by reference thereto. A copy of which is attached as an Appendix to the present application. In particular in such an embodiment having a piggyback capability, for example, an order for a secondary infusion could be pushed to a parent pump as a “piggyback alert”. Then, upon receiving and acknowledging the piggyback alert, an infusion therapy in progress could be interrupted on a syringe pump, for example, to provide a secondary infusion from an LVP via the same tubing; and when the piggybacked LVP infusion is complete, the original syringe pump infusion could be resumed.
It should also be appreciated that the exemplary embodiment or exemplary embodiments are only examples, and are not intended to limit the scope, applicability, or configuration of the novel and inventive subject matter hereof in any way. Rather, the foregoing detailed description will provide those skilled in the art with an enabling disclosure for implementing the exemplary embodiment or exemplary embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope of the subject matter hereof as set forth in the appended claims and the legal equivalents thereof. For example, although described and depicted as being in generally vertical stacks and racks, pumps and devices—as described by example or otherwise contemplated herein—could be provided in any other suitable orientations or arrangements in a particular embodiment of novel and inventive subject matter hereof. For example, although pumps 100 are depicted as being arranged vertically in
Embodiments described by example or otherwise contemplated herein are intended to be illustrative and not limiting. Additional embodiments are within the claims. Although subject matter hereof has been described with reference to particular embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the subject matter. For example, in addition to the “pushing” out of an infusion order change or alert to a change needed or desired for a particular infusion therapy being delivered to a patient, a particular device, system, and method hereof that provides a push alert to an infusion pump and related devices could be configured to push out a recommended cancellation of an active infusion therapy, in progress, but subject in most such embodiments to a required confirmation from the practitioner before the cancellation is imposed and the infusion therapy is stopped.
Also, it is to be appreciated and understood that although not specifically illustrated in the drawings, alert components as have been described by example or otherwise contemplated could include or be, individually or in various combinations with each other, a kinetic/motion-based device or system such as, for example, a suitably sized small waving flag (whether physical and mechanical, or virtual and electronic). In an embodiment, a kinetic/motion-based device or system could include at least one motion sensor so that the alert component would be effective if it would inadvertently not be visually observed by the practitioner. In an embodiment, a kinetic/motion-based device or system could comprise an infrared (IR) detector system. Such a device or system could, for example, also be configured to be recognizable on a security or patient monitoring camera but not in the patient's room environment, to minimize unwanted sensory stimuli or distraction to the patient.
Various modifications to subject matter hereof may be apparent to one of skill in the art upon reading this disclosure. For example, persons of ordinary skill in the relevant art will recognize that the various features described for the different embodiments of the subject matter hereof can be suitably combined, un-combined, and re-combined with other features, alone, or in different combinations, within the spirit of the subject matter. Likewise, the various features described above should all be regarded as example embodiments, rather than limitations to the scope or spirit of the subject matter. Therefore, the above is not contemplated to limit the scope of the subject matter.
For purposes of interpreting the claims for subject matter hereof, it is expressly intended that the provisions of 35 U.S.C. § 112(f) are not to be invoked unless the specific terms “means for” or “step for” are recited in a claim.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2016/056952 | 10/14/2016 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62252925 | Nov 2015 | US |
