JP2025027521A - Information processing system, information processing method, and program - Google Patents

Abstract

To provide a technique that enables integration of patient data entered through a prescribed first application with patient data entered through a second application.SOLUTION: An information processing system comprising one or more processors is provided, the one or more processors being configured to integrate first patient data entered through a first application prescribed for the purpose of treating disease and installed on a terminal of a patient with second patient data entered through a second application different from the first application.SELECTED DRAWING: Figure 10

Description

This disclosure relates to an information processing system, an information processing method, and a program.

Medical institutions that provide health insurance have begun prescribing application programs aimed at treating nicotine addiction and high blood pressure (hereafter referred to as "therapeutic apps"). In addition, there are other therapeutic apps approved under the Pharmaceuticals and Medical Devices Act that aim to treat insomnia.
A patient who has received a prescription for a therapeutic app installs the therapeutic app on their own electronic device and inputs the patient's information (hereinafter also referred to as "patient data") until the next consultation with a doctor. The patient data is stored, for example, in a cloud server managed by the developer of the therapeutic app, and is also used for insurance treatment at insurance medical institutions.

Patent No. 6116769

Therapeutic apps approved under the Pharmaceuticals and Medical Devices Act are regulated by a set period during which they are covered by the medical insurance system (hereinafter referred to as the "insured medical treatment period"). In other words, the use of the therapeutic app is limited to the insured medical treatment period, and after the insured medical treatment period ends, it will no longer be possible to input patient data, etc.
However, treatment for chronic illnesses caused by lifestyle habits continues even after the insurance medical treatment period has ended. For this reason, support for inputting patient data is desired even after the insurance medical treatment period has ended. For example, the use of an application program (hereinafter referred to as a "recording app") separate from the treatment app is considered. In this case, it is desirable to manage the patient data of the treatment app and the patient data of the record app together. These circumstances are also the same for treatment apps with expiration dates that are prescribed in private medical treatment or mixed medical treatment.

One aspect of the present disclosure provides a technology that enables integration of patient data entered through a prescribed first app with patient data entered through a second app.

As another embodiment of the present disclosure, an information processing system is provided that has one or more processors, and the one or more processors integrate first patient data prescribed for the purpose of treating a disease and input through a first app installed on a patient's terminal, and second patient data input through a second app different from the first app.

As another aspect of the present disclosure, an information processing method is provided in which a computer executes a process to integrate first patient data prescribed for the purpose of treating a disease and input through a first app installed on a patient's terminal, and second patient data input through a second app different from the first app.

As one embodiment of the present disclosure, a program is provided for enabling a computer to realize a function of integrating first patient data prescribed for the purpose of treating a disease and input through a first app installed on a patient's terminal, and second patient data input through a second app different from the first app.

According to one embodiment of the present disclosure, a technology can be provided that enables integration of patient data entered through a prescribed first app with patient data entered through a second app.

FIG. 1 is a diagram illustrating an example of the configuration of an information processing system assumed in a first embodiment. FIG. 2 is a diagram illustrating an example of a hardware configuration of a server. 11 is a diagram illustrating an example of authentication data and patient data stored in an auxiliary storage device of the medical application operation server. FIG. 11 is a diagram illustrating an example of patient data stored in an auxiliary storage device of a record application operation server. FIG. FIG. 2 is a diagram illustrating an example of a hardware configuration of an information terminal. 13 is an example of a processing sequence illustrating a processing operation from prescribing a therapeutic application to registering patient data in a therapeutic application operation server. 13 is a diagram illustrating an example of a printed matter on which a prescription code is printed. FIG. FIG. 13 is a diagram illustrating an example of an operation screen of a treatment application. 13 is a diagram illustrating an example of a consultation screen displayed on the display of a doctor's terminal. FIG. 13 is an example of a processing sequence illustrating a patient data integration process in the first embodiment. 13 is a diagram illustrating an example of an operation screen of a recording application displayed on a patient terminal. FIG. 11 is a diagram illustrating an image of a process of combining patient data of a treatment application and patient data of a record application in the first embodiment. FIG. 13 is an example of a processing sequence illustrating a patient data integration process in the second embodiment. FIG. 13 is a diagram illustrating an image of a process of integrating patient data of a treatment application and patient data of a record application in the second embodiment. 13 is a diagram illustrating an example of a consultation screen displayed on the display of a doctor's terminal. FIG. 13 is a processing sequence illustrating another example of the patient data integration process in the second embodiment. 13 is an example of a processing sequence illustrating a patient data migration process in the third embodiment. 13 is a processing sequence illustrating another example of the patient data integration process in the third embodiment. 13 is a diagram illustrating another example of authentication data stored in the auxiliary storage device of the treatment application operation server. FIG.

Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.
<First embodiment>
In this embodiment, an application for assisting in the treatment of hypertension will be described as an example of a treatment application prescribed by a doctor.

<System Configuration>
FIG. 1 is a diagram illustrating an example of the configuration of an information processing system 1 according to the first embodiment.
The information processing system 1 shown in Figure 1 is composed of a treatment app operation server 10, a record app operation server 20, a doctor terminal 30 operated by a doctor who prescribes the treatment app, a patient terminal 40 operated by a patient receiving treatment for hypertension, and a network N connecting these terminals.
It is also anticipated that, to the extent permitted, the doctor terminal 30 will be operated by nurses, pharmacists, public health nurses, nutritionists, hospital staff, and other medical personnel.

The therapeutic application operation server 10 in this embodiment is a server that realizes distribution of the therapeutic application, authentication of the patient, storage of the patient data input through the therapeutic application, provision of the patient data to the health insurance medical institution (specifically, the doctor terminal 30), etc. However, the distribution of the therapeutic application may be performed by an entity different from the entity that operates the therapeutic application operation server 10 and the record application operation server 20.
As mentioned above, therapeutic apps are apps approved under the Pharmaceuticals and Medical Devices Act, and patients who use therapeutic apps can receive insured medical treatment from a doctor during the insured medical treatment period. In this case, insured medical treatment includes not only face-to-face consultations but also online consultations.
The treatment application in the present embodiment is an example of a first application, and the patient data input through the treatment application is an example of first patient data.

In this embodiment, the insured medical treatment period is set to six months. However, six months is just an example, and it may be nine months or twelve months. It may also be set in days, such as 60 days or 180 days, or it may be set in weeks, such as eight weeks later or 24 weeks later. Needless to say, these values are just examples.
In this embodiment, the patient is permitted to use the treatment app only during the insured medical treatment period. That is, the patient is allowed to input and record blood pressure values and the like through the treatment app. The insured medical treatment period here is an example of a validity period.

The starting date of the insured medical treatment period may be determined based on the consultation date when the treatment app was prescribed, the date when the treatment app was installed on the patient terminal 40, the date when use of the treatment app began, or the month when the treatment app was prescribed (hereinafter referred to as the "consultation month").
If the month of the medical examination is used as the starting month, the month following the month of the medical examination is considered to be month 1. This is because if the month of the medical examination is used as the 1st month, the insured medical treatment period for patients who receive medical examinations at the end of the month will be shortened by about one month.

The patient data includes the patient's attributes (gender, date of birth, height, weight), blood pressure, activity records, mood records, physical condition records, medical examination history, treatment app operation history, record app operation history, biological characteristics, psychological characteristics, social characteristics, habits, goal achievement status, etc. However, the patient data does not need to be all of this information and may be only a part of it.
The blood pressure value is, for example, a systolic blood pressure (i.e., a maximum blood pressure value) and a diastolic blood pressure (i.e., a minimum blood pressure value). The blood pressure value is an example of information related to blood pressure.
The activity record is, for example, a usage history of a medical application, a medication record, a food record, a smoking record, a drinking record, and an exercise record. The activity record is an example of information about an activity.

The record of taking medicine is, for example, the type and number of medicines taken, and the time when the medicine was taken. The record of taking medicine is an example of information regarding taking medicine.
The food record is, for example, the contents of the food eaten and the amount of salt ingested. The food record is an example of information related to food.
The smoking record is, for example, whether or not a person smoked, the date and time of smoking, and the number of cigarettes smoked. The smoking record is an example of information related to smoking.
The drinking record is, for example, the date and time of drinking, the amount of alcohol consumed, and the type of alcohol. The drinking record is an example of information related to drinking.

