JP2020064646A5 - Electronic drug order transfer and processing methods and equipment - Google Patents

Description

(A brief description of the drawing)
The present invention can be better understood with reference to the drawings below. The components in the drawings are not necessarily standard, but rather the emphasis is on clearly explaining the principles of the invention. Throughout some of the drawings, the same reference numbers indicate corresponding parts.
It is a schematic representation of the patient medical system. Patient healthcare systems include pharmacy computers, central systems, and digital assistants at treatment locations. FIG. 1 is a block diagram of a computer system representing a pharmacy computer, central system, and / or digital assistant of FIG. The system includes an injection system or a part thereof. It is a schematic representation of the part of the patient medical system of FIG. It is a block diagram which shows the functional element of the patient medical system of FIG. FIG. 1 is an exemplary computer screen for performing various functions of the patient medical system of FIG. It is a block diagram which shows the functional element of the injection system of FIG. Functional elements include, among other things, blocks for infusion system parameterization, infusion order creation, infusion order preparation, drug administration, infusion order modification, and messaging. It is a block diagram which shows the functional element for setting the injection system parameter of FIG. It is a block diagram which shows the functional element for making an injection order of FIG. It is a block diagram which shows the functional element for preparation of an injection order of FIG. It is a block diagram which shows the functional element for drug administration of FIG. FIG. 6 is a block diagram showing functional elements for injection order documentation, injection order modification, and messaging of FIG. It is a figure of the emergency notification system which shows communication. FIG. 5 is a diagram of an emergency notification interface from the perspective of a notifying party, showing preferred notification options provided by the emergency notification system to the notifying party. FIG. 5 is a diagram of an emergency notification interface from the perspective of a target party, showing preferred emergency information received by the target party. It is an embodiment of the flowchart of the alarm / alert escalation process. It is a figure of the alarm / alert interface screen. It is another figure of the alarm / alert interface screen. It is another figure of the alarm / alert interface screen. It is a figure of the interface screen seen from the handheld device of a clinician. It is a figure of the interface screen of the login process. It is a figure of another interface screen of the login process of FIG. It is a figure of the department selection interface screen. It is a figure of the shift selection interface screen. It is a figure of the patient browsing interface screen. It is a figure of the patient selection interface screen. It is a figure of the patient information menu interface screen. It is a figure of the allergy / height / weight interface screen. It is a figure of the drug history interface screen. It is a figure of the inspection result interface screen. It is a figure of the drug delivery schedule interface screen. It is another figure of the interface screen of the drug delivery schedule process of FIG . It is a figure of the interface screen of workflow injection stop. It is another figure of the interface screen of workflow injection stop. It is the figure of the interface screen of the workflow for restarting the injection. It is the figure of the interface screen of the workflow for restarting the injection . It is another figure of the interface screen of the drug delivery schedule process of FIG. It is a figure of the 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 the schedule interface screen. It is a figure of the drug interface screen. It is a figure of the scan interface screen. It is a figure of another scan interface screen. It is a figure of the drug administration interface screen. It is a figure of the route confirmation interface screen. It is a figure of the pump channel scan interface screen. It is a figure of another pump channel scan interface screen. It is a figure of the comparison interface screen. It is another figure of the comparison interface screen. It is another figure of the comparison interface screen. It is another figure of the comparison interface screen. It is another figure of the comparison interface screen. It is a figure of the pump state interface screen. It is a figure of the flow velocity history interface screen. It is a figure of the communication loss interface screen. It is a figure of the communication loss interface screen. It is a figure of a low battery interface screen. It is a figure of a hub. It is a diagram of various icons used on the interface screen. It is a figure of the implementation result recording interface screen. It is a figure of the dosing order having a monitoring parameter link. It is a figure of the monitoring parameter input interface screen. It is a figure of the cycle count interface screen. It is a flowchart of an order comparison process. FIG. 5 is a schematic of a flow control system in which microelectromechanical system (MEMS) elements are connected to a line set. FIG. 3 is a schematic block diagram of software components loaded on the first central computer of FIG. It is a flowchart of an exemplary injection execution process. It is a flowchart of an exemplary injection execution process. It is a flowchart of an exemplary injection execution process. It is a flowchart of an exemplary channel scan process. It is a flowchart of an exemplary pump channel change process. It is a flowchart of an exemplary pump channel change process. It is a flowchart of another exemplary channel scan process. It is a flowchart of yet another exemplary channel scanning process. It is a flowchart of an exemplary injection stop / stop process. It is a flowchart of an exemplary injection resumption process. It is a flowchart of an exemplary pump removal process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process. It is a flowchart of an exemplary authentication process.

