JP2012011204A5 - - Google Patents

Description

(Brief description of the drawings)
The invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. In the drawings, like reference numerals designate corresponding parts throughout the several views.
1 is a schematic representation of a patient care system. The patient care system includes a pharmacy computer, a central system, and a digital assistant at the treatment location. FIG. 2 is a block diagram of a computer system representing the computer, central system, and / or digital assistant of the pharmacy of FIG. The system includes an infusion system or part thereof. 2 is a schematic representation of a portion of the patient care system of FIG. It is a block diagram which shows the functional element of the patient medical system of FIG. 2 is an exemplary computer screen for performing various functions of the patient care system of FIG. FIG. 3 is a block diagram showing functional elements of the injection system of FIG. 2. Functional elements include, among other things, blocks for infusion system parameter setting, infusion order creation, infusion order preparation, medication administration, infusion order modification, and messaging. It is a block diagram which shows the functional element for an injection | pouring system parameter setting of FIG. It is a block diagram which shows the functional element for injection | pouring order preparation of FIG. It is a block diagram which shows the functional element for the injection order preparation of FIG. It is a block diagram which shows the functional element for chemical | medical agent administration of FIG. FIG. 7 is a block diagram showing functional elements for injection order documentation, injection order modification, and messaging of FIG. 1 is a diagram of an emergency notification system showing communication. FIG. FIG. 4 is an emergency notification interface view from the notification party perspective showing preferred notification options provided to the notification party by the emergency notification system. FIG. 3 is an emergency notification interface view from the target party perspective showing preferred emergency information received by the target party. 6 is an embodiment of a flowchart of an alarm / alert escalation process. It is a figure of an alarm / alert interface screen. FIG. 10 is another diagram of an alarm / alert interface screen. FIG. 10 is another diagram of an alarm / alert interface screen. FIG. 6 is a diagram of an interface screen viewed from a clinician's handheld device. It is a figure of the interface screen of a login process. It is a figure of another interface screen of the login process of FIG. It is a figure of a department selection interface screen. It is a figure of a shift selection interface screen. It is a figure of a patient browsing interface screen. It is a figure of a patient selection interface screen. It is a figure of a patient information menu interface screen. It is a figure of an allergy / height / weight interface screen. It is a figure of a medicine history interface screen. It is a figure of a test result interface screen. It is a figure of a medicine delivery schedule interface screen. It is another figure of the interface screen of the medicine delivery schedule process of FIG . It is a figure of the interface screen of workflow injection | pouring stop. It is another figure of the interface screen of workflow injection | pouring stop. It is a figure of the interface screen of the workflow for restarting injection | pouring. It is a figure of the interface screen of the workflow for restarting injection | pouring . It is another figure of the interface screen of the medicine delivery schedule process of FIG. It is a figure of a medication failure interface screen. It is another figure of the interface screen of FIG. It is another figure of the interface screen of FIG. It is a figure of a schedule interface screen. It is a figure of a medicine interface screen. It is a figure of a scan interface screen. It is a figure of another scan interface screen. It is a figure of a medicine administration interface screen. It is a figure of a route confirmation interface screen. It is a figure of a pump channel scan interface screen. FIG. 12 is a diagram of another pump channel scan interface screen. It is a figure of a comparison interface screen. It is another figure of a comparison interface screen. It is another figure of a comparison interface screen. It is another figure of a comparison interface screen. It is another figure of a comparison interface screen. It is a figure of a pump status interface screen. It is a figure of a flow velocity history interface screen. It is a figure of a communication loss interface screen. It is a figure of a communication loss interface screen. It is a figure of a low battery interface screen. It is a figure of a hub. FIG. 6 is a diagram of various icons used on the interface screen. It is a figure of an implementation result recording interface screen. FIG. 3 is a medication order with a monitoring parameter link. It is a figure of the monitoring parameter input interface screen. It is a figure of a cycle count interface screen. It is a flowchart of an order comparison process. 1 is a schematic diagram of a flow control system with micro-electromechanical system (MEMS) elements connected to a line set. FIG. FIG. 4 is a schematic block diagram of software components loaded on the first central computer of FIG. 3. 3 is a flowchart of an exemplary injection implementation process. 3 is a flowchart of an exemplary injection implementation process. 3 is a flowchart of an exemplary injection implementation process. 3 is a flowchart of an exemplary channel scan process. 3 is a flowchart of an exemplary pump channel change process. 3 is a flowchart of an exemplary pump channel change process. 6 is a flowchart of another exemplary channel scan process. 6 is a flowchart of yet another exemplary channel scan process. 6 is a flowchart of an exemplary injection stop / stop process. 6 is a flowchart of an exemplary injection restart process. 3 is a flowchart of an exemplary pump removal process. 4 is a flowchart of an exemplary authentication process. 4 is a flowchart of an exemplary authentication process. 4 is a flowchart of an exemplary authentication process. 4 is a flowchart of an exemplary authentication process. 4 is a flowchart of an exemplary authentication process. 4 is a flowchart of an exemplary authentication process. 4 is a flowchart of an exemplary authentication process.

