Computer program, information processing device, and information processing method

Abstract

Provided are a computer program, an information processing device, and an information processing method. 　The computer program makes a computer execute a processing that includes: evaluating the body water storage state in a patient having heart failure or renal dysfunction; determining whether or not the taking of a diuretic drug should be recommended on the basis of a result of the evaluation; and notifying a terminal device for the patient about a proposal relating to the taking of the diuretic drug on the basis of a result of the determination.

Description

Computer program, information processing device, and information processing method

[0001] The present disclosure relates to a computer program, an information processing device, and an information processing method.

[0002] In recent years, the number of patients with heart failure and renal dysfunction has been increasing year by year, putting pressure on medical facilities. Heart failure and renal dysfunction repeatedly worsen, and the large number of patients who are re-admitted to hospital is thought to be one of the causes of this pressure on medical facilities.

[0003] JP 2007-188149 A

[0004] Physicians in the medical field want to intervene early in patients with heart failure or renal dysfunction, but in reality they tend to refrain from prescribing diuretics because they believe that patients will not be able to take them at the appropriate time, or that the effects and side effects of diuretics cannot be evaluated outside of the hospital.

[0005] Patent Document 1 discloses a medication information provision system that notifies medication information according to the patient's physical condition, but does not solve the problems specific to heart failure and renal dysfunction as described above.

[0006] In one aspect, an object of the present invention is to provide a computer program, an information processing device, and an information processing method that can promote treatment that actively utilizes diuretics as a treatment for patients with heart failure or renal dysfunction.

[0007] (1) The computer program disclosed herein is a computer program for causing a computer to execute a process of evaluating the body fluid retention state of a patient with heart failure or renal dysfunction, determining whether or not to recommend taking a diuretic based on the evaluation results, and notifying a terminal device of the patient of a suggestion regarding taking a diuretic based on the determination results.

[0008] (2) In the computer program of (1) above, it is preferable that the computer is caused to execute a process of sending questions regarding the patient's body water retention status to the terminal device, receiving the patient's answers to the questions from the terminal device, and evaluating the patient's body water retention status based on the received answers.

[0009] (3) In the computer program of (1) or (2) above, it is preferable that measurement data obtained by measuring the patient's bioimpedance is received through the terminal device, and the computer is caused to execute a process of evaluating the patient's body water retention state based on the received measurement data.

[0010] (4) In any one of the computer programs (1) to (3) above, it is preferable to have the computer execute a process of storing the evaluation results of the body water retention state in chronological order and determining whether or not to recommend taking the diuretic depending on changes in the evaluation results stored in chronological order.

[0011] (5) In any one of the computer programs (1) to (4) above, it is preferable to cause the computer to execute a process of acquiring prescription information for the patient and generating a proposal for the patient based on the acquired prescription information.

[0012] (6) In any one of the computer programs (1) to (5) above, it is preferable to have the computer execute a process of acquiring personal authentication information of the patient and acquiring prescription information for the patient from a server device accessible based on the personal authentication information.

[0013] (7) In the computer program of (6) above, it is preferable that a control command be output to the terminal device in order to acquire the prescription information from the server device.

[0014] (8) In any one of the computer programs (1) to (7) above, it is preferable that the computer executes a process of sending a suggestion regarding taking the diuretic to a doctor's terminal device, and when a notification of approval of the suggestion is received from the doctor's terminal device, notifying the patient's terminal device of the suggestion.

[0015] (9) In any one of the computer programs (1) to (8) above, it is preferable that the computer executes a process of notifying the patient's terminal device of suggested actions other than taking medication.

[0016] (10) In the computer program of (9) above, the suggested action preferably includes at least one of contacting a medical institution, visiting a medical institution, and contacting an emergency department.

[0017] (11) In any one of the computer programs (1) to (10) above, it is preferable to have the computer execute a process of receiving information regarding the patient's condition after taking a diuretic from the terminal device and storing the received information in association with the patient's identifier.

[0018] (12) In any one of the computer programs (1) to (11) above, it is preferable to have the computer execute a process of receiving information from the terminal device regarding whether or not the diuretic has been taken, and storing the received information in association with the patient's identifier.

[0019] (13) In the computer program of (12) above, it is preferable to make the computer execute a process for managing at least one of the number of times the patient takes the diuretic and the amount of the diuretic remaining, based on the received information.

[0020] (14) In any one of the computer programs (11) to (13) above, it is preferable that the computer executes a process of sharing the stored information about the patient with a set sharing destination.

[0021] (15) The information processing device of the present disclosure includes at least one processing unit that evaluates the body fluid retention state of a patient with heart failure or renal dysfunction, determines whether or not to recommend taking a diuretic based on the evaluation results, and notifies the patient's terminal device of a suggestion regarding taking a diuretic based on the determination results.

[0022] (16) The information processing method disclosed herein includes a computer-implemented process of evaluating the body fluid retention status of a patient with heart failure or renal dysfunction, determining whether or not to recommend taking a diuretic based on the evaluation results, and notifying the patient's terminal device of a suggestion regarding taking a diuretic based on the determination results.

[0023] In one aspect, it is possible to promote treatment that actively utilizes diuretics as a treatment for patients with heart failure or renal dysfunction.

[0024] FIG. 1 is a schematic diagram showing an example of the configuration of an information processing system according to embodiment 1. FIG. 2 is a block diagram showing the internal configuration of a patient terminal. FIG. 3 is a block diagram showing the internal configuration of a doctor terminal. FIG. 4 is a block diagram showing the internal configuration of a management server. FIG. 5 is a conceptual diagram showing an example of a patient information database. FIG. 6 is a flowchart explaining the procedure of processing executed in the information processing system according to embodiment 1. FIG. 7 is a schematic diagram showing an example of an answer input screen. FIG. 8 is a schematic diagram showing an example of a medication suggestion display. FIG. 9 is a flowchart explaining the procedure of processing executed in the information processing system according to embodiment 2. FIG. 10 is a flowchart explaining the procedure of processing executed in the information processing system according to embodiment 3. FIG. 11 is a schematic diagram showing an example of a medication status confirmation screen. FIG. 12 is a conceptual diagram showing an example of a medication history table.

[0025] The present invention will be described in detail below with reference to the drawings showing embodiments thereof. (Embodiment 1) Fig. 1 is a schematic diagram showing an example of the configuration of an information processing system according to embodiment 1. The information processing system according to embodiment 1 includes a patient terminal 10, a doctor terminal 20, a management server 30, etc. These terminals and servers are communicably connected to each other via a communication network NW. The communication network NW may be a general public line or a dedicated line, or may be configured to use a general public line and a dedicated line in combination.