(General system)
Explaining this with reference 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 a control device for an infusion pump. For easy reference, the present disclosure, as a whole, identifies the medical device of the system as an infusion pump, but the entire system 100 can incorporate any one or more of the various medical devices. Is understood. Therefore, as shown in FIG. 3, the plurality of injection pumps 120 are connected to the hub or interface 107. As described in more detail herein, the infusion pump 120 may be of a conventional design in which each infusion pump 120 is associated with one 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 injection pump 120 may be a single channel pump or a multi-channel pump such as a 3-channel pump . In general, the pump periodically transmits a message containing pump status information to hub 107. To centralize communication for cost effectiveness and / or to allow redesign of existing medical devices that are not currently communicating with central computer system 108, thereby allowing each such medical device to work with central computer system 108. A separate hub 107 can be used away from the medical device 120 so that it can communicate.

Explaining this with reference to FIG. 54, the server 109 is preferably COMPAQ DLG-380 with a MICROSOFT WINDOWS® 2003 server operating system 5414. In one embodiment, the software component loaded in the storage of the first central computer 109 is: First central computer or server application 5412 in NET Framework5416, authentication Acive Directory Domain Service5418 users and devices, (shown as a database) temporary data storage SQL Server 5420, and Internet Information Server 5422 for application hosting (IIS) including. .. NET Framework 5416 is available from Microsoft. NET Framework 1.1 or higher is preferred. The .NET Framework connects the application 5412 of the first central computer to the operating system, Internet Information Services 5422, SQL database 5420, and Active Directory Domain Service 5418 components. As will be appreciated by those skilled in the art, the Active Direction Domain Service 5418 provides services utilized by the Windows® server operating system 5414 and the application 5412 of the first central computer, a genuine and authorized hub subsystem. Helps ensure that only users of the second central computer subsystem and 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 align the functions of other modules of the patient health system 100 included in the management of medical therapy. The medication management module 302 coordinates as a whole with the rest of the patient health system 100. The medication management module 302 operates and / or interfaces with the CPOE, operates and / or communicates with the point of care module, and operates and / or communicates with the medical therapy comparison module. Can include submodules. FIG. 4 shows the entrance / exit transfer (ADT) interface 310, the billing interface 312, the laboratory interface 314, and the pharmacy interface 316. 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 the events input to the hospital's ADT system into a second central computer 108a. HL7 is a protocol for formatting, transmitting and receiving data in a medical environment. It provides interoperability between medical information systems through messaging standards that allow heterogeneous medical applications, such as a variety of different third-party applications, to exchange keysets of clinical and administrative data. Generally, 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 can be an HL7 type interface, and the HL7 type interface interfaces with another system and inputs an order such as CPOE. This feature reduces the need to enter data into the patient medical 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, Phamous and the like. The web service interface can make near real-time coordination between point-of-care medication management systems that support oral medication administration, such as McKesson AdaminRx, Pyxis, Verif5, and infusion pump-related medication management. Various other interfaces are also known to those of skill in the art, but are not shown in FIG.

