WO2018022204A1

WO2018022204A1 - Group coordination of operational features of a plurality of medical devices

Info

Publication number: WO2018022204A1
Application number: PCT/US2017/037020
Authority: WO
Inventors: Michael D. Welsch; Larry R. Zalesky; Grant A. Adams; Kevin S. KOPP; James B. Drost; Ryan D. HEILMAN; Kurt ELLIASON; Eric J. Wilkowske; Linh VO
Original assignee: Smiths Medical ASD Inc
Current assignee: Smiths Medical ASD Inc
Priority date: 2016-07-25
Filing date: 2017-06-12
Publication date: 2018-02-01
Anticipated expiration: 2019-01-25

Abstract

Embodiments include a system providing group coordination of operational features of a plurality of medical devices. The system includes a plurality of medical devices each including a control engine having a set of device-specific parameters governing operation of an operational feature. The system also includes a rack providing a mounting structure for coupling the plurality of medical devices by releasable engagement. The system further includes a communication architecture in the rack providing connectivity between the plurality of medical devices when the plurality of medical devices are coupled to the rack. The control engines in the plurality of medical devices are interoperable with respect to the operational feature and automatically modify the set of device-specific parameters in each one of the plurality of medical devices when coupled to the rack for group coordination of the operational feature.

Description

GROUP COORDINATION OF OPERATIONAL FEATURES OF A PLURALITY OF MEDICAL DEVICES

CROSS REFERENCE TO RELATED APPLICATION

The present application claims the benefit of US Provisional Patent Application No. 62/366,455, filed on July 25, 2016, which is hereby fully incorporated herein by reference.

TECHNICAL FIELD

Embodiments relate generally to medical devices and, more particularly, to group coordination of operational features of a plurality of medical devices. Such coordination can be achieved through particular communication and control components and systems for medical devices and, more particularly, through informational, advisory, and control devices and systems for coordinated infusion pumps and other coordinated medical devices. Embodiments specifically include systems, methods and apparatus related to display brightness normalization, occlusion location, and alarm coordination.

BACKGROUND

In the medical arts, medical devices such as infusion pumps have been useful for managing the delivery and dispensation of a prescribed amount or dose of a drug, fluid, fluid- like substance, or medicament (hereinafter, collectively, an "infusate") 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 practitioners to deliver anesthesia and manage pain. Throughout this disclosure, unless otherwise noted, the term "practitioner" is intended to refer to a properly authorized nurse, physician, medical technician, hospital or healthcare facility caregiver, or other medical care worker responsible for operating medical equipment or a medical device, or any other properly authorized user of medical equipment or a medical device. Also throughout this disclosure, unless otherwise noted, the term "medical device" is intended to include any medical device that is suitable for use with subject matter of this disclosure, including but not limited to infusion pumps, pulse oximeters, blood pressure sensors and monitors, and heart rate sensors and monitors, for example.

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, including in-home care, 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, practitioners strive to ensure that patients receive safe and appropriate medical care including appropriate infusions of infusates. The "five rights of medication administration", commonly referenced in connection with ensuring safe infusions, are: the right medication (determining if a particular infusate has been prescribed correctly); the right patient (determining if the infusate was prescribed for the correct patient); the right dose (determining what volume or how many milliliters, tablets, or doses of the infusate are to be given to the patient); the right route (determining if the infusate should be given to the patient intravenously or by mouth, feeding tube, or other injection, etc.); and the right time (determining what time of day the infusate should be delivered to the patient). Accordingly, most infusion pump manufacturers and users have been keenly interested in ensuring that these "five rights" are implemented, observed, and verified.

Infusion pumps may be controlled locally via the programming of each individual pump. For example, a 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 or other practitioner. 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.

Generally, an infusion pump is specifically programmed or configured according to certain physiological, pharmacokinetic, and operational parameters or limits that are often predefined and with the safety provisions of the aforementioned "five rights". In recent years, infusion pumps have become increasingly sophisticated and may include such features as close error reduction software, which enable infusion pumps to perform functions that assist in proper programming and calculating of dosing and delivery rates in an effort to reduce medication errors and potentially consequential patient harm. Infusion pumps can also be programmed or configured to access databases (often referred to as "drug libraries") containing information relating to medications that can be used with a specific pump, as well as information corresponding to dosing guidelines, drug concentrations, dose limits, and clinical advisories. Such features can include medication safety software and "guard toolboxes" and servers. These features may generally enable practitioners to select medications from pre-loaded lists, which can be tailored to each healthcare facility and patient care area. Additionally, healthcare facilities can integrate infusion pumps with electronic medical records, computerized order entry systems, and medication recognition systems, such as, e.g., barcode scanning systems, to further enhance safety and efficacy. Healthcare facilities and other authorities can also choose to generally or specifically implement dosing and delivery limitations, commonly called hard and soft limits, on preselected drugs.

Many operational settings and systems of medical devices (including, as aforementioned, an infusion pump or infusion pumps), and particular groups of medical devices, operate independently from one another in practice. This type of independent operation can occur even when, for example, a plurality of medical devices are simultaneously treating a common patient or are tasked with functions common to multiple devices. Often this independence of individual medical devices results in duplicated tasks or other inefficiencies, or does not take advantage of the combined resources of all devices involved. Accordingly, systems, methods and apparatuses providing greater coordination and cooperation between multiple medical devices are desired.

SUMMARY

Embodiments described or otherwise contemplated herein substantially provide the advantages of providing or improving patient safety, workflow efficiency, programming, control, and improved operational parameters, among other advantages.

One embodiment relates to a system providing group coordination of operational features of a plurality of medical devices (with the term "medical devices" including, as aforementioned, an infusion pump or infusion pumps). The system includes a plurality of medical devices each including a control engine having a set of device-specific parameters governing operation of an operational feature. The system also includes a rack providing a mounting structure for selectively coupling the plurality of medical devices thereto, by releasable engagement or other suitable coupling technique. The system further includes a communication architecture in the rack providing connectivity between the plurality of medical devices when the plurality of medical devices are coupled to the rack. The control engines in the plurality of medical devices are interoperable with respect to the operational feature or features and automatically modify the set of device-specific parameters in each one of the plurality of medical devices when coupled to the rack for group coordination of the operational feature or features.

Another embodiment relates to a system of display brightness normalization of a plurality of medical devices. The system includes a plurality of medical devices each having a display of adjustable brightness and a rack providing a mounting structure for selectively coupling the plurality of medical devices thereto, by releasable engagement or other suitable coupling technique. By way of the rack, the plurality of medical devices are interoperatively coupled with one another. In this embodiment, a medical device of the plurality of medical devices that most recently receives a user input adjusting brightness of the display sends a command to each of the plurality of other medical devices to make a corresponding adjustment to each of their respective display's brightness.

An embodiment relates to an infusion pump with display brightness normalization.

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 display of adjustable brightness on or with the pump housing. The infusion pump further includes a user interface that receives a user command of display brightness when adjusted, a rack interface that receives a rack command of display brightness from a medical device coupled to a rack structure for the pump when adjusted, and a brightness control engine. The brightness control engine includes a processor and a memory programmable to control a brightness setting of the display. The brightness control engine is controlled by the user command or the rack command that is most recent in time. Further, when the brightness control engine is controlled by the user command, the rack interface further issues the user command directed to all medical devices coupled to the rack requesting uniform display brightness.