(General system)
Turning to FIG. 3, the patient medical system 100 can include a plurality of medical devices 120. In one embodiment, the medical device is an infusion pump 120. In yet another embodiment, the medical device is an infusion pump controller. For ease of reference, the present disclosure generally identifies the medical device of the system as an infusion pump, but the entire system 100 can incorporate any one or more of a variety of medical devices. Is understood. Accordingly, a plurality of infusion pumps 120 are connected to the hub or interface 107 as shown in FIG. As described in further detail herein, the infusion pumps 120 may be of a conventional design with each infusion pump 120 associated with a single patient. However, as will be appreciated by those skilled in the art, the infusion pump 120 shown in FIG. 3 need not be associated with the same patient or treatment location, even though the infusion pump is connected to the same hub 107. Further, each infusion pump 120 may be a single channel pump or a multichannel pump such as a three channel pump . In general, the pump periodically transmits a message containing pump status information to the hub 107. To centralize communication for cost effectiveness and / or to allow redesign of an existing medical device that is not currently in communication with the central computer system 108 so that each such medical device is connected to the central computer system 108 A separate hub 107 can be used away from the medical device 120 so that it can communicate.

Turning to FIG. 54, this will be described. The server 109 is preferably a COMPAQ DLG-380 having a MICROSOFT WINDOWS® 2003 server operating system 5414. In one embodiment, the software components loaded into the storage device of the first central computer 109 are. A first central computer or server application 5412 in the NET Framework 5416, an Active Directory Domain Service 5418 for user and device authentication, a temporary data storage SQL server 5420 (shown as a database), and an Internet Information Server II for application hosting 5422 including. . NET Framework 5416 is a Microsoft. Preferably NET Framework 1.1 or above; NET Framework connects the first central computer application 5412 to the operating system, Internet Information Server 5422, SQL database 5420, and Active Directory Domain Service 5418 component. As will be appreciated by those skilled in the art, the Active Directory Domain Service 5418 provides a service utilized by the Windows® server operating system 5414 and the first central computer application 5412 to provide a genuine and authorized hub subsystem. , To help ensure that only users of the second central computer subsystem and the personal digital assistant subsystem can access the first central computer and thus the application 5412 of the first central computer.

The medication management module 302 can coordinate the functions of other modules of the patient care system 100 that are included in the management of medical therapy. The medication management module 302 cooperates with the rest of the patient care system 100 as a whole. The medication management module 302 operates with and / or interfaces with the CPOE, operates with and / or communicates with the point-of-care module, and operates with and / or communicates with the medical therapy comparison module Submodules can be included. In FIG. 4, an entrance and exit (ADT) interface 310, a billing interface 312, a laboratory interface 314, and a pharmacy interface 316 are shown. The ADT interface 310 is used to capture information such as patient demographic data, size, weight, and allergies. In a preferred embodiment, the ADT system uses an HL7 type interface to transfer events entered into the hospital ADT system into the second central computer 108a. HL7 is a protocol for formatting, transmitting and receiving data in a medical environment. This provides interoperability between medical information systems through messaging standards that allow disparate medical applications, such as a variety of different third party applications, to exchange key sets of clinical and management data. Normally, in the system 100 of the present invention, the HL7 ADT interface consists of three applications: an HL7 ADT server, an HL7 ADT client, and an HL7 ADT viewer. The pharmacy interface 316 imports orders from pharmacies. The pharmacy interface 316 may be an HL7 type interface, and the HL7 type interface interfaces with other systems and inputs an order such as CPOE. This feature reduces the need to enter data into the patient care system 100 more than once. The pharmacy interface 316 can be configured to communicate with commercially available third party systems such as, but not limited to, Cerner, HBOC, Pyxis, Meditech, SMS, Pharmous, and the like. The web service interface can provide near real-time coordination between point-of-care medication management systems that support oral medication administration, such as McKesson AdminRx, Pyxis, Verif5, etc., and infusion pump related medication management. Various other interfaces are known to those skilled in the art, but are not shown in FIG.