The clinician 116 identifies himself by scanning the badge 116a, identifies the patient 112 by scanning the wristband 112a, identifies the drug 124 by scanning the drug label 124a, and scans the label 120d. This identifies a medical device 332 such as an infusion pump 120. The clinician 116 can also identify himself 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 delivering and verifying medical therapy. In an alternative embodiment, the infusion system 210 can include the ability to download operating parameters to the medical device 332. Clinician 116 can visually verify and confirm that the third copy 322 and / or MAR is consistent with the labeled drug 124. The scanner 338 can be used to input machine-readable information from the third copy 322 to the radio device 330 and the medical device 332.

The injection order creation block 504 includes a functional block used to create an injection order. The injection order creation block 504 includes functions similar to those described with reference to the prescription creation block 304 (FIG. 4). The injection 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 override 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). The injection order 702 typically includes an injection schedule 704 (FIG. 8).

(Create order)
FIG. 8 is a block diagram showing functional elements for the injection order creation 504 of FIG. The injection order creation 504 includes a functional block for creating an injection order. The injection order creation 504 includes information input 560, calculation 562, check 564, and override 566 . The information input 560 may include, but is not limited to, functions such as order type identification 560a, drug identification 560b, dose identification 560c, diluent identification 560d, flow rate identification 560e, and injection site identification 560f.

Calculation 562 can include, but is not limited to, calculations such as bag amount calculation 562a, conversion calculation 562b, duration vs. volume calculation 562c, and flow velocity vs. drip velocity calculation 562d. Check 564 includes various checks that the injection order can receive. Checks include, but are not limited to, net concentration check 564a, flow rate check 564b, dosing time check 564c, duration check 564d, injection site check 564e and the like. If the infusion order gets caught in check 564, clinician 116 can disable the check. Overrides 566 can include, but are not limited to, overrides such as net concentration override 566a , flow rate override 566b , dosing time override 566c , duration override 566d , and injection site override 566e . Override 566 can generate a message to doctors and / or pharmacies 520. The injection system 210 can distinguish between system-wide overrides and subsystem overrides in deciding whether or not a 520 message generation is required.

Overriding can include an indication of whether the clinician has the authority to override the tolerance. For example, the flow velocity override 566b can indicate whether the clinician entering the infusion order has the authority to override the flow velocity tolerance 542b of the system. This indication can be applied to the patient medical system 100 or subsystem. The duration override 566d can indicate whether the clinician 116 entering the infusion order has the authority to override the duration 542d of the system. This indication can be applied to the patient medical system 100 or subsystem. The override 566 also includes an indication of the reason for the override 566f . Overriding reason 56 6 f, the clinician 116 can be selected from the drop-down menu.

Modification change 1002 includes new duration identification 1002a, new flow velocity identification 1002b, new injection site identification 1002c, modification reason identification 1002d, remaining amount in injection bag identification 1002e, stop order 516. Is done. The ordering options available during the initial injection order creation 504 are usually also available for modification of the injection order. The ordering options available during the initial order creation 504 include those shown in FIG. The recheck 1006 and the recheck override 1008 are similar to the check 564 and override 566 described with reference to FIG. The new flow rate vs. new infusion rate display 1010 helps clinicians minimize the possibility of error during drug administration 512. A modified injection order can result in a modified injection schedule.

Documenting 1012 captures injection order information in real time. Documentation includes multiple injections in progress at the same time, and, but is not limited to, documentation of duration changes 1012a , flow rate changes 1012b , volume changes 1012c, and injection site changes 1012d .

Although the present disclosure focuses on the use of the infusion pump 120 within the system 210, it is understood that other medical devices can be used within the system 210 without departing from the scope of the 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 extremely 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 an integrated microsystem on a chip that can incorporate moving mechanical components in addition to optical, fluid, electrical, chemical and biomedical elements. The resulting MEMS device or element responds to many types of inputs, including pressure, vibration, chemicals, light, and acceleration. MEMS components can be several different components, including various types of pumps, flow valves, flow sensors, tubes, pressure sensors or combinations of elements.

