JP2023068476A - Alert output program, alert output method, and alert output device - Google Patents

Abstract

To provide an alert output program capable of supporting checking whether the order of injections is being followed, an alert output method, and an alert output device.SOLUTION: The alert output program executed by a server device 10 causes a first collation unit 15B to acquire control parameters set on an infusion pump from the infusion pump that adjusts the flow rate of the drip administered to a patient; and when a second collation unit 15C identifies that the control parameters acquired from the infusion pump are different from the control parameters for the infusion pump specified in the injection order, an alert output unit 15D is caused to output an alert.SELECTED DRAWING: Figure 3

Description

The present invention relates to alert output technology.

The electronic medical record system can include functions such as editing and managing computerized medical records, so-called electronic medical records, and functions related to issuing various orders such as injections and examinations. For example, in the injection business, a doctor or the like issues an injection order including instructions such as the type and amount of medicine and the speed of administering the medicine (so-called flow rate). When an infusion or the like is performed by an infusion pump according to such an injection order, the electronic medical record system records the flow rate of the infusion, the scheduled IN volume, and the like as control parameters of the infusion pump.

WO2015/146663 WO2015/156134 JP 2012-005756 A

However, the above-described electronic medical record system only records the control parameters of the infusion pump that are self-declared by nurses and the like. Therefore, if an error or input error occurs, the control parameters of the infusion pump input to the electronic medical chart system do not necessarily match the control parameters set for the infusion pump by nurses or the like. If the two do not match, it is difficult to confirm whether or not the injection order is being followed in the above electronic medical record system.

An object of one aspect is to provide an alert output program, an alert output method, and an alert output device that can assist in confirming whether an injection order is being followed.

In one aspect, the alert output program obtains the control parameters set in the infusion pump from the infusion pump that adjusts the flow rate of the infusion administered to the patient, and the control parameters obtained from the infusion pump and the instructions in the injection order causes the computer to execute a process of outputting an alert when the control parameter of the infusion pump is different from the received infusion pump control parameter.

It can assist in confirming whether injection orders have been followed.

FIG. 1 is a diagram showing a configuration example of an electronic medical record system. FIG. 2 is a schematic diagram showing an example of a drip scene. FIG. 3 is a block diagram illustrating a functional configuration example of a server device. FIG. 4 is a diagram showing an example of screen transition. FIG. 5 is a diagram showing an example of screen transition. FIG. 6 is a diagram showing an example of screen transition. FIG. 7 is a diagram showing an example of screen transition. FIG. 8 is a flowchart showing the procedure of alert output processing. FIG. 9 is a diagram illustrating a hardware configuration example.

Hereinafter, embodiments of an alert output program, an alert output method, and an alert output device according to the present application will be described with reference to the accompanying drawings. Each embodiment merely shows one example or one aspect, and such examples do not limit the numerical values, the range of functions, the usage scene, and the like. Further, each embodiment can be appropriately combined within a range that does not contradict the processing contents.

<System configuration>
FIG. 1 is a diagram showing a configuration example of an electronic medical record system. An electronic medical chart system 1 shown in FIG. 1 provides an electronic medical chart function for realizing editing and management of electronic medical charts. As part of this electronic medical record function, various functions such as a function to issue various orders such as injections and examinations, a function to refer to examination results, and a medical accounting function such as receipts can be packaged. .

As shown in FIG. 1, the electronic medical record system 1 can include a server device 10, PC (Personal Computer) terminals 30A to 30M, and mobile terminals 50A to 50N. Hereinafter, when individual PC terminals 30A to 30M do not need to be distinguished, they are referred to as "PC terminal 30," and when individual mobile terminals 50A to 50N do not need to be distinguished, they are referred to as "mobile terminal 50." ” may be stated.

The server device 10, the PC terminal 30 and the mobile terminal 50 are communicably connected via a network NW. For example, the network NW may be any type of communication network, such as the Internet or a LAN (Local Area Network), whether wired or wireless.

The server device 10 is an example of a computer that provides the above electronic medical record function. The server device 10 can correspond to an alert output device. As one embodiment, the server apparatus 10 can provide the above electronic medical chart function by causing any computer to execute software that realizes the above electronic medical chart function. As an example, the server device 10 can be implemented as a server that provides the above-described electronic medical record function on-premises. As another example, the server device 10 can also provide the electronic medical record function as a cloud service by implementing it as a SaaS (Software as a Service) type application.

Both the PC terminal 30 and the mobile terminal 50 correspond to examples of client terminals that receive the aforementioned electronic medical record function. For example, the PC terminal 30 may be a laptop or desktop personal computer. Also, the mobile terminal 50 may be a smart phone, a tablet terminal, or the like.

These PC terminal 30 and mobile terminal 50 can be used by medical staff corresponding to an example of a user of the electronic medical record system 1 . "Healthcare personnel" as used herein may include doctors, nurses, and other medical personnel.

Hereinafter, as an example, the case where the mobile terminal 50 is used to support ward nursing work will be taken as an example. An example of a usage scene in such ward nursing work is an injection work such as a drip infusion performed by a nurse or the like.

<Three-point authentication>
For example, the mobile terminal 50 is used to prevent medical malpractice, such as medication mistakes during injections and infusions, and patient mix-ups. Used for three-point authentication. The "injection" as used herein may include not only drugs but also blood products for transfusion.

FIG. 2 is a schematic diagram showing an example of a drip scene. FIG. 2 shows a scene in which a nurse 2 drips a drug to a patient 4 at the bedside as an example of an injection, but all preparations such as blood products for transfusion may be injections. As shown in FIG. 2, the barcode 41 of the patient 4 is used to identify the patient 4 . For example, a wristband 40 distributed to the patient 4 is attached with a print, such as a sticker, of a bar code 41 coded with identification information of the patient 4, such as a patient ID (IDentification). The patient ID can be identified by reading such a bar code 41 via the scanner function of the mobile terminal 50 . Also, the bar code 61 of the medicine 6 is used for identification of the medicine 6 . For example, on the label 60 of the drug 6, a print of a barcode 61 coded with order identification information, such as an order ID, such as a sticker, is attached. The order ID can be identified by reading such a bar code 61 via the scanner function of the mobile terminal 50 . By authenticating the combination of these patient IDs and order IDs, medication errors and patient mix-ups can be suppressed.