Clinician 116 identifies itself by scanning badge 116a, identifies patient 112 by scanning wristband 112a, identifies drug 124 by scanning drug label 124a, and scans label 120d. Thereby identifying a medical device 332, such as infusion pump 120. The clinician 116 may also identify himself / herself by providing the fingerprint and / or password described above and shown in the login screen 1903 of FIG. The medical device 332 can be a medical device capable of bidirectional communication with the medication management module 302. Alternatively, the medical device 332 may only be able to provide information to the medication management module 302. The infusion system 210 assists the clinician 116 in applying and validating medical therapy. In an alternative embodiment, the infusion system 210 can include the ability to download operating parameters to the medical device 332. The clinician 116 can perform visual verification to confirm that the third copy 322 and / or MAR matches the labeled drug 124. The scanner 338 can be used to input machine readable information from the third copy 322 to the wireless device 330 and the medical device 332.

The infusion order creation block 504 includes functional blocks that are used to create an infusion order. The infusion order creation block 504 includes functions similar to those described with reference to the prescription creation block 304 (FIG. 4). The infusion order creation block 504 includes, but is not limited to, a block 560 for inputting information, a calculation block 562, a check block 564, and an overriding block 566 . The injection order creation will be further described below with reference to FIG. The result of creating the injection order is the injection order 702 (FIG. 8). Infusion order 702 typically includes an infusion schedule 704 (FIG. 8).

(Order creation)
FIG. 8 is a block diagram illustrating functional elements for the injection order creation 504 of FIG. Infusion order creation 504 includes functional blocks for creating infusion orders. Infusion order creation 504 includes information input 560, calculations 562, checks 564, and overrides 566 . Information input 560 may include functions such as, but not limited to, order type identification 560a, drug identification 560b, dose identification 560c, diluent identification 560d, flow rate identification 560e, and injection site identification 560f.

The calculations 562 can include calculations such as, but not limited to, a bag volume calculation 562a, a transformation calculation 562b, a duration versus volume calculation 562c, and a flow rate versus infusion rate calculation 562d. Check 564 includes various checks that can be received by the infusion order. Checks include, but are not limited to, a net concentration check 564a, a flow rate check 564b, an administration time check 564c, a duration check 564d, and an injection site check 564e. If the infusion order gets caught at check 564, clinician 116 can override the check. Overrides 566 can include overrides such as , but not limited to, net concentration override 566a , flow rate override 566b , administration time override 566c , duration override 566d , and injection site override 566e . Override 566 can generate 520 a message for the physician and / or pharmacy. The infusion system 210 can distinguish between system-wide and subsystem overrides in determining whether it is necessary to generate 520 a message.

The override can include an indication of whether the clinician has the authority to override the tolerance. For example, the flow rate override 566b may indicate whether the clinician entering the infusion order has the authority to override the system flow rate tolerance 542b. This display can be applied to the patient care system 100 or subsystem. The duration override 566d may indicate whether the clinician 116 entering the infusion order has the authority to override the system duration 542d. This display can be applied to the patient care system 100 or subsystem. Override 566 also includes an indication of override reason 566f . The reason for overriding 568f can be selected by the clinician 116 from a drop-down menu.

The modification change 1002 includes a new duration identification 1002a, a new flow velocity identification 1002b, a new injection site identification 1002c, a correction reason identification 1002d, a remaining amount identification 1002e in the injection bag, and a stop order 516. It is. The ordering options available during initial infusion order creation 504 are typically also available for infusion order modification. The ordering options available during initial order creation 504 include those shown in FIG. Recheck 1006 and recheck override 1008 are similar to check 564 and override 566 described with reference to FIG. The new flow rate versus new infusion rate display 1010 assists the clinician in minimizing the potential for errors during drug administration 512. The modified infusion order can result in a modified infusion schedule.

Documentation 1012 captures injection order information in real time. Documentation includes, but is not limited to, documenting multiple injections in progress and duration change 1012a , flow rate change 1012b , volume change 1012c, and injection site change 1012d .