Therefore, as further described in detail below, one use of the MEMS component is as an in-line MEMS pump 5314 schematically shown in FIG. The MEMS pump 5314 can pump the fluid contained in the infusion bag 5320 through the tube 5312 and from there through the access device 5324 into the patient's body. The MEMS component has a local electronic device element of the MEMS attached thereto, the electronic device element of the MEMS is connected to an external durable MEMS control device, and the MEMS control device is described herein. It can communicate with the system 210, such as the injection pump 120 of the invention described in the document. In one embodiment of the MEMS pump 5314, the electronics element 5332 of the MEMS is preferably built into the MEMS pump 5314 and capable of storing operating information of the MEMS parameters. The electronic device and the MEMS control device having the power supply can be physically or wirelessly connected to the electronic device element of the MEMS. In one embodiment, the parameter operating information can be loaded from the removable MEMS controller 5338. The pump element 5314 preferably creates a flow of fluid through the tube 5312 based on information locally stored within the MEMS electronics 5332. This information is preferably downloaded from the wiring but removable MEMS controller 5338. Further, the MEMS component can communicate with the system 210 by 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.

The patient information menu interface screen 2521 shown in FIG. 25 can also be used 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 to clinician 116 patient-related items such as drug / infusion administration, infusion stop, infusion resumption, infusion titration, flow rate history, pump status, and removal of the patient from shifts. It 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, as well as the latest records of the patient's height and weight. An example of the drug history interface screen 2521b is provided in FIG. 25B . Typically, this screen 2521b provides the clinician with a patient's medication history within the selected lookup period. The lookup period can be adjusted by the clinician. Finally, FIG. 25C shows an example of the inspection result interface screen 2521c. The test results will be available in system 210 through the laboratory interface. All available results are shown and displayed in chronological order.

The 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 the infusion schedule screen 2623, the 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 detail order 2625, treatment parameter 2629 is provided, along with the ability to link to warning 2631 and additional information 2633.

The clinician 116 can then select the pump channel mode, as shown in the interface screen 3881 of FIG. The pump channel mode interface screen 3881 shows therapy 3882, and clinician 116 has the option of designating therapy 3882 or piggyback therapy 3883 as first-line therapy 3884. Each channel of the pump has the ability to provide first-line therapy in addition to piggyback therapy. After completing the pump channel mode selection, the clinician can perform a pump channel scan. FIG. 38A shows the pump channel scan interface screen 3885. On the pump scan screen 3885, the clinician 116 scans the medical device, for example by scanning the barcode corresponding to the pump channel 121 and then clicking the arrow key 4809.

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

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

After the infusion pump initiates treatment, the clinician 116 can view the pump status within the pump status interface screen 4391 shown in FIG. 43 on his or her digital assistant 118. Pump status display 4391 displays a list of all currently performing infusions for a given patient. Normally, one of five icons, an infusion in progress indicator 4807, an infusion waiting indicator 4810 , an infusion stopped indicator 4811, an unknown icon, and a delay icon, is 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 the latest real-time pump status screen is displayed by tapping the refresh button 4819.

Before administering the drug, the clinician 116 can be prompted to enter the parameters being monitored, such as the heart rate before administration of digoxin , or the pain assessment before administration of morphine. If the parameter being monitored is associated with a drug, each dose of drug displayed on the Digital Assistant 118 has a link to an interface screen where the clinician 116 can enter values. 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 monitoring parameter link 5001 is selected, the monitoring parameter input interface screen 5003 as shown in FIG. 50A is displayed. There, the clinician 116 can enter the requested information into the system 210.