Here, although illustration is omitted in FIG. 2, the account of the electronic medical record system 1 can be used to identify the nurse 2 . For example, the ID of a medical worker such as a nurse can be identified by a user's account authenticated by logging into the electronic medical record system 1 via the mobile terminal 50 . In addition, barcodes can also be used to identify nurses 2 . For example, the nurse 2's nameplate or the like displays a bar code in which the identification information of the nurse, such as the nurse ID, is coded. The nurse ID can be identified by reading such a bar code through the scanner function of the mobile terminal 50 . From this nurse ID, it is possible to record the person in charge of the medical staff who administers drips and infusions. Although FIG. 2 shows an example in which barcodes are used to identify individuals such as the patient 4, the medicine 6, and the nurse 2, two-dimensional codes or other codes may be used.

The infusion pump 70 is a medical device that adjusts the flow rate of the drip administered to the patient 4 . As one aspect, the infusion pump 70 can accept settings for the drip flow rate and scheduled IN volume. The "flow rate" referred to here may also be referred to as "velocity". In addition, the “planned IN dose” corresponds to the dose of medicine or the like instructed in the injection order. As an example only, while confirming the display of the display realized as the display unit 71, for example, the numerical value of the flow rate or the planned IN amount, the switches such as the up and down arrow buttons and the setting button realized as the operation unit 72 are operated. , the flow rate and the planned IN amount can be set. The infusion pump 70 administers the drug to the patient 4 in accordance with the flow rate for which the setting has been accepted. This infusion pump 70 enables the administration of minute amounts and precise amounts.

<One aspect of the challenge>
As described in the background art section above, the conventional electronic medical record system merely records the control parameters of the infusion pump that are self-reported and input by the nurse or the like. Therefore, if an error or input error occurs, the control parameters of the infusion pump input to the conventional electronic medical chart system do not necessarily match the control parameters of the infusion pump set by the nurse or the like. If the two do not match, the conventional electronic chart system has difficulty in confirming whether or not the injection order has been followed.

<One aspect of the problem-solving approach>
Therefore, in the server device 10 according to the present embodiment, instead of having the nurse or the like input the control parameters of the infusion pump 70 by self-declaration, the control parameters acquired from the infusion pump 70 are the control parameters instructed by the injection order. Equipped with an alert output function that compares with

As an example only, the server device 10 acquires the control parameters set for the infusion pump 70 via short-range wireless communication between the infusion pump 70 and the mobile terminal 50 . For example, a case where the mobile terminal 50 and the infusion pump 70 are compatible with NFC (Near Field Communication) will be taken as an example. In this case, a holding operation for bringing the reading position mounted with the non-contact IC (Integrated Circuit) chip of the mobile terminal 50 closer to the holding position where the non-contact IC chip of the infusion pump 70 is mounted is accepted. As a result of such holding operation, the control parameters set for the infusion pump 70 are read by the reader function or the reader/writer function of the mobile terminal 50 . When the control parameter obtained from the infusion pump 70 and the control parameter of the infusion pump 70 specified in the injection order are different, an alert is output. Here, as an example, the control parameters of the infusion pump 70 are obtained by short-range wireless communication, but they may be obtained by wireless LAN or wired communication.

Thus, the alert output function according to the present embodiment can output an alert by comparing the control parameters set for the infusion pump 70 with the control parameters for the infusion pump 70 specified in the injection order. Therefore, it is possible to prevent errors and input errors from occurring, such as when the control parameters of the infusion pump 70 are input by a nurse or the like by self-declaration.

Therefore, according to the alert output function according to the present embodiment, it is possible to assist in confirming whether or not the injection order is being followed.

<Configuration of server device 10>
FIG. 3 is a block diagram showing a functional configuration example of the server device 10. As shown in FIG. FIG. 3 schematically shows blocks related to the alert output function of the server device 10 . As shown in FIG. 3 , the server device 10 has a communication interface section 11 , a storage section 13 and a control section 15 . It should be noted that FIG. 3 only shows an excerpt of the functional units related to the alert output function described above, and functional units other than those illustrated, for example, general functions packaged in the electronic medical record function are included in the server device 10. It may be provided for

The communication interface section 11 corresponds to an example of a communication control section that controls communication with other devices such as the PC terminal 30 and the mobile terminal 50 . As an example only, the communication interface unit 11 is realized by a network interface card such as a LAN card. For example, in an example related to hospital ward nursing work, the communication interface unit 11 receives various orders from the PC terminal 30, for example, issuance of injection orders, requests for three-point authentication from the mobile terminal 50, and settings. In addition, the communication interface unit 11 outputs an alert for a medication error or a patient mix-up, or outputs an alert for a discrepancy between an injection order and the setting of the infusion pump 70 .

The storage unit 13 is a functional unit that stores various data. By way of example only, the storage unit 13 is implemented by storage, such as internal, external or auxiliary storage. For example, the storage unit 13 stores order information 13A and a progress log 13B. In addition to the order information 13A and the progress log 13B, the storage unit 13 may store other data such as an account of the electronic medical chart system 1, electronic medical charts, various orders, and receipts.

The control unit 15 is a processing unit that performs overall control of the server device 10 . For example, the control unit 15 is realized by a hardware processor. As shown in FIG. 3, the control unit 15 has an authentication unit 15A, a first collation unit 15B, a second collation unit 15C, an alert output unit 15D, and an update unit 15E.

The authentication unit 15A is a processing unit that performs three-point authentication. As an example only, the authentication unit 15A is activated when a request for three-point authentication is received from the mobile terminal 50 . For example, 3-point authentication may be requested at timings such as the start of infusion, the change in infusion rate, the middle tightening of infusion, and the end of infusion.