Although the present disclosure focuses on the use of infusion pump 120 in system 210, it is understood that other medical devices can be used in system 210 without departing from the scope of the present invention. For example, various types of medical devices include, but are not limited to, infusion pumps, ventilators, dialysis machines, and the like. An additional type of medical device is a microelectromechanical system (MEMS) component. MEMS is a technique used to create very small devices that can be smaller than millimeters in size. MEMS devices are typically is manufactured from a glass wafer or silicon, this technology has grown far beyond its origins of the semiconductor industry. Each MEMS device is a microsystem integrated on a chip that can incorporate moving mechanical components in addition to optical, fluidic, electrical, chemical and biomedical elements. The resulting MEMS device or element is responsive to many types of inputs including pressure, vibration, chemicals, light, and acceleration. The MEMS component can be several different elements including various types of pumps, flow valves, flow sensors, tubes, pressure sensors or combinations of elements.

Thus, as further described in detail below, one use of the MEMS component is as an in-line MEMS pump 5314 shown schematically in FIG. The MEMS pump 5314 can pump fluid contained within the infusion bag 5320 through the tube 5312 and through the access device 5324 from there into the patient's body. The MEMS component has a MEMS local electronics element attached to it, the MEMS electronics element is connected to an external durable MEMS controller, the MEMS controller being described herein. Like the infusion pump 120 of the present invention described in the document, it can communicate with the system 210. In one embodiment of the MEMS pump 5314, the MEMS electronics element 5332 is preferably embedded in the MEMS pump 5314 and is capable of storing MEMS parameter operational information. The MEMS controller with its electronics and power supply can be physically or wirelessly connected to the MEMS electronics elements. In one embodiment, parameter operational information can be loaded from a removable MEMS controller 5338. The pump element 5314 preferably generates a fluid flow through the tube 5312 based on information stored locally within the MEMS electronics 5332. This information is preferably downloaded from a wired but removable MEMS controller 5338. Further, the MEMS component can communicate with system 210 via wireless communication. Further, the MEMS control device can transfer information to and from the system 210, and fully automates the control and inquiry processing of the MEMS components in the system 210 through a wireless or wired communication path.

A patient information menu interface screen 2521 shown in FIG. 25 is also available on this system. The patient information menu screen 2521 provides a small patient chart for the selected patient. The patient menu screen 2521 also links the clinician 116 with patient related items such as drug / infusion administration, infusion infusion, infusion resumption, infusion titration, flow rate history, pump status, and removal of the patient from the shift. Also provides functionality. The patient menu screen 2521 also has tabs for allergies and Ht / Wt, medication history, and test results. An example of an allergy and Ht / Wt interface screen 2521a is provided in FIG. 25A . Normally, this screen 2521a is displayed when the mini chart is first opened. It displays information about the patient's drug allergies and general allergies, and the latest record of the patient's height and weight. An example of the medication history interface screen 2521b is provided in FIG. 25B . Typically, this screen 2521b provides the clinician with the patient's medication history within the selected lookback period. The lookback period can be adjusted by the clinician. Finally, an example of the inspection result interface screen 2521c is shown in FIG. 25C . Test results are made available in the system 210 through the laboratory interface. All available results are shown and displayed in new order.

An infusion schedule interface screen 2623 for the patient is shown in FIG. This screen 2623 shows the infusion schedule for the selected patient. By clicking on one of the identified orders, such as order 2625 for morphine sulfate on infusion schedule screen 2623, system 210 will link to the drug order interface screen 2627 shown in FIG. 26A . The drug order screen 2627 provides order details 2625 for a particular order (ie, morphine sulfate). As part of the detailed order 2625, treatment parameters 2629 are provided, as well as the ability to link to alerts 2631 and additional information 2633.

Next, the clinician 116 can select the pump channel mode as shown in the interface screen 3881 of FIG. The pump channel mode interface screen 3881 shows the therapy 3882 and the clinician 116 has the option of specifying the therapy 3882 or the piggyback therapy 3883 as the primary therapy 3884. Each channel of the pump has the function of performing primary therapy in addition to piggyback therapy. After completing the selection of the pump channel mode, the clinician can perform a pump channel scan. FIG. 38A shows a pump channel scan interface screen 3885. On the pump scan screen 3885, the clinician 116 scans the medical device, such as by scanning a bar code corresponding to the pump channel 121 and then clicking the arrow key 4809.

Clinician 116 scans the patient up in such interface screen 2313 (a) for example, FIG. 23, (b) for example by scanning the drug over at such interface screen 3465 of FIG. 34, (c) for example interface screen of FIG. 38A 3885 After scanning the pump channel, such as above, the clinician 116 can program the infusion pump and compare the programmed infusion pump parameters or setpoint values with the pharmacy order parameters.