The exercise record includes, for example, records related to sports, as well as records of daily activities such as walking, shopping, cleaning, etc. The exercise record is an example of information related to exercise.
The mood record is, for example, a subjective mood. The mood record is an example of information related to mood.
The record of physical condition is, for example, a subjective physical condition or symptoms. The record of physical condition is an example of information related to physical condition.
The medical examination history is, for example, the treatment start date, the examination date, the details of the treatment, and advice. The medical examination history is an example of information related to medical examinations.

The operation history of the treatment application or the recording application is, for example, a history of operations related to start-up operations, input operations of blood pressure values, and reviews.
Biological characteristics include, for example, the presence or absence of other diseases, the presence or absence of injuries undergoing treatment, the presence or absence of knee or leg pain, the presence or absence of experience of treatment for hypertension, the number of years since hypertension was diagnosed, the strength of seasonings used in home cooking, and the amount of food eaten.
Psychological characteristics include, for example, expectations regarding app treatment, willingness to acquire knowledge about hypertension treatment, whether reducing salt intake is difficult or whether one cannot change one's sense of taste, and psychological resistance to leaving food on one's plate.

Social characteristics include, for example, wake-up time, bedtime, type of work (e.g., shift work, day shift, night shift), days of the week worked, start time of work, time home from work, regular days off, and whether or not there is a heater in the changing room.
Habits include, for example, exercise habits, the habit of weighing oneself, the habit of checking the calorie content of food labels, the habit of choosing low-fat foods, the habit of not consuming caffeine after 4 p.m., the habit of eating and drinking after 10 p.m., the habit of skipping breakfast, the habit of snacking, the habit of taking a bath one hour before going to bed, the habit of stretching or massaging before going to bed, and the habit of sleeping six hours or more.
The goal achievement status is, for example, the relationship between the patient's status and the goal set for each patient by a doctor or the like.
The above-mentioned information can be classified into subjective information and objective information.

The record application operation server 20 is a server that distributes record applications, authenticates patients, stores patient data input after the period of insured medical treatment has expired, and provides patient data to insured medical institutions.
The recording application in the present embodiment is different from the treatment application in that the recording application is an application that does not require approval under the Pharmaceutical and Medical Device Act. The recording application is an example of a second application. The patient data input through the recording application is an example of second patient data.

In the case of Figure 1, one therapy application operation server 10 and one record application operation server 20 are depicted, but multiple therapy application operation servers 10 may exist on the network N, and multiple record application operation servers 20 may exist on the network N.
In addition, the services provided by one treatment application operation server 10 may be realized by the cooperative operation of multiple servers, and the services provided by one record application operation server 20 may be realized by the cooperative operation of multiple servers.
In the present embodiment, the business entity that operates the treatment application operation server 10 is the same as the business entity that operates the record application operation server 20. However, the business entity that operates the treatment application operation server 10 and the business entity that operates the record application operation server 20 may be different.

The doctor terminal 30 refers to a terminal operated by a doctor at a health insurance medical institution, etc. A plurality of doctor terminals 30 are illustrated in FIG.
The patient terminal 40 refers to a terminal operated by a patient who is examined or treated for hypertension. A plurality of patient terminals 40 are illustrated in FIG.
For example, a desktop computer, a notebook computer, a tablet computer, or a smartphone is used as the doctor terminal 30 and the patient terminal 40. However, wearable computers such as smart glasses and a headset may also be used as the doctor terminal 30 and the patient terminal 40.
The doctor terminal 30 and the patient terminal 40 are examples of information terminals connected to the network N.

The network N is, for example, a LAN (Local area network), the Internet, or a mobile communication system (4G, 5G).
Figure 1 illustrates an example in which the treatment application operation server 10, the record application operation server 20, the doctor terminal 30, and the patient terminal 40 are connected to one network N, but they may also be connected via multiple networks N that are connected to each other.

<Server hardware configuration>
2 is a diagram illustrating an example of a hardware configuration of a server. The hardware configuration illustrated in FIG. 2 is common to the treatment application operation server 10 and the record application operation server 20.
Therefore, in the following, the therapeutic application operation server 10 will be described as a representative example of the server.

The treatment application operation server 10 shown in FIG. 2 has a processor 11, a ROM (Read Only Memory) 12 in which a BIOS (Basic Input Output System) and the like are stored, a RAM (Random Access Memory) 13 used as a work area for the processor 11, an auxiliary storage device 14, and a communication interface 15. Each device is connected via a bus and other signal lines 16.

The processor 11 is a device that realizes various functions through the execution of programs.
The processor 11, the ROM 12, and the RAM 13 function as a computer.
The auxiliary storage device 14 is configured by, for example, a hard disk device or a semiconductor storage device. In addition to the therapeutic app, the auxiliary storage device 14 stores data related to authentication of patients to whom the therapeutic app is prescribed and patient data registered through the therapeutic app.

In this embodiment, the treatment application, the recording application, and the OS (Operating System) are collectively referred to as a program.
The auxiliary storage device 14 of the treatment application operation server 10 is an example of a first area, and the auxiliary storage device 24 of the record application operation server 20 is an example of a second area.
The communication interface 15 is an interface for communicating with other servers and terminals via the network N. The communication interface 15 supports Ethernet (registered trademark), Wi-Fi (registered trademark), mobile communication systems, and other communication standards.

<Data managed by the server>
3 is a diagram for explaining an example of the authentication data 141 and the patient data 142 stored in the auxiliary storage device 14 (see FIG. 2) of the therapeutic application operation server 10. In the case of FIG. 3, only the information of "Tokyo Taro" is illustrated, but data of other patients is also recorded.
The authentication data 141 shown in FIG. 3 includes, for example, a patient ID, a user ID, a patient name, a prescription date, a medical institution ID, a doctor ID, a prescription code, and an insured medical treatment period (last month) of the medical treatment application.

The patient ID is an ID for identifying a patient that is notified by an insurance medical institution when a medical treatment application is prescribed.
The user ID is an ID used for managing the medical application operation server 10 and is used for authenticating the patient.
The patient name is recorded when the patient name is notified by the health insurance medical institution. In the case of Figure 3, the patient name is "Tokyo Taro."
The prescription date is the date on which the therapeutic app was prescribed. In the case of FIG. 3, the prescription date is July 31, 2023.

The medical institution ID is an ID that identifies the health insurance medical institution that prescribed the medical treatment app.
The doctor ID is an ID for identifying the doctor who prescribed the treatment application.
The prescription code is a code that is notified to the patient in order to activate the treatment app. The prescription code is generated for each prescription. The prescription code has a usage period, and the prescription code that has passed the usage period is invalidated. The usage period of the prescription code is, for example, three days after the prescription date.
The insured medical treatment period (last month) of the treatment app is information that gives the period during which the treatment app can be used. In the present embodiment, the insured medical treatment period is managed on a monthly basis. Therefore, the last month of the insured medical treatment period is recorded. In the case of FIG. 3, it is January 2024. The insured medical treatment period is recorded when the treatment app is activated.

The patient data 142 shown in Fig. 3 includes, for example, a patient ID, a user ID, a patient name, an input date and time, and a blood pressure value. As described above, the patient data 142 also includes information other than the blood pressure value, but this information is omitted in Fig. 3 due to space limitations.
The patient ID and user ID here are used to link with the authentication data 141.
The input date and time is the date and time when the patient inputs the blood pressure value, etc., into the activated treatment app. In the case of Fig. 3, the beginning of the input date and time is recorded as 6:35 on August 1, 2023, the day after the prescription date. In the case of Fig. 3, "145" is recorded as the systolic blood pressure value and "97" is recorded as the diastolic blood pressure value at the same time on the same day.
In addition, the patient data 142 shown in FIG. 3 also records input values on the evening of August 1, 2023 and input values on the following morning.