More specifically, the authentication unit 15A acquires, via the mobile terminal 50, the identification information of the medical staff, the identification information of the patient, and the identification information of the order, which are used for three-point authentication. These three pieces of identification information may be obtained individually in any order, or all or part of the identification information may be obtained in parallel.

For example, the authentication unit 15A accepts login to the electronic medical record system 1 via the mobile terminal 50 as a request for three-point authentication. In this case, the authentication unit 15A can acquire the identification information of the medical worker, such as the nurse ID, from the account used for login. By using such a nurse ID or the like, the authentication unit 15A can authenticate whether or not the person who is going to perform the drip infusion is a legitimate medical worker. For example, it is possible to authenticate whether or not the infusion practitioner has a doctor or nurse account in the electronic medical record system 1, or whether or not the person is a medical worker scheduled to go to work.

In addition to such medical staff identification information, the authentication unit 15A acquires from the mobile terminal 50 the patient ID read from the barcode 41 of the wristband 40 distributed to the patient 4, as illustrated in FIG. be able to. By using such a patient ID, the authentication unit 15A can authenticate whether or not the patient to whom drip infusion is performed is a legitimate patient. For example, it is possible to authenticate whether or not a person to be infused is a patient registered in an electronic medical record (not shown), for example, a patient registered in either outpatient or hospitalization classification.

Furthermore, the authentication unit 15A can acquire the order ID read from the barcode 61 of the label 60 attached to the medicine 6 from the mobile terminal 50, as illustrated in FIG. Using the order ID and patient ID acquired in this way, the authentication unit 15A authenticates whether or not there is a medication error or a mix-up of patients.

For example, the authentication unit 15A searches the order information 13A stored in the storage unit 13 for an injection order entry corresponding to the order ID read from the bar code 61 of the medicine 6 .

Here, the order information 13A is data in which the identification information of the order, for example, the instruction issued in the order is associated with each order ID. For example, taking an injection order as an example, in addition to the type of drug to be infused, the scheduled IN amount, the flow rate, etc., the patient ID of the patient who receives the injection, etc. are instructed via the PC terminal 30 having the doctor's account. An injection order entry is issued. An injection order entry corresponding to the order ID read from the bar code 61 of the medicine 6 is retrieved from the order information 13A including such a set of injection order entries.

After that, the authentication unit 15A collates the patient ID included in the injection order retrieved using the order ID read from the bar code 61 of the drug 6 and the patient ID read from the bar code 41 of the patient 4. . If these two patient IDs match, it can be confirmed that the doctor is about to administer an infusion to the patient issuing the injection order. In this case, it can be authenticated that there is no risk of medication error or patient mix-up. On the other hand, if the two patient IDs do not match, it can be confirmed that the doctor is about to administer an infusion to a patient other than the patient issuing the injection order. In this case, it can be authenticated that there is a risk of medication error or patient mix-up.

In addition, when the person who administers the intravenous drip is authenticated as a legitimate medical practitioner, the subject of the intravenous drip is authenticated as a legitimate patient, and there is no risk of medication error or patient mix-up. , the authentication unit 15A authenticates that the three-point authentication is successful, that is, "three-point authentication OK". Further, if it is authenticated that the person performing the drip is not a legitimate medical worker, the subject of the drip is not a legitimate patient, or there is a risk of medication error or patient mix-up, the authentication unit 15A has three points. If the authentication fails, it is authenticated as "three-point authentication NG".

The first verification unit 15B is a processing unit that verifies the identification information of the infusion pump 70, such as the device ID. As an example only, the first collation unit 15B performs the following processing when the three-point authentication by the authentication unit 15A is successful, that is, when the three-point authentication is OK. That is, the first verification unit 15B acquires the device ID and control parameters of the infusion pump 70 read by the mobile terminal 50 from the mobile terminal 50 through the operation of holding the mobile terminal 50 over the infusion pump 70 . After that, the first verification unit 15B refers to the entry corresponding to the injection order for which the 3-point authentication has succeeded in the progress log 13B stored in the storage unit 13, and the status regarding the implementation status of the injection order is set to "not implemented." ” is determined.

Here, the progress log 13B is log information related to the progress of the injection order. For example, taking an injection order as an example, the identification information of the order, for example, the nurse ID and patient ID that succeeded in three-point authentication for each order ID, and the date and time of the start and end of the infusion are associated as an implementation history. , associated with the status of implementation. Such an implementation status may include "not implemented", in which the infusion has not started, and "in progress," in which the infusion is in progress. In addition, the status of the implementation status may include "middle tightening" indicating intermediate tightening of the drip, "implemented" indicating completion of the drip, and the like.

At this time, if the status regarding the execution status of the injection order is "unexecuted", it can be identified that the phase in which the three-point authentication request was accepted is the start of the infusion. In this case, at the time of changing the drip speed, during tightening during drip, or at the end of drip, it is confirmed whether the same infusion pump 70 as at the start of drip is about to change the drip speed, tighten during drip, or end drip. , the device ID of the infusion pump 70 at the start of drip infusion is recorded. For example, the first verification unit 15B registers the device ID of the infusion pump 70 in the entry corresponding to the injection order for which the 3-point authentication has succeeded in the progress log 13B stored in the storage unit 13 . Here, as an example, the device ID of the infusion pump 70 is registered in the entry of the progress log 13B. However, the data structure for managing the device ID of the infusion pump 70 is not limited to the progress log 13B. It can be any data structure.

In addition, when the status regarding the execution status of the injection order is not "unexecuted", the phase in which the request for three-point authentication is accepted is not at the start of the drip, in other words, at the time of changing the drip speed, tightening during the drip, or at the end of the drip. Either aspect can be identified. In this case, from the aspect of confirming whether the same infusion pump 70 as the infusion pump 70 at the start of drip infusion is about to undergo infusion speed change, tightening during infusion, or end of infusion, the first verification unit 15B performs the following: perform a similar process. That is, the first collation unit 15B obtains the device ID included in the entry having the order ID for which the three-point authentication was successful among the entries in the progress log 13B and the operation of holding the mobile terminal 50 over the infusion pump 70. The device ID of the infusion pump 70 is collated. As a result, the two device IDs, ie, the device ID at the start of drip and the device ID at the time of changing the speed of drip, tightening during the middle of drip, or at the end of drip, are collated.