An example of a comparison interface screen 3987 associated with a match as a result of the comparison is shown in FIG. 39A and identified in block 5226 of FIG. In this example, if the pharmacy prescription parameters match the programmed pump channel settings, the clinician 116 is instructed to start the infusion pump 120.

After the infusion pump begins treatment, the clinician 116 can view the status of the pump on his or her digital assistant 118 in the pump status interface screen 4391 shown in FIG. The pump status display 4391 displays a list of all currently infusions for a given patient. Typically, one of five icons, an infusion indicator 4807, an infusion wait indicator 4810 , an infusion stop indicator 4811, an unknown icon, and a delay icon, will be displayed in conjunction with the infusion in this screen. become. The pump status display 4391 is not updated in real time while the current screen is displayed, but by tapping the refresh button 4819, the latest real-time pump status screen is displayed.

Prior to administering the drug, the clinician 116 can be prompted to enter the parameters being monitored, such as the heart rate prior to administering digoxin , or the pain assessment prior to administering morphine. If the parameter being monitored is associated with a medication, each administration of the medication displayed on the digital assistant 118 has a link to an interface screen where the clinician 116 can enter a value. An example of such an order having a link 5001 to the input of the parameter being monitored is shown in the order displayed in FIG. After the monitored parameter link 5001 is selected, a monitored parameter input interface screen 5003 as shown in FIG. 50A is displayed. The clinician 116 can then enter the requested information into the system 210.

If necessary, the clinician can stop an ongoing infusion before it ends. This can be done with or without a stop order to stop the infusion in the system. The aborted infusion can be resumed as needed, for example when titrating the order. When the infusion stop icon 4813 and the infusion in progress icon 4807 are both displayed on the digital assistant 118, the clinician 116 displays a list of all active infusions for the patient on the digital assistant 118. Receive instructions to move. An example of such an injection stop interface screen 2727a is shown in FIG. 27A . In FIG. 27A , the aborted infusion order will be highlighted and shown as being an aborted infusion order. The clinician 116 will then scan the bar code on the discontinued solution container for infusion and then scan the patient's ID. Next, an interface screen 2727b as shown in FIG. 27B is provided on the clinician's digital assistant 118. On the interface screen 2727b, the clinician can enter the time at which the infusion was stopped and the reason for the infusion being stopped. The clinician can then physically stop the infusion pump 120 by pressing a stop button on the infusion pump 120.

An infusion resume interface screen 2727c is provided in FIG. 27C . It is also possible to resume an infusion recorded as having been aborted without an order to abort. To resume the infusion, the clinician 116 must first go to the appropriate interface screen on the digital assistant 118. By tapping the infusion stop icon 4811 in the patient menu, a list of all infusions that are currently stopped for that patient will be displayed as shown in the interface screen 2727c of FIG. 27C . The clinician is prompted to select an infusion to resume. The clinician 116 then scans the barcode on the solution container for infusion to be resumed. The system 210 compares the scanned ID with that for the infusion that is currently discontinued for the patient. After the system 210 compares the ID with that currently suspended for the patient, the digital assistant 118 prompts the clinician 116 to scan the patient's ID. The system 210 then verifies that the scanned ID matches the patient's ID, after which the system 210 will display the scanned infusion prescription on the digital assistant 118 as shown in the interface screen 2727d of FIG. 27D . And prompts clinician 116 to select the reason set by the institution for resuming the infusion. Once the reason is selected, the clinician 116 can resume infusion with the pump 120 and then tap the arrow 4809 to continue. System 210 records the infusion as having been resumed.