If desired, the clinician can discontinue the ongoing infusion before it is complete. This can be done with or without a stop order to stop the injection in the system. The discontinued infusion can be resumed as needed, for example if the order is being titrated. When both the infusion discontinuation icon 4813 and the infusion in progress icon 4807 are displayed on the digital assistant 118, the clinician 116 is required to display a list of all inflicted infusions to 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 discontinued injection order will be highlighted and indicated as the discontinued injection order. The clinician 116 will then scan the barcode on the discontinued infusion solution container and then the patient's ID. An interface screen 2727b, as shown in FIG. 27B , is then provided on the clinician's Digital Assistant 118. On the interface screen 2727b, the clinician can enter the time when the infusion was discontinued and the reason for the discontinuation. The clinician can then physically stop the infusion pump 120 by pressing the stop button on the infusion pump 120.

The injection restart interface screen 2727c is provided in FIG. 27C . It is also possible to resume infusions that are recorded as discontinued without an order to discontinue. To resume infusion, clinician 116 must first navigate to the appropriate interface screen on Digital Assistant 118. By tapping the infusion discontinuation icon 4811 in the patient menu, a list of all currently discontinued infusions for that patient will be displayed as shown in interface screen 2727c of FIG. 27C . The clinician is prompted to choose an injection to resume. Clinician 116 then scans the barcode on the solution container for infusion to be resumed. System 210 compares the scanned ID to that for the currently discontinued infusion for the patient. After the system 210 compares the ID to the patient's current discontinuation, the digital assistant 118 prompts the clinician 116 to scan the patient's ID. The system 210 then confirms that the scanned ID matches the patient's ID, after which the system 210 prescribes the scanned infusion on the digital assistant 118, as shown in the interface screen 2727d of FIG. 27D . Will be displayed, prompting clinician 116 to choose a reason determined by the facility for resumption of infusion. Once the reason is selected, clinician 116 can resume infusion with pump 120 and then tap arrow 4809 to continue. System 210 records that injection has been resumed.

Various icons are used to assist the clinician 116, as shown in the various screen shots / interfaces to the Digital Assistant 118. Many of these icons are shown in FIG. The patient list button 4801 is a key that allows the clinician 116 to move directly to a patient list screen, such as the patient list screen 2313 shown in FIG. 23, when tapped. The back button 4803 is a key that returns the screen on the digital assistant 118 to the previous screen when tapped. The OK button 4805 is tapped to approve the data shown on digital device 118. When you tap the OK button 4805, the following screen is usually displayed. The infusion in progress indicator button 4807 indicates that an infusion programmed for the selected pump 120 and channel is currently in progress. Waiting for infusion indicator 4810 indicates that the infusion programmed for the selected patient, pump 120 and channel is in a waiting state. The infusion discontinuation indicator 4811 indicates that the programmed infusion for the selected patient, pump 120 and channel has been discontinued. Infusion discontinuation order indicator 4813 indicates that infusion to the patient, pump 120 and channel selected by the pharmacy input order will be discontinued. The physician note indicator 4815 indicates the presence of a physician note for the selected patient, pump 120 and channel. Clinician 116 can tap the note indicator 4815 to see the note. The comparison button 4817 is provided on various screens and, when tapped, causes the system 210 to compare the scanned item with the pharmacy input order and perform additional comparisons. The refresh button 4819 is tapped to update the latest data and show it on the screen. 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 enter data selected from the options in the drop-down list or manually entered in the field. The comparison match indicator 4823 indicates that the programmed pump set value matches the pharmacy input order information. The comparison mismatch indicator 4825 indicates that the programmed pump settings do not match the pharmacy input order information. The incomparable indicator 4827 indicates that the system cannot compare the programmed pump settings with the pharmacy input order information. The pump alarm / alert indicator 4872 indicates that an alarm condition or 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, the red alarm / alert icon 4872 indicates the alarm status, and the yellow alarm / alert icon 4872 indicates the alert status. 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 is not properly communicating with system 210. The message that accompanies this indication describes the steps to be taken to resolve the issue. The wireless module low battery alert indicator 4835 indicates that the hub 107 is currently running on a spare battery with less than 30 minutes of remaining battery power.