Here, if the above two device IDs match, it can be identified that there is no risk of mistaking the infusion pump 70 when changing the infusion rate, when tightening during the infusion, or when the end of the infusion. In this case, the first collation unit 15B identifies that the authentication result of the device ID of the infusion pump 70 is OK. On the other hand, if the above two device IDs do not match, it can be identified that there is a risk that the infusion pump 70 will be mixed up when changing the infusion rate, tightening during infusion, or ending infusion. In this case, the first verification unit 15B identifies that the authentication result of the device ID of the infusion pump 70 is authentication NG.

The second verification unit 15C is a processing unit that verifies control parameters of the infusion pump 70 . As an example only, the second collation unit 15C collates the following two control parameters when the authentication result of the device ID of the infusion pump 70 is OK. A first control parameter is a control parameter acquired from the mobile terminal 50 through an operation of holding the mobile terminal 50 over the infusion pump 70 . The second control parameter is a control parameter corresponding to the planned IN amount and flow rate of the drug included in the injection order corresponding to the order ID for which the three-point authentication has succeeded among the injection orders in the order information 13A. The former corresponds to the control parameters being set in the infusion pump 70, and the latter corresponds to the control parameters of the infusion pump 70 specified in the injection order. Hereinafter, the former control parameter may be referred to as "pump setting control parameter", and the latter control parameter may be referred to as "control parameter specified in the injection order".

Here, when the control parameters of the pump settings and the control parameters specified in the injection order match, it can be identified that the control parameters specified in the injection order are set in the infusion pump 70 . In this case, the second collation unit 15C identifies that the authentication result of the control parameters of the infusion pump 70 is OK. On the other hand, if the control parameters of the pump settings and the control parameters specified in the injection order do not match, it can be identified that the control parameters specified in the injection order are not set in the infusion pump 70 . In this case, the second collation unit 15C identifies that the authentication result of the control parameter of the infusion pump 70 is NG.

The alert output unit 15D is a processing unit that outputs an alert. As one aspect, when the authentication result of the device ID of the infusion pump 70 is NG, the alert output unit 15D outputs an alert regarding the mix-up of the infusion pump 70 to the mobile terminal 50 for which the three-point authentication request has been accepted. . As another aspect, when the authentication result of the control parameter of the infusion pump 70 is NG, the alert output unit 15D outputs an alert to the mobile terminal 50 that the control parameter of the pump setting and the control parameter indicated by the injection order do not match. Output to Note that although the mobile terminal 50 for which the request for three-point authentication has been accepted is taken as an example of the output destination of the alert here, the output destination of the alert is not limited to this. For example, the alert output destination may be the PC terminal 30 or the mobile terminal 50 corresponding to the account of the doctor who issued the injection order.

The updating unit 15E is a processing unit that updates the progress log 13B. As one aspect, when the authentication result of the control parameter of the infusion pump 70 is authentication OK, the updating unit 15E updates the contents of the entry of the order ID for which the three-point authentication has succeeded among the entries in the progress log 13B. For example, the update unit 15E registers the execution history of drip start, drip speed change, middle tightening, or drip end, and updates the status of the execution status according to the phase of drip start, drip speed change, middle tightening, or drip end. Update to "in progress", "midterm" or "implemented". In addition, the update unit 15E can additionally register an alert regarding authentication NG of the device ID of the infusion pump 70 or authentication NG of the control parameters of the infusion pump 70 when the alert is output.

<Screen transition at the start of infusion>
FIG. 4 is a diagram showing an example of screen transition. FIG. 4 shows the transition of the screen of the mobile terminal 50 at the start of infusion in chronological order. For example, logging in to the electronic medical chart system 1 via the mobile terminal 50 in a state in which "start of drip infusion" is designated among progress categories of "start of drip infusion", "change in drip rate", "intermediate tightening", and "end of drip infusion". is accepted as a request for three-point authentication. At this time, by using the nurse ID or the like identified from the account used for login, the authenticating unit 15A authenticates whether or not the person performing the intravenous drip is a legitimate medical worker.

After the nurse ID is authenticated, the mobile terminal 50 displays a patient authentication screen 410 shown in FIG. For example, the patient authentication screen 410 includes a message "Please read the wristband or the barcode containing the patient ID" prompting the reading of the barcode 41 of the patient 4. In addition, the patient authentication screen 410 may include a shooting area 411 that displays a live image being shot by an out-camera (not shown). The patient ID is read by applying the bar code scanner function to the live image displayed in the imaging area 411 . When the patient ID is read in this manner, the authenticating unit 15A authenticates whether or not the patient to whom the intravenous drip is to be administered is a legitimate patient.

After authenticating the patient ID, the mobile terminal 50 displays an injection authentication screen 420 for authenticating the injection order. For example, the injection authentication screen 420 includes a message “Please read the injection barcode” prompting the barcode 61 of the medicine 6 to be read. In addition, the injection authentication screen 420 may include a shooting area 421 that displays a live image being shot by an out-camera (not shown). By applying the bar code scanner function to the live image displayed in the imaging area 421, the order ID is read. By using the order ID and patient ID thus acquired, the presence or absence of medication errors and patient mix-ups is authenticated by the authentication unit 15A.

After verifying the consistency of the order ID and the patient ID, for example, if three-point verification is OK, the injection execution screen 430 is displayed on the mobile terminal 50 . Here, although FIG. 4 shows the entire page included in the injection execution screen 430, part of the page may be displayed on the display unit of the mobile terminal 50 using a scroll bar or the like. For example, on the injection execution screen 430, the content of the injection order corresponding to the order ID read on the injection authentication screen 420 is confirmed and displayed, and a message prompting the operator to hold the mobile terminal 50 over the infusion pump 70 is displayed. .

Thereafter, when the mobile terminal 50 is held over the infusion pump 70 and the execution button 431 is operated, the device ID and control parameters of the infusion pump 70 read by the mobile terminal 50 are sent from the mobile terminal 50 to the first The collation unit 15B is notified.