Various icons are used to assist the clinician 116 as shown in the various screen shots / interfaces for the digital assistant 118. Many of these icons are shown in FIG. The patient list button 4801 is a key that, when tapped, allows the clinician 116 to move directly to a patient list screen such as the patient list screen 2313 shown in FIG. A return button 4803 is a key for returning the screen on the digital assistant 118 to the previous screen when tapped. An OK button 4805 is tapped to accept the data shown on the digital device 118. When the OK button 4805 is tapped, the next screen is normally displayed. An infusion in progress indicator button 4807 indicates that a programmed infusion is currently being performed for the selected pump 120 and channel. Infusion waiting indicator 4810 indicates that the programmed infusion for the selected patient, pump 120 and channel is on standby. The infusion stop indicator 4811 indicates that the programmed infusion for the selected patient, pump 120 and channel has been stopped. The infusion stop order indicator 4813 indicates that the infusion for the patient, pump 120 and channel selected by the pharmacy input order will be stopped. Physician note indicator 4815 indicates the presence of a physician note for the selected patient, pump 120 and channel. The clinician 116 can tap the note indicator 4815 to view the note. A compare button 4817 is provided on various screens and when tapped, causes the system 210 to perform a comparison between the scanned item and the pharmacy input order, and additional comparisons. A refresh button 4819 is tapped to update the latest data and display it on the screen. The exit button 4821 allows the clinician to exit the current screen and return to the previously displayed screen. The enter button 4809 is also an OK button, and is tapped to approve and input data selected from the options in the drop-down list or data manually entered in the field. The comparison match indicator 4823 indicates that the programmed pump setting value matches the pharmacy input order information. The comparison mismatch indicator 4825 indicates that the programmed pump setting value does not match the pharmacy input order information. Incomparable indicator 4827 indicates that the system is unable to compare the programmed pump settings with pharmacy input order information. Pump alarm / alert indicator 4872 indicates that an alarm condition or an alert condition has occurred. When the alarm / alert indicator 4872 is tapped, an enlarged pump alarm / alert screen is displayed. On the alarm / alert screen, a red alarm / alert icon 4872 indicates an alarm condition, and a yellow alarm / alert icon 4872 indicates an alert condition. The alarm / alert mute button 4874 is tapped to temporarily mute the audible alert on the digital device 118. Communication loss indicator 4833 indicates that pump 120 and / or hub 107 are not properly communicating with system 210. The message accompanying this indication describes the steps that should be taken to resolve the problem. The wireless module low battery alert indicator 4835 indicates that the hub 107 is currently operating on a spare battery with a remaining battery charge of less than 30 minutes.

As mentioned above, one type of notification is an alarm / alert notification. In this system, notifications can be increased step by step. The specific alarm / alert escalation process is shown in FIG. Typically, a notification step is provided for sending notifications to any number of clinicians 116. The identified alarm / alert escalation process 1500 of FIG. 15 has the ability to notify a set of clinicians via the clinician's device 118 when an alarm or alert is active on a medical device such as the infusion pump 120. provide. In a preferred embodiment, the clinician's device is a personal digital assistant (“PDA”) 118 as shown in FIGS. 1 and 3, generally having a display 118a and an audible sound or sound generator 118c. For illustrative purposes only, the clinician's device is identified below as digital assistant 118 in this detailed description. Further, the alarm / alert escalation process 1500 provides an escalation process if the clinician does not respond to the alarm / alert notification on the digital assistant 118. When the escalation process is initiated, a notification is sent to another or second clinician's digital assistant 118 identified in the escalation process. While alarm / alert notifications are sent to the digital assistant 118, it is understood that normally pump alarms and alerts can only be resolved at the pump. As described herein, as in block 1580 of FIG. 15, the mute of the alarm or alert in the digital assistant 118 may or may not act on the pump.

The signal is received by the clinician's digital assistant 118 and subsequently displayed at block 1530 of FIG. In this block, an alarm or alert condition is displayed on the clinician's digital assistant 118. The display on the clinician's digital assistant 118 can be visible, audible, or both visible and audible. In addition, the visual display can include one or more text, icons, symbols, and the like. Similarly, as described above, an audible display can include various audible sounds at various decibel levels. Visible indicators and audible indicators can be set by the hospital. FIG. 16A discloses a screen shot of an exemplary alarm / alert interface list screen 1662a on the clinician's digital assistant 118. FIG. The alarm / alert list interface 1662a includes a list of patients currently associated with the active channel alarm / alert. As shown in FIG. 16A , the clinician's digital assistant 118 currently has three active alarm / alert displays. There are alarm conditions for patient 1, 1664, alarm conditions for patient 2, 1666, and alert conditions for patient 3, 1668. As shown in FIG. 17, each patient name and the corresponding alarm / alert icon is hyperlinked to the appropriate pump alarm details interface screen. In one embodiment, the list of patients is filtered to include only patients currently associated with the clinician 116 logged into the digital assistant 118 displaying this interface screen. This clinician-to-patient association may be performed as a primary clinician or as a temporary clinician. The second clinician can also be accessed through the escalation process. The alarm / alert list interface 1662 is typically accessed by clicking on an alarm / alert icon 4872 displayed on the clinician's 116 digital assistant 118 during normal clinician workflow.