As mentioned above, one type of notification is an alarm / alert notification. In this system, notifications can be increased in stages. The escalation process for a particular alarm / alert is shown in FIG. Notification steps are typically provided to send notifications to any number of clinicians 116. The identified alarm / alert escalation step 1500 of FIG. 15 has the ability to notify a series 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, which generally has a display 118a and an audible or sound generator 118c. For illustration purposes only, the clinician's device will be referred to below as Digital Assistant 118 in this detailed description. Further, the alarm / alert escalation step 1500 provides an escalation step if the clinician does not respond to the alarm / alert notification on the digital assistant 118. When the escalation step is initiated, a notification is sent to the digital assistant 118 of another or second clinician identified in the escalation step. Although alarm / alert notifications are sent to the Digital Assistant 118, it is generally understood that pump alarms and alerts can only be resolved by the pump. As described herein, the muffling of alarms or alerts in the Digital Assistant 118 may or may not act on the pump, as in block 1580 of FIG.

The signal is received by the clinician's digital assistant 118 and subsequently displayed in block 1530 of FIG. In this block, the alarm status or alert status 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 visible display can include one or more texts, icons, symbols and the like. Similarly, as mentioned above, the audible display can include different audible sounds at different decibel levels. The visible and audible indicators can be set by the hospital. FIG. 16A discloses a screen shot of a list screen 1662a of an exemplary alarm / alert interface on the clinician's Digital Assistant 118. The alarm / alert list interface 1662a contains a list of patients currently associated with the alarm / alert of the active channel. As shown in FIG. 16A , the clinician's Digital Assistant 118 currently has three active alarm / alert displays. There are alarm states for patients 1, 1664, alarm states for patients 2, 1666, and alert states for patients 3, 1668. As shown in FIG. 17, each patient name and corresponding alarm / alert icon are hyperlinked to the appropriate pump alarm detail interface screen. In one embodiment, the list of patients is filtered to include only those 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 care clinician. A second clinician can also be accessed through the escalation process. The alarm / alert list interface 1662 is generally accessed during the normal clinician workflow by clicking on the alarm / alert icon 4872 displayed on the clinician 116's Digital Assistant 118.

As mentioned above, when an alarm or alert condition is displayed on the clinician's Digital Assistant 118 at block 1530, this display can be provided visually, audibly, or both. If the clinician's digital assistant 118 is provided with an audible display, an alarm icon 4872 will appear on the clinician's digital assistant 118's display 118a. If an audible display is provided, the clinician may have the ability to mute the audible display, even if the clinician is not responding to an alarm or alert condition. If the clinician mute the alarm, the server 109 will activate the mute timer. The visible display will remain even if the audible display sound is muted. As shown in FIG. 16A , the alarm / alert provides the clinician's digital assistant 118 with an audible display, but if the clinician's muffling causes the sound to be muted, the alarm / alert muffling icon 4874 is provided. To. Furthermore, if the clinician does not respond to the alarm within the timer time limit at the same time as the alarm / alert status rises, the audible display can be demuted. An alternative embodiment of the audible display can be a vibration alert.

Furthermore, it is understood that the times of multiple alarm / alert states can occur simultaneously or at the same time. Accordingly, simultaneous or partially overlapped signals containing data related to a particular alarm or alert state are generated and transmitted from the medical device 120 to the server 109 in block 1510. The alarm / alert signal can be created from the same medical device 120 or different medical devices 120. In addition, alarm / alert signals can be associated with the same patient or different patients. However, each of the alarm / alert signals is individually routed to the alarm / alert escalation step 1500 described herein for each alarm / alert state. As shown in FIG. 16A , a particular clinician may have numerous alarm / alert displays on his / her digital assistant 118. Another example of the alarm / alert screen is shown on the interface screen 1662b of FIG. 16B . As is common in the 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. Is shown.