An embodiment relates to a method of display brightness normalization for a group of medical devices. The method includes searching for one or more medical devices connected to a subnet and establishing a connection with the one or more medical devices in the subnet. The method also includes receiving a display brightness adjustment command, adjusting brightness on a first medical device based on the display brightness adjustment command, and sending commands to adjust the display brightness in the one or more medical devices in the subnet to match the display brightness of the first medical device.

Another embodiment relates to a multi-pump occlusion location system. The system includes a plurality of infusion pumps each including at least one fluid line for infusate delivery, at least one sensor to obtain a data set related to the at least one fluid line, and an occlusion detection engine. The system further includes a manifold common to at least two of the fluid lines. The system also includes a rack providing a mounting structure for selectively coupling the plurality of infusion pumps thereto, by releasable engagement or other suitable coupling technique, and a communication architecture associated with the rack providing connectivity between the plurality of infusion pumps coupled to the rack. Further, the plurality of infusion pumps permit interoperability and sharing of the data sets with one another used in occlusion detection, such that a location of detected occlusion can be determined by the occlusion detection engine in one of the plurality of infusion pumps.

Another embodiment relates to a first infusion pump including occlusion location. The first infusion pump includes a pump housing, a first fluid line for infusate delivery, a pumping mechanism coupled to the pump housing that selectively delivers an infusate to a patient using the first fluid line and a first sensor to obtain data related to the first fluid line. The first infusion pump further includes a control module that receives data from the first sensor. The first infusion pump includes a rack interface for receiving data from at least a second sensor associated with a second infusion pump connected to a common communication structure related to occlusion of a fluid line of the second infusion pump. The first infusion pump also has a pump control system including a processor and a memory programmable to control operation of the pumping mechanism. The pump control system provides an occlusion detection engine that determines occlusion location based upon the data from the first sensor and the second sensor.

A further embodiment relates to a method of occlusion detection for a group of infusion pumps. The method includes monitoring tubing of a first infusion pump of the group of infusion pumps for a pressure increase indicative of occlusion. The method also includes querying one or more infusion pumps of the group of infusion pumps that utilize a manifold that is common to the first infusion pump, for increases in pump pressure. The method also includes determining an occlusion location based upon pressure increase information received from the first infusion pump and the one or more infusion pumps of the group of infusion pumps. The method additionally includes providing an alert on a display of the first infusion pump indicating the occlusion location.

An embodiment is directed to a system for alarm control over a plurality of infusion pumps. The system includes a plurality of infusion pumps. Each infusion pump includes a control engine having an independent alarm mode in which each of the plurality of infusion pumps operates independently from one another, and a multi-pump alarm mode in which alarms are interoperatively coordinated and prioritized between the plurality of infusion pumps. Each of the control engines has a set of device specific settings. The system also includes a rack providing a mounting structure for selectively coupling the plurality of infusion pumps thereto, by releasable engagement or other suitable coupling technique, and a communication architecture associated with the rack providing connectivity between the plurality of infusion pumps coupled to the rack. The plurality of infusion pumps automatically operate in the multi-pump alarm mode upon coupling the plurality of infusion pumps to the rack. An embodiment is directed to an infusion pump including alarm control. The infusion pump includes a pump housing, a pumping mechanism, a pump control system, and a control module. The pumping mechanism is coupled to the pump housing that selectively delivers an infusate to a patient. The pump control system includes a processor and a memory programmable to control operation of the pumping mechanism. The control module relays commands to the pump control system, including a user interface providing selection of multiple operation modes including an independent alarm mode and a multi-pump alarm mode.

An embodiment relates to a method of alarm coordination for a group of medical devices. The method includes searching for one or more medical devices connected to a subnet, establishing a connection with the one or more medical devices in the subnet, receiving a plurality of alarms from the one or more medical devices, prioritizing the plurality of alarms based on predetermined criteria, and providing alerts to a user from the plurality of alarms of highest priority.

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.

BRIEF DESCRIPTION OF THE DRAWINGS

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:

FIGS. 1 A-C are various infusion pumps that are examples of medical devices that can be part of systems, applications or methods providing group coordination of operational features, according to various embodiments.

FIG. 2 is a block diagram of various elements of an infusion pump system that can be part of systems, applications or methods providing group coordination of operational features, according to various embodiments. FIG. 3 is an example of a system with a mounting rack including a plurality of infusion pumps, according to an embodiment.

FIG. 4A is a diagram of a system providing coordination of operational features of a plurality of medical devices, according to an embodiment.

FIG. 4B is a diagram of a system providing coordination of operational features of a plurality of medical devices, according to an embodiment.

FIG. 5 is a diagram of a display brightness normalization system for medical device displays, according to an embodiment.

FIG. 6 is a diagram of a display brightness normalization system for medical device displays, according to an embodiment.

FIG. 7 is a flow chart of a method of display brightness normalization for a group of medical devices, according to an embodiment.

FIG. 8 is a diagram of an occlusion location system for infusion pumps, according to an embodiment.

FIG. 9 is a diagram of an occlusion location system for infusion pumps, according to an embodiment.

FIG. 10 is a flow chart of a method of occlusion location for infusion pumps, according to an embodiment.

FIG. 11 is a diagram of an alarm control system for medical devices, according to an embodiment.

FIG. 12 is a diagram of an alarm control system for medical devices, according to an embodiment.

FIG. 13 is a flow chart of a method of alarm coordination for a group of medical devices, according to an embodiment.

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. DETAILED DESCRIPTION

Medical device systems in which multiple programmed infusion pumps and/or other medical devices are present are increasingly complex. Accordingly, there is a need for systems, apparatuses and methods that can aid in the coordination of certain features and parameters for these groups of devices.

In general, aspects of patient safety, workflow efficiency, programming, control, and operational parameters or limits, among potentially other important considerations, can be understood at times throughout this disclosure as belonging to integrated informational, advisory, and control ("Inform / Advise / Control") systems, whether in total, or individually, or in various sub-combinations:

"Inform" pertains to a linking and transfer of patient and medical device data for both use and view by means of a portal or user interface; "Advise" pertains to use of the "Inform" data to derive clinical suggestions or recommendations for a particular patient's therapy; and "Control" pertains to use of, for example, algorithms and/or real-time patient data to change a therapy, with or without direct involvement of a practitioner.

In an embodiment of a medical device or system incorporating an Inform / Advise / Control system, "Inform" (if included in a particular embodiment) could assist in meeting a practitioner's need or desire for easily and efficiently obtaining data from a medical device or coordinated group of devices in treatment of a particular patient. Such data could include, for example, information on the status and operating parameters of the device or group of devices and/or so-called Continuous Quality Improvement or "CQI" data. The data could also be used, for example, to populate the EMR. Beyond "Inform", "Advise" (if included in a particular embodiment) could assist in meeting a practitioner's need or desire for easily and efficiently obtaining more information on how to improve clinical outcomes and/or provide recommended therapies. This could be provided by, for example, an "Advise" system utilizing "Inform" data that then links patient outcomes to therapies provided by the medical devices. The medical devices themselves could accordingly be linked in so-called machine- to-machine (M2M) fashion. "Advise" could also introduce new algorithms that link therapies to desired effects; and through "Advise", practitioners could be provided with means for creating their own algorithms and decision support rules. Beyond "Advise", "Control" (if included in a particular embodiment) could assist in meeting a practitioner's need or desire for easily and efficiently acknowledging a changed therapy within medication safety software limits. M2M interfaces could link patient states to therapeutic actions, and the algorithms could titrate infusates to desired therapeutic effects.