As described above, if an alarm or alert condition is displayed on the clinician's digital assistant 118 at block 1530, this indication can be provided visually, audibly, or both. If an audible display is provided to the clinician's digital assistant 118, an alarm icon 4872 will appear on the display 118a of the clinician's digital assistant 118. If an audible indication is provided, the clinician may have the ability to silence the audible indication even if the clinician is not responding to an alarm or alert condition. If the clinician silences the alarm, the server 109 will activate a silence timer. The visual display will remain even if the audible display is muted. As shown in FIG. 16A , if an alarm / alert provides an audible indication to the clinician's digital assistant 118, but the sound is muted due to the clinician's silence, an alarm / alert silence icon 4874 is provided. The Furthermore, if the clinician does not respond to the alarm within the timer's time limit, at the same time as the alarm / alert status increases, the audible display can be silenced. An alternative embodiment of the audible display can be a vibration alert.

Further, it will be appreciated that multiple alarm / alert state times may occur simultaneously or overlapping. In response, a simultaneous or partially overlapping signal containing data related to a particular alarm condition or alert condition is generated and transmitted from the medical device 120 to the server 109 at block 1510. Alarm / alert signals can be generated from the same medical device 120 or from different medical devices 120. Furthermore, the alarm / alert signal can be related to the same patient or different patients. However, each alarm / alert signal is individually routed to the alarm / alert escalation process 1500 described herein for an individual alarm / alert state. As shown in FIG. 16A , a particular clinician may have multiple alarm / alert displays on his / her digital assistant 118. Another example of an alarm / alert screen is shown on the interface screen 1662b of FIG. 16B . As is common in this system, the line referenced as 1676 in the interface screen 1662b of FIG. 16B is the end of the list, specifically the alarm / alert display list for a particular clinician in this interface. Indicates.

FIG. 17 is a detailed view after selecting to view one of the alarm / alert indications for the patient hyperlink on the clinician's digital assistant 118 from the list 1662a in the interface of FIG. 16A . A patient alarm / alert interface 1765 is shown. Here, the clinician has selected an alarm display for patient 1, 1664. The alarm / alert details screen 1765 provides the clinician with a message detailing the reason for the alarm / alert. The clinician can click the refresh button 4819 to update the current information displayed on the screen 1765. As shown on the interface 1867 of FIG. 18, there may be multiple alarms or alerts 1878, 1882 for the same patient. This alarm / alert interface 1867 provides a list of all active pump alarms / alerts currently associated with a given patient. These active pump alarms / alerts may be from multiple channels 121 and / or pumps 120 and may even be spread across multiple hubs 107. This interface screen 1867 is accessed by identifying a given patient on the pump alarm list screen 1662.

If the alarm is escalated, the server 109 performs another prerequisite check at block 1550 . This prerequisite check 1550 includes associating the patient with a second clinician (this association can be made at the central system service device 108a) and the second clinician with the second clinician's device or the first clinician. And associating with the second clinician's digital assistant 118, also referred to as the second clinician's digital assistant 118. Server 109 uses the information obtained in its prerequisite check at block 1550 to establish a relationship between medical device 120, patient, second clinician, and second clinician's digital assistant 118.

Following the second prerequisite check at block 1550 , the server 109 may also determine whether the second clinician's digital assistant 118 is active. If the second clinician's digital assistant 118 is active, then the server 109 generates an escalated signal representing an existing alarm or alert condition. This escalated signal also includes data such as patient name, patient location, room identification, bed identification, alarm or alert type, status description, time, date, clinician identification and / or prescription. In the preferred embodiment, the escalated signal is transmitted from server 109 to wireless access point 114. The wireless access point 114 then transmits, at block 1555, an escalated signal associated with the alarm condition or alert condition to the second clinician's digital assistant 118 via a wireless communication transmission.

Referring to block 1520, if the server 109 determines that the primary clinician's digital assistant 118 is not active, and if the server 109 determines that an alarm / alert condition still exists at block 1545, the server 109 is discussed above. Proceeding to block 1550, a suitable second clinician or primary clinician will be determined to send an alarm / alert signal. Further, it is understood that block 1520 can occur at any time during the alarm / alert escalation process 1500. One reason that the clinician's digital assistant 118 is inactive may be a loss of signal from the server 109. As shown in the communication loss interface screen 4501 of FIGS. 45A and 45B , if a signal is lost, the digital assistant 118 provides the clinician 116 with a screen 4501 showing signal loss and / or an audible / vibration display. . The loss of communication screen 4501 also notifies the clinician 116 which patient's signal has been lost. In screen 4501, system 210 also provides clinician 116 with troubleshooting information to regain the signal. When hub 107 or digital assistant 118 is out of radio range, pump alarms and alerts cannot be received by digital assistant 118.