FIG. 17 is detailed after selecting to view one of the alarm / alert displays for a hyperlink to a patient on the clinician's digital assistant 118 from list 1662a in the interface of FIG. 16A . Shows patient alarm / alert interface 1765. Here, the clinician has selected an alarm display for Patient 1, 1664. The alarm / alert detail 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 interface 1867 in FIG. 18, there may be multiple alarms or alerts 1878, 1882 for the same patient. This alarm / alert interface 1867 provides a list of alarms / alerts for all active pumps currently associated with a given patient. The alarms / alerts for these active pumps can be from multiple channels 121 and / or pumps 120, and can even extend across multiple hubs 107. The interface screen 1867 is accessed by identifying a given patient on the pump alarm list screen 1662.

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

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

Referring to block 1520, if server 109 determines that the primary clinician's digital assistant 118 is inactive, and if server 109 determines that an alarm / alert condition still exists at block 1545, server 109 discusses above. Proceed to block 1550 to determine the appropriate second or chief clinician to send the alarm / alert signal. Further, it is understood that block 1520 can occur at any time during alarm / alert escalation step 1500. One reason the clinician's Digital Assistant 118 is inactive may be the loss of signal from the server 109. If the signal is lost, as shown in the communication loss interface screen 4501 of FIGS. 45A and 45B , the digital assistant 118 provides the clinician 116 with a screen 4501 indicating the signal loss and / or an audible / vibration display. .. The communication loss screen 4501 also informs the clinician 116 which patient's signal was lost. On screen 4501, system 210 also provides clinician 116 with troubleshooting information to regain the signal. When the hub 107 or digital assistant 118 is out of radio range, pump alarms and alerts cannot be received by the digital assistant 118.

Other reasons why the Digital Assistant 118 is inactive may be a low battery in the Digital Assistant 118, a low battery in the wireless hub 107, or a signal loss in the Digital Assistant due to the access point 114. .. System 210 provides 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 warns the clinician that a low battery condition is present in the wireless hub 107 connected to the patient's infusion pump. When a low battery screen is provided, the screen contains a list of patients whose infusions are associated with that particular hub 107. The list of patients is typically only those who are currently associated with the clinician logged in to Digital Assistant 118 displaying screen 4603, or all patients who share the same infusion pump 120 / hub 107 with the logged in clinician. Filtered to include. This clinician-to-patient association may be a first clinician or a second clinician throughout the escalation process. It is understood that there may be other reasons why the clinician's Digital Assistant 118 is inactive. Nevertheless, whenever the clinician's digital assistant 118 becomes inactive, step 1500 may proceed to block 1550 so that the signal can be sent to the second clinician and / or the chief clinician. it can. Further, as described above with respect to the timeout feature and other features of the present disclosure, if the communication signal from the server 109 or the medical device 120 is lost, the signal loss on the digital assistant 118, as shown in FIGS. 45A and 45B . Can provide a message.

If injection is resumed in block 6134, in block 6144 the first central server 109 returns the success code to the second central server 108a via the completion URL. The first central server 109 maintains an association between the patient identifier, drug identifier, and channel identifier for the selected infusion . The second central server 108a only updates the injection status to "running" at the same time as receiving the success code from the first central server 109. Any other outcome (eg cancellation code or failure code) causes the second central server 108a to hold the injection in its previous state. Preferably, if the user wishes to resume both the primary and piggyback injections running on one channel, the user will perform the "restart injection" operation twice, once for each injection. can do. The resumption step can be used to document that the infusion has been resumed for the purposes of MAR.

Claims (20)