4 is a diagram for explaining an example of patient data 241 stored in the auxiliary storage device 24 (see FIG. 2) of the record application operation server 20. The patient data 241 is data input using the record application. In the case of FIG. 4, only the information of "Tokyo Taro" is illustrated, but the auxiliary storage device 24 also records data of other patients.
4 includes, for example, a patient ID, a user ID, a patient name, an input date and time, and a blood pressure value. As described above, the patient data 241 may include information other than the blood pressure value, but this information is omitted in FIG. 4 due to space limitations.

The patient ID is taken over from the treatment application, for example, when registering to start using the record application.
The user ID is an ID used for managing the record application operation server 20, and is used for authenticating the patient. In the present embodiment, the user ID in Fig. 4 is the same as the user ID in Fig. 3. However, the user ID in Fig. 4 may be different from the user ID in Fig. 3. In that case, by recording two types of user IDs, it is possible to link the patient data 142 inputted through the treatment application with the patient data 241 inputted through the record application.

The patient name is registered by the patient when starting to use the record application, or is inherited from the treatment application. In the case of FIG. 4, the patient name is "Tokyo Taro."
In the case of FIG. 4, the input date and time is 7:05 on Feb. 1, 2024, which is the date after the end of the insured medical treatment period.
In addition, the patient data 241 shown in FIG. 4 also records input values on the evening of Feb. 1, 2024 and input values on the following morning.

<Hardware configuration of information terminal>
5 is a diagram illustrating an example of a hardware configuration of an information terminal. The hardware configuration shown in FIG.
Therefore, in the following, the doctor terminal 30 will be described as a representative example of an information terminal.
5 includes a processor 31, a ROM 32 storing a BIOS and the like, a RAM 33 used as a work area for the processor 31, an auxiliary storage device 34, a communication interface 35, a display 36, and an input reception device 37. Each device is connected via a bus or other signal lines 38. The patient terminal 40 is also provided with a camera.

The communication interface 35 is an interface for communicating with other servers and terminals via the network N, and an interface for communicating with peripheral devices. The communication interface 35 is compatible with Ethernet (registered trademark), Wi-Fi (registered trademark), Bluetooth (registered trademark), USB (Universal Serial Bus), mobile communication systems, and other communication standards.

The display 36 is, for example, a liquid crystal display or an organic EL (Electro Luminescence) display.
The input reception device 37 is, for example, a mouse or a keyboard. In addition, when the doctor terminal 30 is a notebook computer, a tablet computer, or a smartphone, a capacitive touch sensor having transparency that does not interfere with the visibility of the image displayed on the display 36 is used as the input reception device 37. A device that combines this type of touch sensor with a display is called a touch panel.

<Processing operations during the insured medical treatment period of the treatment app>
Here, a series of processing operations starting with a prescription of a treatment application will be described.
6 is an example of a processing sequence illustrating a process from prescription of a therapeutic application to registration of patient data in the therapeutic application operation server 10. Note that the symbol S in the figure indicates a step, and the symbol t indicates time.
The processing sequence shown in FIG. 6 is made up of three stages.

The first stage is processing operations S101 to S105 (t11 to t14) related to notification of a prescription code of a medical treatment application.
The second stage is processing operations S111 to S124 (t21 to t28) related to installing the therapeutic application on the patient terminal 40 and linking the therapeutic application with information identifying the patient.
The third stage is processing operations S131 to S137 (t31 to t35) related to the registration of patient data in the medical application operation server 10 through the medical application.