At the start of drip infusion, the status regarding the execution status of the injection order is "unexecuted", so verification of the device ID of the infusion pump 70 by the first verification unit 15B is skipped. Instead, the device ID of the infusion pump 70 at the start of the infusion is recorded in the entry of the progress log 13B in preparation for the start of the infusion when the infusion rate is changed, when the infusion is tightened during the infusion, or when the infusion ends. After that, the control parameters of the infusion pump 70 are checked by the second checking section 15C.

Here, when the authentication result of the control parameter of the infusion pump 70 is authentication NG, an alert screen 440 is displayed on the mobile terminal 50 . For example, alert screen 440 displays an alert message that there is a mismatch between the control parameters of the pump settings and the control parameters specified in the injection order. In the example of the alert screen 440, a discrepancy between the flow rate "200 ml/h" instructed in the injection order and the flow rate pump setting "100 ml/h" is written together. Furthermore, on the alert screen 440, there are a button 441 of "Import as it is" for recording the execution history of the infusion while the instructions of the injection order and the pump setting remain inconsistent, and a "Reset" button for resetting the control parameters of the infusion pump 70. ' button 442 is displayed. This discrepancy between the injection order instructions and the pump settings is accepted because the doctor verbally instructs the nurse to change the flow rate or planned IN volume before the start of the drip, or the doctor instructs the nurse before the start of the drip. This is because there are operations such as changing the drip flow rate and the scheduled IN amount. By permitting this operation, the electronic medical record function can be made flexible enough to respond to a sudden change in the patient's condition.

If the authentication result of the control parameters of the infusion pump 70 is OK, or if the “Import as is” button 441 on the alert screen 440 is operated, the mobile terminal 50 displays an injection result screen 450 . The injection execution result screen 450 displays the updated contents of the entry in the progress log 13B, for example, the execution history at the start of the infusion and the status of the execution status "in progress".

<Screen transition when changing drip speed>
FIG. 5 is a diagram showing an example of screen transition. FIG. 5 shows the transition of the screen of the mobile terminal 50 when the drip speed is changed in chronological order. For example, in a state in which "change infusion rate" is specified among progress categories of "start infusion", "change infusion rate", "intermediate tightening", and "end of infusion", access to the electronic medical record system 1 via the mobile terminal 50 Login is accepted as a request for three-point authentication. At this time, by using the nurse ID or the like identified from the account used for login, the authenticating unit 15A authenticates whether or not the person performing the intravenous drip is a legitimate medical worker.

After authentication of the nurse ID, the mobile terminal 50 displays a patient authentication screen 510, as shown in FIG. 5, which functions similarly to the patient authentication screen 410 shown in FIG. For example, the patient ID is read by applying the barcode scanner function to the live image displayed in the imaging area 511 within the patient authentication screen 510 . When the patient ID is read in this manner, the authenticating unit 15A authenticates whether or not the patient to whom the intravenous drip is to be administered is a legitimate patient.

After authenticating the patient ID, the mobile terminal 50 displays an injection authentication screen 520 that functions similarly to the injection authentication screen 420 shown in FIG. For example, the order ID is read by applying the barcode scanner function to the live image displayed in the imaging area 521 within the injection authentication screen 520 . By using the order ID and patient ID thus acquired, the presence or absence of medication errors and patient mix-ups is authenticated by the authentication unit 15A.

After verifying the consistency of the order ID and the patient ID, for example, if three-point verification is OK, the mobile terminal 50 displays an infusion rate change screen 530 . For example, on the infusion speed change screen 530, the injection order corresponding to the order ID read on the injection authentication screen 520, that is, the injection order for changing the infusion speed is confirmed and displayed, and the operation of holding the mobile terminal 50 over the infusion pump 70 is performed. A message prompting you to

Thereafter, when the mobile terminal 50 is held over the infusion pump 70 and the execution button 531 is operated, the device ID and control parameters of the infusion pump 70 read by the mobile terminal 50 are sent from the mobile terminal 50 to the first The collation unit 15B is notified. For example, when the drip rate is changed, the status regarding the execution status of the injection order is "in progress", so the device ID of the infusion pump 70 is verified by the first verification unit 15B.

At this time, if the result of authentication of the device ID of the infusion pump 70 is authentication NG, an alert screen 540 is displayed on the mobile terminal 50 . For example, the alert screen 540 displays an alert about a mix-up of the infusion pump 70, for example, a message that the device ID of the infusion pump 70 at the start of infusion does not match the device ID of the infusion pump 70 at the time of changing the infusion rate. As a result, when the infusion pump 70 is mixed up, the infusion rate can be changed again.

Further, even if the authentication result of the device ID of the infusion pump 70 is authentication OK, if the authentication result of the control parameter of the infusion pump 70 is authentication NG, the alert screen 550 is displayed on the mobile terminal 50 . For example, alert screen 550 displays an alert message that there is a mismatch between the control parameters of the pump settings and the control parameters specified in the injection order. In the example of the alert screen 550, a discrepancy between the flow rate "60 ml/h" instructed in the injection order and the flow rate pump setting "50 ml/h" is written together. Furthermore, on the alert screen 550, there are a button 551 of "Import as is" for recording the execution history of the infusion while the instructions of the injection order and the pump settings do not match, and a "Reset" button for resetting the control parameters of the infusion pump 70. ' button 552 is displayed. Note that when the authentication result of the control parameter of the infusion pump 70 is authentication OK, or the screen transition after the alert screen 550 is the same as at the start of infusion except for the progress division, the explanation is omitted. do.

<Screen transition during middle tightening>
FIG. 6 is a diagram showing an example of screen transition. FIG. 6 shows transitions of screens of the mobile terminal 50 in time series during middle closing. For example, logging in to the electronic medical record system 1 via the mobile terminal 50 in a state in which "intermediate tightening" is specified among progress categories of "infusion start", "infusion rate change", "intermediate tightening", and "infusion end". is accepted as a request for three-point authentication. At this time, by using the nurse ID or the like identified from the account used for login, the authenticating unit 15A authenticates whether or not the person performing the intravenous drip is a legitimate medical worker.