A pharmacy system configured to print human readable operator steps on a drug label to program a medical device.
With memory configured to store instructions for programming medical devices,
With a label printer configured to print drug labels for drug containers,
With a pharmacy computer communicatively connected to the memory and the label printer
With
The pharmacy computer
Receiving an electronic drug order corresponding to a drug given intravenously to a patient
At least one of the instructions and one or more therapy-specific driving parameters for the medical device to administer the drug corresponding to the electronic drug order to the patient based on the electronic drug order. To generate and
Generating human-readable operator steps for programming the medical device according to one or more therapy-specific driving parameters, the operator steps being i) arranged in order and ii) said medical. Having unit measurements that meet the requirements for programming the device,
The label to print the human readable operator step on the drug label to allow the medical device to be programmed by a healthcare professional to administer the drug corresponding to the electronic drug order to the patient. To instruct the printer
A system that is configured to run. The system of claim 1, wherein at least one of the instructions comprises the operator step. The system of claim 1, wherein the medical device comprises an infusion pump, and the one or more therapy-specific operating parameters include the amount to be infused and the infusion rate. The pharmacy computer
Determining the medical device to administer the drug corresponding to the electronic drug order, and
To generate the one or more therapy-specific driving parameters based further on i) the determined medical device and ii) at least one of the determined medical device types.
The system of claim 1, wherein is configured to perform. The memory is configured to store instructions for programming a plurality of medical devices, and the pharmacy computer is specified to administer the drug to the patient from among the plurality of medical devices. The system according to claim 1, which is configured to determine the medical device. The pharmacy computer instructs the label printer to print the one or more therapy-specific driving parameters as a barcode read by the medical device's bar code reader to automatically program the medical device. The system according to claim 1, which is configured in 1. The system of claim 1, wherein the pharmacy computer is configured to receive the electronic drug order as an HL7 drug order message. The system according to claim 1, wherein the label printer is configured to attach the drug label to a drug container. The pharmacy computer is configured to instruct the label printer to print at least one of the patient identifier, the medical device identifier, or the drug expiration date on the drug label. , The system according to claim 1. Further including an RF (Radio Frequency) writer, the pharmacy computer wirelessly writes the therapy-specific operating parameters and information related to the electronic drug order to the RF device connected to the drug label. The system of claim 1, configured to instruct a writer. The system of claim 1, wherein the electronic drug order is received from a computerized physician order entry (CPOE) system. The electronic drug order includes (a) the dose of the drug at a specific concentration, (b) the amount of the drug per unit body weight, (c) the dose of the drug per unit body surface area, or (d). The system of claim 1, wherein at least one of the total dose and duration is specified. 12. The system of claim 12, wherein the drug order identifies at least one of (a)-(d) over a period of time. A method for printing a human readable operator step on a drug label to program a medical device, said method.
A pharmacy computer communicatively connected to a memory device receives an electronic drug order corresponding to a drug given intravenously to a patient.
For a medical device for administering the drug corresponding to the electronic drug order to the patient based on at least one instruction stored in the memory device and the electronic drug order via the pharmacy computer. To generate one or more therapy-specific driving parameters of
Through the pharmacy computer, generating human-readable operator steps for programming the medical device according to the one or more therapy-specific operating parameters, the operator steps are i) arranged in order. And ii) having a unit measurement that meets the requirements for programming the medical device.
The human-readable operator step on a drug label to allow a medical device to program the medical device to administer the drug corresponding to the electronic drug order to the patient via the pharmacy computer. To instruct the label printer to print
Including methods. 14. The method of claim 14, further comprising storing the at least one instruction for programming the medical device in the memory device. Determining the medical device to administer the drug corresponding to the electronic drug order via the pharmacy computer.
Through the pharmacy computer, i) generate the one or more therapy-specific driving parameters based further on at least one of the determined medical device and ii) the type of the determined medical device. To do
14. The method of claim 14, further comprising. The label printer is instructed via the pharmacy computer to print the one or more therapy-specific operating parameters as a barcode read by the medical device's bar code reader to automatically program the medical device. 14. The method of claim 14, further comprising doing so. Further instructing the label printer to print at least one of the patient identifier, the medical device identifier, or the drug expiration date on the drug label via the pharmacy computer. The method of claim 14, comprising. 14. The method of claim 14, wherein the at least one instruction comprises the operator step. 14. The method of claim 14, wherein the medical device comprises an infusion pump, and the one or more therapy-specific operating parameters include the amount and infusion rate to be infused.

Images