Embodiments of an Inform / Advise / Control system, whether in total, or individually, or in various sub-combinations, could be decidedly advantageous in provision or improvement of patient safety, workflow efficiency, programming, control, and operational parameters or limits, etc., for infusion pumps and other coordinated medical devices.

One specific area involving an Inform / Advise / Control type system which applicants have identified for improvement relates to coordinating operational features and parameters for groups of infusion pumps and medical devices.

FIGS. 1A-C show various pumps 100 as examples of medical devices that can be used in Inform / Advise / Control systems. Namely, the pumps 100 (also referred to and distinguished more specifically as pumps 100A, 100B and lOOC, respectively, in FIGS 1A, IB, and 1C) shown are examples of various infusion pumps that can be used in a system or method providing group coordination of operational features.

Infusion pumps 100A and 100B, shown respectively in FIGS. 1A and IB, are syringe- type pumps that can be used to deliver a wide range of drug therapies and treatments. Infusion pumps 100A and 100B include a pharmaceutical container or syringe 110, which is supported on and secured to housing 120 by clamp 130, respectively. In embodiments, syringe 110 can be separately supplied from the respective pump 100. In other embodiments, syringe 110 is an integrated component of pump 100. Syringe 110 includes a plunger 140 that forces fluid outwardly from syringe 110 via infusion line 160 that is connected to a patient. A motor and lead screw arrangement internal to housing 120 of pump 100 cooperatively actuates a pusher or plunger driver mechanism 170, to move plunger 140. In embodiments, a sensor can monitor force and/or position of the plunger 140 in the syringe 110 according to system specifications. Also, depicted on the pumps 100A and 100B is at least one user interface 172 for operator input and/or display 174. In various embodiments, display 174 can also be combined with or serve as part of a user interface 172 as a touch screen or touchless interface, for example. Infusion pump lOOC shown in FIG. 1C is an example of an ambulatory infusion pump that can be used to deliver a wide range of drug therapies and treatments. Such ambulatory pumps can be comfortably worn by or otherwise removably coupled to a user for in-home ambulatory care by way of belts, straps, clips or other simple fastening means, and can also be alternatively provided in ambulatory pole-mounted arrangements within hospitals and other medical care facilities.

Infusion pump lOOC generally includes a peristaltic type infusion pump mechanism that controls the flow of medication from a reservoir (not shown in FIG. 1C) of fluid coupled to pump lOOC through a conduit from the reservoir which matingly passes along bottom surface 180 of pump lOOC. The reservoir can comprise a cassette that is attached to the bottom of pump lOOC at surface 180, or an IV bag or other fluid source that is similarly connected to pump lOOC via, for example, a "remote reservoir adapter" (not shown) at surface 180. Specifically, pump lOOC uses valves and an expulsor located on bottom surface 180 to selectively squeeze a tube of fluid (not shown) connected to the reservoir to effect the movement of the fluid supplied by the reservoir through the tube or line and to a patient in peristaltic pumping fashion. Pump lOOC also has at least one user interface 182 for operator input and/or display 184. In various embodiments, the display 184 can also be combined with or serve as part of a user interface 182 as a touch screen or touchless interface, for example.

Infusion pumps 100A, 100B, and lOOC are each examples of some types of infusion pumps that can be modified or adapted to 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.

FIG. 2 is a block diagram of an infusion pump system 200. System 200 includes infusion pump 100 having pump control system 202 with processor 204 and memory 206 programmable with selected protocols, profiles, segments of profiles, and other settings for controlling operation of pumping mechanism 208 such as, for example, the aforementioned syringe and ambulatory or peristaltic type mechanisms that can draw infusate from a reservoir or other fluid or infusate source 210 through a fluid tube or line 212. In embodiments, reservoir 210 can comprise any suitable infusate supply, such as an IV bag, syringe, continuous supply, or other infusate storage. Processor 204 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 204 can be a central processing unit (CPU) configured to carry out the instructions of a computer program. Alternatively, processor 204 can be an application specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). Processor 204 is therefore configured to perform arithmetical, logical, and input/output operations.

In an embodiment, memory 206 can comprise volatile or non-volatile memory as required by the coupled processor 204 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.

Pump control system 202 may also include a control engine 214 in various embodiments. Such a control engine 214 may be somewhat general in nature or be specifically directed to various specific operational features such as brightness normalization/control, occlusion detection/location or alarm control/coordination, for example. Many other types of specific control engines 214 are contemplated as well. Control engine 214 may include processor 204 and memory 206 in certain embodiments or may utilize separate or distinct components in other embodiments.

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-engine, each of which can be regarded as an engine, whether collectively or individually.

Infusion pump 100 also includes an input control engine 220 for relaying commands to the pump control system 202. Input control engine 220 can include at least one user interface 230 utilizing a user input 260 including input mechanism(s) 235, that works cohesively with a display 225. In some cases, display 225 will be considered part of user interface(s) 230. In some embodiments, operation modes including a group pump mode, individual pump mode, multi-pump alarm mode, or independent alarm mode may be selectable by this user interface 230. User interface 230 generally allows a user to enter various operating parameters, including but not limited to names, drug information, limits, delivery shapes, information relating to hospital facilities, as well as various user-specific operating parameters (e.g., patient age and/or weight).

In some embodiments, infusion pump 100 includes an input/output (I/O) interface

240. Interface 240 may be a USB port or other appropriate port for connecting infusion pump 100 to a network or computer 250 having software designed to interface with pump 100. In some cases, interface 240 may also be useful for connecting to a rack or other hardware for localized networking or connectivity. In such cases, interface 240 may alternatively be referred to as a rack interface or subnet interface at times for purposes of this disclosure. Embodiments relating to rack and other subnet or hardware arrangements will be discussed later in greater detail. Power to infusion pump 100 is provided via an AC power cord or internally provided battery.

User inputs 260 to system 200 are provided by programming of a user such as a nurse, physician, or other medical practitioner. These inputs 260 can include a variety of forms. Inputs 260 are generally received by input mechanism(s) 235.

In FIG. 3, a plurality of infusion pumps 100 are depicted as each being installed in a generally vertical stacked relationship along pole 310 as part of a group coordination of operational features system 300. Although illustrated fragmentally, it will be appreciated by those of skill in the art that pole 310 may be any suitable and generally vertical support structure such as is commonly used for suspending elevated intravenous (IV) fluid reservoirs, bags, and the like. A mounting rack 302 is coupled to pole 310 by way of a pole clamp or clamps (not illustrated) and pumps 100 are each removably couplable to rack 302. In other embodiments, rack 302 may be freestanding or coupled to other structures or support features. Accordingly, rack 302 includes a plurality of vertically aligned infusion pumps 100 coupled thereto. Other arrangements are possible in embodiments as well. Infusion pumps 100 merely represent one type of medical device that could be removably coupled to a mounting rack such as rack 302. Other medical devices of various shapes sizes and functions could be coupled to a rack as well. Examples of other medical devices include monitors, sensors and status/ alerting devices (e.g. pulse oximeters, blood pressure monitors, blood gas sensors, breathing assistance devices, and core temperature sensors, among others) that are routinely used in hospital settings for patient care.

FIG. 4A depicts a diagram of system 400 for group coordination of operational features of medical devices. In some embodiments, the system 400 can have similar structure to the system 300 shown in FIG. 3. The system 400 includes a rack 402, communication architecture 404 associated with rack 402, and a plurality of medical devices 410a, 410b, 410c, and 410d (or more generally referred to as "medical devices 410") coupled to rack 402.