After authentication of the nurse ID, the mobile terminal 50 displays a patient authentication screen 610, as shown in FIG. 6, which functions similarly to the patient authentication screen 410 shown in FIG. For example, the patient ID is read by applying the barcode scanner function to the live image displayed in the imaging area 611 within the patient authentication screen 610 . When the patient ID is read in this manner, the authenticating unit 15A authenticates whether or not the patient to whom the intravenous drip is to be administered is a legitimate patient.

After the patient ID is authenticated, the mobile terminal 50 displays an injection authentication screen 620 that functions similarly to the injection authentication screen 420 shown in FIG. For example, the order ID is read by applying the barcode scanner function to the live image displayed in the imaging area 521 within the injection authentication screen 620 . By using the order ID and patient ID thus acquired, the presence or absence of medication errors and patient mix-ups is authenticated by the authentication unit 15A.

After verifying the consistency of the order ID and the patient ID, for example, if three-point verification is OK, the mobile terminal 50 displays a middle closing screen 630 . For example, on the middle tightening screen 630, the injection order corresponding to the order ID read on the injection authentication screen 620, that is, the middle tightening injection order is confirmed and displayed. When the mobile terminal 50 is held over the infusion pump 70 while the intermediate tightening screen 630 is being displayed, the intermediate tightening screen 630 displays the IN amount read by the mobile terminal 50, that is, the cumulative amount from the start of the intravenous drip to the intermediate tightening. quantity is displayed. After that, by operating the confirmation button 631, the entry in the progress log 13B is updated, for example, the execution history of intermediate closing and the status of the implementation status "middle closing" is executed.

Although not shown in FIG. 6, when the authentication result of the device ID of the infusion pump 70 is NG, the following display can be performed. For example, similar to the alert screen 540, the mobile terminal 50 can display an alert screen in which the device ID of the infusion pump 70 at the start of drip does not match the device ID of the infusion pump 70 at the time of intermediate tightening.

<Screen transition at the end of infusion>
FIG. 7 is a diagram showing an example of screen transition. FIG. 7 shows the transition of the screen of the mobile terminal 50 in chronological order at the end of the infusion. For example, logging in to the electronic medical record system 1 via the mobile terminal 50 in a state in which "end of drip" is specified among progress categories of "start of drip", "change of drip speed", "middle tightening", and "end of drip". is accepted as a request for three-point authentication. At this time, by using the nurse ID or the like identified from the account used for login, the authenticating unit 15A authenticates whether or not the person performing the intravenous drip is a legitimate medical worker.

After authentication of the nurse ID, the mobile terminal 50 displays a patient authentication screen 710, as shown in FIG. 7, which functions similarly to the patient authentication screen 410 shown in FIG. For example, the patient ID is read by applying the barcode scanner function to the live image displayed in the imaging area 711 within the patient authentication screen 710 . When the patient ID is read in this manner, the authenticating unit 15A authenticates whether or not the patient to whom the intravenous drip is to be administered is a legitimate patient.

After authenticating the patient ID, the mobile terminal 50 displays an injection authentication screen 720 that functions similarly to the injection authentication screen 420 shown in FIG. For example, the order ID is read by applying the barcode scanner function to the live image displayed in the imaging area 721 within the injection authentication screen 720 . By using the order ID and patient ID thus acquired, the presence or absence of medication errors and patient mix-ups is authenticated by the authentication unit 15A.

After verifying the consistency of the order ID and the patient ID, for example, if the three-point verification is OK, the drip end screen 730 is displayed on the mobile terminal 50 . For example, on the infusion end screen 730, the injection order being executed corresponding to the order ID read on the injection authentication screen 720 is displayed for confirmation. When the mobile terminal 50 is held over the infusion pump 70 while the infusion end screen 730 is being displayed, the infusion end screen 730 displays the IN amount read by the mobile terminal 50, that is, the cumulative total from the start of the infusion to the end of the infusion. quantity is displayed. After that, by operating the implementation button 731, the entry in the progress log 13B is updated, for example, the implementation history of the completion of the infusion and the status of the implementation status “implemented” is executed.

Although not shown in FIG. 7, when the authentication result of the device ID of the infusion pump 70 is NG, the following display can be performed. For example, similar to the alert screen 540, the mobile terminal 50 can display an alert screen in which the device ID of the infusion pump 70 at the start of infusion does not match the device ID of the infusion pump 70 at the end of infusion.

<Process flow>
FIG. 8 is a flowchart showing the procedure of alert output processing. This process may be executed when a request for three-point authentication is accepted, as an example only. As shown in FIG. 8, the authentication unit 15A acquires identification information of a medical worker, such as a nurse ID, from the account used to log in to the electronic medical record system 1 when requesting three-point authentication (step S101).

Also, as illustrated in FIG. 2, the authentication unit 15A acquires the patient ID read from the barcode 41 of the wristband 40 distributed to the patient 4 from the mobile terminal 50 (step S102).

Further, the authentication unit 15A acquires the order ID read from the barcode 61 of the label 60 attached to the medicine 6 from the mobile terminal 50, as illustrated in FIG. 2 (step S103).

Using the identification information of the medical staff, the identification information of the patient, and the identification information of the order, the authentication unit 15A performs three-point authentication (step S104). For example, the authentication unit 15A uses the nurse ID to determine whether or not the person performing the infusion is a legitimate medical worker, and uses the patient ID to determine whether or not the subject of the infusion is a legitimate patient. , the order ID and the patient ID are used to authenticate whether or not there is a risk of medication error or patient mix-up.

At this time, if the 3-point authentication is successful, that is, if the 3-point authentication is OK (step S105 Yes), the first matching unit 15B performs the following processing. That is, the first verification unit 15B acquires the device ID and control parameters of the infusion pump 70 read by the mobile terminal 50 from the mobile terminal 50 through the holding operation of the mobile terminal 50 over the infusion pump 70 (step S106).