<First stage>
First, the doctor operates the doctor terminal 30 to input the details of the examination of the hypertension patient (S101). The details of the examination are registered in the management system of the health insurance medical institution to which the doctor belongs.
In this embodiment, the doctor determines that a prescription for a therapeutic application is necessary for the patient. In this case, the doctor accesses a website for medical institutions published by the therapeutic application operation server 10 and requests a prescription code (S102). Incidentally, for example, a doctor ID and a login password are used to log in to the website. At this time, the patient identification information (for example, the patient's name, date of birth, etc.) may be attached, or the patient ID used in the hospital system may be attached.

The therapeutic application operation server 10 that has received the prescription code issues the prescription code (S103). In the present embodiment, the prescription code is issued for each request. The issued prescription code is associated with information (e.g., patient ID, user ID) that identifies the patient to whom the prescription code is to be issued, and is registered in the authentication data 141 (see FIG. 3).
The medical application operation server 10 then transmits the issued prescription code to the requesting doctor terminal 30 (S104). The received prescription code is printed on a sheet of paper and handed to the patient (S105). The doctor terminal 30 may also notify the patient terminal 40 by email.

Fig. 7 is a diagram for explaining an example of a printed matter 50 on which a prescription code is printed. On the printed matter 50 shown in Fig. 7, a title 51, a medical record number 52, an issue date 53, a patient's name 54, a patient's gender 55, information on the health insurance medical institution 56, a prescription code 57, a QR code (registered trademark) 58, and a note 59 are printed.
The expiration date is also printed on the prescription code 57. In the case of Fig. 7, the expiration date is 10:31 on Aug. 3, 2023, three days after the date of issue.
The QR code 58 has prescription code information embedded therein.

<Second stage>
For example, the patient accesses a website provided by a doctor and requests a therapeutic application (S111 in FIG. 6). In the present embodiment, the therapeutic application is distributed by the therapeutic application operation server 10. Therefore, in S111, the therapeutic application is requested from the therapeutic application operation server 10.
The therapeutic application operation server 10 that has received the request for the therapeutic application transmits the requested therapeutic application to the patient terminal 40 (S112).
In addition, if the treatment application has already been downloaded to the patient terminal 40, the processing operations of S111 and S112 are omitted.

The patient terminal 40 that has received the therapeutic application installs the therapeutic application, starts the installed prescription application, and receives the prescription code in this order in response to the patient's operation (S113). The therapeutic application cannot be used simply by being installed, and activation by inputting the prescription code is required.
The patient terminal 40 transmits the input prescription code to the medical application operation server 10 (S114).
The therapeutic application operation server 10 authenticates the patient by comparing the prescription code received from the patient terminal 40 with the prescription code in the authentication data 141 (see FIG. 3) (S115).

If these two prescription codes match, the therapeutic application operation server 10 determines that the authentication is successful. On the other hand, if these two prescription codes do not match, the therapeutic application operation server 10 determines that the authentication is unsuccessful.
In addition, even if the two prescription codes match, if the prescription code usage period has expired, the therapeutic application operation server 10 regards the authentication as a failure. As described above, in this embodiment, the usage period is three days after the prescription date.
In either case, the therapeutic application operation server 10 transmits the result of the authentication to the patient terminal 40 (S116).

If the authentication is successful, the authentication result includes a code that allows activation of the therapeutic app. In this case, activation of the therapeutic app is executed in the patient terminal 40 (S117). As a result, the therapeutic app can be used in the patient terminal 40. When the therapeutic app is in an activated state, the prescription code input in S113 is recorded in association with the therapeutic app. The prescription code is used, for example, when transferring patient data 142 (see FIG. 3) to the record app operation server 20 (see FIG. 1).
On the other hand, if the authentication fails, the authentication result does not include a code that authorizes activation of the therapeutic application, and in this case, an error screen is displayed on the display 46 of the patient terminal 40 (see FIG. 5).

When the therapeutic application is activated, it becomes possible to register patient information in the therapeutic application operation server 10 .
Specifically, the account ID and password used for logging in are transmitted from the patient terminal 40 to the therapeutic application operation server 10 (S118), and are registered in association with the prescription code, etc. (S119). For example, the account ID and password are added to the authentication data 141 (see FIG. 3).
When the registration of the account ID and password used for logging in is completed, the therapeutic application operation server 10 notifies the patient terminal 40 of the completion of the registration (S120).

After completing the registration of the account ID and password used for logging in, the patient inputs the patient name and other patient information into the patient terminal 40 (S121). When the input is confirmed, the input patient information is transmitted from the patient terminal 40 to the therapeutic application operation server 10 (S122).
The therapeutic application operation server 10 registers the received patient information in association with the prescription code and the like (S123), and notifies the patient terminal 40 of the completion of the registration (S124). The completion of the registration is displayed on the display 46 of the patient terminal 40 (see FIG. 5).

<Third stage>
Here, the input process of patient data using the treatment app after activation will be described.
First, the patient operates the patient terminal 40 to start the therapeutic application (S131). When the therapeutic application is started, the patient terminal 40 transmits an account ID and a password used for logging in to the therapeutic application operation server 10 (S132). The therapeutic application operation server 10 executes an authentication process using the received account ID and password (S133).
If the received account ID and password exist in the authentication data 141, the therapy application operation server 10 determines that the authentication is successful. On the other hand, if the received account ID and password do not exist in the authentication data 141, the therapy application operation server 10 determines that the authentication is unsuccessful.

The result of the authentication is transmitted from the therapeutic application operation server 10 to the patient terminal 40 (S134).
If the authentication is successful, it becomes possible to input data such as blood pressure values into the patient terminal 40. If the authentication is unsuccessful, the patient terminal 40 displays an error on the display 46.

8 is a diagram for explaining an example of an operation screen of a treatment application. In the case of Fig. 8, the patient terminal 40 is a smartphone. The operation screen displayed on the display 46 is a screen for manual input.
In the case of FIG. 8, the measurement date is August 1, 2023 (Tuesday), and the blood pressure input time is 8 p.m.
The systolic blood pressure was 135 mmHg, the diastolic blood pressure was 85 mmHg, and the pulse rate was 70 bpm.

Returning to the explanation of FIG.
When the patient inputs data such as blood pressure values (S135), the patient terminal 40 transmits the input patient data to the therapeutic application operation server 10 (S136).
The medical application operation server 10 registers the received data as the patient data 142 (see FIG. 3) (S137).
The input of data such as blood pressure values may be done manually by the patient, or may be done automatically by inputting blood pressure values measured by a peripheral device connected via Bluetooth, etc. The peripheral device here is a blood pressure monitor.
The patient data 142 registered in the therapeutic application operation server 10 can be downloaded and viewed from a doctor terminal 30 (see FIG. 1) operated by the doctor who prescribed the therapeutic application. For example, patient data that matches a patient ID and other information entered by the doctor is transmitted to the doctor terminal 30. As a result, the doctor can use information such as blood pressure values at home for examinations.

FIG. 9 is a diagram for explaining an example of a medical examination screen displayed on the display 36 of the doctor terminal 30. As shown in FIG.
The consultation screen shown in FIG. 9 is displayed based on the patient data 142 of “Tokyo Taro” (see FIG. 3) read out from the medical application operation server 10 .
The patient data column in the examination screen shown in FIG. 9 is composed of a display column 361 for displaying changes in average blood pressure, a display column 362 for displaying review information, a display column 363 for displaying records of activities, and an end button 364.

In the case of FIG. 9, the date displayed on the consultation screen is Jan. 21, 2024.
Therefore, the display field 361 displays the average blood pressure, average pulse, and blood pressure measurement rate calculated from patient data from 8 weeks to 4 weeks before the displayed date (from December 3 to December 23, 2023), and the average blood pressure, average pulse, and blood pressure measurement rate calculated from patient data from 4 weeks before the displayed date to the day before (from December 24, 2023 to January 20, 2024). In addition, the examination screen displays blood pressure values during the insured medical treatment period and blood pressure values after the insured medical treatment period as a continuous graph.

A record of mood and physical condition is displayed in a display field 362 shown in Fig. 9. A record of mood and physical condition is also called a diary.
9 displays, as activity records, the number of days the treatment app was used, the number of days a salt reduction in meals was recorded, the number of days a weight loss was recorded, etc. Of course, these are just examples.
When the end button 364 is operated, the examination screen is closed.

<Processing operations after the insurance medical treatment period of the treatment app>
Here, a series of processing operations executed after the end of the insured medical treatment period of the medical treatment application will be described. Specifically, the process of combining patient data during the insured medical treatment period with patient data after the insured medical treatment period will be described.
10 is an example of a processing sequence illustrating the integration process of patient data in the embodiment 1. Note that the symbol S shown in the figure represents a step, and the symbol t represents time.
The processing operation shown in FIG. 10 is an example of an information processing method, and assumes access from a medical treatment application to the medical treatment application operation server 10 after the end of the insured medical treatment period.

The processing sequence shown in FIG. 10 is made up of two stages.
The first stage is the processing operations S151 to S163 (t51 to t58) until the use of the treatment application becomes impossible.
The second stage is the processing operations S171 to S190 (t61 to t71) that are started by installing the recording application.

<First stage>
First, the patient operates the patient terminal 40 to start the therapeutic application (S151). When the therapeutic application is started, the patient terminal 40 transmits an account ID and a password used for logging in to the therapeutic application operation server 10 (S152). The therapeutic application operation server 10 executes an authentication process using the received account ID and password (S153).

If the received account ID and password exist in the authentication data 141, the therapeutic application operation server 10 determines that the authentication is successful, regardless of whether the current time is within the period of insurance coverage or not. Note that whether the current time is within the period of insurance coverage or not is determined separately from the authentication process.
On the other hand, if the received account ID and password do not exist in the authentication data 141, the therapeutic application operation server 10 determines that the authentication has failed.

The result of the authentication is transmitted from the treatment application operation server 10 to the patient terminal 40 (S154). This transmission also includes the result of the period check. As described above, in FIG. 10, it is assumed that the current time is after the end of the insured medical treatment period. Therefore, the end of the insured medical treatment period is displayed on the patient terminal 40 (S155). At that time, it is also displayed that the blood pressure value recording can be continued by installing an application other than the treatment application (i.e., a recording application).
If the patient wishes to continue recording the blood pressure values, a message indicating that a dedicated account for the recording application is required is displayed on the patient terminal 40. This message is displayed on the operation screen of the treatment application.

If the patient agrees to register a dedicated account for the record application, the patient terminal 40 transmits a dedicated account registration request to the therapeutic application operation server 10 (S156).
The treatment application operation server 10, which has received the request to register the account for the record application, registers the account (S157). For example, an account ID and a password for logging in are registered in association with the account. Completion of the registration is notified to the patient terminal 40 (S158).
Next, the patient terminal 40 requests to link the user ID to its own patient data 142 (see FIG. 3) (S159). The user ID is an ID for management purposes used to identify the patient who is logged in through the treatment app, and is included in the completion notification of S158.

When the request is received, the treatment application operation server 10 registers the user ID in the patient data 142 of the patient who has logged in through the treatment application (S160), and notifies the patient terminal 40 of the completion of the registration (S161). By linking the user ID to the patient data 142, the data can be transferred to the recording application.
After receiving the registration completion notification, the patient terminal 40 installs the recording application indicated in the completion notification on the patient terminal 40 (S162). The install button displayed on the patient terminal 40 has embedded therein the URL (=Uniform Resource Locator) of the server that distributes the recording application, and the patient's operation of the install button starts the download and installation of the recording application.
Thereafter, the patient terminal 40 controls the therapeutic application so as to make it unavailable (S163). Making the therapeutic application unavailable here means, for example, uninstalling the therapeutic application.

<Second stage>
First, the patient starts up the recording application installed on the patient terminal 40 (S171). This is the first start-up after installation.
When the recording application is started, a sign-in screen is displayed on the patient terminal 40 (S172).
When the patient instructs to sign in (i.e., requests to sign in) (S173), the patient terminal 40 transmits an account ID and password to be used for logging in to the therapeutic application operation server 10 (S174).
The therapeutic application operation server 10 executes an authentication process using the received account ID and password (S175).

If the received account ID and password exist in the authentication data 141, the therapeutic application operation server 10 determines that the authentication is successful. On the other hand, if the received account ID and password do not exist in the authentication data 141, the therapeutic application operation server 10 determines that the authentication is unsuccessful.
The result of the authentication is transmitted from the therapeutic application operation server 10 to the patient terminal 40 (S176).

If the authentication is successful, the patient terminal 40 displays a screen requesting consent to the transfer of patient data (S177). If the authentication is unsuccessful, the patient terminal 40 displays a message indicating that the authentication has failed.
When the patient agrees to the transfer of the patient data input through the therapeutic application, the patient terminal 40 requests the therapeutic application operation server 10 to transfer the patient data (S178).

In this embodiment, the request includes the prescription code and the user ID.
The prescription code and user ID may be read from the patient terminal 40 and transmitted by the recording application, or may be input by the patient.
The medical application operation server 10 identifies the handover data based on the prescription code and the user ID included in the received request (S179).

The risk of making a mistake in the patient data to be handed over is significantly reduced by combining the prescription code printed when the treatment app is prescribed with the user ID included in the authentication data 141 (see FIG. 3) used to authenticate the patient. The user ID is linked to the patient data 142 (see FIG. 3).

When the handover data is specified, the medical application operation server 10 transmits the handover data (i.e., the patient's own patient data during the period of insured medical treatment) to the patient terminal 40 that has requested the handover (S180).
The transfer data is transmitted as a copy. Therefore, at this point, the original transfer data is stored in the treatment application operation server 10. Therefore, even if an error occurs during the transfer data transmission, the original transfer data can be retransmitted.

The patient terminal 40 that has completed receiving the handover data transmits the handover data received from the treatment application operation server 10 to the record application operation server 20 (S181).
The record application operation server 20 writes the received handover data into a dedicated storage area (i.e., the second area) linked to the patient terminal 40 that is the sender of the handover data (S182).

The record application operation server 20 transmits the writing result to the patient terminal 40 (S183).
If the writing of the handover data is successful, the patient terminal 40 notifies the therapeutic application operation server 10 of the completion of the transfer (S184). That is, the writing of the handover data here is an example of the transfer of patient data.
If the writing of the handover data fails, the patient terminal 40 resends the handover data to the record application operation server 20. If the writing of the handover data to the record application operation server 20 fails a predetermined number of times in succession, the patient terminal 40 notifies the treatment application operation server 10 of the failure of the data transfer.

The treatment app operation server 10 that has received the migration completion notification executes migration completion processing (S185) and transmits the results of the processing to the patient terminal 40 (S186). In the migration completion processing, for example, the patient data for which the transfer has been completed may be deleted from the treatment app operation server 10, or the patient data for which the transfer has been completed may be transferred to an area dedicated to backup. In addition, the execution of the migration to the record app operation server 20 may be recorded as auxiliary information of the patient data, and the storage of the patient data may continue as is. Note that the processing from S178 to S186 is executed in the background on the patient terminal 40.

The patient terminal 40, which has received the notification that the transfer process of the handover data has been completed, displays the home screen of the recording application (S187). After this, it becomes possible to input blood pressure values and the like into the recording application.
When the patient inputs data such as blood pressure values (S188), the patient terminal 40 transmits the input patient data to the record application operation server 20 (S189).
The data input in S188 is an example of the first recording of patient data using the recording application, and is also an example of a case where a predetermined condition is satisfied.

In this case, the record application operation server 20 reads out the handover data (i.e., the patient data of the treatment application) stored in a dedicated storage area (i.e., the second area) linked to the patient terminal 40 that is the sender, and integrates the newly received data such as blood pressure values (S190). Specifically, the patient data of the record application is added to the patient data of the treatment application. That is, the record application operation server 20 has only one data file corresponding to a certain patient.
In addition, in the case of the second or subsequent sign-in, steps S177 to S186 are not executed, and steps S187 to S190 are executed. That is, the newly input patient data is added to the integrated patient data.

Fig. 11 is a diagram for explaining an example of an operation screen of a recording application displayed on the patient terminal 40. In Fig. 11, parts corresponding to those in Fig. 8 are denoted by the same reference numerals.
FIG. 11 shows two operation screens.
The operation screen located on the left side of Figure 11 is an example of a home screen of the recording app, and the display 46 displays a field 461 for inputting blood pressure values and displaying the input blood pressure values, and a field 462 for inputting review information.
The upper row of the blood pressure value display field 461 shows the morning blood pressure value, and the lower row shows the evening blood pressure value. In the case of Fig. 11, the morning blood pressure value shows an input value, but the evening blood pressure value is left blank.
Incidentally, the review information input field 462 is used to record mood and physical condition.

The operation screen on the right side of Fig. 11 is an example of an input screen of the recording application, and is displayed, for example, by tapping the blood pressure value display field 461 on the home screen. The measurement date on the input screen shown in Fig. 11 is Thursday, February 1, 2024, and the blood pressure input time is 20:12.
The blood pressure values and the like shown on the input screen in FIG. 11 are the values measured the first time, with the systolic blood pressure being 135 mmHg, the diastolic blood pressure being 85 mmHg, and the pulse rate being 70 bpm.
When the operation of button 463 is accepted on the operation screen located on the right side of Fig. 11, the recording application moves to an input screen for the second measurement value. On the other hand, when the operation of button 464 is accepted, the recording application closes the input screen and transmits the input blood pressure value, etc. as patient data to the recording application operation server 20 (see Fig. 10).

<Image of joining process>
FIG. 12 is a diagram illustrating an image of a process of combining patient data of a treatment application and patient data of a record application in the first embodiment.
The image shown in FIG. 12 represents two periods: the insured medical treatment period and the period after the end of the insured medical treatment period.
As described above, a treatment application is used to input blood pressure values and the like during the period of insured medical treatment.
Patient data such as blood pressure values input through the therapeutic application are stored in a dedicated memory area for each patient secured in the therapeutic application operation server 10 (see FIG. 1). In the case of FIG. 12, patient data for "Tokyo Taro" is managed by a file name such as "Tokyo Taro_Home Blood Pressure 1".

In the case of Fig. 12, the final month of the insured medical treatment period is January 2024. Therefore, January 31, 2024 will be the final day of the insured medical treatment period.
In the case of this embodiment, after the end of the insured medical treatment period, the treatment app will no longer be available, so the patient data of "Tokyo Taro" stored in the treatment app operation server 10 is transferred to the memory area of "Tokyo Taro" secured in the record app operation server 20.
In the example of Fig. 12, the transferred patient data is given a file name different from that before the transfer. In the case of Fig. 12, the file name is "Tokyo Taro_Home Blood Pressure 2".

The recording app is used to input blood pressure values after the end of the insured medical treatment period. In the case of Fig. 12, blood pressure values are input to the recording app on the day after the last day of the insured medical treatment period (i.e., February 1, 2024).
When the recording application receives input of blood pressure values, etc., the recording application transmits the input blood pressure values, etc. as patient data to the recording application operation server 20 (see S188 to S189 in FIG. 10). Meanwhile, the recording application operation server 20 combines the patient data received from the recording application with the patient data of the corresponding treatment application (S190 in FIG. 10).

In this embodiment, the patient data entered through the recording application is combined with a data file of the patient data entered through the treatment application (i.e., "Tokyo Taro_Home Blood Pressure 2").
In the present embodiment, no time limit is set for inputting blood pressure values and the like to the recording app. For this reason, in FIG. 12, the corresponding period for patient data input through the recording app is depicted as "February 1, 2024 onwards."

<Summary>
After the end of the insured medical treatment period, patients will be guided to input their blood pressure values through the recording app, allowing them to continue the experience of inputting their blood pressure values, which has become a habit through the prescribed treatment app.
In addition, after the end of the insured medical treatment period, the patient data input through the treatment application and the patient data input through the record application are combined to generate one patient data, which eliminates the need to extract and combine the patient data for the same patient for two periods each time. In other words, in this embodiment, by simply reading out one data file corresponding to a specific patient from the record application operation server 20, viewing of the patient data for the two periods and other processing can be started.

In addition, by generating a data file in which patient data entered after the end of the insured medical treatment period is added to the patient data transferred to record application operation server 20 during the insured medical treatment period, doctors can access both the patient data during the insured medical treatment period and the patient data after the end of the insured medical treatment period by simply accessing record application operation server 20.
As a result, doctors will be able to consider treatment plans based on trends in blood pressure values measured at home.

<Other examples of data migration>
In the case of Figure 10, when the patient agrees to the data transfer (S177 in Figure 10), the transfer of the patient data stored in the treatment app operation server 10 to the record app operation server 20 is initiated, but an instruction to use the record app on the treatment app operation screen (e.g., S156 in Figure 10) or the like can be regarded as consent to the transfer (handover) of patient data, and the patient data transfer process can be initiated.

In the case of FIG. 10, the patient data input through the treatment app is transferred to the record app operation server 20 via the patient terminal 40, but this may also be achieved by direct communication between the treatment app operation server 10 and the record app operation server 20. In this case, the transfer of patient data may be automatically executed, for example, with the start conditions being the installation of the record app on the patient terminal 40, the download of the record app, successful authentication of the record app, or the end of the insured medical treatment period.

<Embodiment 2>
Next, an application for assisting in the treatment of hypertension will be described as an example of a treatment application prescribed by an insurance medical institution.
<System configuration and hardware configuration>
The information processing system assumed in this embodiment is the same as the information processing system 1 (see FIG. 1 ) described in embodiment 1. The hardware configurations of the treatment application operation server 10, the record application operation server 20, the doctor terminal 30, and the patient terminal 40 are also the same as the hardware configurations described in embodiment 1.

<Processing operations after the insurance medical treatment period of the treatment app>
Fig. 13 is an example of a processing sequence for explaining the integration processing of patient data in the embodiment 2. In Fig. 13, the parts corresponding to those in Fig. 10 are denoted by the same reference numerals. The processing operation shown in Fig. 13 is also an example of an information processing method.
In this embodiment, the processing operation of the first stage (S151 to S163) is the same as that in embodiment 1. That is, when the treatment app is started after the end of the insurance medical treatment period, the installation of the record app is recommended.

For the second stage, the processing operations from S171 to S189 are the same as those in the first embodiment. That is, when the patient signs in to the recording app for the first time, the patient data of the patient who operates the patient terminal 40 is transferred from the treatment app operation server 10 to the recording app operation server 20, and the blood pressure values and the like inputted to the recording app are sent to the recording app operation server 20 as patient data.

However, in this embodiment, patient data such as blood pressure values input through the recording application is written to the recording application operation server 20 as a separate file from patient data such as blood pressure values input through the treatment application (S191).
That is, in this embodiment, two sets of patient data relating to the same patient are recorded as separate files in the record application operation server 20. In this manner, in this embodiment, by managing patient data during the insured medical treatment period and patient data after the insured medical treatment period as separate files, it becomes possible to manage the reading, etc. of patient data by period.

In the case of this embodiment, as the third stage, processing operations S201 to S207 (t81 to t84) related to viewing of patient data by a doctor will be described. The integration of the two patient data is executed when the patient data is viewed by the doctor terminal 30.
First, the doctor inputs the patient ID into the doctor terminal 30 (S201) and opens the patient's electronic medical record, etc.
Next, the doctor instructs the doctor to view the patient data input through the treatment app or the record app on the operation screen of the doctor terminal 30 (S202). The viewing instruction here may be an instruction to view the patient data in the treatment app, an instruction to view the patient data in the record app, or an instruction to view both the patient data in the treatment app and the patient data in the record app.

In the present embodiment, both the patient data of the treatment application and the patient data of the record application are stored in the record application operation server 20 .
Therefore, the doctor terminal 30 that has received the instruction requests the patient data from the record application operation server 20 (S203). This request includes the patient ID, user ID, prescription code, etc., which are necessary to identify the patient data. The patient ID, user ID, prescription code, etc. here are examples of link information that links two patient data of the same patient. Incidentally, the user ID and prescription code corresponding to the patient ID may be provided from, for example, the patient terminal 40, or may be obtained from the treatment application operation server 10. Moreover, the information of the record application operation server 10 may be obtained from, for example, the patient terminal 40.
The record application operation server 20 that has received the request for patient data reads out two pieces of patient data recorded for the requested patient (S204), and integrates the two pieces of patient data so that their contexts are consistent (S205).

In this embodiment, an integration process of the two patient data is executed whether the viewing instruction is for patient data in a treatment app, for patient data in a record app, or for both patient data in a treatment app and patient data in a record app.
When the data integration process is completed, the record application operation server 20 transmits the integrated patient data (hereinafter also referred to as "integrated data") to the doctor terminal 30 that has made the request (S206).
The doctor terminal 30 displays the received integrated data (S207).

FIG. 14 is a diagram illustrating an image of a process of integrating patient data of a treatment application and patient data of a record application in the second embodiment.
In FIG. 14 , the file name of the patient data input through the treatment app and transferred from the treatment app operation server 10 to the record app operation server 20 is indicated as “Tokyo Taro_Home Blood Pressure 2”, and the file name of the patient data input through the record app and recorded in the record app operation server 20 is indicated as “Tokyo Taro_Home Blood Pressure 3”.

Incidentally, "Tokyo Taro_Home Blood Pressure 2" includes patient data input during the insured medical treatment period from August 1, 2023 to January 31, 2024. Also, "Tokyo Taro_Home Blood Pressure 3" includes patient data input during the insured medical treatment period from February 1, 2024 to February 22, 2024, which is after the end of the insured medical treatment period.
Thereafter, when a viewing instruction is received from the doctor terminal 30, the integration process of the two patient data is executed and displayed on the screen of the doctor terminal 30.
In this manner, the integration process in this embodiment is executed each time blood pressure values, etc., are viewed during and after the end of the insured medical treatment period.

Fig. 15 is a diagram for explaining an example of a consultation screen displayed on the display 36 of the doctor terminal 30. Fig. 15 shows corresponding parts to Fig. 9 .
In the case of FIG. 15, the consultation date is assumed to be February 23, 2024, after the insured medical treatment period.
Therefore, the consultation screen shown in Figure 15 displays the average value of patient data during the insured medical treatment period (January 2, 2024 to January 30, 2024) and the average value of patient data from the last day of the insured medical treatment period to the day before the consultation date (January 31, 2024 to February 22, 2024).
In this way, even if the patient data for "Tokyo Taro" during his insured medical treatment period and the patient data after the end of the insured medical treatment period are managed as separate files within the record application operation server 20, the doctor's terminal 30 can display the results of processing all patient data up to the day before the consultation date as a single data.

<Summary>
Even if patient data during the insured medical treatment period and patient data after the end of the insured medical treatment period are managed as separate files in the record application operation server 20, the two patient data can be treated as a single patient data by executing an integration process for the two patient data each time they are viewed, which is one form of using the two patient data.
The integration process may be executed only when viewing of both the patient data during the insured medical treatment period and the patient data after the end of the insured medical treatment period is instructed on the doctor terminal 30. In other words, when viewing of only the patient data during the insured medical treatment period or only the patient data after the end of the insured medical treatment period is instructed, it is also possible to adopt a processing operation that does not execute the integration process of the two patient data.

Furthermore, in the case where patient data during the insured medical treatment period and patient data after the end of the insured medical treatment period are managed as separate files in the record application operation server 20 as in this embodiment, it is possible to clearly distinguish between the handling of patient data during the insured medical treatment period and the handling of patient data after the end of the insured medical treatment period.
Therefore, in processes that use only patient data within the insured medical treatment period or only patient data after the end of the insured medical treatment period, it is possible to eliminate the need for a process of selectively extracting relevant patient data from the integrated patient data.

<Other integration processing examples>
In FIG. 13, the integration process of two pieces of patient data that is executed when the patient data is viewed is executed on the record application operation server 20 side, but it may be executed on the doctor terminal 30 side that views the patient data.
Fig. 16 is a processing sequence for explaining another example of the integration process of patient data in the embodiment 2. In Fig. 16, the parts corresponding to those in Fig. 13 are denoted by the same reference numerals. The processing operation shown in Fig. 16 is also an example of an information processing method.

In the case of Figure 16, in S206, the patient data entered through the treatment app and the patient data entered through the record app for the patient to be viewed are sent as separate files, and an integration process is executed on the doctor terminal 30 (S208).
It is also possible that the patient data is viewed on the patient terminal 40. In this case, the integration process can be executed on the record application operation server 20 side as described in Fig. 13, or on the information terminal (i.e., the patient terminal 40) side that views the patient data as described in Fig. 16.

<Third embodiment>
Next, an application for assisting in the treatment of hypertension will be described as an example of a treatment application prescribed by an insurance medical institution.
<System configuration and hardware configuration>
The information processing system assumed in this embodiment is the same as the information processing system 1 (see FIG. 1 ) described in embodiment 1. The hardware configurations of the treatment application operation server 10, the record application operation server 20, the doctor terminal 30, and the patient terminal 40 are also the same as the hardware configurations described in embodiment 1.

<Processing operations after the insurance medical treatment period of the treatment app>
Fig. 17 is an example of a processing sequence for explaining a patient data transfer process in the third embodiment. In Fig. 17, the parts corresponding to those in Fig. 16 are denoted by the same reference numerals. The processing operation shown in Fig. 17 is also an example of an information processing method.
In this embodiment, the processing operation of the first stage (S151 to S163 in FIG. 10) is the same as that in embodiment 1. That is, when the treatment app is started after the end of the insurance medical treatment period, the installation of the record app is recommended.

17, however, it is assumed that the transfer process of patient data within the insurance medical treatment period is not executed, that is, the transfer of patient data from the treatment application operation server 10 to the record application operation server 20 is not executed.
Therefore, after the process operations from the start of the recording app to successful authentication (S171 to S176), the home screen is displayed (S187). The process operations thereafter are the same as those in the second embodiment. That is, the blood pressure values and the like input through the recording app are recorded as patient data in the recording app operation server 20 (S188 to S191).

As described above, in the present embodiment, the patient data input through the treatment application is recorded in the treatment application operation server 10 , and the patient data input through the recording application is recorded in the recording application operation server 20 .
Under this premise, processing operations S201 to S208 (t81 to t84) relating to the doctor's viewing of patient data are executed.
The difference from FIG. 16 is that a request for patient data from the doctor terminal 30 (S203) is sent to both the treatment application operation server 10 and the record application operation server 20.

Therefore, the reading of the patient data (S204) and the transmission of the read patient data to the doctor terminal 30 (S206) are also performed by the treatment application operation server 10 and the record application operation server 20, respectively.
When two pieces of patient data relating to the same patient are received, the doctor terminal 30 shown in FIG. 17 integrates these two pieces of patient data (S208) and displays the integrated patient data (i.e., integrated data) on the examination screen (S207).

<Summary>
In this embodiment, the doctor terminal 30 reads out the patient data of the patient to be viewed from each of the treatment application operation server 10 and the record application operation server 20, integrates the data, and displays the data on the examination screen. The contents that can be confirmed on the doctor terminal 30 are the same as those in the second embodiment.
In this embodiment, it is possible to eliminate the need for a series of processes for transferring patient data from the treatment application operation server 10 to the record application operation server 20 after the end of the insurance medical treatment period.

<Other integration processing examples>
In FIG. 17, the integration process of two patient data is executed on the doctor terminal 30 side where the patient data is viewed, but it may be executed on the patient terminal 40 side.
Fig. 18 is a processing sequence for explaining another example of the integration process of patient data in the embodiment 3. In Fig. 18, the parts corresponding to those in Fig. 17 are denoted by the same reference numerals. The processing operation shown in Fig. 17 is also an example of an information processing method.
The case of Fig. 18 is basically the same as Fig. 17 except that the instruction to view the patient data is executed through the recording application of the patient terminal 40. However, in the case of Fig. 18, since the instruction to view is given through the patient terminal 40 operated by the patient, input of the patient ID (S201) is omitted.

<Other embodiments>
(1) Although the embodiments of the present disclosure have been described above, the technical scope of the present disclosure is not limited to the scope described in the above-mentioned embodiments. It is clear from the claims that the technical scope of the present disclosure also includes various modifications or improvements to the above-mentioned embodiments.

(2) The processor in the above-described embodiments refers to a processor in a broad sense, and includes general-purpose processors (e.g., CPU (Central Processing Unit)) as well as dedicated processors (e.g., GPU (Graphical Processing Unit), ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array), programmable logic devices, etc.).
In addition, the operations of the processor in each of the above-mentioned embodiments may be executed by multiple processors in cooperation with each other, and the order of execution of each operation in the processor is not limited to the order described in each of the above-mentioned embodiments, and may be changed individually.

(3) In the above-described embodiment, an example was given of a case where all authentication processing when the patient terminal 40 accesses the treatment app operation server 10 or when the patient terminal 40 accesses the record app operation server 20 is completed within the server, but the results may be used in combination with authentication by a third party, including the business entity or telecommunications carrier from which the patient obtained the treatment app or record app.

(4) The treatment app and record app described in the above embodiment are intended to be prescribed to patients with hypertension, but may also be apps prescribed to patients suffering from other diseases.
That is, the above-mentioned treatment application and record application may be applications prescribed for, for example, nicotine addiction, insomnia disorder, depression, diabetes, alcoholism, obesity, etc. Note that the information inputted into the treatment application and record application differs depending on the type of disease.

In the case of an app prescribed to a patient with nicotine addiction, for example, carbon monoxide (CO) in the breath, nicotine concentration in saliva, smoking date and time, number of cigarettes smoked or number of times, patient's cognitive information (way of thinking, values), exercise (number of steps, length of time exercised, distance traveled), other illnesses (diabetes), medication, blood pressure, heart rate, pulse, current physical condition (headache, irritability, feeling good, nausea, etc.), and all or part of the answers to the assumed causes are input. These pieces of information are examples of information related to smoking.
In the case of an app prescribed to a patient with insomnia, for example, all or part of the following information is input: bedtime, wake-up time, sleep duration, sleep efficiency, number and type of meals, exercise record, and medication record. Bedtime, wake-up time, sleep duration, and sleep efficiency are examples of information related to sleep.
In the case of an app prescribed to a patient suffering from depression, for example, all or part of the following records may be entered: mood records, behavior records, medication records, sleep records, and appetite records.

In the case of an app prescribed for a diabetic patient, for example, all or part of the number and contents of meals, exercise records, medication records, weight, blood pressure value, and blood glucose level are input. Blood glucose level is an example of information related to blood glucose level.
In the case of an app prescribed to patients with alcoholism, for example, medication records, whether or not they have drunk alcohol, and all or part of the details of their drinking are entered.
In the case of an app prescribed to an obese patient, for example, all or part of the target weight, start date of treatment, number of days of treatment, appropriate calorie intake, health history (mood), weight history, calorie intake history, date and time of calorie intake, medication history (dosage taken, date and time of taking medication), therapy history (therapy, content of advice, whether or not the patient performed it), medical history, blood data (AST (aspartate aminotransferase) and ALT (alanine aminotransferase)), and CT value are input.
The treatment application and the record application may be capable of inputting information on a plurality of diseases.

(5) In the above-described embodiment, it is assumed that the integration process of patient data is executed after the end of the insured medical treatment period, but the integration process of patient data may be executed before the end of the insured medical treatment period. For example, if the usage period of a treatment app is set to the last day of the month following the date of a visit to the hospital or within 30 days from the date of a visit to the hospital, and the use of the treatment app is restricted when the usage period expires even before the end of the insured medical treatment period, the processing of the above-described embodiment may be executed on the condition that an extension of the usage period by a doctor is not recorded within a predetermined period from the end of the usage period.
Fig. 19 is a diagram for explaining another example of the authentication data 141 stored in the auxiliary storage device 14 (see Fig. 2) of the treatment application operation server 10. In Fig. 19, the parts corresponding to those in Fig. 3 are denoted by the same reference numerals.

In the case of Figure 19, the authentication data 141 shown in Figure 3 differs in that the "Prescription date" column has been changed to "Prescription date/Consultation date" and a column for "Expiration month of treatment app" has been added.
In the case of FIG. 19, the date on which the treatment app was prescribed to "Tokyo Taro" is July 31, 2023. Therefore, the insured medical treatment period is set to January 2024. Meanwhile, the expiration month of the treatment app is recorded as August 2023. If "Tokyo Taro" does not receive his next medical examination within August 2023, he will no longer be able to use the treatment app.
However, in the case of FIG. 19, "Tokyo Taro" has his second medical examination on August 29, 2023. Therefore, the expiration month of the treatment app is updated to September 2023.
In this way, when the expiration date of the medical treatment app is set separately from the medical treatment period covered by insurance, the patient data transfer process or the like may be executed on the condition that the expiration date expires.
The expiration date here is also an example of a validity period.

(6) In the above description, the patient data transfer process is executed after the end of the insured medical treatment period or the expiration date of the treatment app, which is set based on the consultation date, but the patient data integration process may be executed before the expiration date of these valid periods. For example, if a patient starts using the record app during the valid period and patient data is input through the record app, the integration process of the patient data input through the treatment app and the patient data input through the record app may be executed during the valid period.
The integration of patient data during the validity period is triggered by a viewing instruction from the doctor terminal 30 or the patient terminal 40 or the input of new patient data.

(7) In the above-described embodiment, the treatment application operation server 10 and the record application operation server 20 include both an authentication function and a patient data storage function, but the authentication function may be performed by an authentication server and the patient data storage function may be performed by a storage server. When servers are provided for different functions, the above-described patient data migration process is realized by cooperation between multiple servers.

(8) In the above-described embodiment, patient data such as blood pressure values input through a treatment app is integrated with patient data such as blood pressure values input through a recording app, but the relationship between the source and destination may be reversed. In other words, patient data such as blood pressure values input through a treatment app may be integrated with patient data such as blood pressure values input through a recording app.

(9) In the above explanation, the processing operations executed by the server and the information terminal are explained using Figures 6, 10, 13, 16, 17, and 18. However, the entity that executes each processing operation is not limited to the exemplified contents.
For example, a processing operation that is executed by a server may be executed by an information terminal, and a processing operation that is executed by an information terminal may be executed by a server.
In addition, a processing operation whose execution subject is the treatment application operation server 10 may be executed by the record application operation server 20. In addition, a processing operation whose execution subject is the doctor terminal 30 may be executed by the patient terminal 40, and a processing operation whose execution subject is the patient terminal 40 may be executed by the doctor terminal 30.

(10) In the above explanation, the insurance medical institution is assumed to be a hospital or other facility that is equipped with a doctor terminal 30 that prescribes treatment apps. However, when a pharmacist, public health nurse, nurse, nutritionist, hospital staff, or other medical professional issues a prescription code, the insurance medical institution also includes a facility or institution that is equipped with an information terminal operated by a pharmacist, public health nurse, nurse, nutritionist, hospital staff, or other medical professional. In addition, prescription codes are not limited to issuance for medical treatment, and may be issued for uninsured medical treatment or mixed medical treatment.

(11) In the above description, the second app is a record app that does not require a prescription. However, the second app may be a treatment app that is installed on the patient terminal 40 by a prescription different from that of the first app. In addition, the second app may be a completely different app from the first app, or may be the same app as the first app.
In this case, it is possible to realize integration of patient data input through a previously prescribed treatment app with patient data input through a separately prescribed treatment app.

<Summary>
The disclosed examples described in the above-mentioned embodiments are shown below.
(((1)))
An information processing system having one or more processors, which integrates first patient data prescribed for the purpose of treating a disease and input through a first app installed on a patient's terminal, and second patient data input through a second app different from the first app.
This information processing system can provide a technique that enables integration of patient data entered through a prescribed first app with patient data entered through a second app.

(((2)))
The information processing system according to (((1))), further comprising: a processor that, when a predetermined condition is satisfied, executes integration processing of the first patient data and the second patient data.
This information processing system allows the two sets of patient data to be automatically integrated.

(((3)))
The information processing system according to (((2))), wherein the predetermined condition is the first recording of the second patient data input through the second application.
According to this information processing system, the integration of patient data can be performed without the patient being aware of it.

(((4)))
The information processing system according to (((2))), wherein the predetermined condition is the end of a validity period.
According to this information processing system, the integration of patient data can be performed without the patient being aware of it.

(((5)))
The information processing system according to (((1))), wherein when a predetermined operation is received, the processor is caused to execute integration processing of the first patient data and the second patient data.
According to this information processing system, it is possible to improve the predictability of the timing at which the integration process will be executed.

(((6)))
The information processing system described in (((5))), wherein the specified operation is inputting an instruction to view first patient data to a terminal of a medical institution, or inputting an instruction to view second patient data, or inputting an instruction to view the first patient data and the second patient data.
According to this information processing system, the data of two patients can be viewed in a linked state.

(((7)))
The information processing system described in (((5))), wherein the specified operation is inputting an instruction to view first patient data on a patient's terminal, or inputting an instruction to view second patient data, or inputting an instruction to view the first patient data and the second patient data.
According to this information processing system, the data of two patients can be viewed in a linked state.

(((8)))
The information processing system according to any one of (((1))) to (((7))), wherein the integration is performed as a process of combining the first patient data and the second patient data into one data.
According to this information processing system, the first patient data during the validity period and the second patient data after the validity period can be used as one patient data.

(((9)))
The information processing system according to any one of (((1))) to (((7))), wherein the integration is performed using link information linking the first patient data stored in a first area reserved for the first application with the second patient data stored in a second area reserved for the second application.
According to this information processing system, the first patient data during the valid period and the second patient data after the valid period can be processed as one data while being stored in separate areas.

(((10)))
The information processing system according to any one of (((1))) to (((9))), wherein the second application is an application that is not covered by the medical insurance system.
According to this information processing system, the second app is not subject to the restrictions of the Pharmaceutical and Medical Device Act, making it easier to respond to patient requests.

(((11)))
An information processing method in which a computer executes a process of integrating first patient data prescribed for the purpose of treating a disease and input through a first app installed on a patient's terminal, and second patient data input through a second app different from the first app.
This information processing method provides a technique that enables integration of patient data entered through a prescribed first app with patient data entered through a second app.
It should be noted that in this information processing method as well, it is possible to combine techniques corresponding to (((2))) to (((10))).

(((12)))
A program for enabling a computer to realize a function of integrating first patient data prescribed for the purpose of treating a disease and input through a first app installed on a patient's terminal, and second patient data input through a second app different from the first app.
The program can provide technology that allows integration of patient data entered through a prescribed first app with patient data entered through a second app.
In this program too, it is possible to combine technologies corresponding to (((2))) through (((10))).

1...information processing system, 10...treatment application operation server, 20...recording application operation server, 11, 21, 31, 41...processor, 12, 22, 32, 42...ROM, 13, 23, 33, 43...RAM, 14, 24, 34, 44...auxiliary storage device, 15, 25, 35, 45...communication interface, 16, 26, 38, 48...signal line, 30...doctor terminal, 36, 46...display, 37, 47...input reception device, 40...patient terminal

Claims (12)

One or more processors;
The one or more processors:
An information processing system that integrates first patient data prescribed for the purpose of treating a disease and input through a first app installed on a patient's terminal, and second patient data input through a second app different from the first app. causing the processor to execute a process of integrating the first patient data and the second patient data when a predetermined condition is satisfied;
The information processing system according to claim 1 . The predetermined condition is the first recording of the second patient data input through the second application.
The information processing system according to claim 2 . the predetermined condition is the expiration of a validity period of the first application;
The information processing system according to claim 2 . When a predetermined operation is received, the processor is caused to execute a process of integrating the first patient data and the second patient data.
The information processing system according to claim 1 . The predetermined operation is inputting an instruction to view the first patient data, or an instruction to view the second patient data, or an instruction to view the first patient data and the second patient data, to a terminal of a medical institution.
6. The information processing system according to claim 5. The predetermined operation is inputting an instruction to view the first patient data, or an instruction to view the second patient data, or an instruction to view the first patient data and the second patient data, to the terminal of the patient.
6. The information processing system according to claim 5. The integration is performed as a process of combining the first patient data and the second patient data into one data.
The information processing system according to claim 1 . The integration is performed by using link information linking the first patient data stored in a first area reserved for the first application and the second patient data stored in a second area reserved for the second application.
The information processing system according to claim 1 . The second app is an app that is not covered by the medical insurance system.
The information processing system according to any one of claims 1 to 9. An information processing method in which a computer executes a process to integrate first patient data prescribed for the purpose of treating a disease and input through a first app installed on the patient's terminal, and second patient data input through a second app different from the first app. A program that enables a computer to realize a function of integrating first patient data that is prescribed for the purpose of treating an illness and that is input through a first app installed on the patient's device, and second patient data that is input through a second app that is different from the first app.