Rack 402 includes mounting structures 420 that permit releasable coupling to medical devices 410. Mounting structures 420 may include various mechanical coupling structures of various sizes, shapes, and forms and are not intended to be limited to any particular shape or type. Accordingly, medical devices 410 can be selectively engaged to rack 402. Rack 402 may take on various shapes and structural configurations. In various embodiments, medical devices may be arranged vertically, horizontally or be otherwise aligned.

Rack 402 also includes communication architecture 404, providing connectivity between medical devices 410 when they are coupled to rack 402. Communication architecture 404 may include a communications bus, for example. Such a communications bus can include a communication system that transfers data between components inside a computing device, or between computing devices. In some embodiments, a communications bus can cover related hardware components (wire, optical fiber, etc.) and software, including communication protocols. A communications bus can utilize an Ethernet, SPI, CAN, RS232 or method as the communication architecture 404. In some embodiments, the communication architecture can include a router. In such embodiments, a router could be configured to enable digital communications between medical devices 410 that are physically and removably coupled to rack 402 and into a local area network (LAN).

Accordingly, connectivity between medical devices 410 makes it possible for the devices to communicate and work together. Rack 402 or similar arrangements may be considered and referred to as a subnet or local subnet for purposes of this disclosure. In general, such a subnet is largely isolated and has either no connection to a larger hospital network/medical system network or only minimal connections, such as a single connection of one device to such a network. In such an arrangement using an isolated subnet, communication can occur between many devices without all being connected directly to the same system -wide network.

As discussed earlier, medical devices 410 may include, but are not limited to, infusion pumps and other monitors, sensors, and related patient care devices, systems, and machines. The same or different types of medical devices 410 may be coupled to the same rack 402. However, medical devices 410 can each include a control engine 430 having a set of device- specific parameters 432 governing operation of an operational feature 434. An operational feature 434 can include display brightness normalization, occlusion location/detection, or alarm control/coordination in some embodiments, for example. Accordingly, device specific parameters 432 may include parameters such as: a brightness or intensity setting, a time of day setting, a location of pump, a hospital unit or group, a type of medical device, a type of infusate, a treatment protocol, a route of infusion, a type of therapy, a type of procedure, a type of application, a type of disposable unit, a type of tubing frame assembly, a patient identifier, a medical care personal identifier, a fluid line pressure setting, a drug library, medical safety settings, patient data, etc.

Control engines 430 in medical devices 410 are interoperable with respect to their respective operational features 434. They are interoperable in the sense that the medical devices can exchange and make use of information supplied by each one to another. Control engines 430 automatically modify the set of device-specific parameters 432 in each one of the medical devices when coupled to rack 402 for group coordination of the respective operational features 434. This automatic modification can rely on a programmed set of rules.

In certain embodiments, medical devices 410 can be considered infusion pumps with structure similar to that disclosed in FIGS. 2 and 3 or variations thereof. For example, control engine 430 may be deemed to be interchangeable or have structures and components equivalent to control engine 214.

FIG. 4B depicts a diagram of a system 450 for group coordination of operational features of a plurality of medical devices 460a, 460b, 460c, 460d, and 460e (or more generally referred to as "medical devices 460"). In some embodiments, system 450 can be similar to system 300 of FIG. 3 or system 400 of FIG. 4A. System 450 includes a network 452 that is connected to a subnet 454 (such as a rack) by a single direct connection to one medical device 460a. Subnet 454 further includes wireless communications between medical device 460a and the other medical devices 460b, 460c, 460d, and 460e. Each of these medical devices 460 may contain a control engine for an operational feature, and corresponding parameters, similar to medical devices 410 in FIG. 4 A. Further, although connected wirelessly to one another, the medical devices may be coupled to a common mounting structure or system.

Wireless technologies that can be used to interconnect medical devices 460 with one another include: infrared communication; ultrasonic communication; Bluetooth®; peer-to- peer or network-based WiFi; short range communication (i.e. ZigBee, ANT, etc.); near-field communication (NFC); and radio-frequency identification (RFID) communication. These wireless technologies enable the rapid expansion of protocols from one medical device 460 to many medical devices 460.

Additional discussion and disclosure related to subnets that may make use of racks and embedded server designs that could be utilized or partially incorporated in the various embodiments of this application, can be found in currently co-pending PCT patent application number PCT/US2016/030978, entitled Systems and Methods for Coordinating and Controlling Infusion Pumps, and is hereby fully incorporated by reference herein. A copy of this co-pending patent application is attached in an Appendix to this application.

BRIGHTNESS NORMALIZATION

Shown in FIG. 5, is a diagram of a system 500 including a plurality of medical devices 510a, 510b, and 510c (or more generally referred to as "medical devices 510") with a brightness normalization operational feature. Specifically, in FIG. 5, the medical devices 510 shown are various types of infusion pumps. Certain embodiments contemplate use of brightness normalization system 500, which uses a local subnet/rack arrangement compatible with or similar to the ones disclosed earlier in systems 200, 400 and/or 450, to control brightness of an entire group of infusion pumps or other medical devices in a unified way.

Medical devices 510 each have a display 512 of adjustable brightness in or with a pump housing 516. System 500 further includes a mounting rack 530 on which medical devices 510 are selectively mounted and interoperatively coupled with one another. Mounting rack 530 of FIG. 5 is represented diagrammatically as a horizontal bar and does not reflect an actual structural configuration or embodiment of such a mounting rack 530. Some possible mounting racks 530 could have a structure and appearance similar to rack 302 in FIG. 3. Such a mounting rack 530 may provide connectivity between medical devices 510 mounted or coupled thereto and may take on various shapes and forms. Medical devices 510 are interoperatively coupled in the sense that they readily exchange certain information, data, parameters, and commands through or via a communicative signal path or paths of rack 530.

In an example embodiment of operation of system 500, a practitioner 540 manually enters a user input 542 of brightness adjustment to display 512 into medical device 510a. This user input 542 could be a simple finger swipe made with an up or down gesture on a screen of the device, a menu selection, or other button press, for example. Medical device 510a sends a command 550 to each of the other medical devices 510b and 510c that are interoperatively coupled via rack 530 with medical device 510a. Command 550 can be sent to each medical device 510b and 510c directly, or by passing or handing off command 550 in series through a chain of medical devices 510 coupled to rack 530.

In an event that other medical devices 510 have subsequent user inputs 542 adjusting display brightness, commands 550 would subsequently be sent to the other medical devices 510 to adjust display brightness accordingly. Specifically, a medical device 510 that most recently receives a user input 542 adjusting brightness becomes the "parent" medical device and sends a command to each of the remaining "child" medical devices to make a corresponding adjustment to display brightness. In some embodiments, the roles of parent and child can be changed for subsequent user inputs depending on which medical device most recently received a user input.

It is recognized by the applicants that reducing workload and saving time for medical practitioners, such as nurses, is widely desired in hospitals and other medical care. In the case of a Neonatal Intensive Care Unit (NICU) nurse, for example, a single patient could require twenty-four distinct medical devices, such as infusion pumps, which each has its own display acklight at the patient's bedside. Each of these displays/backlights could independently require adjustment at any given time as light levels and conditions change. If these efforts are then multiplied across a number of patients for a given medical practitioner, a significant amount of time and effort can be required to be dedicated to this relatively mundane task of display brightness adjustment.