Subsequently, the first verification unit 15B refers to the entry corresponding to the injection order for which the three-point authentication has succeeded in the progress log 13B stored in the storage unit 13, and determines that the status regarding the implementation status of the injection order is "not It is determined whether it is "implementation" (step S107).

At this time, if the status regarding the execution status of the injection order is "unexecuted" (Yes in step S107), it can be identified that the stage in which the request for three-point authentication was accepted is the start of infusion. In this case, the first verification unit 15B registers the device ID of the infusion pump 70 in the entry corresponding to the injection order for which the 3-point authentication has succeeded in the progress log 13B stored in the storage unit 13 (step S108). .

On the other hand, if the status regarding the execution status of the injection order is not "unexecuted" (No in step S107), it can be identified that the phase in which the three-point authentication request was received is not the start of infusion. In this case, from the aspect of confirming whether the same infusion pump 70 as the infusion pump 70 at the start of drip infusion is about to undergo infusion speed change, tightening during infusion, or end of infusion, the first verification unit 15B performs the following: perform a similar process.

That is, the first verification unit 15B compares the device ID included in the entry of the progress log 13B having the order ID for which the three-point authentication was successful, and the infusion pump acquired through the operation of holding the mobile terminal 50 over the infusion pump 70. 70 device ID (step S109). As a result, the two device IDs, ie, the device ID at the start of drip and the device ID at the time of changing the speed of drip, tightening during the middle of drip, or at the end of drip, are collated.

At this time, if the above two device IDs do not match (No at step S109), it can be identified that there is a risk of a mix-up of the infusion pump 70 at the time of changing the infusion rate, tightening during the infusion, or at the end of the infusion. In this case, the alert output unit 15D outputs an alert regarding the mix-up of the infusion pump 70 to the mobile terminal 50 for which the three-point authentication request has been accepted (step S111).

On the other hand, if the above two device IDs match (step S109 Yes), it can be identified that there is no risk of mistaking the infusion pump 70 when changing the infusion rate, tightening during the infusion, or finishing the infusion. In this case, the second collation unit 15C corresponds to the control parameter of the pump setting acquired in step S106 and the scheduled IN amount and flow rate of the drug included in the injection order corresponding to the order ID for which the three-point authentication has succeeded. The control parameters are collated (step S110).

Here, if the control parameters of the pump settings and the control parameters specified in the injection order do not match (step S110 No), it can be identified that the control parameters specified in the injection order are set in the infusion pump 70. In this case, the alert output unit 15D outputs to the mobile terminal 50 an alert indicating that the control parameters of the pump settings and the control parameters specified in the injection order do not match (step S112).

On the other hand, if the control parameters of the pump settings and the control parameters specified in the injection order match (step S110 Yes), it can be identified that the control parameters specified in the injection order are set in the infusion pump 70 . In this case, the process of step S112 is skipped.

After that, the update unit 15E updates the contents of the entry of the order ID for which the three-point authentication has succeeded among the entries in the progress log 13B (step S113), and ends the process. For example, you can register the execution history of drip start, drip speed change, middle tightening, or drip end, or change the implementation status to "in progress", Update to "mid-tightening" or "implemented". In addition, when outputting an alert, it is also possible to additionally register an alert regarding authentication NG of the device ID of the infusion pump 70 or authentication NG of the control parameters of the infusion pump 70 .

<One aspect of the effect>
As described above, the alert output function according to the present embodiment compares the control parameters set for the infusion pump 70 with the control parameters for the infusion pump 70 specified in the injection order and outputs an alert. Therefore, it is possible to prevent errors and input errors from occurring, such as when the control parameters of the infusion pump 70 are input by a nurse or the like by self-declaration. Therefore, according to the alert output function according to the present embodiment, it is possible to assist in confirming whether or not the injection order is being followed.

Although embodiments of the disclosed apparatus have been described so far, the present invention may be embodied in various forms other than the embodiments described above. Therefore, other embodiments included in the present invention will be described below.

<Decentralization and Integration>
Also, each component of each illustrated device may not necessarily be physically configured as illustrated. In other words, the specific form of distribution and integration of each device is not limited to the one shown in the figure, and all or part of them can be functionally or physically distributed and integrated in arbitrary units according to various loads and usage conditions. Can be integrated and configured. For example, the authentication unit 15A, the first verification unit 15B, the second verification unit 15C, the alert output unit 15D, or the update unit 15E may be connected to the server device 10 via a network as external devices. In addition, different devices each have the authentication unit 15A, the first verification unit 15B, the second verification unit 15C, the alert output unit 15D, or the update unit 15E, and are connected to a network to cooperate with each other, so that the server The functions of the device 10 may be realized. In addition, the order information 13A and the progress log 13B stored in the storage unit 13 are all or partially stored in separate devices, which are connected to a network and cooperate with each other to realize the functions of the server device 10 described above. You may do so.

[Alert output program]
Moreover, various processes described in the above embodiments can be realized by executing a prepared program on a computer such as a personal computer or a work station. Therefore, an example of a computer that executes an alert output program having functions similar to those of the first and second embodiments will be described below with reference to FIG.

FIG. 9 is a diagram illustrating a hardware configuration example. As shown in FIG. 9, the computer 100 has an operation section 110a, a speaker 110b, a camera 110c, a display 120, and a communication section . Furthermore, this computer 100 has a CPU 150 , a ROM 160 , an HDD 170 and a RAM 180 . Each part of these 110 to 180 is connected via a bus 140 .

As shown in FIG. 9, the HDD 170 has functions similar to those of the authentication unit 15A, the first verification unit 15B, the second verification unit 15C, the alert output unit 15D, and the updating unit 15E shown in the first embodiment. is stored an alert output program 170a that exerts This alert output program 170a can be integrated or separated in the same manner as the components of the authentication unit 15A, the first verification unit 15B, the second verification unit 15C, the alert output unit 15D, and the update unit 15E shown in FIG. good too. That is, the HDD 170 does not necessarily store all the data shown in the first embodiment, and the HDD 170 only needs to store data used for processing.