[0026] The patient terminal 10 is a terminal device such as a smartphone used by a patient with heart failure or renal dysfunction. The patient terminal 10 collects data (hereinafter referred to as evaluation data) used to evaluate the patient's state of body fluid retention and transmits the collected evaluation data to the management server 30. The evaluation data includes data on the patient's responses to questions regarding the state of body fluid retention, measurement data of bioelectrical impedance, video data for observing the degree of jugular venous distension or edema, and voice data of the patient. The management server 30 evaluates the patient's state of body fluid retention based on the evaluation data transmitted from the patient terminal 10, determines whether or not to recommend the administration of a diuretic, and makes a dosing suggestion to the patient based on the determination result. The patient terminal 10 presents the dosing suggestion notified by the management server 30 to the patient.

[0027] The doctor terminal 20 is a terminal device such as a personal computer used by a doctor at a medical institution. Before transmitting a medication suggestion from the management server 30 to the patient terminal 10, the doctor may determine whether the medication suggestion is appropriate, and if the doctor determines that the medication suggestion is appropriate, may approve the medication suggestion from the management server 30.

[0028] The information processing system may include an authentication server 40 that provides official authentication to the patient's personal information. The authentication server 40 is established by a public certification authority (for example, the Japan Agency for Local Government Information Systems, also known as J-LIS). The personal identification number card (My Number Card) issued to each individual by a government agency is used for official authentication. In this embodiment, the authentication server 40 authenticates the digital signature certificate recorded on the IC (Integrated Circuit) chip of the personal identification number card, thereby providing official authentication to the personal information (four basic pieces of information: name, date of birth, gender, and address) included in the digital signature certificate.

[0029] The information processing system may include an information providing server 50 that provides personal information of patients and the like. The information providing server 50 is installed by the national or local government, or a private business. The personal information managed by the information providing server 50 includes prescription information for patients. In this embodiment, the prescription information includes the type of diuretic prescribed to the patient and the dosage per dose. Access to the personal information registered in the information providing server 50 may be permitted only when the patient has been authenticated by the authentication server 40.

[0030] 2 is a block diagram showing the internal configuration of the patient terminal 10. The patient terminal 10 is a computer such as a smartphone, tablet terminal, or personal computer, and includes, for example, a control unit 11, a storage unit 12, a communication unit 13, a connection unit 14, an imaging unit 15, a voice input unit 16, a reading unit 17, an operation unit 18, and a display unit 19.

[0031] The control unit 11 includes, for example, a CPU (Central Processing Unit), a ROM (Read Only Memory), and a RAM (Random Access Memory). The ROM included in the control unit 11 stores control programs and the like that control the operation of each hardware component included in the patient terminal 10. The CPU in the control unit 11 reads and executes the control programs stored in the ROM and various computer programs stored in the storage unit 12, and controls the operation of each hardware component, thereby causing the entire device to function as the patient terminal 10 of the present disclosure. The RAM included in the control unit 11 temporarily stores data used during the execution of calculations and control.

[0032] The control unit 11 is not limited to the above configuration, and may be configured as a single piece of hardware (SoC: System On a Chip) that integrates a processor, memory, storage, communication interface, etc. The control unit 11 may also have functions such as a clock that outputs date and time information, a timer that measures the elapsed time from when an instruction to start measurement is given until when an instruction to end measurement is given, and a counter that counts numbers.

[0033] The storage unit 12 includes a storage such as a flash memory, and stores various computer programs executed by the control unit 11, data required for executing the computer programs, and the like.

[0034] The computer programs stored in the storage unit 12 include application programs (self-care apps) for supporting patient self-care. The example in FIG. 2 shows a configuration in which a heart failure self-care app PG11 is installed in the storage unit 12. The heart failure self-care app PG11 is an application program for patients suffering from heart failure. The heart failure self-care app PG11 is installed on the patient terminal 10 by the patient suffering from heart failure. The heart failure self-care app PG11 has a function for accepting input of patient information, including the patient's vital signs (weight, blood pressure, body temperature, pulse rate, respiratory rate, etc.), physical condition information, exercise content, exercise time, meal images, medication information, etc., and uploading the accepted patient information to the management server 30. The information uploaded via the heart failure self-care app PG11 is stored in a database (patient information database DB31 shown in FIG. 5 ) in the management server 30 together with the patient's management ID. Here, the management ID is an identifier for identifying the patient. The management ID may be an identifier unique to the patient, or may be an identifier assigned to the patient for each disease (each self-care application).

[0035] In the present embodiment, as an example, a configuration in which the heart failure self-care app PG11 is installed on the patient terminal 10 (i.e., a case in which the patient is a heart failure patient) will be described. However, if the patient also suffers from renal dysfunction, a self-care app for patients with renal dysfunction is installed on the patient terminal 10. The patient can select a self-care app according to the disease they suffer from and install the selected self-care app on their own device. The items to be entered in the self-care app may be set according to the disease.

[0036] The computer programs stored in the storage unit 12 are provided by a non-transitory recording medium on which the computer programs are readably recorded. The recording medium is a portable memory such as a CD-ROM, a USB memory, or an SD card. The control unit 11 reads the various computer programs from the recording medium using a reading device (not shown) and installs the read various computer programs in the storage unit 12. Alternatively, the computer programs stored in the storage unit 12 may be provided by communication. In this case, the control unit 11 obtains the various computer programs through the communication unit 13 and installs the obtained various computer programs in the storage unit 12.

[0037] The communication unit 13 includes a communication interface for transmitting and receiving various data to and from an external device. The communication interface of the communication unit 13 may be a communication interface conforming to a communication standard such as Wi-Fi (registered trademark), LAN (Local Area Network), Bluetooth (registered trademark), ZigBee (registered trademark), 3G, 4G, 5G, or LTE (Long Term Evolution). When data to be transmitted is input from the control unit 11, the communication unit 13 transmits the data to the destination external device, and when data transmitted from the external device is received, the communication unit 13 outputs the received data to the control unit 11. In this embodiment, the external device is the management server 30, the authentication server 40, or the like.

[0038] The connection unit 14 includes a connection interface for connecting various sensors or measuring devices. The connection interface of the connection unit 14 may be a wired connection interface such as USB (Universal Serial Bus) or a wireless connection interface such as Bluetooth (registered trademark). For example, a body composition analyzer IB having a function for measuring bioimpedance is connected to the connection unit 14. The control unit 11 acquires measurement data of the bioimpedance measured for the patient from the body composition analyzer IB connected to the connection unit 14 via a wired or wireless connection and stores the acquired measurement data in the memory unit 12. The connection unit 14 may be connected to not only the body composition analyzer IB but also sensors or measuring devices for acquiring vital information such as the patient's weight, blood pressure, body temperature, pulse rate, and respiratory rate. The control unit 11 acquires the vital information obtained by these sensors or measuring devices via the connection unit 14. The sensor may be a wearable sensor for continuously acquiring vital information.