Accordingly, this disclosure contemplates embodiments in which a local subnet of devices, such as a rack of interconnected medical devices for example, permits a practitioner to merely adjust one device to the desired brightness level and have the rest of the devices in the rack adjust to the same or similar level of brightness automatically. For example, in a situation with multiple devices, a manual brightness adjustment of any one of the devices could cause similar adjustments in all devices connected through a common subnet. In embodiments in which one of the devices in the subnet utilizes a touchscreen, a simple swipe made with an up or down gesture on the screen of the device can adjust the brightness with the remaining devices reacting to the swipe as the command propagates through the subnet. In some embodiments, the reacting devices can have coordinated brightness adjustments that appear to be satisfyingly instantaneous, or nearly so, to the user.

Similarly, other embodiments contemplated include arrangements in which a brightness command from a network is sent to one of the medical devices in a subnet to dim or brighten its display. This adjustment would then propagate throughout the subnet. In certain network embodiments, this adjustment of medical device brightness could be accomplished with a daily planner feature (such as disclosed in, for example, PCT Publication No. WO 2014/210465A1, entitled Infusion Planning System, which is hereby incorporated by reference herein), denoting night times, nap times, and day times, such that the devices are automatically adjusted. Accordingly, in this arrangement, a single medical device could be attached to a hospital network, yet be able to access all medical devices within the subnet to respond to a command given. In such an embodiment, the system would not require bandwidth in the hospital network to access each and every one of the medical devices for which the brightness change is desired. In certain embodiments, medical devices 510 may include infusion pumps, as shown in FIG. 5 and understood in combination with the infusion pump diagrams of FIGS. 2 and 3, or variations thereof.

As shown in FIG. 6, an infusion pump 610 with display brightness normalization can include a pump housing 612, a pumping mechanism 614, a display 616 of adjustable brightness, a user interface 618, a rack interface 620, and a brightness control engine 622.

Pump housing 612 can include a selected type of infusion pump 610 from various types of infusion pumps, with a pumping mechanism 614 that is coupled to the pump housing 612 for selectively delivering an infusate to a patient. Also located on the pump housing 612 is at least one display 616. Display(s) 616, in one or more embodiments, can include a screen or screens of adjustable brightness such that these can be set for enhanced readability and convenience of the medical users utilizing the pump. Medical environments can vary significantly in terms of amounts of light available at various times. In certain environments where there is a great deal of ambient light, a more intense brightness setting might be preferred, while in darker environments, a less intense brightness would be preferably provided. Easier to read displays promote safety and convenience for users.

A practitioner may readily adjust brightness settings for infusion pump 610 through use of user interface 618. Specifically, user commands 630 related to display brightness are input into user interface 618 via touchscreen, button selections, or any other suitable input. In some cases, similarly to infusion pump system 200 of FIG. 2, display 616 will be considered part of user interface 618. Rack interface 620 may also receive command(s) 632 related to an adjustment of display brightness. Command(s) 632 are sometimes referred to as rack command(s) 632 for purposes of this disclosure. Rack commands 632 include inputs regarding display brightness adjustment that are first input into another medical device on a common rack. Specifically, inputs are made while the medical device is coupled to the same common rack structure as infusion pump 610. In general, when a brightness adjustment is made to the medical device coupled to the same rack as infusion pump 610, the medical device so adjusted in display brightness sends a corresponding display brightness rack command 632 through the rack to pump 610 and also any other medical devices connected to the rack to adjust display brightness to a brightness that is the same or similar as that of the medical device so adjusted in display brightness. Brightness control engine 622 can include a processor and a memory programmable to control operation of the pumping mechanism in some embodiments. Brightness control engine 622 can accept display brightness command(s) 630 and/or 632 to adjust a brightness of display 616 of pump 610 based on the display brightness command that is most recent in time from user interface 618 or rack interface 620.

Display brightness command(s) 632 can be relayed from the rack interface whenever display brightness is adjusted for a medical device connected to a common rack. Further, the infusion pump uses a group pump mode when the infusion pump is coupled to a rack subnet.

FIG. 7 depicts a method 700 of display brightness normalization for a group of medical devices. At 702, the method includes searching for one or more medical devices connected to a subnet. At 704, the method includes establishing a connection with the one or more medical devices in the subnet. At 706, the method includes receiving a display brightness adjustment command. At 708, the method includes adjusting display brightness on a first medical device. At 710 the method includes sending commands automatically to adjust the display brightness in the one or more medical devices in the subnet to match or at least approximate the display brightness of the first medical device.

Irrespective of a particular embodiment of subject matter hereof, it is to be appreciated and understood that a "one-input group adjustment" feature for display brightness, as described by example with reference to FIGS. 5-7 or otherwise contemplated herein, can be implemented in a variety of ways for all devices communicatively connected through a rack. For example, one device could be designated as, and be capable of being, the primary brightness adjustment input device; or some or all devices in the common rack could be so capable of brightness adjustment for communication of such adjustment to the other devices in the rack.

In certain embodiments, a brightness control command can be based upon a prescheduled brightness adjustment based on the time of day. Adjustment of display brightness for one of the devices and/or pumps can be commanded by, or operate in cooperation with or by input from, a daily planner (e.g., PCT Patent Publication No. WO 2014/210465A1 as aforementioned) on one of the devices and/or pumps, or in a larger network. Adjustments to display brightness during night times, nap times, and day times, can be preprogrammed so the devices and/or pumps are automatically adjusted. In certain embodiments brightness control commands originate from a user input. In other embodiments, brightness control commands originate from a larger network only communicatively coupled with a limited number of devices and/or pumps in a subnet or localized network.

The subnet architecture discussed above is useful beyond dimming and brightening or otherwise adjusting a display, including but not limited to, brightness, contrast, display blanking time, alarm volume, alarm style, vibratory use, power saving settings, etc. Some of these possible operating parameters for adjustment will be discussed later in greater detail.

Some embodiments are not limited to adjusting the brightness of a display 512 of a medical device 510, but also can include adjustment of lighting associated with a keypad, LEDs, and other buttons and lights capable of backlighting or illumination.

In some embodiments, control of lighting and brightness can be done with a multi- touch sliding motion. In some embodiments, control of lighting and brightness can be based upon a light sensor built into or otherwise associated with one of the medical devices 510. Using the light sensor, the medical device 510 can automatically dim or brighten the displays or features based on the amount or intensity of ambient light in the room or environment sensed.

In certain embodiments, the brightness of a display 512 is designed to adapt to situations in which difficult operating conditions are present. This can mean rapid adjustment to best suit the inside and outside environments associated with patients in ambulances, helicopters, accident scenes, or active military theater.

In some embodiments, the displays 512 of the medical devices 510 can coordinate use of the brightness of the displays 512 to collectively provide additional information. For example, a group of medical devices 510 located near one another can enhance an alarm by creating timed and sequential brightness increases that, when viewed together, direct a user's attention in a particular direction. Further, a brightness setting can be used to indicate which medical devices 510 are non-functioning. For example, dimly light medical devices 510 can indicate that the medical devices 510 are not being used at a certain time of day. The nonfunctioning pumps could accordingly provide grayed out menu choices. In some embodiments, different brightness backlight levels can be provided for different infusates, routes of infusion, care areas, patients, hospital units, or other grouping potentially benefiting from association or distinction from other medical devices 510.

OCCLUSION LOCATION