Other reasons why the digital assistant 118 is not active may be a decrease in the battery power of the digital assistant 118, a decrease in the battery power of the wireless hub 107, or a loss of signal of the digital assistant due to the access point 114. . System 210 provides the clinician 116 with a low battery screen. As shown in the interface screen 4603 of FIG. 46, one type of low battery screen is a screen that alerts the clinician that a low battery condition exists in the wireless hub 107 connected to the patient's infusion pump. When a low battery screen is provided, it includes a list of patients whose infusion is associated with that particular hub 107. The list of patients usually includes only patients currently associated with the clinician logged in to the digital assistant 118 displaying the screen 4603, and all patients sharing the same infusion pump 120 / hub 107 with the logged in clinician. Filtered to include. This clinician-to-patient association may be the first clinician or the second clinician throughout the escalation process. It will be appreciated that there may be other reasons why the clinician's digital assistant 118 is not active. Nevertheless, whenever the clinician's digital assistant 118 becomes inactive, the process 1500 may proceed to block 1550 so that a signal can be sent to the second clinician and / or the lead clinician. it can. Further, as described above with respect to the timeout feature and other features of the present disclosure, if a communication signal from the server 109 or medical device 120 is lost, the signal loss on the digital assistant 118 as shown in FIGS. 45A and 45B . A message can be provided.

If injection is resumed at block 6134, at block 6144, the first central server 109 returns a success code to the second central server 108a via the completion URL. The first central server 109 maintains an association between the patient identifier, medication identifier, and channel identifier for the selected infusion . The second central server 108 a only updates the injection state to “running” upon receipt of the success code from the first central server 109. Any other result (eg, cancellation code or failure code) causes the second central server 108a to keep the infusion in its previous state. Preferably, if the user wishes to resume both the primary injection and the piggyback injection that are running on one channel, the user performs the “resume injection” operation twice, once for each injection. can do. The resume process can be used to document that the infusion has been resumed for MAR purposes.

Claims (17)

  A system for reporting on the integrity of a wireless communication link in a medical facility,
  The system
  A module associated with a device for medication therapy application, the module having a status information output responsive to a signal output generated by the device for drug therapy application;
  A wireless remote device within the medical facility having a message indicator responsive to the status information output transmitted over the wireless communication link, wherein the message indicator represents a signal generated by the medication therapy application device Wireless remote devices,
  Software installed on the wireless remote device;
  With
  The software
  (I) transmitting a signal to the wireless communication link;
  (Ii) waiting for a response to the signal transmitted to the wireless communication link for a predetermined time;
  (Iii) generating a timeout output indicating a loss of the wireless communication link if the response is not received within the predetermined time;
  A system configured to report on the integrity of the wireless communication link.   The system of claim 1, wherein the association of the module with the device for medication treatment application provides at least some data in the status information output passing through the module.   The system of claim 1, wherein the device for medication treatment application is an infusion pump that infuses a patient.   The system of claim 1, wherein the output generated by the medication therapy device includes data related to an alarm condition.   The system of claim 1, wherein the output generated by the medication therapy device includes data related to an alert condition.   The system of claim 1, wherein the output generated by the medication therapy device includes data related to infusion rate.   The system of claim 1, wherein the output generated by the medication therapy device includes data related to time remaining until an infusion bag is empty.   The system of claim 1, wherein the wireless remote device is a personal digital assistant.   The system of claim 1, wherein the wireless communication link operates within a radio frequency range.   The system of claim 9, wherein the radio frequency is in a 2.4 gigahertz band.   The system of claim 9, wherein the radio frequency is in a 2.45 gigahertz band.   The system of claim 9, wherein the radio frequency is in a 5 gigahertz band.   The system of claim 1, wherein the message indicator is an audible alarm.   The system of claim 1, wherein the message indicator is a visual display.   The system of claim 13, wherein the audible alarm generates an audible sound in response to the timeout output.   The system of claim 14, wherein an icon responsive to the timeout output is provided on the visual display.   The system of claim 14, wherein a pop-up window is provided on the visual display in response to the timeout output.

Images