[0039] The image capturing unit 15 includes an image capturing element such as a CMOS (Complementary Metal Oxide Semiconductor) or a CCD (Charge-Coupled Device), and generates digital video data based on the output of the image capturing element when capturing an image of an object. The control unit 11 acquires the video data generated by the image capturing unit 15 and stores the acquired video data in the storage unit 12.

[0040] The voice input unit 16 includes an input device such as a microphone, and generates digital voice data by converting an analog voice signal input through the input device into a digital format. The control unit 11 acquires the voice data generated by the voice input unit 16 and stores the acquired voice data in the storage unit 12.

[0041] The reading unit 17 has a communication interface for short-range wireless communication such as NFC (Near Field Communication). The reading unit 17 performs short-range wireless communication with the personal number card NC brought close by the patient, thereby reading information recorded on the personal number card NC.

[0042] The operation unit 18 is equipped with operation devices such as a touch panel, a keyboard, and switches, and receives various operations and inputs from the patient. The control unit 11 performs appropriate control based on various operation information provided by the operation unit 18, and stores the input information in the storage unit 12 as necessary.

[0043] The display unit 19 includes a display device such as a liquid crystal display or an organic EL (Electro-Luminescence) display, and displays information to be presented to the patient in response to instructions from the control unit 11 .

[0044] In this embodiment, the patient terminal 10 is configured to be equipped with a reading unit 17, but it may also be configured to connect an IC card reader / writer to the patient terminal 10 and read the information recorded on the personal identification number card NC through the IC card reader / writer.

[0045] 3 is a block diagram showing the internal configuration of the doctor terminal 20. The doctor terminal 20 is a computer such as a personal computer or a tablet terminal, and includes a control unit 21, a storage unit 22, a communication unit 23, an operation unit 24, and a display unit 25.

[0046] The control unit 21 includes, for example, a CPU, a ROM, and a RAM. The ROM included in the control unit 21 stores a control program that controls the operation of each hardware component included in the doctor terminal 20. The CPU in the control unit 21 reads and executes the control program stored in the ROM and a computer program (described below) stored in the memory unit 22, and controls the operation of each hardware component, thereby causing the entire device to function as the doctor terminal 20 of the present disclosure. The RAM included in the control unit 21 temporarily stores data used during calculation and control.

[0047] The storage unit 22 includes storage such as a hard disk, a flash memory, etc. The storage unit 22 stores various computer programs executed by the control unit 21 and various data used by the control unit 21.

[0048] The communication unit 23 has a communication interface for transmitting and receiving various data to and from an external device. The communication interface of the communication unit 23 can be the same as the communication interface of the patient terminal 10. When data to be transmitted is input from the control unit 21, the communication unit 23 transmits the data to the destination external device, and when data transmitted from the external device is received, the communication unit 23 outputs the received data to the control unit 21.

[0049] The operation unit 24 includes operation devices such as a touch panel, a keyboard, and switches, and receives various operations and inputs from the doctor. The control unit 21 performs appropriate control based on various pieces of operation information provided by the operation unit 24, and stores the input information in the storage unit 22 as necessary.

[0050] The display unit 25 includes a display device such as a liquid crystal display or an organic EL display, and displays information to be presented to the doctor in response to instructions from the control unit 21 .

[0051] 4 is a block diagram showing the internal configuration of the management server 30. The management server 30 is a server computer, and includes a control unit 31, a storage unit 32, a communication unit 33, an operation unit , and a display unit .

[0052] The control unit 31 includes, for example, a CPU, a ROM, and a RAM. The ROM included in the control unit 31 stores a control program that controls the operation of each hardware unit included in the management server 30. The CPU in the control unit 31 reads and executes the control program stored in the ROM and a computer program (described below) stored in the storage unit 32, and controls the operation of each hardware unit, thereby causing the entire device to function as the management server 30 (information processing device) of the present disclosure. The RAM included in the control unit 31 temporarily stores data used during calculation and control.

[0053] The control unit 31 is not limited to the above configuration, and may be one or more processing circuits or arithmetic circuits including a GPU (Graphics Processing Unit), an FPGA (Field Programmable Gate Array), a DSP (Digital Signal Processor), a quantum processor, volatile or non-volatile memory, etc. The control unit 31 may also have functions such as a clock that outputs date and time information, a timer that measures the elapsed time from when an instruction to start measurement is given until when an instruction to end measurement is given, and a counter that counts numbers.

[0054] The storage unit 32 includes storage such as a hard disk, a flash memory, etc. The storage unit 32 stores various computer programs executed by the control unit 31 and various data used by the control unit 31.

[0055] The computer programs (program products) stored in the storage unit 32 include a medication suggestion program PG31. This medication suggestion program PG31 is a computer program for causing a computer to execute a process of evaluating the body fluid retention state of a patient with heart failure or renal dysfunction, determining whether or not to recommend taking a diuretic based on the evaluation result, and notifying the patient terminal 10 of a suggestion regarding taking a diuretic based on the determination result.

[0056] The computer programs stored in the storage unit 32 are provided by a non-transitory recording medium RM on which the computer programs are readably recorded. The recording medium RM is a portable memory such as a CD-ROM, a USB memory, or an SD card. The control unit 31 reads the various computer programs from the recording medium RM using a reading device (not shown) and installs the read various computer programs in the storage unit 32. Alternatively, the computer programs stored in the storage unit 32 may be provided by communication. In this case, the control unit 31 acquires the various computer programs via the communication unit 33 and installs the acquired various computer programs in the storage unit 32.

[0057] The medication suggestion program PG31 may be a single computer program or a group of programs consisting of multiple computer programs. Furthermore, the medication suggestion program PG31 may be executed by a single computer or by multiple computers working together. For example, the medication suggestion program PG31 may execute processing in cooperation with a terminal-side application program, such as a heart failure self-care application PG11 installed on the patient terminal 10. Furthermore, the medication suggestion program PG31 may partially use an existing library.

[0058] The storage unit 32 may include a patient information database DB31. FIG. 5 is a conceptual diagram showing an example of the patient information database DB31. The patient information database DB31 stores patient information, including the patient's name, age, contact information (email address, address, etc.), disease name, and patient's vital signs (bioimpedance, weight, blood pressure, body temperature, pulse rate, respiratory rate, etc.), in association with the patient's management ID. The patient information stored in the patient information database DB31 may include video data obtained by capturing an image of the patient, voice data of the patient, and answer data to questions posed to the patient. The video data, voice data, and answer data are stored in the storage unit 32 as files in an appropriate format, and the storage location of each file is registered in the patient information database DB31. The patient information database DB31 may store not only the most recent measurement values ​​and data, but also past measurement values ​​and data as history.