Medical care for certain patients can be relatively complex, as in critical care cases for example, and can require multiple pumps delivering fluids to a single infusion site. Infusion lines (i.e. tubing) can be merged in these cases through use of a manifold or "Y site". These merged infusion lines generally share a pressure signature. When an occlusion occurs, the pressure increases in the infusion line. If the pressure increase is sensed by a single pump, the occlusion will thus be believed to be between the pump and the site of the infusate merger at the manifold (or upstream from the manifold). Alternatively, if the pressure increase is sensed across multiple pumps, the occlusion will thus be believed to be between the site of the infusate merger at the manifold and the patient (or downstream from the manifold). Accordingly, the present disclosure describes a system where various pumps have and react to information about occlusion pressure in the tubing of multiple grouped pumps. This type of system provides enhanced occlusion detection and information about occlusion location. One way in which to accomplish this is via infusion pumps grouped together in a local subnet (as aforedescribed) configuration as described in greater detail below.

FIG. 8 is a diagram of an example of a multi-pump occlusion location system 800 in accordance with subject matter hereof, which utilizes a subnet 802 to accomplish group infusion detection. Specifically, in this example system 800, there are four infusion pumps 810, 812, 814, and 816 shown that are joined together through their respective tubing 830 (or "fluid lines") at manifold 850, and one infusion pump 818 connected directly to a patient 860 through its tubing or fluid line 830'. Manifold 850 can include all types of Y-site structures and components for combining multiple fluid lines or tubing 830 into a single fluid tube or line 890. When there is an occlusion between pump 810 and the manifold 850, as indicated by symbol 870 in the drawing, this would typically cause an increase in pressure in tubing 830 associated with pump 810. An occlusion between manifold 850 and patient 860, as indicated by symbol 880 in the drawing, would however result in a pressure increase in tubing 830 associated with all four pumps 810, 812, 814, and 816. Using this aggregated infusion information scheme, a pump or series of pumps can thus be suitably programmed to analyze the occlusion data and determine where the occlusion is located. Information about the location of a particular occlusion in system 800 can thereby be rapidly relayed to a practitioner, allowing for faster troubleshooting of the occlusion and enhanced efficiency of overall operation and maintenance of the aggregated pumps.

System 800 in FIG. 8 has infusion pumps 810, 812, 814, and 816, each including an occlusion detection engine 820, tubing or fluid line 830, and a sensor 840 to obtain a data set related to operating conditions of line 830. Occlusion detection engines 820 each receive information related to each of corresponding lines 830. This combination of data allows assumptions to be made about infusion line 890 that is downstream of manifold 850. Tubing or fluid line 830 can be made of various materials and be associated with different types of infusion pumps. Although only one line 830 is shown as being associated with each infusion pump 810, 812, 814, and 816 in FIG. 8, multiple lines 830 could be associated with certain infusion pumps.

Sensors 840 for lines 830 can include a variety of possible embodiments. Some sensors 840 may be located on or with pumps 810, 812, 814, and 816, while others may reside on or with lines 830 themselves. In an embodiment, sensor 840 can include a stall sensor on the motor of the corresponding pumps or a pressure transducer within the corresponding line 830. Alternatively, in an embodiment, a sensor 840 might rely on volume or flow rate for obtaining the aforementioned data set.

System 800 also relies on infusion pumps 810, 812, 814, and 816 having connectivity between each other provided by rack or subnet 802 with a communication architecture 892 that is associated with rack or subnet 802. Rack or subnet 802 can also include a mounting structure (not shown) for coupling the infusion pumps thereto by releasable engagement.

System 800 provides infusion pumps 810, 812, 814, and 816 that permit interoperability and sharing of data with each other. Specifically, pumps 810, 812, 814, and 816 permit data sets used in occlusion detection, such as fluid line pressure data sets, to be shared across the pumps such that a location of detected occlusion can be determined by occlusion detection engine 820 in one or more of the infusion pumps.

In certain embodiments, infusion pumps 810, 812, 814, and 816 can be understood in view of the infusion pump diagrams of FIGS. 2, 9 or variations thereof. Although only one pump 818 is illustrated in FIG. 8 as being connected directly to patient 860 and therefore not communicatively coupled to the other pumps 810-816, it is to be appreciated and understood that additional pumps and devices can be communicatively coupled in various combinations and that other communicative groupings can be established via rack or subnet 802. For example, in an embodiment (not illustrated) there could be a plurality of groupings of pumps attributable to a corresponding plurality of manifolds 850.

FIG. 9 illustrates an example embodiment of a system 900 including an infusion pump 910, which is equipped for occlusion location. In general, infusion pump 910 includes a pump housing 912, a first fluid line 914 for infusate delivery, and a pumping mechanism 916 coupled to pump housing 912. Pumping mechanism 916 can be used to selectively deliver an infusate to a patient using the first fluid line 914. At least one sensor 918 is part of pump 910 as well and is generally responsible for obtaining data for occlusion detection determinations. Sensor 918 may include one or more pressure sensors, acoustic sensors, optical sensors, force sensors, or electro-mechanical sensors. Sensors 918 may be coupled to or within the pump housing 912, in some embodiments, or may be coupled to or within a fluid line 914 in other embodiments (such as, e.g., the aforedescribed sensors 840 with lines 830 of FIG. 8).

Data or data sets 920 from sensor 918 are received by a sensor controller 930. Second data or data sets 940 are also received from a rack 950. These second data sets 940 generally can include fluid line data from other pumps (not illustrated) that are connected to rack 950. Specifically, second data sets 940 are received in the infusion pump 910 via rack interface 960. The connectivity and transfer of data sets 940 via rack 950 is made possible due to a common communications structure between the infusion pumps mounted on rack 950 (as aforedescribed, for example, in FIG. 8 with respect to connectivity between pumps provided by rack or subnet 802 with an associated communication architecture 892).

Pump control system 902 receives data from both sensor controller 930 as well as rack interface 960. Pump control system 902 can include various components including a processor and a programmable memory. These and other features of pump control system 902 can provide an occlusion detection engine 970 that determines occlusion location 980. In some embodiments, occlusion location 980 may be communicated to a practitioner via a suitable pump display or provided by voice alerts or commands from a speaker associated with pump 910 or rack 950.

In embodiments, data or data sets 920 include pressure measurements of fluid line 914; and data or data sets 940 include pressure measurements of another fluid line (not illustrated) associated with another pump (not illustrated) with rack 950.

In certain embodiments, infusion pump 910 uses a group pump mode when it is coupled to a rack subnet 950 (such as, e.g., rack subnet 802 of FIG. 8). Further, pump 910 can use an individual pump mode when it is not coupled to rack subnet 950.

FIG. 10 depicts a method 1000 of occlusion location for a group of infusion pumps. At 1002, a fluid line or tubing of a first infusion pump is monitored for a pressure increase indicative of an occlusion. At 1004, one or more infusion pumps utilizing a manifold common to the first infusion pump are queried for increases in pump pressure. At 1006, an occlusion location is determined based upon pressure increase information received from the first infusion pump and the one or more infusion pumps. At 1008 an alert on a display of the first infusion pump is provided indicating the occlusion location.

In some embodiments, in addition to determining occlusion location, grouped infusion pumps may also provide related information regarding pump performance as well. For example, monitoring of downstream pressure in various pumps can also aid in detection of overall pump failure by an individual pump from the group.

ALARM COORDINATION