Under such an environment, the CPU 150 reads out the alert output program 170 a from the HDD 170 and develops it in the RAM 180 . As a result, the alert output program 170a functions as an alert output process 180a as shown in FIG. The alert output process 180a deploys various data read from the HDD 170 in an area assigned to the alert output process 180a among storage areas of the RAM 180, and executes various processes using the deployed various data. For example, an example of processing executed by the alert output process 180a may include the processing shown in FIG. Note that the CPU 150 does not necessarily have to operate all the processing units described in the first embodiment, as long as the processing units corresponding to the processes to be executed are virtually realized.

Note that the alert output program 170a described above does not necessarily have to be stored in the HDD 170 or the ROM 160 from the beginning. For example, the alert output program 170a is stored in a “portable physical medium” such as a flexible disk inserted into the computer 100, so-called FD, CD-ROM, DVD disk, magneto-optical disk, IC card, or the like. The computer 100 may acquire and execute the alert output program 170a from these portable physical media. Also, the alert output program 170a is stored in another computer or server device connected to the computer 100 via a public line, Internet, LAN, WAN, or the like. The alert output program 170a stored in this manner may be downloaded to the computer 100 and executed.

The following notes are further disclosed with respect to the embodiments including the above examples.

(Appendix 1) Acquiring a control parameter set in the infusion pump from the infusion pump that adjusts the flow rate of the drip administered to the patient,
Outputting an alert when the control parameter obtained from the infusion pump and the control parameter of the infusion pump indicated in the injection order are different;
An alert output program characterized by causing a computer to execute processing.

(Appendix 2) The acquiring process includes acquiring the control parameters read by the mobile terminal via short-range wireless communication executed in response to the mobile terminal approaching the infusion pump.
The alert output program according to Supplementary Note 1, characterized by:

(Appendix 3) The acquiring process includes a process of acquiring identification information of the infusion pump,
The output process includes outputting an alert when the infusion pump identification information acquired at the start of the infusion is different from the infusion pump identification information acquired at the timing after the start of the infusion.
The alert output program according to Supplementary Note 1, characterized by:

(Appendix 4) The timing includes at least one of at least one of when changing the drip speed, when tightening the middle tightening, or when the drip is finished.
The alert output program according to Supplementary Note 3, characterized by:

(Appendix 5) Acquiring a control parameter set in the infusion pump from the infusion pump that adjusts the flow rate of the infusion administered to the patient,
Outputting an alert when the control parameter obtained from the infusion pump and the control parameter of the infusion pump indicated in the injection order are different;
An alert output method characterized in that a computer executes processing.

(Appendix 6) The acquiring process includes acquiring the control parameters read by the mobile terminal via short-range wireless communication executed in response to the mobile terminal approaching the infusion pump.
The alert output method according to appendix 5, characterized by:

(Appendix 7) The obtaining process includes a process of obtaining identification information of the infusion pump,
The output process includes outputting an alert when the infusion pump identification information acquired at the start of the infusion is different from the infusion pump identification information acquired at the timing after the start of the infusion.
The alert output method according to appendix 5, characterized by:

(Appendix 8) The timing includes at least one of at least one of when changing the drip speed, when tightening the middle tightening, or when the drip is finished.
The alert output method according to appendix 7, characterized by:

(Appendix 9) Acquiring a control parameter set in the infusion pump from the infusion pump that adjusts the flow rate of the infusion administered to the patient,
Outputting an alert when the control parameter obtained from the infusion pump and the control parameter of the infusion pump indicated in the injection order are different;
An alert output device comprising a control unit that executes processing.

(Appendix 10) The acquiring process includes acquiring the control parameters read by the mobile terminal via short-range wireless communication, which is executed in response to the mobile terminal approaching the infusion pump.
The alert output device according to appendix 9, characterized by:

(Appendix 11) The acquiring process includes a process of acquiring identification information of the infusion pump,
The output process includes outputting an alert when the infusion pump identification information acquired at the start of the infusion is different from the infusion pump identification information acquired at the timing after the start of the infusion.
The alert output device according to appendix 9, characterized by:

(Supplementary Note 12) The timing includes at least one of at least one of when changing the drip speed, when tightening the middle tightening, or when the drip is finished.
The alert output device according to appendix 11, characterized by:

1 electronic chart system 2 nurse 4 patient 6 drug 10 server device 11 communication interface unit 13 storage unit 13A order information 13B progress log 15 control unit 15A authentication unit 15B first collation unit 15C second collation unit 15D alert output unit 15E update unit 30 PC terminal 40 wristband 41 barcode 50 mobile terminal 60 label 61 barcode 70 infusion pump 71 display unit 72 operation unit

Claims (6)

Acquiring a control parameter set in the infusion pump from the infusion pump that adjusts the flow rate of the infusion administered to the patient;
Outputting an alert when the control parameter obtained from the infusion pump and the control parameter of the infusion pump indicated in the injection order are different;
An alert output program characterized by causing a computer to execute processing. The acquiring process includes acquiring the control parameters read by the mobile terminal via short-range wireless communication executed in response to the mobile terminal approaching the infusion pump.
The alert output program according to claim 1, characterized by: The obtaining process includes a process of obtaining identification information of the infusion pump,
The output process includes outputting an alert when the infusion pump identification information acquired at the start of the infusion is different from the infusion pump identification information acquired at the timing after the start of the infusion.
3. The alert output program according to claim 1 or 2, characterized by: The timing includes at least one of at least one of when changing the drip speed, when tightening the middle tightening, or when the drip is finished,
4. The alert output program according to claim 3, characterized by: Acquiring a control parameter set in the infusion pump from the infusion pump that adjusts the flow rate of the infusion administered to the patient;
Outputting an alert when the control parameter obtained from the infusion pump and the control parameter of the infusion pump indicated in the injection order are different;
An alert output method characterized in that a computer executes processing. Acquiring a control parameter set in the infusion pump from the infusion pump that adjusts the flow rate of the infusion administered to the patient;
Outputting an alert when the control parameter obtained from the infusion pump and the control parameter of the infusion pump indicated in the injection order are different;
An alert output device comprising a control unit that executes processing.

Images