Healthcare processing device and display system
A processing device and display system supporting a plurality of different modules providing different functions used in delivering healthcare to a patient, includes a patient monitoring module, including a processor, for acquiring and processing signals derived from sensors suitable for attachment to a patient. A patient treatment module, including a processor, supports delivering treatment to the patient using a treatment delivery device. A central processor exchanges data with module processors and processes signals derived from said patient treatment module to support monitoring of patient condition while concurrently monitoring operation of said treatment delivery device in delivering said treatment to said patient.
The present invention relates to a processing device and display system, and in particular to a modular healthcare processing and display system.
BACKGROUND OF THE INVENTIONHospitals routinely monitor physiological parameters of patients from first entry until final release. Originally, this was performed by one or more patient monitoring devices, such as a heart rate monitor, an EKG monitor, an SpO2 monitor, and so forth. These physiological parameters were separately detected by separate pieces of equipment, possibly manufactured by respectively different manufacturers. The monitoring equipment included the connections to the patient necessary to measure the physiological parameter and a display device of the type necessary to display the physiological parameter in an appropriate manner. A healthcare worker, such as a nurse, visited the patient's location and looked at each separate system to accumulate the patient's vital signs.
Current systems have integrated measurement of some of the physiological parameters (e.g. EKG, SpO2, etc.) into a single patient monitoring device. Such a device includes the patient connections necessary to measure the physiological parameters measurable by the device and a display device which can display the measured physiological parameters in an appropriate manner. Such patient monitors may be considered to be partitioned into two sections. A first, operational, section controls the reception of signals from the electrodes connected to the patient and performs the signal processing necessary to calculate the desired physiological parameters. A second, control, status and communication, section interacts with a user to receive control information and with the operational section to receive the physiological parameters, and displays status information and the values of the physiological parameters in an appropriate manner. Either or both of these sections may include a computer or processor to control the operation of that section. This approach has an economic advantage since the control, status and communication section is shared among the parameter monitoring functions.
Such patient monitors may also be connected to a central hospital computer system via a hospital network. In this manner, data representing patient physiological parameters may be transferred to the central hospital computer system for temporary or permanent storage in a storage device. Data received from the patient monitors may also be monitored by a person, such as a nurse, at the central location. The stored data may be retrieved and analyzed by other healthcare workers via the hospital network. Patient monitors in such a networked system include a terminal which is capable of being connected to and communicating with the hospital network. In such a patient monitor, the control, status and communication section controls the display of the physiological parameters, and also the connection to the hospital network and the exchange of the physiological parameters with other systems, such as other patient monitors and/or the central computer storage device, via the hospital network.
Such patient monitoring modules may also be portable. That is, they may operate while being transported with a patient who is being moved from one location to another in the hospital, for example, between a patient room and a therapy or operating room. A portable patient monitor consists of a base unit, and a portable unit which may be docked and undocked from the base unit. Base units may be placed at appropriate locations in the hospital. They are permanently connected to the hospital network and receive power from the power mains. The portable unit includes the necessary patient connections, connections for docking with base units, and a display screen. The portable unit also includes a processor which controls the operation of the portable unit The portable unit further includes a battery and an internal memory device.
While the portable unit of the patient monitor is docked, the batteries are recharged, and data representing physiological parameters are transmitted to the central hospital computer through the base unit via the hospital network. While the portable unit of the patient monitor is undocked, it runs on battery power. During transportation, the patient monitor continues to receive and display physiological parameters, and stores a record of those parameters in the internal memory device. If a base unit is available at the destination, the portable unit may be docked there. Communications is reestablished with the hospital central computer, and battery recharging commenced. At this time, data representing the previously stored parameters is retrieved from the internal memory device and transmitted to the storage device in the central hospital computer via the hospital network.
In such a patient monitor, the control, status and communication section controls display of the physiological parameters and communication of those parameters to the hospital network via the docking unit, and also detection of docking and undocking, control of power (either from the base unit when docked or the internal battery when undocked), storage of physiological parameter data in internal memory when the patient monitor is undocked, and transmission of stored physiological parameter data when the patient monitor is redocked.
Patient monitors have also been adapted to be used to transmit information to the hospital network from other modules. These modules may be patient monitoring modules measuring physiological parameters which are not measured by the patient monitor, or patient treatment modules reporting the status of treatments being provided to the patient. Such patient monitors include input terminals, or wireless input ports, to which these other monitoring modules are connected. Information from these modules is passed through the patient monitor to the hospital network through the base unit.
The modules illustrated in
A patient monitor is passive in the sense that it monitors physiological parameters of the patient to which it is attached. However, other medical devices are active in the sense that their operation affects the patient in some manner. For example, the anesthesia device controls the administration of anesthesia to a patient, e.g. during an operation; the fluid management device controls the administration of fluids (blood, saline, and/or medication) to a patient; the ventilator device assists or controls breathing of a patient, e.g. during an operation, and so forth. The active devices also include a computer or processor which controls the operation of the device. These devices also may be connected to a hospital network through a base unit. This allows a central location to monitor and to control the active device. As with the patient monitoring device, an active device, such as a fluid monitoring device, may be portable in the sense that a control module, including a processor, may be undocked from a fixed unit. This control module continues to operate the device, at the last received control settings, e.g. while a patient is transported from one location to another. When at the new location, the control module may be docked in a fixed unit at the new location and control by a central computer resumed.
The existing processing and display systems, described above used in patient monitoring and treatment have numerous limitations. Such existing processing systems employ different software for monitor computers, anesthesia computers, ventilation computers, and fluid management computers. Further, system devices are typically transported and connected to a particular corresponding type of medical device computer (e.g., a monitor device may be transported and connected to a corresponding monitor computer). Further, in existing systems, medical device processing devices and displays are typically able to view and control parameters and functions of other like devices, that is, a monitor processing device and display is limited to be able to view and control parameters and functions of another monitor processing device and display. In addition, existing systems typically derive patient parameters using specialized equipment and devices individually tailored to process a specific corresponding type of patient parameter. These devices require multiple individual electrical connections and fail to provide inter-device communication and central parameter processing capability.
Consequently to provide a desired therapy to a patient, the patient monitoring and/or treatment modules required to provide that therapy is assembled at the patient bedside. They are attached to the patient, and separately configured. Further, to provide the desired therapy may require changing the settings of one of the patient treatment devices based on readings derived from another device, are required. Because the different patient monitoring and/or treatment modules are from different sources and include different user interfaces, there is a significant risk of a mistake being made in the settings of one device based on the readings from another. In order to minimize such mistakes, detailed instructions are provided to the clinician for operating the patient monitoring and/or treatment devices required to provide the desired therapy, and the requirement for human interaction with the patient monitoring and/or treatment modules slows the process of providing the desired therapy.
A system which addresses these deficiencies and associated problems is desirable.
BRIEF SUMMARY OF THE INVENTIONIn accordance with principles of the present invention, a processing device and display system supporting a plurality of different modules providing different functions used in delivering healthcare to a patient, includes a patient monitoring module, including a processor, for acquiring and processing signals derived from sensors suitable for attachment to a patient. A patient treatment module, including a processor, supports delivering treatment to the patient using a treatment delivery device. A central processor exchanges data with module processors and processes signals derived from said patient treatment module to support monitoring of patient condition while concurrently monitoring operation of said treatment delivery device in delivering said treatment to said patient.
BRIEF DESCRIPTION OF THE DRAWINGIn the drawing:
In operation, the PAN 216 may be implemented in any manner allowing a plurality of modules to intercommunicate. For example, the PAN 216 may be implemented as an Ethernet network, either wired or wireless (WLAN). If implemented as a wireless network, it may be implemented according to available standards, such as: (a) a WLAN 802.11b compatible standard, (b) 802.11a compatible standard, (c) 802.11 g compatible standard, (d) Bluetooth 802.15 compatible standard, and/or (e) GSM/GPRS compatible standard communication network.
The patient monitoring module 210 corresponds to the operational portion of a prior art patient monitor described above. It receives signals from the electrodes and sensors attached to the patient, performs the signal processing required to calculate the physiological parameters, and provides that information to the central processor 220 via the PAN 216. Similarly, the patient treatment modules, i.e. the fluid management module 212 and the anesthesia module 214, correspond to the operational portion of the prior art treatment modules described above. The patient treatment modules 212, 214 receive operational data from the central processor 220 via the PAN 216 and in response perform their treatment functions, e.g. monitoring fluids administered to the patient and supplying anesthesia to the patient, respectively. Concurrently, the patient treatment modules 212, 214 send status data to the central processor 220 via the PAN 216. The central processor 220 processes the signals received from the patient monitoring module 210 and the patient treatment modules 212 and 214.
The central processor 220 interacts with the user to receive patient identifier information and treatment instructions and parameters. The central processor 220 configures the patient treatment modules 212, 214 by sending patient identifier information, the treatment instructions and parameters to the patient treatment modules 212 and 214 via the PAN 216.
The patient monitoring and/or treatment modules 210, 212, 214 may include a processor for receiving the configuration parameters from the central processor 220, for controlling the operation of the module 210, 212, 214 and for sending status and patient physiological parameter information to the central processor 220 via the PAN 216. The configuration parameters may include patient identifier information, set-up parameters, and/or data representing executable instructions for execution by the processor in the module 210, 212, 214 in processing data to be provided to the central processor 220. The modules 210, 212, 214, in turn, use the received configuration parameters, and executable instructions in supporting their operation, e.g. for processing data to be provided to the central processor 220.
As described above, there may be more than one central processor 220 in remote locations in the hospital. If a module 210, 212, 214 is disconnected from one central processor 220, then the patient identifier information, the set-up parameters and/or the executable instructions previously sent to it are used to control the operation of that module 210, 212, 214 while it is disconnected. If the disconnected module 210, 212, 214 is reconnected to a central processor 220, possibly in a different location than the central processor 220 from which it is disconnected, then the reconnected module 210, 212, 214 sends data representing the patient identifier information, the operational characteristics of the module, and any patient physiological parameter data gathered while disconnected to the central processor 220 to which it is connected.
The central processor 220 also receives signals representing physiological parameters from the patient monitoring module 210 and possibly from the patient treatment modules 212, 214. These parameters may be relatively standard physiological parameter, such as EKG, heart rate, SpO2, etc. The central processor 220 may also initiate generation of a new parameter based on signals derived using the patient monitoring module 210 and/or the patient treatment modules 212, 214. For example, the new parameter may be associated with (a) gas exchange, (b) skin color, (c) haemodynamics, (d) pain and/or (e) electro-physiology.
The central processor 220 conditions the display generator 222 to generate signals representing an image for displaying these physiological parameters in an appropriate manner, e.g. a waveform, a status phrase or a number. The display generator 222 is coupled to the display device 223 which displays this image. The display generator 222 may optionally send appropriate image representative signals to the slave display device 224. The slave display device 224 may have a larger, higher resolution screen, or may simply be a display device at a location remote from the location of the central processor. The image generated by the display device 223, under the control of the central processor 220 and display generator 222, may also integrate the display of patient identification, treatment instructions and parameters and status from the patient treatment modules 212, 214 in an appropriate manner. In this manner, information from users as well as patient monitoring modules 210 and patient treatment modules 212, 214 may be integrated into one or more composite images displayed on display devices 223 and 224, for example.
The central processor 220 may also communicate with the central processors of corresponding processing device and display systems in other locations in the hospital, such as those in the ICU room 204, the emergency room 206 and the other critical care room 208 via the critical care area network 205. The central processor 220 may optionally communicate with a central hospital location via a hospital network 230, illustrated in phantom in
The central processor 220 is coupled to a communications and power hub 235. The communications and power hub 235 comprises the patient area network (PAN) 216 and also a set 240 of module connectors coupled to the PAN 216: e.g. a patient monitor connector 241, a ventilator connector 243, a fluid management hub connector 245, an anesthesia delivery system connector 247 and a fluid (IV pump) management connector 249. The connectors 240 permit the individual modules 210, 212, 214, 250, 260 to be plugged into and removed from the central unit 300 as required. In one embodiment, a user may activate a single mechanical release mechanism to remove a module 210, 212, 214, 250, 260 from the central unit 300 or reattach a module to the central unit 300. The connectors 240 pass data signals between the modules 210, 212, 214, 250, 260 and the central processor 220 via the PAN 216.
The communications and power hub 235 further comprises a power bus 234 for distributing power to the central unit 300. The power bus 234 is further coupled to the PAN 216 for receiving commands from and returning status to the central processor 220. The power bus 234 is also coupled to the connectors 240 (not shown to simplify the figure) to distribute power to the patient monitoring and/or treatment modules 210, 212, 214, 250, 260. In this manner, the central processor 220 may manage the power-on and power-off status of the patient monitoring and treatment modules 210, 212, 214, 250, 260 in accordance with a set of predetermined rules maintained in the central processor 220.
As described above, at least some of the attached modules 210, 212, 214, 250, 260 include circuitry, e.g. batteries, which permit them to continue to operate when disconnected from the central unit 300. When docked, the central processor 220 conditions these modules 210, 212, 214, 250, 260 to transition from operating on battery power to operating on the power supplied by the power bus 234 and recharge their batteries. The internal power supply circuitry of these modules 210, 212, 214, 250, 260 may also supply power supply status information, e.g. current battery capacity, to the central processor 220 through the connectors 240 and PAN 216. The central processor 220 may condition the display generator 222 to generate signals representing an image showing the battery charging condition of the patient monitoring and treatment modules 210, 212, 214, 250, 260 plugged into the central unit 300. This image may be displayed on the display devices 321, 331 and/or 225 in the main control panel 320, slave control panel 330 and/or remote display device 224, respectively.
As described above, the PAN 216 may be implemented as a wireless network. In such an embodiment, the central processor 220 may include a wireless communication interface to the PAN 216. Such an interface enables bidirectional communication with the patient monitoring and treatment modules 210, 212, 214, 250, 260 when they are disconnected from the central unit 300. This communications link enables the central processor 300 to maintain control of the patient monitoring and treatment modules 210, 212, 214, 250, 260 while they are disconnected from the central unit.
Individual patient monitoring and/or treatment modules 210, 212, 214, 250, 260 are coupled to corresponding ones of the connectors 240. For example, a patient monitor module 210 may be plugged into the monitor connector 241, a ventilator module 250 may be plugged into the ventilator connector 243, and so forth. The central unit 300 may include connectors 241, 243, 245, 247, 249 which are specific to the type of patient monitoring or treatment module, 210, 212, 214, 250, 260, expected to be plugged in. Alternatively, the modules 210, 212, 214, 250, 260 may be fabricated with the same type of connector and the connectors 240 may be the same type of matching connectors. In the former embodiment, a particular type of patient monitoring or treatment module 210, 212, 214, 250, 260 may be plugged into a connector 241, 243, 245, 247, 248 corresponding to that type of module. In the latter embodiment, any patient monitoring or treatment module 210, 212, 214, 250, 260 may be interchangeably plugged into any of the connectors 241, 243, 245, 247, 248.
As described above, the patient monitor module 210, plugged into the monitor connector 241, connects to a plurality of electrodes and sensors which may be placed on a patient. A monitoring pod 211 is used to connect the patient-connected electrodes to the patient monitor module 210. Similarly a ventilator module 250 may be plugged into the ventilator connector 243. The ventilator module 250, in turn, is coupled to a blower 254 and a humidifier 252. A fluid management hub 260 is plugged into the fluid management hub connector 245. Two fluid (IV pump) management modules 264 and 266 are plugged into the fluid management hub 267. Each fluid (IV pump) management module, 264, 266, is connected to an IV pump (not shown). An anesthesia delivery module is plugged into an anesthesia delivery connector 247. The anesthesia delivery module 214 is connected to a anesthesia delivery device (not shown). An individual IV pump 212 is coupled to an IV pump connector 249. Similar to the other IV pump modules 264 and 266, the fluid (IV pump) management module 212 is connected to an IV pump (not shown).
The central processor 220 is also coupled to the critical care area LAN 205, which, as illustrated in
It is further possible that a central processor 220 in a central unit 300 in a processing device and display system in one treatment room 202, 204, 206, 208 may communicate with a second central processor 220 in a central unit 300 in a processing device and display system in a different treatment room 202, 204, 206, 208 (
It is also possible for the central processor 220 to receive data from one or more of the patient monitoring and/or treatment modules 210, 212, 214, 250, 260, process that data and send control data to one or more of the patient treatment modules 212, 214, 250, 260 in response to the received data, in a manner to be described in more detail below.
The display generator 222 is coupled to a main control panel 320. The main control panel 320 includes a display device 321, a keyboard 322 and a pointing device in the form of a mouse 324. Other input/output devices (not shown) may be fabricated on the main control panel 320, such as: buttons, switches, dials, or touch screens; lights, LCDs, or LEDs; buzzers, bells or other sound making devices, etc. These input/output devices receive signals from and supply signals to the central processor 220, either through the display generator 222, or through separate signal paths, not shown to simplify the figure. The main control panel 320 may be fabricated as a part of the central unit 300, or may be fabricated as a separate unit. The display generator 222 is optionally coupled to a slave control panel 330, which substantially duplicates the functionality of the main control panel 320, but is located remote from the central unit 300. The display generator 222 is also optionally coupled to a slave display device 224. The slave display device 224 includes a display device 225, but does not include any of the other input/output devices included in the main control panel 320 and slave control panel 330.
In operation, the central unit 300 and main control panel 320 provide control and display functions for the patient monitoring and/or treatment modules 210, 212, 214, 250, 260 which are plugged into the common unit 300. A user may manipulate the input devices coupled to the main control panel 320, or slave control panel 330 if available, e.g. the keyboard 322, mouse 324 or other input devices described above. The resulting signals are received by the central processor 220. In response, the central processor 220 sends control signals via the PAN 216 to the patient monitoring or treatment modules 210, 212, 214, 250, 260 which are currently plugged into the central unit 300.
Concurrently, the central processor 220 receives data signals from the patient monitoring and/or treatment modules 210, 212, 214, 250, 260, as described above, and conditions the display generator 222 to produce a signal representing an image for displaying the data from the patient monitoring and/or treatment modules 210, 212, 214, 250, 260, in an appropriate manner. For example, if a patient monitor 210 having the capability of performing an EKG on a patient is plugged into the central unit 300, EKG lead data from the patient monitor 210 is supplied to the central processor 220 through the monitor connector 241 via the PAN 216. The central processor 220, in turn, conditions the display generator 222 to produce signals representing an image of the EKG lead signal waveforms. These image representative signals are supplied to the display device 321 in the main control panel 320, which displays the image of the waveforms of the EKG lead signals. An image representing the heart rate of the patient, derived from the EKG lead signals, may also be similarly displayed in numeric form. Images representing other physiological parameters measured by the patient monitor 210, e.g. blood pressure, temperature, SpO2, etc. may also be displayed, in an appropriate form, on the display device 321 of the main control panel 320 in a similar manner. The image data may also be displayed on the display device 331 of the slave control panel 330 and on the display device 225 of the slave display 224, if they are available.
In a similar manner, images representing data received from the patient treatment modules, 212, 214, 250, 260, may be displayed on the display devices 321, 331, 225 in an appropriate form. Such data may represent, for example, present settings for the respective treatment modules, such as specified drip rates for IV pumps attached to fluid management modules 212, 264, 266. This data may be represented by images of appropriate form. Such data may also represent physiological parameters which may be measured by the patient treatment devices 212, 214, 250, 260. For example, respiration loops may be displayed in graphical form based on data received from the ventilator module 250, or drip rates for attached IV pumps may be displayed in numerical form based on data received from the fluid management hub 260.
A user may select which physiological parameters to display on the display device 321 and may arrange the location on the display device 321 of the images displaying the selected physiological parameters. In addition, the user may select different physiological parameters to display on the display device 321 in the main control panel 320 than on the display device 331 in the slave control panel 330 and/or on the display device 225 in the slave display 224. Further, the slave display device 224 may have a display device 225 which is larger and/or higher resolution than those in the main control panel 320 and the slave control panel 330, so that the images may be more easily seen, and/or may be displayed at an increased resolution.
The central processor 220 may also receive data from the power bus 234 via the PAN 216 representing the state of the power supplies in the patient monitoring and treatment modules 210, 212, 214, 250, 260. The central processor 220 may, for example, condition the display generator 222 to generate a signal representing an image representing the current charge condition of the respective batteries in the patient monitoring and treatment modules 210, 212, 214, 250, 260 plugged into the central unit 300, either separately or in composite, based on data received from the power bus 234. Further, the patient monitoring and/or treatment modules 210, 212, 214, 250, 260 may provide data to the central processor 220 indicating an error condition in the module. The central processor 220 may condition the display generator 222 to generate a signal representing an image showing the user the error condition of that module.
The central processor 220 may also produce signals for controlling the operation of the other output devices on the main and slave control panel 320, 330, described above. For example, the central processor 220 may analyze the physiological parameters derived from signals received from the patient monitoring and/or treatment modules 210, 212, 214, 250, 260 to determine if any limits have been exceeded. This may entail separately calculating and verifying each physiological parameter response determined from a patient monitoring and/or treatment module, and comparing it to a predetermined parameter range to determine if it exceeds a limit, or analyzing more than one physiological parameter to determine if a function of those physiological parameters exceeds a limit. If a limit has been exceeded, then the central processor 220 may condition the output devices on the main and slave control panel 320, 330 to provide an alarm. For example, the central processor 220 may generate a signal which activates a light, a buzzer, a bell and/or other such device on the main control panel 320, and/or the slave control panel 330, if available, to produce a visible or an audible alarm. The central computer 220 may also send a signal over the critical care area LAN 205 and/or the hospital LAN 230 indicating that a limit has been exceeded. A similar alarm may be generated at the remote location in response to the receipt of this signal.
In
A first Ethernet adapter 404 couples the CPU 402 to the patient area network (PAN) 216, which in turn is interconnected with patient monitoring and/or treatment modules 210, 212, 214, 250, 260. A second Ethernet adapter 406 couples the CPU 402 to the critical care area LAN 205. A third Ethernet adapter 432 couples the CPU 402 to the hospital LAN 230 which in turn is interconnected with the central storage device 232.
The display generator 222 couples the CPU 402 to the display devices 321, 331 and 225 in the main control panel 320, the slave control panel 330 and the slave display 224, respectively. A set of panel I/O ports 410 couple the CPU 402 to the panel I/O devices, described above, on the main control panel 320 and the slave control panel 330. As previously described, such I/O devices may include rotary switches, touch panels, pushbutton keys, lights, and so forth.
A watchdog circuit 430 checks the proper operation of the CPU 402 and produces a signal indicating a fault condition if the CPU 402 is not operating properly. The watchdog circuit 430 may check for proper operation of the CPU 402 using any of a variety of methods. For example, the watchdog circuit 430 may send a challenge signal at regular intervals to the CPU 402. If the CPU 402 is operating properly, it receives and recognizes the challenge signal, and provides a reply signal back to the watchdog circuit 430. If the watchdog circuit 430 does not receive the reply signal back from the CPU 402 within a specified time of issuing the challenge signal, then it detects a fault in the CPU 402, and produces the fault condition signal. The watchdog circuit 430 may also attempt to restart operation, i.e. reboot of the CPU 402, upon detecting a fault in the operation of the CPU 402.
The remainder of the elements illustrated in the central unit 300 are typically included in personal computers. A keyboard/mouse interface 408, typically using a PS/2 or USB standard, couples the keyboard 332 and mouse 324 to the CPU 402. A sound card 412 responds to instructions from the CPU 402 to generate sound representative signals, which may be coupled to speakers (not shown) to reproduce sound. A read-write memory unit (RAM) 414 provides local storage for programs controlling the CPU 402 and for data used and/or created by the CPU 402. A serial port 416 exchanges serial binary data signals with external peripherals e.g. using the RS232 standard. A USB port 418 similarly exchanges serial binary data signals with external peripherals using the USB standard. A DVD/CD player 420 allows the CPU 402 to access data on DVDs and/or CDs. It is also possible to write data onto DVDs and/or CDs. An expansion card port 422 allows the CPU to exchange data with portable devices, such as a Personal Computer Memory Card International Association (PCMCIA) card, Compact Flash (CF), Secure Digital (SD), and so forth. A real time clock (RTC) 424 with its associated battery 425, maintains and provides current time and date to the CPU 402. An integrated drive electronics (IDE) bus 426, into which conforming cards may be plugged, allow such cards to exchange information with the CPU 402. Similarly, a peripheral component interconnect (PCI) bus, into which conforming cards may be plugged, allow such cards to exchange information with the CPU 402. Cards plugged into either the IDE bus 426 or the PCI bus 428 may be coupled to peripheral devices, both internal and external to the central unit 300, and permit the CPU 402 to exchange data with the peripheral devices.
In operation, the CPU 402 interacts with the peripheral devices connected to it under control of software. Because the central unit 300 is designed and implemented similarly to a typical personal computer, it may be controlled using software typically executed on a personal computer, augmented by executable applications for performing specialized tasks related to monitoring and providing treatment to patients.
Each element in
The system software 500 illustrated in
The software framework 502 includes a hardware dependent operating system 506, which in
The software framework 502 further includes a set of common platform components 508 (see Table 1 (below)). These components provide monitoring and executive functions for the central unit 300. Specifically, a watchdog function, a resource monitor, and a monitor for critical components are provided by the common platform components 508. In addition, the common platform components 508 provide security, lifetime management, diagnostics, real time infrastructure and event management, safety and availability management, and user set up configuration support for the central unit 300.
The software framework 502 also provides common communications component 510 (see Table 1 (below)). More specifically, the common communications component provides access to the PAN 216, the critical care area network 205 and any other networks to which the central unit 300 may be coupled, such as the hospital network 230 (
The software framework 502 also provides a common human interface component 512 (see Table 1 (below)). The common human interface component 512 provides functions for displaying graphical user interfaces (GUIs) on display devices 225, 321, 331 (
These functions also include those GUI functions which are specific to a patient monitoring and treatment module, for example, support for the display of waveforms, such as EKG waveforms or respirator loops, maintenance of trends, and generation of reports. These GUI functions also include the ability for a user to arrange on the screen of the display device the images representing the physiological parameters of the patient. That is, to be able to move those images around on the screen, to resize them, to remove an image displaying a physiological parameter and/or to insert an image displaying a different physiological parameter. The common human interface 512 further supports maintenance of patient data and status, and the database containing these and/or other data items. The common human interface 512 component further provides alarm support and processing, including providing functions for generating an audible and/or visible alarm at the central unit 300 (
The remainder of the components in the system software are application programs 520. An application program is software which uses functions provided by the software framework 502, described above, to support clinical domains and/or to provide clinical functions at the point of care. As used herein, a clinical domain is an area of a patient monitoring and/or treatment process. For example, patient monitoring is a clinical domain; patient ventilation is another clinical domain; anesthesia and fluid administration are others, and so forth. The system software 500 includes several types of application programs 520.
The application programs 520 include a set of common point of care (POC) applications 522 (CPOC) which are common to the clinical domains (see Table 1 (below)). The functions provided by the CPOC 522 are application-related but generic and not specific to any particular domain. That is, the central processor 402 in the central unit 300 executes at least a portion of the common code in the CPOC application 522 to support the operation of two or more of the patient monitoring and/or treatment modules 210, 212, 214, 250, 260.
For example, the CPOC application 522 may provide a home screen from which other functions may be selected and configured. Functions for configuring and controlling the central unit 300 itself may be selected from the home screen, including: software option handling; application selection and configuration; remote control, both wired and wireless, from e.g. slave control units (
One skilled in the art will recognize that point of care (POC) patient monitoring and/or treatment modules, e.g. 210, 212, 214, 250, 260 (
Typically, SPOC applications 523, 524, 526 have a presentation function e.g. 523A, a control and management function e.g. 523B, a data server function e.g. 523C, and a pluggable front-end (FE) module interface function e.g. 523D. As used herein, the term pluggable front end module refers to a medical monitoring and/or treatment module, such as modules 210, 212, 214, 250, 260 (
More specifically, the SPOC application 526, which is associated with a patient monitoring module 210, provides the specific functions required to control and interact with the monitoring module 210. As described in more detail in Table 1 (below), the monitoring SPOC 526 provides module management, control and report functions, such as: monitor setup; export protocol management; nurse call; and setting display modes, including bedside and surgical display modes. The monitoring SPOC 526 also provides physiological parameter monitoring functions, such as: EEG, SpO2, respiratory mechanics, invasive and non-invasive blood pressure, body temperature, transcutaneous blood gases, and so forth.
The SPOC application 523, which is associated with the anesthesia module 214, provides the specific functions required to interact with the anesthesia module 214. As described in more detail in Table 1 (below), the anesthesia SPOC 523 provides module management, control and report functions such as: warm up; carrier gas selection, and so forth. The anesthesia SPOC 523 also provides anesthesia control and monitoring functions, such as anesthetic gas control, including N2O, Xenon, etc.; consumption monitoring, and anesthetic gases supply, and so forth.
The SPOC application 524, which is associated with the fluid management module 212, provides the specific functions required to interact with the fluid management module 212. As described in more detail in Table 1 (below), the fluid management SPOC 524 provides functions supporting different fluid managements modes, including: total controlled infusion (TCI), total intravenous anesthesia (TIVA), and patient controlled analgesia (PCA). As described above, other medical monitoring and/or treatment modules 210, 212, 214, 250, 260, corresponding to other medical domains, are associated with SPOC applications which control and manage them. Details for these SPOCs are described in detail in Table 1 (below).
The application programs 520 further include cross domain POC applications (CDPOC), one of which 528 is shown in
Referring specifically to
The application programs 520 may further include imaging applications 530, as described in more detail in Table 1 (below). These applications condition the various display devices, 225, 321, 331 (
The application programs 520 may further include information technology (IT) applications 532, as described in more detail in Table 1 (below). Such applications may include e.g. a chart assistant program, a remote viewing program, and other programs for exchanging and analyzing information. Other third party applications 534 may also be included in the application programs 520. As used herein, third party applications 534 may provide clinical functions which may provide a benefit at the point of care, and may be developed outside and independently of the architecture developed for the central unit 300 to interact with the medical monitoring and/or treatment modules 210, 212, 214, 250, 260. For example, medical image and report distribution, appointment scheduling, client records management, copayment tracking and billing, medical charting, insurance submission and billing, scheduling, and so forth are functions which may be provided by third party application programs 534.
A Semantical Product Application (SPA) 536 provides coordination for the application programs 520 included in the system software. The SPA 536 covers the target domain or domains of the system, as configured with selected medical monitoring and/or treatment modules 210, 212, 214, 250, 260. The SPA 536 uses, deploys and combines other application programs 520. More specifically, the SPA 536 includes SPOC 523, 524, 526 configuration; CPOC 522 configuration; and CDPOC 528 configuration functions, and so forth. The SPA 536 also provides version management for the system.
The central units 300 in the respective critical areas and/or the hospital employ substantially the same type of CPU 402 and are implemented to support the operation of the different types of patient monitoring and/or treatment modules 210, 212, 214, 250, 260. In addition, the central processor 220 in the respective central units 300 in the critical care area and/or the hospital employ substantially the same system software 500, described above, supporting the operation of the patient monitoring and/or treatment modules 210, 212, 214, 250, 260.
The hardware and software architecture described above and illustrated in
More specifically, a fabricator may implement a product such as a transportable breathing support equipment system. Such a device is illustrated in
Other products such as an emergency room product as illustrated in room 206 (
As described above, a CDPOC application 528 can advantageously coordinate the operation of two or more SPOC applications 523, 524, 526, which in turn control the operation of associated patient monitoring and/or treatment modules 210, 212, 214, 250, 260. This coordination enables the central processor 220 (
The central processor 220 may also verify the safety of the treatment by receiving data from the patient monitoring and/or treatment modules 210, 212, 214, 250, 260 and using said received data to determine whether settings of the treatment delivery devices attached to the patient treatment modules 212, 214, 250, 260 are compatible with the desired treatment to be delivered to a patient. That is, the central processor 220 may verify the safety of a desired treatment by comparing patient physiological parameters received following initiation of delivery of a treatment, or following a change in the treatment induced by a corresponding change in the settings of a patient treatment module 212, 214, 250, 260, with predetermined physiological parameter value response ranges. In response to a determination that the settings of a patient treatment module 212, 214, 250, 260 are incompatible with a desired treatment the central processor 220 may (a) automatically alter the settings and/or (b) initiate generation of an alert message to a user warning of the incompatibility.
This coordination among different patient monitoring and/or treatment modules 210, 212, 214, 250, 260 allows patient medical tests to be performed, and physiological parameters to be determined, by such a system, without requiring the use of more expensive, or more invasive testing methods. A single configured system as illustrated in
A general form of such patient medical tests involves providing a predetermined physiological stimulus to a patient, monitoring the patient physiological parameters after the stimulus, and verifying an acceptable response. For example, the physiological stimulus may be (a) a medication, (b) a gas administered to said patient, (c) an electrical stimulus, (d) a physical or mechanical stimulus, (e) an application of heat or cold, (f) an acoustic stimulus, (g) a light stimulus and/or (h) a radiation stimulus. The patient physiological parameters monitored may be (a) BP, (b) HR, (c) RR, (d) SpO2, (e) O2, (f) CO2, (g) NBP, (h) EEG and/or (i) blood gas parameters.
In the system described above, the central processor 220 (
A more specific example of a medical test is a respiratory systolic variation test (RSVT), which may be performed by such a system. This test determines the blood filling conditions in the left atrium. It enables a physician to manage fluid input and output of a patient, and lung recruitment efforts (hypovolemea is often the reason for a patient not tolerating pressure-controlled inverse ratio ventilation (PCIRV)). The result of this test is a patient physiological parameter which may be displayed on the display devices 225, 321, 331 (
A Gedeon non-invasive cardiac output test (NICO) may also be performed by the system described above. This test estimates output of the left ventricle and effective gas exchange area of the lungs (i.e. the effective lung volume (ELV). It enables a physician to titrate the positive end-expiratory pressure (PEEP) for optimal CO and ELV after initiating mechanical ventilation. As used herein, the term “titrate” refers to the adjustment of a patient treatment parameter (such as the PEEP pressure) such that a desired patient physiological parameter is achieved (that is, optimal CO and ELV). The titration may be performed manually by the physician in response to the results of the test, or may be performed automatically under the control of a CDPOC (not shown) programmed to perform the test and titrate the PEEP parameter. The results of this test may be displayed on the display devices 225, 321, 331 (
A lung mechanics calculation test (LMC) may also be performed by the system described above. This test permits the modeling of a patient respiratory system in terms of elastic and resistive forces. More specifically, this test may determine inflection points in the respiratory cycle, i.e. points of alveolar collapse (atelectasis) during expiration and hyperinflation during inspiration. This test may also calculate physiological dead space, i.e. air which is inhaled by the body in breathing, but which does not partake in gas exchange. The results of the former test may be numerical or a graphic display, and the results of the latter test may be a numerical display, either or both of which may be displayed on the display devices 225, 321, 331 (
A stress index test (SI) may also be performed by the system described above. This test quantifies the stress on the lungs induced by mechanical ventilation. More specifically this test detects and measures the effect of cyclic stretch, i.e. recruitment of alveola at the extreme end of inspiration and collapse at the extreme end of expiration. The results of this test may be numeric or graphical and may be displayed on the display devices 225, 321, 331 (
An automatic lung parameter estimator test (ALPE) may also be performed by the system described above. This test assists a physician in quantifying the amount of pulmonary shunt and the distribution of pulmonary circulation (e.g. ventilation-perfusion ratio (V/Q) scatter). This test may also detect and quantify cardiac congestion, i.e. congestive heart failure (CHF). The results of this test may be numeric or graphical and may be displayed on the display devices 225, 321, 331 (
Diaphragm electromyographically (EMG) controlled ventilation may also be advantageously performed by the system described above. In this ventilation mode the electrical signal related to the diaphragm muscle contraction is detected using electrodes on an oesphageal catheter. Because contraction of the diaphragm muscles occurs when a patient begins to take a breath, the EMG signal may be used to trigger the ventilator to begin a respiration cycle. Thus, this ventilation mode permits the patient's brain to advantageously control respiratory support. This mode may be selected by a user selection via the interaction of the GUI and user input devices such as the keyboard 322 and mouse 324, or by panel I/O devices on the main control panel 320 and/or slave control panel 330 (
The system described above may also be used to perform electrical impedance tomography (EIT). EIT may provide continuous, breath-to-breath, and beat-to-beat anatomical images of respiratory and cardiac dynamics and distribution, respectively. More specifically, the physician may see and quantify areas of atelectasis and hyperinflation in the lungs and/or may see and quantify the output of the right ventricle and the deposition of blood in the lungs with each heartbeat. Electrodes for providing current and sensing voltage are applied to the patient and appropriate signals are applied to them to sense the conductivity of the respective portions of the body. From these readings, an anatomical image, or real-time series of images, may be synthesized. The display generator 222 (
Referring again to
As described above, a patient monitoring and/or treatment module 210, 212, 214, 250, 260 is sometimes removed from a central unit 300 in one location and reconnected to a central unit 300 at a different location (
A system described above integrates passive patient monitoring modules 210 (
Claims
1. A processing device and display system supporting a plurality of different modules providing different functions used in delivering healthcare to a patient, comprising:
- a patient monitoring module, including a processor, for acquiring and processing signals derived from sensors suitable for attachment to a patient;
- a patient treatment module, including a processor, supporting delivering treatment to the patient using a treatment delivery device; and
- a central processor for exchanging data with module processors and for processing signals derived from said patient treatment module to support monitoring of patient condition while concurrently monitoring operation of said treatment delivery device in delivering said treatment to said patient.
2. A processing device and display system supporting a plurality of different modules providing different functions used in delivering healthcare to a patient, comprising:
- a patient monitoring module for acquiring and processing signals derived from sensors suitable for attachment to a patient and at least one second module supporting delivering treatment to the patient using a treatment delivery device, said second module comprising at least one of: (a) a module supporting delivery of anesthesia to a patient; (b) a module supporting ventilation of a patient; and (c) a module supporting infusion pump control; said second module includes a processor supporting operation of functions of said second module; and
- a central processor for exchanging data with module processors and for processing signals derived from said at least one second module to support monitoring of patient condition while concurrently monitoring operation of said treatment delivery device in delivering said treatment to said patient.
3. The system of claim 2 wherein said central processor initiates a stimulus to a patient by temporarily changing operational settings of a treatment delivery device using said at least one second module and by measuring a response to said change by monitoring said derived signals using said patient monitoring module.
4. The system of claim 3 wherein said central processor calculates and verifies an acceptable response by comparing a determined patient parameter derived based on said derived signals against a predetermined parameter range.
5. The system of claim 2 wherein said central processor supports monitoring operation of said treatment delivery device by at least one of, (a) deriving data, based on combinations of parameters from said patient monitoring module and a second module, for presentation to a user and (b) prompting a user with suggested treatment delivery device configuration settings.
6. The system of claim 5 wherein said treatment delivery device is at least one of:
- (a) apparatus for delivering anesthesia to a patient;
- (b) apparatus supporting patient breathing;
- (c) an infusion pump device for delivering a fluid infusion to a patient;
- (d) an incubator;
- (e) a defibrillator;
- (f) a warming device;
- (g) a diagnostic imaging device;
- (h) a photo-therapy device;
- (i) a fluid output support device;
- (j) a heart-lung support device;
- (k) a blood gas monitor;
- (l) a controllable implanted therapy device; and
- (m) a controllable surgical table and weighing scale.
7. The system of claim 2 wherein said central processor verifies safety of treatment delivered using said treatment delivery device by receiving data from said treatment delivery device and using said received data in determining whether settings of said device are compatible with a treatment to be delivered to a patient using said device.
8. The system of claim 7 wherein said central processor, in response to a determination said settings of said device are incompatible with a treatment, at least one of, (a) automatically alters said settings and (b) initiates generation of an alert message to a user warning of said incompatibility.
9. The system of claim 2 wherein said central processor supports monitoring operation of said treatment delivery device by deriving data, based on combinations of parameters from said patient monitoring module and a second module, for presentation to a user.
10. The system of claim 2 wherein said central processor manages operation of said treatment delivery device.
11. The system of claim 2 wherein said central processor verifies safety of a treatment delivered using said treatment delivery device by comparing patient parameters received, following initiation of delivery of a treatment using said healthcare device, with predetermined parameter value response ranges.
12. The system of claim 2 wherein said central processor verifies safety of a modified treatment delivered using said treatment delivery device by comparing patient parameters received, following a change in settings of said device, with predetermined parameter value response ranges.
13. The system of claim 2 including a display generator for initiating generation of data representing at least one user interface image including processed signal information of said first and at least one second module.
14. The system of claim 2 wherein said central processor configures said at least one second module by communicating configuration parameters to a processor of said at least one second module.
15. The system of claim 14 wherein:
- said central processor and said display generator are housed in a central unit for adaptively accommodating said at least one second module; and
- said at least one second module is removable from said central unit and capable of operation while external to said central unit.
16. The system of claim 2 wherein said patient parameters derived using said patient monitoring module include at least two of, (a) a blood pressure parameter, (b) a ventilation parameter, (c) a vital sign parameter, (d) a blood oxygen concentration representative parameter, (e) an infusion pump parameter associated with fluid delivery, (f) a drip medication related parameter, (g) an anesthesiology device parameter and (h) another fluid related parameter.
17. The system of claim 2 wherein said patient parameters derived using said patient monitoring module include at least one of, (a) RSVT, (b) NICO, (c) LMC, (d) ALPE, (e) EMG, (f) EIT, and (g) SI.
18. The system of claim 2 wherein said patient parameters derived using said patient monitoring module include at least one of, (a) BP, (b) HR, (c) RR, (d) SpO2, (e) O2, (f) CO2, (g) NBP and (h) EEG.
19. A processing device and display system supporting a plurality of different modules providing different functions used in delivering healthcare to a patient, comprising:
- a patient monitoring module for acquiring and processing signals derived from sensors suitable for attachment to a patient and at least one second module supporting delivering treatment to the patient using a treatment delivery device, said second module comprising at least one of:
- (a) a module supporting delivery of anesthesia to a patient;
- (b) a module supporting ventilation of a patient; and
- (c) a module supporting infusion pump control;
- said second module includes a processor supporting operation of functions of said second module; and
- a central processor for exchanging data with module processors and for initiating a stimulus to a patient by temporarily changing operational settings of a treatment delivery device using said at least one second module and by verifying an acceptable response to said change by monitoring said derived signals using said patient monitoring module.
20. The system of claim 19 wherein said central processor verifies an acceptable response by comparing a determined patient parameter derived based on said derived signals against a predetermined parameter range.
21. The system of claim 19 wherein said patient parameters determined using said patient monitoring module include at least one of, (a) RSVT, (b) NICO, (c) LMC, (d) ALPE, (e) EMG, (f) EIT, and (g) SI.
22. The system of claim 19 wherein said patient parameters determined using said patient monitoring module include at least one of, (a) BP, (b) HR, (c) RR, (d) SpO2, (e) O2, (f) CO2, (g) NBP, (h) EEG and (i) blood gas parameters.
23. The system of claim 19 wherein said stimulus to said patient comprises at least one of, (a) a medication, (b) a gas administered to said patient, (c) an electrical stimulus, (d) a physical or mechanical stimulus, (e) an application of heat or cold, (f) an acoustic stimulus, (g) a light stimulus and (h) a radiation stimulus.
24. The system of claim 19 wherein said central processor initiates generation of a new parameter based on said signals derived using said patient monitoring module.
25. The system of claim 24 wherein said new parameter is associated with at least one of, (a) gas exchange, (b) skin color, (c) haemodynamics, (d) pain and (e) electro-physiology.
Type: Application
Filed: Oct 28, 2004
Publication Date: Jun 9, 2005
Inventors: Joseph Elaz (North Andover, MA), Wolfgang Scholz (Beverly, MA), Samuel Cavallaro (Warner, NH), Jay Butterbrodt (Noth Andover, MA)
Application Number: 10/976,025