FIGS. 11-13 disclose diagrams and charts setting forth various alarm coordination and alarm prioritization systems as well as related apparatuses and methods. Medical care for certain patients frequently requires many medical devices in the form of machines, infusion pumps, and monitors with sensors, for example. Many of these devices are equipped with an array of audible, visual or sensory alarms to alert practitioners of a range of events. Such events could include anything from a minor infusion pump malfunction to a critical rise in patient heart rate or blood pressure. When a large number of medical devices are being used, there is a risk that continual alerts and warnings from these devices can lead to a type of "alarm fatigue" experienced by medical practitioners. This can result in important alarms being ignored or missed. Further, practitioners trying to address alarms created by less important events can be distracted from addressing the most critical alarms that are occurring. Various manifestations and consequences of "alarm fatigue" may be considered to be significant and problematic issues in modern medical practice, particularly in hospitals.

Accordingly, this disclosure addresses problems of "alarm fatigue" by disclosing an alarm coordination system 1100, as shown in FIG. 11, providing intelligent and relevant delivery of alarms 1102 to medical practitioners. In certain embodiments, alarm coordination system 1100 can include an auto-order feature in which certain alarms 1102 from various medical devices 1110 are sent directly to, for example, a pharmacy or biomedical department requesting repair when respective alarms pertain to matters that are typically addressed by a pharmacist or biomedical technician, respectively. In certain embodiments, system 1100 can include prioritization of alarms 1102 sounded or displayed by medical devices that are part of a common group.

In general, alarm coordination system 1100 is useful as it is able to coordinate alarms 1102 with other pumps that are present in a particular subnet, such as a rack 1120 of infusion pumps and/or other medical devices 1110 (analogously to rack subnets as aforedescribed, with reference to preceding drawings herein). Accordingly, if one such pump 1110 is alarming, the other pumps 1110 in a rack 1120 can automatically coordinate and adjust alarms 1102 in a desirable way such that they are appropriately enhanced/reduced, delayed, advanced, anticipated, combined, altered, removed, or silenced altogether.

Alarm coordination system 1100, as described by example or otherwise contemplated herein, is advantageous as it can prioritize multiple alarms occurring from one rack 1120 of (or otherwise communicatively connected) pumps. The prioritization can be customized such that the desired importance of alarms can be established or defined as desired. Further, system 1100 can be designed to predict alarms that will likely occur in the future, such that they can be appropriately conveyed or silenced. Such prediction of future alarms can be provided by, or operate in cooperation with or by input from, a daily planner (e.g., PCT Publication No. WO 2014/210465A1 as aforementioned).

Other alarm coordination features are made possible when medical devices 1110 with alarms 1102 are part of the same subnet. For example, brightness of the alarms could be appropriately coordinated with information provided across the subnet. Pumps 1110 could be allowed to brighten when alarming, or non-alarming pumps could be made to dim when the alarming pumps brighten, to help practitioners quickly and efficiently assess the situation with minimal distraction from a potential cacophony of alarms. Alarm volume, alarm style and alarm vibration characteristics could likewise be adapted as desired by a user of the system 1100.

As illustrated in FIG. 11, a system 1100 controls alarms 1 102 of several medical devices 1110. Coordination of these alarms 1102 using communications 1130 between devices 1110 enables more useful and effective alerts to medical practitioners and others in proximity thereto.

In some embodiments, devices 1110 each can include an alarm control engine (not illustrated) with multiple alarm modes (not illustrated). In a first "independent" alarm mode, each of devices 1110 operate independently from each other. In a "multi-device" alarm mode, alarms 1102 are interoperatively coordinated and prioritized between the plurality of devices 1110. In either mode, coordination and prioritization of the alarms for the alarm control engines is determined by a set of predetermined device specific settings and associated programming. In some embodiments, devices 1110 automatically operate in the multi-device alarm mode when they are commonly coupled to a rack or otherwise communicatively coupled to each other.

In the example of FIG. 11, system 1100 also contains a rack 1120 (diagrammatically depicted) providing a mounting structure for coupling devices 1110 thereto by releasable engagement. Rack 1120 also is associated with a communication architecture 1150 providing connectivity between each device 1110 coupled to rack 1120. In certain embodiments, the multi-device alarm mode includes selectively silencing or delaying certain alarms.

In certain embodiments, medical devices 1110 may include infusion pumps, as shown in FIG. 11 and understood in combination with the infusion pumps illustrated in, for example, the preceding drawings, or variations thereof.

FIG. 12 depicts a partial diagram of an infusion pump system 1200 containing an alarm control feature. An infusion pump 1210 is shown, and can be understood to be similar to pumps illustrated in, for example, the preceding drawings where the infusion pump 1210 has a pump housing 1212 and a pumping mechanism 1216 coupled to the pump housing 1212 that selectively delivers an infusate to a patient via an infusion line 1214. Infusion pump 1210 includes a pump control system 1220 having an alarm control engine 1230, an input controller 1240 that receives user inputs 1242, and a rack interface 1250 that receives rack inputs 1252.

Pump control system 1220 can include a processor and a memory (not illustrated) that are programmable to control operation of pump 1210. Alarm control engine 1230 can include and make use of such hardware components of pump control system 1220 as well as related software.

Input controller 1240 relays commands to pump control system 1220 including a user interface providing selection of multiple operation modes. In some embodiments, operation modes that could be selected include an independent alarm mode and a multi-pump alarm mode.

In certain embodiments, the multi-pump alarm mode includes an alarm control engine 1230 that determines if a first alarm is needed by the infusion pump, searches for other infusion pumps associated with the patient in multi-pump alarm mode currently delivering a second alarm, determines if the first alarm or second alarm requires silencing or delay, and displays or otherwise presents the first alarm and/or second alarm based upon the determination. In some embodiments, the infusion pump automatically uses the multi-pump alarm mode when the infusion pump is coupled to a rack subnet.

Based on the settings and data accessed by alarm control engine 1230, an alarm coordination output 1260 is generated to govern operation of the alarms of pump 1210 and other medical devices and pumps commonly coupled to, or otherwise communicatively connected with, the rack subnet.

FIG. 13 illustrates a flow chart of a method of alarm coordination 1300 for a group of medical devices. At 1302, method 1300 includes searching for and recognizing medical devices connected to a common rack subnet or otherwise communicatively coupled. At 1304, a connection is established with the medical devices in the rack subnet or as otherwise communicatively coupled. At 1306, a plurality of alarms are received from medical devices in the rack subnet or as otherwise communicatively coupled. At 1308, the alarms are prioritized by customized, predetermined criteria. At 1310, alerts are provided to a practitioner for high priority alarms in the subnet or rack (or as otherwise communicatively coupled). In some embodiments, alarms that are duplicative or of lesser urgency can be automatically silenced or delayed. In addition to the above alarm coordination embodiments, other alarm embodiments can be used to help assist users with alarm coordination and effectiveness. For example, in one embodiment, the lights of the medical device 1110 could be used to indicate a problem condition in an infusion line. Specifically, the medical device can utilize display brightness, intensity, or pattern to provide an appropriate alarm. In some embodiments, coordination of multiple medical devices can produce successive sounds as alarms.

Further, combining the alarms 1102 of several medical devices 1110 into a single medical device can help mitigate alarm component failures. For example, typically if the speaker producing an audible alarm on a medical device fails in a non-coordinated arrangement, that particular alarm will not likely be noticed. However, in a coordinated alarm arrangement, failure of a speaker in one medical device 1110 will be mitigated as its alarms will be routed through the speakers of another medical device 1110.