[0059] The communication unit 33 includes a communication interface for transmitting and receiving various data to and from an external device. The communication interface of the communication unit 33 may be a communication interface conforming to a communication standard such as Wi-Fi (registered trademark), LAN, Bluetooth (registered trademark), ZigBee (registered trademark), 3G, 4G, 5G, or LTE. When data to be transmitted is input from the control unit 31, the communication unit 33 transmits the data to the destination external device. When data transmitted from the external device is received, the communication unit 33 outputs the received data to the control unit 31. In this embodiment, examples of external devices are the patient terminal 10 and the doctor terminal 20.

[0060] The operation unit 34 includes operation devices such as a touch panel, a keyboard, and switches, and receives various operations and inputs from an administrator, etc. The control unit 31 performs appropriate control based on various pieces of operation information provided by the operation unit 34, and stores the input information in the storage unit 32 as necessary.

[0061] The display unit 35 includes a display device such as a liquid crystal display or an organic EL display, and displays information to be presented to the administrator or the like in response to instructions from the control unit 31 .

[0062] In this embodiment, the management server 30 may be a single computer, or may be a computer system configured with multiple computers and peripheral devices, etc. Furthermore, the management server 30 may be a virtual machine whose entity is virtualized, or may be a cloud.

[0063] The operation of the information processing system according to the first embodiment will be described below. Fig. 6 is a flowchart illustrating the procedure of processing executed in the information processing system according to the first embodiment. When a predetermined operation for launching the heart failure self-care app PG11 is received on the operation unit 18 of the patient terminal 10, the control unit 11 reads the heart failure self-care app PG11 from the storage unit 12 and launches it (step S101). After the heart failure self-care app PG11 is launched, the control unit 11 instructs the patient to read their personal identification number card NC (step S102) and acquires digital signature certificate data from the personal identification number card NC brought close to the reading unit 17 (step S103). The digital signature certificate data includes the patient's personal information (the four basic pieces of information: name, date of birth, gender, and address), a public key, and the issue number of the digital certificate.

[0064] The control unit 11 transmits a request to the authentication server 40 via the communication unit 13 to confirm the validity of the electronic signature certificate (step S104). The control unit 11 includes the data of the electronic signature certificate acquired in step S103 in the confirmation request to the authentication server 40. The authentication server 40 is a known server that performs public personal authentication (JPKI: Japanese Public Key Infrastructure) using the personal identification number card NC. When the control unit 11 receives a confirmation request from the patient terminal 10, it verifies the electronic signature certificate according to a known verification procedure and confirms its validity (step S105).

[0065] The control unit 11 receives the verification result by the authentication server 40 via the communication unit 13 as a response to the confirmation request sent in step S104 (step S106). If the verification by the authentication server 40 determines that the signature electronic certificate is invalid (if personal authentication has failed), the control unit 11 terminates the processing according to this flowchart without performing the following processing. On the other hand, if the verification by the authentication server 40 determines that the signature electronic certificate is valid (if personal authentication has succeeded), the control unit 11 performs the following processing.

[0066] The control unit 11 establishes a connection with the management server 30 via the heart failure self-care application PG11, and transmits the patient's management ID and personal information contained in the data of the digital signature certificate to the management server 30 (step S107).

[0067] The control unit 31 of the management server 30 receives the management ID and personal information transmitted from the patient terminal 10 via the communication unit 33 (step S108). When the control unit 31 receives the personal information verified by the authentication server 40 along with the management ID, it permits access to the patient's own information registered in the patient information database DB31. The control unit 11 of the patient terminal 10 may read the patient's own information associated with the management ID from the patient information database DB31 via the communication network NW and display the read information so that it can be viewed on the heart failure self-care app PG11. Furthermore, when the control unit 11 of the patient terminal 10 receives new information to be registered in the patient information database DB31, it may transmit the received information to the management server 30 via the communication network NW and store it in the patient information database DB31.

[0068] In this embodiment, the personal identification number card NC is used for identity authentication, but the management server 30 may also be configured to authenticate the patient using a pre-set management ID and password. In this case, instead of the procedure of steps S102 to S107, the management ID and password entered into the patient terminal 10 may be sent to the management server 30, and the management server 30 may authenticate the patient based on the management ID and password sent from the patient terminal 10.

[0069] In response to the access from the patient terminal 10, the control unit 31 of the management server 30 requests the transmission of evaluation data (step S109). The evaluation data requested by the management server 30 is, for example, data of the patient's answers to questions inquiring about the patient's heart failure state. The management server 30 displays the questions for the patient on the display unit 19 of the patient terminal 10 and acquires the answer data entered using the operation unit 18 via the communication network NW.

[0070] 7 is a schematic diagram showing an example of a response input screen. The response input screen represents a screen displayed on the display unit 19 of the patient terminal 10 in response to an instruction from the management server 30. The response input screen may be generated by the heart failure self-care app PG11 installed on the patient terminal 10, or may be generated by the medication suggestion program PG31 of the management server 30. The response input screen includes questions inquiring about the patient's heart failure condition, such as "Do you get short of breath?", "If you have difficulty breathing, is it easier to sit down?", "Do you have trouble sleeping at night?", and "Do you have swelling?". The content of the questions is not limited to the above, and any questions that directly or indirectly inquire about the patient's heart failure condition may be used.

[0071] The patient answers the questions using the operation unit 18. The answer input screen in FIG. 7 has a slide bar for each question that can be slid left and right (in the direction of the arrow shown in the figure) using the operation unit 18 to accept answers to the questions. The patient self-evaluates their own heart failure condition on a scale of 1 to 10 by sliding the slide bar left and right using the operation unit 18. When the send button located in the lower right corner of the answer input screen is pressed using the operation unit 18, the patient's answer data is sent to the management server 30.

[0072] The evaluation data may be the patient's bioimpedance. When the management server 30 requests transmission of the bioimpedance as the evaluation data, the patient terminal 10 transmits the bioimpedance data measured by the body composition analyzer IB to the management server 30. The patient's bioimpedance may be measured in advance or may be measured at a timing after receiving a request from the management server 30.