It is to be appreciated and understood 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 example 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.

The 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.

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 various embodiments of 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 herein should all be regarded as example embodiments, rather than limitations to the scope or spirit of the subject matter. Therefore, the foregoing descriptions and drawings are not contemplated to necessarily 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.

Claims

1. A system providing group coordination of operational features of a plurality of medical devices, comprising:

a plurality of medical devices each including a control engine having a set of device- specific parameters governing operation of an operational feature; a rack including a mounting structure for removably coupling the plurality of medical devices thereto by releasable engagement;

a communication architecture in the rack providing connectivity between the plurality of medical devices when the plurality of medical devices are coupled to the rack; and

wherein the control engines in the plurality of medical devices are interoperable with respect to the operational feature and automatically modify the set of device- specific parameters in each of the plurality of medical devices when coupled to the rack for group coordination of the operational feature.

2. The system of claim 1, wherein the operational feature is display brightness normalization.

3. The system of claim 1, wherein the operational feature is occlusion location.

4. The system of claim 1, wherein the operational feature is alarm control.

5. The system of claim 1, wherein the plurality of medical devices include at least one infusion pump.

6. A system of display brightness normalization of a plurality of medical devices, comprising:

a plurality of medical devices each having a display of adjustable brightness; and a mounting rack on which the plurality of medical devices are selectively mounted and interoperatively coupled with each other, wherein a medical device, of the plurality of medical devices, that most recently receives a user input adjusting brightness of the display of that medical device sends a command to each of others of the plurality of medical devices to make a corresponding adjustment to display brightness.

7. The system of claim 6, wherein the plurality of medical devices includes at least one infusion pump.

8. An infusion pump with display brightness normalization, comprising:

a pump housing;

a pumping mechanism coupled to the pump housing that selectively delivers an infusate to a patient;

a display of adjustable brightness on the pump housing;

a user interface that receives a user command of display brightness when adjusted; a rack interface that receives a rack command of display brightness from a medical device coupled to a rack structure for the pump when adjusted; and

a brightness control engine including a processor and a memory programmable to control a brightness setting of the display, the brightness control engine controlled by the user command or the rack command that is most recent in time;

wherein when the brightness control engine is controlled by the user command, the rack interface further issues the user command to all medical devices coupled to the rack requesting uniform display brightness.

9. The infusion pump of claim 8, wherein the user interface is integrated with the display as a touch screen.

10. The infusion pump of claim 9, wherein the infusion pump uses a group pump mode when the infusion pump is coupled to a rack.

11. A method of display brightness normalization for a group of medical devices, comprising:

searching for one or more medical devices connected to a subnet;

establishing a connection with the one or more medical devices in the subnet;

receiving a display brightness adjustment command;

adjusting display brightness on a first medical device based on the display brightness adjustment command; and

sending commands automatically to adjust the display brightness in the one or more medical devices in the subnet to match the display brightness of the first medical device.

12. The method of claim 11, wherein the display brightness adjustment command is based upon a prescheduled brightness adjustment based on a time of day.

13. The method of claim 11, wherein the display brightness adjustment command originates from a user input.

14. The method of claim 11, wherein the display brightness adjustment command originates from a network command.

15. A multi-pump occlusion location system, comprising:

a plurality of infusion pumps each including at least one fluid line for infusate delivery, at least one sensor to obtain a data set related to the at least one fluid line, and an occlusion detection engine;

a manifold common to the at least one fluid line each of the plurality of infusion pumps;

a rack including a mounting structure for removably coupling the plurality of infusion pumps thereto by releasable engagement; and

a communication architecture associated with the rack providing connectivity between the plurality of infusion pumps coupled to the rack, wherein the plurality of infusion pumps permit interoperability and sharing of the data sets with each other used in occlusion detection, such that a location of detected occlusion can be determined by the occlusion detection engine in one of the plurality of infusion pumps.

16. The system of claim 15, wherein the data set provides pressure data for each of the at least one fluid line.

17. An infusion pump including occlusion location, comprising:

a pump housing;

a first fluid line for infusate delivery;

a pumping mechanism coupled to the pump housing that selectively delivers an infusate to a patient using the first fluid line;

a sensor to obtain data related to the first fluid line;

a control module that receives data from the sensor;

a rack interface for receiving data from at least a second sensor associated with a second infusion pump connected to a common communication structure related to occlusion a second fluid line; and

a pump control system including a processor and a memory programmable to control operation of the pumping mechanism,

wherein the pump control system provides an occlusion detection engine that determines occlusion location based upon the data from the sensor and the second sensor.

18. The infusion pump of claim 17, wherein the data includes pressure measurement of the first fluid line and the second fluid line.

19. The infusion pump of claim 17, wherein the infusion pump uses a group pump mode when the infusion pump is coupled to a rack subnet.

20. A method of occlusion location for a group of infusion pumps, comprising: monitoring tubing of a first infusion pump for a pressure increase indicative of occlusion;

querying one or more infusion pumps utilizing a manifold common to the first infusion pump for increases in pump pressure;

determining an occlusion location based upon pressure increase information received from the first infusion pump and the one or more infusion pumps; and providing an alert on a display of the first infusion pump indicating the occlusion location.

A system for alarm control over a plurality of infusion pumps, comprising:

a plurality of infusion pumps, each including an alarm control engine having:

an independent alarm mode in which each of the plurality of infusion pumps operates independently from one another; and

a multi-pump alarm mode in which alarms are interoperatively coordinated and prioritized between the plurality of infusion pumps, each of the control engines having a set of device specific settings;

a rack providing a mounting structure for removably coupling the plurality of infusion pumps thereto by releasable engagement; and

a communication architecture associated with the rack providing connectivity between the plurality of infusion pumps coupled to the rack,

wherein the plurality of infusion pumps automatically operate in the multi-pump alarm mode upon coupling the plurality of infusion pumps to the rack.

22. The system of claim 21, wherein the multi-pump alarm mode includes selectively silencing or delaying certain alarms.

23. An infusion pump including alarm control, comprising:

a pump housing;

a pumping mechanism coupled to the pump housing that selectively delivers an infusate to a patient; a pump control system including a processor and a memory programmable to control operation of the pumping mechanism; and

a control module that relays commands to the pump control system including a user interface providing selection of multiple operation modes including:

an independent alarm mode; and

a multi-pump alarm mode.

24. The infusion pump of claim 23, wherein the multi-pump alarm mode includes an alarm control engine that:

determines if a first alarm is needed by the infusion pump;

searches for other infusion pumps associated with the patient in multi-pump alarm mode currently delivering a second alarm;

determines if the first alarm or the second alarm requires silencing or delay; and presents the first alarm and/or the second alarm based upon the determination.

25. The infusion pump of claim 23, wherein the infusion pump automatically uses the multi-pump alarm mode when the infusion pump is coupled to a rack subnet.

26. A method of alarm coordination for a group of medical devices, comprising:

searching for one or more medical devices connected to a subnet;

establishing a connection with the one or more medical devices in the subnet;

receiving a plurality of alarms from the one or more medical devices;

prioritizing the plurality of alarms based on predetermined criteria; and

providing alarms to a user from the plurality of alarms of highest priority.

27. The method of claim 26, wherein some of the plurality of alarms received are silenced.

28. The method of claim 26, wherein some of the plurality of alarms received are combined.