[0073] The evaluation data may be video data obtained by imaging the patient. When the management server 30 requests transmission of video data as evaluation data, the patient terminal 10 transmits video data obtained by imaging the patient (particularly the patient's neck or feet) to the management server 30. The video data may be captured in advance by the imaging unit 15 of the patient terminal 10 or an external camera, or may be captured at a timing after a request from the management server 30.

[0074] The evaluation data may be voice data obtained by recording the voice of the patient. When the management server 30 requests transmission of voice data as evaluation data, the patient terminal 10 transmits the voice data obtained by recording the patient's voice to the management server 30. The voice data may be recorded in advance by the voice input unit 16 of the patient terminal 10 or an external microphone, or may be recorded at a timing after a request from the management server 30.

[0075] When the patient terminal 10 receives a transmission request for evaluation data transmitted from the management server 30, it transmits the evaluation data to the management server 30 (step S110). The evaluation data transmitted by the patient terminal 10 includes at least one of response data, bioelectrical impedance measurement data, video data, and audio data. In this embodiment, the patient terminal 10 transmits the evaluation data in response to a transmission request from the management server 30, but the patient terminal 10 may also transmit the evaluation data voluntarily.

[0076] The control unit 31 of the management server 30 receives the evaluation data transmitted from the patient terminal 10 via the communication unit 33 and evaluates the patient's body water retention status based on the received evaluation data (step S111). For example, when using the patient's response data as the evaluation data, the control unit 31 scores the patient's responses to each question on a 10-point scale and evaluates the body water retention status based on the total score. For example, if the total score is TH1 or greater, the control unit 31 evaluates the patient's body water retention as excessive, and if the total score is less than TH1, the control unit 31 evaluates the patient's body water retention as normal. Here, TH1 is a threshold value that is appropriately set depending on the number and content of questions. In this embodiment, it is sufficient to be able to distinguish between a state in which the patient's body water retention is excessive and a state in which it is not excessive; therefore, a state in which it is not excessive (including a state in which the body water retention is low) may be evaluated as normal.

[0077] When bioimpedance is used as the evaluation data, the control unit 31 evaluates the state of body water retention based on the level of the bioimpedance. For example, if the value of the bioimpedance is equal to or less than TH2, the control unit 31 evaluates that the patient's body water retention is excessive, and if the value of the bioimpedance is greater than TH2, the control unit 31 evaluates that the patient's body water retention is normal. Here, TH2 is a threshold value that is appropriately set for the value of the bioimpedance.

[0078] When using patient video data as evaluation data, the control unit 31 evaluates the patient's state of body fluid retention by detecting jugular vein distension from the video data. Jugular vein distension refers to a state in which blood vessels in the neck are dilated and visible from the surface of the skin. If the control unit 31 detects jugular vein distension from video data captured when the patient is in a higher position than sitting, it evaluates the patient's body fluid retention as excessive. If the control unit 31 does not detect jugular vein distension, it evaluates the patient's body fluid retention as normal. Any method for detecting specific structures from video data can be used as the detection method. For example, when the control unit 31 inputs video data using a large number of video data showing jugular vein distension as correct answer data, it may prepare in advance a learning model trained to recognize jugular vein distension contained in the video data, and detect jugular vein distension by inputting video data acquired from the patient terminal 10 into the trained learning model.

[0079] Alternatively, the control unit 31 may evaluate the patient's state of body fluid retention by detecting the degree of edema from video data. For example, the video data may be obtained by pressing a subcutaneous area of ​​a bone, such as the tibia, with a finger and capturing an image of the skin condition after releasing the pressure. If the control unit 31 confirms, based on the video data, an indentation that lasts for a predetermined time (e.g., 15 seconds) or more after releasing the pressure, it determines that the degree of edema is high and evaluates that the patient's body fluid retention is excessive. On the other hand, if the control unit 31 cannot confirm an indentation based on the video data or confirms that the indentation disappears within a predetermined time (e.g., 15 seconds), it determines that edema is not present or that the degree of edema is low, and evaluates that the patient's state of body fluid retention is normal. Similarly, the control unit 31 may detect edema by preparing a learning model trained to recognize the degree of edema contained in video data in advance and inputting video data acquired from the patient terminal 10 into the trained learning model.

[0080] When using the patient's voice data as the evaluation data, the control unit 31 evaluates the patient's body water retention state by detecting hoarseness and other characteristics associated with blood stagnation (congestion) from the voice data. An example of an evaluation method is the method disclosed in "Vocal Biomarker Is Associated With Hospitalization and Mortality Among Heart Failure Patients," Elad Maor et. al., Journal of the American Heart Association, Volume 9, Issue 7, April 9, 2020. If the feature extracted from the patient's voice data is equal to or greater than TH3 (or equal to or less than TH3), the control unit 31 evaluates the patient's body water retention as excessive. If the feature is less than TH3 (or greater than TH3), the control unit 31 evaluates the patient's body water retention as normal. Here, TH3 is a threshold value appropriately set for the feature value of the voice data. Multiple feature values ​​may be extracted from the voice data. In this case, a threshold value is set for each feature value, and the body water retention state is evaluated based on the magnitude relationship between each feature value and each threshold value.

[0081] In this embodiment, the system is configured to distinguish between two states, an excessive state and a normal state, in order to evaluate the patient's body water retention status, but multiple thresholds may be set to distinguish between three or more states depending on the amount of body water retention. The thresholds for evaluating body water retention may be set for each patient.

[0082] In this embodiment, the patient's water retention status is evaluated using each evaluation data. However, multiple evaluation data may be combined to calculate an index related to the water retention status, and the patient's water retention status may be evaluated based on the calculated index. For example, assuming that N1 is a score determined based on response data, N2 is a score determined based on bioimpedance, N3 is a score determined based on video data, and N4 is a score determined based on audio data, the control unit 31 calculates the index as f(N1, N2, N3, N4), where f is an appropriate function set in advance. The control unit 31 compares the calculated index with a threshold value. If the index is equal to or greater than the threshold value (or equal to or less than the threshold value), the control unit 31 evaluates the patient's water retention as normal. If the index is less than the threshold value (or greater than the threshold value), the control unit 31 evaluates the patient's water retention as excessive. The calculation method for the scores N1 to N4 is set appropriately depending on each evaluation data. Furthermore, multiple threshold values ​​for the index may be set, or may be set for each patient.

[0083] After evaluating the patient's body water retention state in step S111, the control unit 31 determines whether to recommend taking a diuretic based on the evaluation result (step S112). If the control unit 31 evaluates in step S111 that the patient's body water retention is excessive, it determines to recommend taking a diuretic, and if the control unit 31 evaluates that the patient's body water retention is normal, it determines not to recommend taking a diuretic. It is assumed that the type of diuretic to be taken by the patient is predetermined by a doctor's prescription.

[0084] The control unit 31 may store the evaluation result of step S111 as a history in the storage unit 32 (patient information database DB31) and determine whether to recommend taking a diuretic depending on changes in the evaluation result. For example, the control unit 31 may determine to recommend taking a diuretic when it determines that the body water retention has changed from a normal state to an excessive state. The control unit 31 may also determine not to recommend taking a diuretic when it determines that the body water retention has changed from an excessive state to a normal state and that the normal state has continued multiple times.

[0085] The control unit 31 notifies the patient terminal 10 of a suggestion regarding the administration of a diuretic in accordance with the determination result of step S112 (step S113). That is, if the control unit 31 determines in step S112 that the administration of a diuretic is recommended, the control unit 31 notifies the patient terminal 10 of a message suggesting that the patient take the diuretic prescribed to the patient. To generate specific suggestion content (the type and dosage of the diuretic to be taken), the control unit 31 may acquire a user authentication electronic certificate from the patient terminal 10, access the information providing server 50 using the acquired user authentication electronic certificate, and acquire prescription information for the patient from the information providing server 50. The control unit 31 acquires prescription information for the patient (information on the type and dosage of the diuretic prescribed to the patient) from the information providing server 50, and generates suggestion content for the patient based on the acquired prescription information. Specifically, the control unit 31 generates suggestion content by preparing a template and embedding the name and dosage of the diuretic obtained from the prescription information into the template.

[0086] If prescription information is recorded in the patient terminal 10, the control unit 31 may acquire the prescription information from the patient terminal 10. In this case, the control unit 31 requests the prescription information from the patient terminal 10 and receives the prescription information transmitted from the patient terminal 10 via the communication unit 33.

[0087] The control unit 31 may use a large-scale language model instead of using a fixed phrase. The control unit 31 generates a prompt including an instruction to the large-scale language model to make a medication suggestion to the heart failure patient and including prescription information as reference information, and transmits the generated prompt to the large-scale language model to obtain a sentence including the suggestion to the patient. The large-scale language model may be a general-purpose model or may be fine-tuned for the patient.

[0088] In addition, the control unit 31 may set multiple thresholds for the amount of body water retention and vary the content of the medication suggestion (type and dosage of diuretic to be taken) depending on the amount of body water retention.

[0089] If it is determined in step S112 that taking a diuretic is not recommended, the control unit 31 may notify the patient terminal 10 of a message suggesting not to take a diuretic, or may end the processing according to this flowchart without notifying the patient of the dosage suggestion. The control unit 31 may also store the date and time when the dosage suggestion was made in the storage unit 32, and end the processing according to this flowchart without notifying the patient of the dosage suggestion if a certain period of time (e.g., 24 hours) has not elapsed since the previous dosage suggestion.

[0090] In addition, after determining whether or not to recommend taking a diuretic in step S111, the patient terminal 10 is notified of the dosage suggestion. However, the control unit 31 may be configured to send the suggestion to the doctor terminal 20 before notifying the patient terminal 10, and notify the patient terminal 10 only if the doctor approves the suggestion. In this case, the control unit 31 sends the suggestion to the doctor terminal 20 as preprocessing for step S113. The doctor terminal 20 displays the suggestion from the management server 30 on the display unit 25 and accepts the doctor's approval. If the doctor's approval is accepted, the doctor terminal 20 sends a notification to the management server 30 that the suggestion is approved. If the control unit 31 of the management server 30 receives the notification that the suggestion is approved, it notifies the patient terminal 10 of the suggestion.

[0091] When the control unit 11 of the patient terminal 10 receives a notification from the management server 30 via the communication unit 13, it displays a message regarding a diuretic dosage suggestion on the display unit 19 (step S114). Fig. 8 is a schematic diagram showing an example of a dosage suggestion display. The example of Fig. 8 shows an example in which the message "Please take one furosemide tablet prescribed by XX Hospital" is displayed on the display unit 19 of the patient terminal 10 as a diuretic dosage suggestion.

[0092] As described above, in the first embodiment, the patient's state of body water retention is evaluated, and based on the evaluation result, it is determined whether or not to recommend taking a diuretic. Taking a diuretic can be suggested depending on the determination result. Even if the patient has no subjective symptoms, if an excessive body water retention state is detected, taking a diuretic (as-needed dose) can be suggested, so the patient can take the diuretic at an appropriate time.

[0093] In the first embodiment, the management server 30 is configured to notify the patient terminal 10 of a suggestion to take a diuretic, but an action suggestion other than taking a medication may also be notified to the patient terminal 10. For example, the management server 30 may notify the patient terminal 10 of an action suggestion related to limiting intake of at least one of fluids and salt, together with (or instead of) the suggestion to take a diuretic. Furthermore, the management server 30 may notify the patient terminal 10 of an action suggestion for the patient to contact a medical institution, visit a medical institution, or contact an emergency department, together with (or instead of) the suggestion to take a diuretic.

[0094] In embodiment 1, when the patient terminal 10 accesses the management server 30, the management server 30 requests the patient terminal 10 to send evaluation data. However, the management server 30 may also be configured to request the patient terminal 10 to send evaluation data periodically (for example, once a day).

[0095] (Actual Embodiment 2) In the second embodiment, a specific processing procedure will be described when the management server 30 acquires prescription information. The overall configuration of the system and the internal configuration of each device are the same as those in the first embodiment, and therefore the description thereof will be omitted.

[0096] 9 is a flowchart illustrating the processing steps executed in the information processing system according to the second embodiment. Following the same procedure as in the first embodiment, the control unit 31 of the management server 30 evaluates the patient's state of body fluid retention based on the evaluation data transmitted from the patient terminal 10 in response to the request to transmit evaluation data, and determines whether or not to recommend the administration of a diuretic (steps S109 to S112). The steps S109 to S112 are the same as those in the first embodiment. Prior to the steps S109 to S112, the heart failure self-care application PG11 is launched on the patient terminal 10, and identity authentication is performed via the authentication server 40.

[0097] The control unit 31 requests access information to the information providing server 50 from the patient terminal 10 (step S201). The access information to the information providing server 50 is information necessary for accessing the information providing server 50 from outside. The control unit 31 may request the patient terminal 10 for the necessary access information depending on the access restriction implemented by the information providing server 50. For example, if the information providing server 50 implements access restriction using a user authentication electronic certificate, the control unit 31 may request the user authentication electronic certificate from the patient terminal 10 as access information. Furthermore, if the information providing server 50 implements access restriction using a patient ID and password, the control unit 31 may request the patient terminal 10 for the patient ID and password as access information.

[0098] The control unit 11 of the patient terminal 10 transmits the access information requested by the management server 30 to the management server 30 (step S202). For example, if the access information requested by the management server 30 is a usage authentication electronic certificate, the control unit 11 reads the user authentication electronic certificate from the IC chip of the personal identification number card NC via the reading unit 17 and transmits the read user authentication electronic certificate to the management server 30. If the access information requested by the management server 30 is a patient ID and password, the control unit 11 may display an input screen for the patient ID and password on the display unit 19 and transmit the patient ID and password entered on the input screen to the management server 30.

[0099] When the control unit 31 of the management server 30 receives the access information transmitted from the patient terminal 10, it accesses the information providing server 50 using the received access information and requests the patient's prescription information from the information providing server 50 (step S203).

[0100] The information providing server 50 determines whether to permit access based on the access information from the management server 30, and if it determines to permit access, transmits the patient's prescription information requested by the management server 30 to the management server 30 (step S204). The patient's prescription information includes information on the type and dosage of the diuretic prescribed for the patient.

[0101] The control unit 31 of the management server 30 receives the patient's prescription information transmitted from the information providing server 50 and generates a suggestion for the patient based on the received prescription information. For example, the control unit 31 can generate the suggestion by embedding the name and dosage of the diuretic extracted from the prescription information into a pre-prepared template. Alternatively, the control unit 31 may generate the suggestion using a large-scale language model. For example, the control unit 31 may generate a prompt including an instruction to suggest a medication to the heart failure patient and the prescription information as reference information, and transmit the generated prompt to the large-scale language model to obtain a text including the suggestion for the patient. The control unit 31 notifies the patient terminal 10 of the generated diuretic medication suggestion (step S113).

[0102] When the control unit 11 of the patient terminal 10 receives the notification from the management server 30 via the communication unit 13, the control unit 11 displays the text regarding the suggestion to take a diuretic on the display unit 19 (step S114). The display example is the same as that in the first embodiment.

[0103] As described above, the management server 30 according to the second embodiment can access the information providing server 50 and notify the patient of a suggestion to take a diuretic based on the patient's prescription information obtained from the information providing server 50.

[0104] (Embodiment 3) In embodiment 3, a specific processing procedure will be described when the management server 30 acquires prescription information through the patient terminal 10. The overall configuration of the system and the internal structure of each device are the same as those in embodiment 1, and therefore a description thereof will be omitted.

[0105] 10 is a flowchart illustrating the processing steps executed in the information processing system according to the third embodiment. Following the same procedure as in the first embodiment, the control unit 31 of the management server 30 evaluates the patient's body water retention state based on the evaluation data transmitted from the patient terminal 10 in response to the request to transmit evaluation data, and determines whether or not to recommend the administration of a diuretic (steps S109 to S112). The steps S109 to S112 are the same as those in the first embodiment. Prior to the steps S109 to S112, the heart failure self-care application PG11 is launched on the patient terminal 10, and identity authentication is performed via the authentication server 40.

[0106] The control unit 31 requests the patient terminal 10 to access the information providing server 50 (step S301). For example, the control unit 31 may display an access URL or the like to the information providing server 50 on the display unit 19 of the patient terminal 10 and request access to the information providing server 50.

[0107] In response to the access request from the management server 30, the patient terminal 10 requests prescription information from the information providing server 50 (step S302). When requesting prescription information, the patient terminal 10 transmits access information, such as a user authentication electronic certificate, a patient ID, and a password, to the information providing server 50 and accesses the information providing server 50.

[0108] In response to the request from the patient terminal 10, the information providing server 50 transmits the patient's prescription information to the patient terminal 10 (step S303).

[0109] The patient terminal 10 transmits the patient's prescription information received from the information providing server 50 to the management server 30 (step S304).

[0110] The control unit 31 of the management server 30 receives the patient's prescription information transmitted from the information providing server 50 and generates a suggestion for the patient based on the received prescription information. For example, the control unit 31 can generate the suggestion by embedding the name and dosage of the diuretic extracted from the prescription information into a pre-prepared template. Alternatively, the control unit 31 may generate the suggestion using a large-scale language model. For example, the control unit 31 may generate a prompt including an instruction to suggest a medication to the heart failure patient and the prescription information as reference information, and transmit the generated prompt to the large-scale language model to obtain a text including the suggestion for the patient. The control unit 31 notifies the patient terminal 10 of the generated diuretic medication suggestion (step S113).

[0111] When the control unit 11 of the patient terminal 10 receives the notification from the management server 30 via the communication unit 13, the control unit 11 displays the text regarding the suggestion to take a diuretic on the display unit 19 (step S114). The display example is the same as that in the first embodiment.

[0112] As described above, the management server 30 according to the third embodiment can acquire prescription information through the patient terminal 10 used by the patient himself / herself, and notify the patient terminal 10 of a suggestion to take a diuretic.

[0113] (Embodiment 4) In embodiment 4, a configuration will be described in which information from patients who have taken diuretics is managed in a management server 30. The overall configuration of the system and the internal configuration of each device are the same as in embodiment 1, and therefore a description thereof will be omitted.

[0114] Fig. 11 is a schematic diagram showing an example of a medication status confirmation screen. After proposing to the patient that they take a diuretic, the management server 30 displays a medication status confirmation screen such as that shown in Fig. 11 on the display unit 19 of the patient terminal 10 in order to check the patient's status when a set time (e.g., several hours) has elapsed since the suggestion. The medication status confirmation screen shown as an example in Fig. 11 is a screen that asks the patient whether they took the diuretic as prescribed, the amount of urine produced after taking the diuretic, whether they had any side effects after taking the diuretic, and the symptoms of any side effects.

[0115] The patient responds to the inquiry by operating the operation unit 18 of the patient terminal 10. When the send button located in the lower right corner of the medication status confirmation screen is pressed, the patient's response is sent to the management server 30.

[0116] 11, the patient is asked whether or not they have taken a diuretic, but the patient may also be asked to take a video of themselves taking a diuretic and send the video data. If a diuretic intake detection device is used to detect the taking of a diuretic (taking out a diuretic from a designated storage location), the management server 30 may obtain the detection results of the diuretic intake detection device instead of asking the patient a question.

[0117] The management server 30 may also display questions inquiring about the patient's physical condition, as well as whether or not the patient has taken medication, the amount of urine, and whether or not there have been any side effects, on the medication status confirmation screen. Furthermore, the management server 30 may request the patient terminal 10 to transmit data such as the patient's response data to questions about the state of body fluid retention, bioelectrical impedance measurement data, video data for observing the degree of jugular venous distension or edema, voice data of the patient, and vital information of the patient (weight, blood pressure, body temperature, pulse rate, respiratory rate, etc.). When transmission of the response data, bioelectrical impedance measurement data, video data, voice data, vital information, etc. is requested, the patient terminal 10 may collect this data and transmit it from the patient terminal 10 to the management server 30.

[0118] The management server 30 stores the medication history in the storage unit 12 based on the response from the patient terminal 10. Fig. 12 is a conceptual diagram showing an example of a medication history table. Based on the response from the patient terminal 10, the medication history table stores the suggested medication date and time, whether or not medication was taken, urine volume (high / low / none), whether or not side effects occurred, and symptoms if side effects were present, in association with the patient's management ID.

[0119] The management server 30 may manage at least one of the number of times a diuretic has been taken and the remaining amount of diuretic based on the information stored in the administration history table. The management server 30 may also refer to the information stored in the administration history table to change the content of the next administration suggestion. For example, if the management server 30 determines that the patient is taking a diuretic as prescribed but has little or no urine output, the management server 30 may notify the patient terminal 10 to increase the diuretic dosage. If a record of side effects is found, the management server 30 may notify the patient terminal 10 to visit or contact a hospital as soon as possible.

[0120] The management server 30 may also share the information stored in the medication history table with medical institutions. Specifically, the management server 30 may transmit the information stored in the medication history table to the doctor terminal 20. In addition to sharing information with medical institutions, the management server 30 may also share information with local governments, diuretic manufacturers, pharmacies, etc.

[0121] As described above, in the fourth embodiment, the patient's medication history is managed by the management server 30, making it possible to easily grasp the patient's condition. Furthermore, by sharing medication history information with medical institutions, doctors can evaluate the effects and side effects of diuretics.

[0122] Furthermore, if the number of times a diuretic is taken in a predetermined period exceeds a threshold, the control unit 301 may generate alert information such as "Caution is required as the number of times the drug is taken is increasing" and transmit the alert information to the doctor terminal 20. Patients who take the drug many times in a predetermined period may be experiencing a worsening condition of heart failure. This makes it easier for a doctor who receives the alert information to take appropriate measures according to the patient's condition, such as encouraging the patient to visit a doctor.

[0123] The control unit 301 may also calculate the number of remaining diuretics based on the number of diuretics and the number of times they are taken included in the prescription information, and when the number of remaining diuretics falls below a threshold, may notify the patient terminal 10 of an action suggestion to prompt the patient to receive the prescription from a medical institution or to get a diuretic at a pharmacy. This makes it possible to avoid a situation in which the patient's heart failure condition worsens because the patient does not have a diuretic on hand, even though it has been determined in step S112 that taking a diuretic is recommended.

[0124] Furthermore, when the number of remaining medications falls below the threshold, the control unit 301 may send a notification to the doctor terminal 20 or a pharmacy terminal (not shown) at the pharmacy informing the patient that the number of remaining medications is low. This allows the medical institution to encourage patients who need a new prescription for a diuretic to visit the doctor or the pharmacy to encourage them to pick up the diuretic.

[0125] The embodiments disclosed herein are illustrative in all respects and should not be considered limiting. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the meaning and scope of the claims.

[0126] REFERENCE SIGNS LIST 10 Patient terminal 11 Control unit 12 Memory unit 13 Communication unit 14 Connection unit 15 Imaging unit 16 Voice input unit 17 Reading unit 18 Operation unit 19 Display unit 20 Doctor terminal 30 Management server 31 Control unit 32 Memory unit 33 Communication unit 34 Operation unit 35 Display unit DB31 Patient information database PG11 Heart failure self-care application PG31 Medication suggestion program

Claims

1. A computer program for causing a computer to execute the following processes: assessing the fluid retention status of a patient with heart failure or renal dysfunction; determining whether or not to recommend the administration of a diuretic based on the assessment results; and notifying a terminal device of the patient of a suggestion regarding the administration of a diuretic based on the determination results.

2. The computer program according to claim 1, which causes the computer to execute the following process: sending questions regarding the patient's state of body hydration to the terminal device; receiving the patient's answers to the questions from the terminal device; and evaluating the patient's state of body hydration based on the received answers.

3. The computer program according to claim 1, which causes the computer to execute the process of receiving measurement data obtained by measuring the patient's bioelectrical impedance via the terminal device, and evaluating the patient's state of body water retention based on the received measurement data.

4. The computer program according to claim 1, which causes the computer to execute the process of: storing the results of the assessment of the state of body water retention in chronological order; and determining whether or not to recommend taking the diuretic depending on changes in the results of the assessment stored in chronological order.

5. The computer program according to claim 1, for causing the computer to execute the process of: acquiring prescription information for the patient; and generating a recommendation for the patient based on the acquired prescription information.

6. The computer program according to claim 1, for causing the computer to execute the process of acquiring personal authentication information of the patient, and acquiring prescription information for the patient from a server device accessible based on the personal authentication information.

7. The computer program according to claim 6, for causing the computer to execute a process of outputting a control command to the terminal device in order to acquire the prescription information from the server device.

8. The computer program according to claim 1, for causing the computer to execute the process of sending a suggestion regarding taking the diuretic to a doctor's terminal device, and notifying the patient's terminal device of the suggestion when a notification of approval of the suggestion is received from the doctor's terminal device.

9. The computer program according to claim 1, for causing the computer to execute a process of notifying the terminal device of the patient of suggested actions other than taking medication.

10. The computer program of claim 9, wherein the suggested actions include at least one of contacting a medical institution, visiting a medical institution, and contacting an emergency department.

11. The computer program according to claim 1, for causing the computer to execute the process of receiving, from the terminal device, information relating to the patient's condition after taking a diuretic, and storing the received information in association with the patient's identifier.

12. The computer program according to claim 1, for causing the computer to execute the process of receiving, from the terminal device, information on whether or not the diuretic has been taken, and storing the received information in association with the patient's identifier.

13. A computer program according to claim 12, for causing said computer to execute a process of managing at least one of the number of times said patient has taken said diuretic and the amount of said diuretic remaining based on said received information.

14. A computer program according to any one of claims 11 to 13, for causing the computer to execute a process of sharing the stored information about the patient with a set sharing destination.

15. An information processing device comprising at least one processing unit that evaluates the body fluid retention state of a patient with heart failure or renal dysfunction, determines whether or not to recommend the administration of a diuretic based on the evaluation results, and notifies a terminal device of the patient of a suggestion regarding the administration of a diuretic based on the determination results.

16. An information processing method in which a computer performs the following processes: assessing the body fluid retention state of a patient with heart failure or renal dysfunction; determining whether or not to recommend the administration of a diuretic based on the evaluation results; and notifying a terminal device of the patient of a suggestion regarding the administration of a diuretic based on the determination results.

Images