Information processing device, information provision method, and program

Abstract

This system provides a mechanism to support interaction with users who are working to treat or prevent diseases using application programs. [Solution] The processor of the information processing device acquires health-related data recorded by a user who is working to treat or prevent a disease, identifies information to support interaction with the user based on the acquired data, and presents the identified information to a terminal operated by a medical professional.

Description

Technical Field

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

Background Art

[0002] Attention has been paid to the utilization of application programs (hereinafter also referred to as "apps") that operate on terminals operated by users for the treatment or prevention of diseases. Currently, various apps are being published on app stores. In addition, examinations using this type of app have been started at some medical institutions, and an increase in the number of medical institutions corresponding to this type of examination is expected.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] By the way, examinations that utilize data recorded through apps are also a new attempt for doctors. Therefore, in the case of doctors who are not used to examinations using apps, there is a possibility that they may not be able to conduct examinations or interviews that reflect the user's engagement situation. On the other hand, users may have their motivation for disease treatment and prevention using the app reduced because examinations and interviews based on the data recorded through the app are not conducted.

[0005] The present disclosure provides a mechanism for assisting the interaction with users who are working on the treatment or prevention of diseases using an application program.

Means for Solving the Problems

[0006] One of the disclosures is an information processing device having a processor, which acquires health data recorded by a user working to treat or prevent a disease, identifies information to support interaction with the user based on the acquired data, and presents the identified information to a terminal operated by a healthcare professional. In this context, the processor should ideally present at least one of the following pieces of information: information that affirms the user's progress and information that supports the improvement of the challenges in the user's progress. Furthermore, it is desirable that the processor present at least one of the following as affirmative content regarding the user's efforts: content praising the user, content encouraging the continuation of the efforts, or content demonstrating the results of the efforts. Furthermore, it is desirable that the processor present at least one of the following to support the improvement of the problem: content to consult with the user, content to confirm with the user, content to instruct the user, content to suggest to the user, content to ask the user, content to advise the user, content to interview the user, content of unfulfilled goals, proposed solutions to the aforementioned problem, hints for improving the problem, hints for the interview, points to note during the interview, and the user's current physical condition. Furthermore, it is desirable that the processor detect at least one of a predetermined improvement and a predetermined problem appearing in the aforementioned data, and identify at least one of one of a predetermined improvement corresponding to the detected predetermined improvement and one of a predetermined problem corresponding to a predetermined problem. Furthermore, it is desirable that the processor detects predetermined improvements and predetermined problems appearing in the aforementioned data, and identifies one or more pieces of information depending on the combination of the detected predetermined improvements and predetermined problems. Furthermore, it is desirable that the processor detects predetermined improvements or predetermined challenges based on one or more indicators determined according to the disease. Furthermore, if there are multiple candidates for the information to be presented, it is desirable for the processor to identify one or more pieces of information based on a predetermined priority or priority relationship. Furthermore, it is desirable for the processor to use a trained model that has learned the correspondence between the aforementioned data and the aforementioned information to present the information corresponding to the data to the terminal. Furthermore, it is desirable that the processor, in addition to the information mentioned above, also present the user's progress in addressing the information mentioned above. In this context, when the processor presents both affirmative information about the user's efforts and information that supports improvement of the challenges in the user's efforts, it is desirable that it presents the user's efforts corresponding to the affirmative information, but not the user's efforts corresponding to the information that supports improvement of the challenges in the user's efforts. One of the disclosures is an information provision method in which a computer performs the following processes: acquiring health data recorded by a user who is working to treat or prevent a disease; identifying information that supports interaction with the user based on the acquired data; and presenting the identified information to a terminal operated by a healthcare professional. One of the disclosures is a program that enables a computer to have the following functions: to acquire health data recorded by users who are working to treat or prevent a disease; to identify information that supports interaction with the user based on the acquired data; and to present the identified information to a terminal operated by a healthcare professional. [Effects of the Invention]

[0007] According to one form of this disclosure, it is possible to support interaction with users who are working to treat or prevent diseases using an application program. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram illustrates an example of the overall configuration of an information processing system according to an embodiment. [Figure 2] This diagram illustrates an example hardware configuration for a PDT platform. [Figure 3] This diagram illustrates an example of status management data stored in the auxiliary storage device of the PDT platform. [Figure 4] It is a diagram for explaining an example of the hardware configuration of a PDT server. [Figure 5] It is a diagram for explaining an example of patient data stored in the auxiliary storage device of a PDT server. [Figure 6] It is a diagram for explaining an example of the hardware configuration of a doctor terminal and a patient terminal. [Figure 7] It is a diagram for explaining an example of the processing sequence in the embodiment. [Figure 8] It is a diagram for explaining an example of a status management screen. [Figure 9] It is a chart for explaining an example of an interaction support table. [Figure 10] It is a chart for explaining an example of an interaction support table. [Figure 11] It is a diagram for explaining a display example of a diagnosis support screen. [Figure 12] It is a diagram for explaining another display example of the "Situation in the Last Month" column. [Figure 13] It is a diagram for explaining another display example of the "Situation in the Last Month" column. [Figure 14] It is a diagram for explaining another example of the hardware configuration of a PDT server. [Figure 15] It is a diagram for explaining an example of the input / output relationship of a learned model. [Figure 16] It is a diagram for explaining another example of the input / output relationship of a learned model.

Mode for Carrying Out the Invention

[0009] <Terminology> First, the terms used in the embodiments described below will be explained. "User" refers to an individual who uses a program equipped with a function of recording health-related data to address the treatment or prevention of diseases. Users include those before visiting a medical institution and those who have visited a medical institution. Users who have visited a medical institution include those subject to the calculation of medical fees and those not subject to the calculation of medical fees. "Patient" refers to a user who is receiving medical treatment at a medical institution. In other words, a patient is a user who has started or is undergoing treatment at a medical institution.

[0010] The "program with a function to record health-related data" includes programs located in medical devices and programs located in non-medical devices. The "program located in a medical device" refers to a program that has received certification or approval under the Pharmaceutical Affairs Law. Programs located in medical devices include programs prescribed by a medical institution for a user who is engaged in the treatment or prevention of a disease, and programs used by medical staff at a medical institution. The "program located in a non-medical device" does not require approval under the Pharmaceutical Affairs Law. Therefore, a user who is engaged in the treatment or prevention of a disease can freely use a program located in a non-medical device. Note that programs located in non-medical devices also include programs used by medical staff at a medical institution.

[0011] As described above, the program with a function to record health-related data includes a program that operates on the terminal of a user who is engaged in the treatment or prevention of a disease (i.e., the user terminal), and a program that operates on the terminal of a medical institution. Among the programs that operate on the user terminal, there are programs that encourage changes in the user's behavior. However, a program that encourages changes in behavior does not guarantee changes in the user's behavior. Whether the user's behavior actually changes depends on the user who uses the program. Therefore, a program that encourages changes in behavior can also be said to be a program that supports changes in behavior. A user who changes their behavior or a user who attempts to change their behavior is an example of a user who is engaged in the treatment or prevention of a disease.

[0012] Programs that have the functionality to record health-related data are downloaded, for example, from app stores. Some of these programs are distributed by private companies and public organizations for use in employee health management. When distinguishing the programs mentioned above that run on user terminals from those used on terminals in medical institutions, the programs in question are sometimes referred to as user applications.

[0013] The "purpose of the app" refers to the effect that should be achieved through the use of the program, etc. The purpose of the app varies depending on the disease being treated or prevented. For example, the purpose of the app may include weight loss, lower blood pressure, reduced alcohol intake, reduced nicotine intake, improvement of related lifestyle habits, maintenance of improved lifestyle habits, and maintenance of improved values.

[0014] "App goals" refer to the objectives that are to be achieved through the use of the program, etc. Goals are defined from the perspective of achieving the objective. Goals are classified into qualitative and quantitative indicators. Furthermore, goals can be classified into indicators defined by measurements or other numerical values, and indicators defined by the content of actions. For example, goals include improving or maintaining habits, behaviors, and numerical values. App goals can also be defined by one or more sub-goals. Sub-goals are smaller-grained goals set to achieve the corresponding goal.

[0015] A "therapeutic app" refers to a program that has received approval under the Pharmaceuticals and Medical Devices Act. A therapeutic app is a program that falls under the category of medical devices as mentioned above. Therapeutic apps are approved on a disease-by-disease basis. Diseases for which approval has already been obtained include, for example, hypertension, nicotine addiction, and insomnia. Diseases for which therapeutic apps are currently under development include, for example, NASH (non-alcoholic steatohepatitis), diabetes, dyslipidemia, kidney disease, and alcoholism.

[0016] Treatment apps include patient apps and doctor apps. A "patient app" is a program that runs on a device operated by the patient (hereinafter also referred to as the "patient device") and is prescribed to the patient by a doctor. In this sense, patient apps are also called PDT (=Prescription Digital Therapeutic). The patient app can be downloaded, for example, from an app store. In the embodiment described later, the code required for activation (hereinafter referred to as the "prescription code") is issued by a doctor upon prescription. The patient app is used to record patient health data outside of medical facilities (hereinafter also referred to as "patient app data").

[0017] Patient apps have an expiration date set upon approval. This expiration date is determined based on, for example, the period during which the public health insurance system applies. The expiration date is also determined by the type of disease the patient app addresses. For example, the expiration date for a hypertension patient app is six months, starting from the month following the month in which the app was prescribed. However, six months is just an example; it could be nine months or twelve months, for example. The expiration date can also be set in days, such as 60 days or 180 days, or in weeks, such as eight weeks or 24 weeks. Needless to say, these numbers are just examples. Programs classified as non-medical devices generally do not have a set expiration date. However, it is possible to set an expiration date even for programs classified as non-medical devices.

[0018] A "doctor's app" refers to a program that can be used through a terminal operated by a doctor (hereinafter also referred to as a "doctor's terminal"). A doctor's app runs, for example, on a cloud server that can be operated from a doctor's terminal. Alternatively, a doctor's app may run on the doctor's terminal itself. Doctor's apps are used to view patient data (including patient app data). Medical professionals are also referred to as healthcare workers.

[0019] "Patient data" includes, for example, patient attributes, measurements, activity records, mood records, physical condition records, medical history, patient app usage history, biological characteristics, psychological characteristics, social characteristics, habits, goal achievement status, and answers to various questions. Patient data is also an example of data recorded by users working to treat or prevent a disease. However, the information recorded as patient data varies depending on the disease, and it does not need to include all of the example information; it may include only some of it, or other information. Furthermore, all the information recorded as patient data is also an example of health-related data.

[0020] "Patient attributes" include, for example, the patient's name, gender, and date of birth. This information is just one example of basic patient information. "Measured values" refer to numerical values ​​measured using measuring instruments. The items of measured values ​​recorded as patient app data are defined for each disease. For example, in the case of NASH, weight is recorded as a measured value. For example, if the disease is hypertension, blood pressure is recorded as a measured value. Blood pressure is defined, for example, by systolic blood pressure (i.e., maximum blood pressure) and diastolic blood pressure (i.e., minimum blood pressure). For example, if the disease is nicotine addiction, carbon monoxide (CO) in exhaled breath and nicotine concentration in saliva are recorded as measured values. Other measured values ​​include, for example, pulse rate, respiratory rate, body temperature, blood glucose level, Na / K ratio, oxygen saturation, and electroencephalogram (EEG).

[0021] "Activity records" include, for example, patient app operation history, medication records, meal records, smoking records, alcohol consumption records, and exercise records. These records also represent the user's behavior. Activity records are just one example of information related to activities. A "mood record" is, for example, a record of the user's perceived mood. A mood record is just one example of information related to mood. "Health record" refers to a record of physical condition or symptoms as perceived by the user. A health record is just one example of information related to health. Records of activities, mood, and physical condition are examples of records related to the practice of behavioral goals and the habituation of behaviors. This information is recorded, for example, as a "daily reflection."

[0022] "Medical history" includes, for example, the date treatment began, the date of the consultation, the content of the treatment, the agreement between the doctor and the patient, and the doctor's advice to the patient. Medical history is just one example of information related to a medical consultation. The "patient app operation history" includes, for example, the history of operations such as launching the patient app and inputting measurements and reflections. The patient app operation history is an example of putting behavioral goals into practice and habituating those actions. The "patient app operation history" is also the usage history of the user app. "Biological characteristics" include, for example, the presence or absence of other diseases, injuries currently being treated, the presence or absence of knee or foot pain, experience with disease treatment, and the number of years since the disease was diagnosed.

[0023] "Psychological characteristics" include, for example, expectations for app-based treatment, willingness to acquire knowledge about disease treatment, whether one finds reducing salt intake difficult, whether one believes one cannot change their taste preferences, and psychological resistance to leaving food on one's plate. "Social characteristics" include, for example, the type of work (e.g., shift work, day shift, night shift), the days of the week worked, the start time of work, the time of return home, regular days off, and the presence or absence of heating equipment in the changing room.

[0024] "Habits" include, for example, exercise habits, weight measurement habits, habits of checking calorie information on food labels, habits of choosing low-fat foods, habits of not consuming caffeine after 4 PM, eating habits after 10 PM, skipping breakfast habits, snacking habits, bathing habits one hour before bedtime, habits of stretching or massaging before bedtime, habits of getting more than 6 hours of sleep, wake-up and bedtime, the intensity of seasoning at home, and the amount of food consumed.

[0025] "Goal achievement status" refers to information showing the progress toward goals set by a doctor for each patient. It could also be information showing the progress toward goals set by the patient themselves. Furthermore, it could be information showing the progress toward goals presented by a patient app for each patient. Goal achievement status is an example of the practice of behavioral goals and the habituation of those behaviors. Furthermore, the information mentioned above can be classified into subjective information and objective information.

[0026] Patient data is recorded using various formats, such as text, images (video and still images), audio, numerical data, and codes. Images include pictures of the affected area (e.g., inflamed areas) taken by the patient. Video and audio recordings are useful, for example, in the examination of mental illnesses. "Health-related data" refers to data owned by or related to a user, and includes personal information. Health-related data may include data recorded through programs or other means that have the function of recording health-related data, as well as data obtained by processing such data. Furthermore, health-related data may also include data measured at medical institutions, data recorded by doctors during consultations, and data obtained by processing these.

[0027] The processing here also includes processing performed by AI (=Artificial Intelligence). The processed data includes, for example, advice for doctors, processed patient data, data obtained from statistical processing of patient data, and summaries of patient data generated by AI. Advice for doctors includes information that supports interactions with users based on health data recorded through the user's device. These interactions include, for example, conversations between doctors and patients during examinations or consultations. Processed data, data obtained through statistical processing, and summaries include, for example, the mean, the maximum and minimum values ​​within a given period, the data distribution for each given period, and the difference value from the baseline.

[0028] Health-related data may include data related to programs other than those that have the function of recording health-related data or programs that encourage behavioral change. For example, it may include user accounts used to access various services and privacy-related information. Health-related data can be qualitatively identifiable or quantitatively identifiable. Hereinafter, qualitatively identifiable information will be referred to as "qualitative information," and quantitatively identifiable information will be referred to as "quantitative information."

[0029] "Management indicators" refer to indicators that a user application (including patient applications) manages. In other words, management indicators are indicators used to manage the status of efforts toward the treatment or prevention of a disease. Management indicators are used to detect specific improvements in the status of efforts or specific issues. Note that management indicators may also include information that is measured continuously, such as weight and blood pressure. In the case of NASH, management indicators include, for example, "food content," "substitute eating," "eating motivation," "regularity of eating habits," "snacks," "nutritional balance," "exercise," and "eating patterns." Each of these indicators is just one example of a management indicator. "Substitute eating" refers to the behavior of eating to relieve stress.

[0030] You may use some of the eight indicators exemplified as your management indicators. These may include not only multiple indicators, but also a single indicator. In addition, the management indicators may be a combination of the eight indicators exemplified and other indicators different from these. Furthermore, the management indicators may be a combination of some of the eight indicators exemplified and other indicators different from those exemplified. Also, the management indicators may be a combination of other indicators different from any of the eight indicators exemplified.

[0031] Furthermore, the indicators or combinations of indicators used as management indicators may be set for each disease. Furthermore, the indicators or combinations of indicators used as management indicators may differ depending on the patient app, for example. For instance, patient app A may use "meal content," "substitute feeding," "eating motivation," "regularity of eating habits," "snacks," "nutritional balance," "exercise," and "eating style" as management indicators, while patient app B may use "meal content," "substitute feeding," "eating motivation," and "regularity of eating habits" as management indicators. Management indicators are also called "behavioral goals."

[0032] The "score" is a numerical value calculated based on health data recorded through the patient app. The score is used, for example, to detect changes in the user's progress. Detecting changes in progress includes identifying areas for improvement and areas for improvement. The score includes the implementation rate of management indicators. The implementation rate is also called the habit formation rate. The average habit formation rate (i.e., the average habit formation rate) is also an example of a score. The score is an example of data processed from health-related information. The process of calculating a score can involve several methods: calculating the score through calculations; determining the score using pre-defined branching rules (e.g., programs, judgment tables); or inputting health data into a pre-trained model (such as one created using machine learning) that has been trained to understand the relationship between health data and the score, and then outputting the score.

[0033] A "PDT server" is a server that manages patient data entered through patient applications, etc. A PDT server is also an example of a cloud server. A PDT server is typically set up for each patient application. Therefore, in order for a doctor to view patient data, they must log in to the PDT server running the doctor's application that is paired with the patient's application.

[0034] For example, if a patient is using a hypertension patient app provided by service provider A, the doctor needs to log in to the PDT server operated by service provider A for hypertension. Furthermore, if a patient is using a hypertension patient app provided by service provider B, the doctor needs to log in to the PDT server operated by service provider B for hypertension.

[0035] Furthermore, if a patient is using a patient app for nicotine addiction provided by service provider A, the doctor needs to log in to the PDT server operated by service provider A for nicotine addiction. Furthermore, a single PDT server may be shared among multiple patient applications targeting different diseases. Furthermore, multiple patient apps provided by different service providers may share a single PDT server.

[0036] The "PDT platform" is a server that manages the prescription of patient apps and the usage status of those apps after prescription. The PDT platform is also an example of a cloud server. The PDT platform is also called an APS (Application Prescription Service) server, as it is a server that provides prescription services for patient apps. Usage statuses include, for example, "Not yet started," "Start date expired," "In use," "Scheduled to end," "Ended," and "Period expired."

[0037] The PDT platform supports multiple patient apps that target the same disease but are provided by different service providers, as well as multiple patient apps that are provided by the same service provider but target different diseases. In this sense, the PDT platform functions as a platform for multiple patient applications. Apps running on the PDT platform manage the usage status of multiple patient apps, each with different diseases and service providers, on a patient-by-patient basis.

[0038] In the embodiment described later, "medical institution" refers to a health insurance medical institution. More specifically, a medical institution refers to a health insurance medical institution to which the doctor who issues the prescription code necessary to activate the patient app belongs. However, if deregulation allows pharmacists, public health nurses, nurses, dietitians, hospital staff, and other healthcare professionals (hereinafter also referred to as "doctors, etc.") to issue prescription codes, then the term "healthcare institution" will also include facilities and organizations where these healthcare professionals are located.

[0039] Furthermore, prescription codes may be issued not only through medical consultations, but also through uninsured medical services (i.e., private medical services) or mixed medical services. Incidentally, medical consultations include not only in-person consultations but also online consultations. "Consultation" refers to receiving a medical examination at a medical institution. In the embodiments described below, the examination may include not only consultations by doctors but also interviews by other medical professionals. For example, it may include interviews by nurses or pharmacists.

[0040] <Embodiment> <Overall System> Figure 1 is a diagram illustrating an example of the overall configuration of an information processing system 1 according to an embodiment. The information processing system 1 shown in Figure 1 consists of a PDT platform 10, PDT servers 20 (20A, 20B, 20C...20F), a physician terminal 30, and a patient terminal 40.

[0041] Figure 1 shows only one PDT platform 10. However, multiple PDT platforms 10 may exist. The PDT platform 10 may consist of multiple servers connected via a network. In this case, the multiple servers work together to provide the PDT platform services. The PDT platform 10 and the PDT server 20 are connected via a network (not shown) that enables communication. For reference, the network could include, for example, a LAN (Local Area Network), the Internet, or a mobile communication system (4G, 5G, etc.).

[0042] In Figure 1, six PDT servers 20 are connected to one PDT platform 10. However, the number of PDT servers 20 connected to one PDT platform 10 is arbitrary. The PDT server 20 is a server that performs tasks such as patient authentication, management of patient application data entered through the patient application, and provision of patient data to physician terminals (not shown). The PDT server 20 is an example of an information processing device. In Figure 1, the PDT server 20A is a server that manages patient data for a patient application (hereinafter referred to as "Patient Application A") provided by Company A for patients with alcohol dependence. PDT Server 20B is a server that manages patient data for a patient application (hereinafter referred to as "Patient Application B") provided by Company B for patients with hypertension.

[0043] PDT Server 20C is a server that manages patient data for a patient application (hereinafter referred to as "Patient Application C") provided by Company A for patients with diabetes. PDT Server 20D is a server that manages patient data for a patient application (hereinafter referred to as "Patient Application D") provided by Company B for patients with diabetes. PDT Server 20E is a server that manages patient data for a patient application (hereinafter referred to as "Patient Application E") provided by Company C for patients with dyslipidemia. PDT Server 20F is a server that manages patient data for the patient application (hereinafter referred to as "Patient Application F") provided by Company D for patients with NASH.

[0044] As shown in Figure 1, a PDT server 20 is prepared for each combination of the disease targeted by the patient application and the service provider that provides the patient application. Therefore, even if the service provider that provides the patient application is the same, different PDT servers 20 will be prepared if the targeted diseases are different. Furthermore, even if the target disease is the same, different PDT servers 20 will be provided if the service provider offering the patient app is different.

[0045] However, it is also possible to provide a single PDT server 20 for multiple patient applications with different combinations. The PDT platform 10 and the PDT servers 20 are not limited to being operated by the same operator; they may be operated by different operators. For example, some of the operators of the multiple PDT servers 20 may be the same operator as the operator of the PDT platform 10.

[0046] The physician terminal 30 is a terminal operated by physicians and other medical professionals who use the services provided by the PDT platform 10 and the PDT server 20. Figure 1 shows only one physician terminal 30 as a representative example. For example, physicians can view the usage status of patient applications by logging into the PDT platform 10. They can also view patient data by logging into the PDT server 20. The physician's terminal 30 can be, for example, a desktop computer, a laptop computer, a tablet computer, a smartphone, smart glasses, or a server.

[0047] The patient terminal 40 is a terminal operated by the patient. The patient terminal 40 uploads patient application data recorded through the patient application to the corresponding PDT server 20. Figure 1 shows only one patient terminal 40 as a representative example. Note that the patient terminal 40 is an example of a user terminal. The patient terminal 40 may be, for example, a smartphone, smart glasses, a desktop computer, a laptop computer, or a tablet computer.

[0048] <Device Hardware Configuration> <PDTプラットフォーム> Figure 2 illustrates an example of the hardware configuration of the PDT platform 10. The PDT platform 10 is a so-called server. The PDT platform 10 shown in Figure 2 includes a processor 11, semiconductor memory 12, auxiliary storage device 13, and communication interface 14. Each device is connected via a bus or other signal lines.

[0049] The processor 11 is a device that realizes various functions through the execution of a program. The processor 11 may be composed of multiple CPU (Central Processing Unit) cores. In that case, the processor 11 executes the program through the cooperation of the multiple CPU cores. The semiconductor memory 12 stores UEFI (Unified Extensible Firmware Interface) and the like. The semiconductor memory 12 is also used as an execution area for programs. The processor 11 and the semiconductor memory 12 function as a computer.

[0050] The auxiliary storage device 13 is composed of, for example, a hard disk device or a semiconductor storage. The auxiliary storage device 13 stores an operating system and other programs. Among the other programs, there is a status management application 130 that manages the status of the patient application prescribed to the patient. The auxiliary storage device 13 also stores status management data 131 of the patient application prescribed to the patient. The communication interface 14 is an interface for communicating with an external terminal such as a PDT server 20 (see FIG. 1) through a network. The communication interface 14 supports communication standards such as Ethernet (registered trademark), Wi-Fi (registered trademark), and mobile communication systems.

[0051] <PDT Platform Management Data> FIG. 3 is a diagram for explaining an example of the status management data 131 stored in the auxiliary storage device 13 (see FIG. 2) of the PDT platform 10 (see FIG. 1). The status management data 131 shown in FIG. 3 stores a prescription code 131A, a patient ID / patient name 131B, a prescription date / consultation date 131C, a medical institution ID / prescriber ID 131D, a patient application name 131E, and a usage status 131F. However, these are just examples, and for example, the patient's medical record number, the patient's gender, the patient's date of birth, age, type of insurance card, insurance company number, and version of the patient application may be stored.

[0052] The prescription code 131A is issued every time a prescription is notified from the doctor terminal 30 (see FIG. 1). Patient ID / Patient Name 131B is the patient ID and patient name registered when the prescription was issued in the patient app. In Figure 3, the patient name for patient ID "12543" is "Mr. A", the patient name for patient ID "12544" is "Mr. B", and the patient name for patient ID "12545" is "Mr. C".

[0053] The prescription date / consultation date 131C is the date the doctor examined the patient. In this embodiment, the consultation date on which the doctor prescribed the patient app is indicated as the "prescription date" to distinguish it from other consultation dates. In Figure 3, only the prescription date is stored. In Figure 3, the prescription date for the patient app for "Person A" and "Person B" is "2024 / 5 / 28", and the prescription date for the patient app for "Person C" is "2024 / 5 / 24". The Medical Institution ID / Prescriber ID 131D is an ID that identifies the medical institution and prescriber that prescribed the patient app. In Figure 3, prescription codes "12345" and "23456" were prescribed by the same doctor or other medical institution at the same medical institution.

[0054] Patient app name 131E is the name of the patient app prescribed by the doctor or other medical professional. However, it is sufficient to remember the patient app's identification code, as long as the patient app can be identified. In Figure 3, "Patient A" and "Patient B" are prescribed patient app A. Also, "Patient C" is prescribed patient app D. Usage status 131F indicates the usage status of the patient's application. The usage status can store one of the following: not yet started, start date expired, in use, scheduled to end, ended, or period expired. In Figure 3, all patient applications are in the "in use" status.

[0055] <PDTサーバ> Figure 4 illustrates an example of the hardware configuration of the PDT server 20. The PDT server 20 shown in Figure 4 includes a processor 21, semiconductor memory 22, auxiliary storage device 23, and communication interface 24. Each device is connected via a bus or other signal lines.

[0056] The processor 21 is a device that realizes various functions through program execution. The processor 21 may be composed of multiple CPU cores. In that case, the processor 21 executes the program through the cooperation of multiple CPU cores. The semiconductor memory 22 stores UEFI and the like. The semiconductor memory 22 is also used as a program execution area. The processor 21 and the semiconductor memory 22 function as a computer.

[0057] The auxiliary storage device 23 is composed of, for example, a hard disk device or a semiconductor storage. The auxiliary storage device 23 stores an operating system and other programs. Other programs include, for example, the doctor app 230. The doctor app 230 is a program that generates a diagnostic support screen corresponding to a patient examined by a doctor or the like.

[0058] In addition, the auxiliary storage device 23 stores patient data 231 recorded through the patient app, and dialogue support tables 232 and 233. The dialogue support table 232 is a table that stores messages and advice regarding points where the user's efforts are good (so-called improvement points or improved points). The dialogue support table 233 is a table that stores advice regarding points where there are problems in the user's efforts (so-called problem points or points with problems). In the case of this embodiment, the message is stored only in the dialogue support table 232. The communication interface 24 is an interface for communicating with an external terminal such as the PDT platform 10 through a network. The communication interface 24 corresponds to communication standards such as Ethernet (registered trademark), Wi-Fi (registered trademark), and mobile communication systems.

[0059] <Management data of the PDT server> FIG. 5 is a diagram for explaining an example of patient data 231 stored in the auxiliary storage device 23 (see FIG. 4) of the PDT server 20. The patient data 231 shown in Figure 5 stores measurements and other information recorded through the patient app. The content of the information recorded as patient data 231 varies depending on the disease the patient app supports. In Figure 5, patient data 231 stores prescription code 231A, patient ID / patient name 231B, and patient application data 231C.

[0060] In this embodiment, patient application data 231C means patient application management data and data recorded by the user through the patient application. Prescription code 231A records prescription code 131A (see Figure 3) issued by the PDT platform 10 (see Figure 1). Prescription code 231A is registered by the patient when they start using the patient app (i.e., when they register for the first time). The patient ID / patient name 231B is, for example, the patient ID and patient name at the medical institution that prescribed the patient app. The patient ID and patient name are obtained from the PDT platform 10, for example, when the prescription code is authenticated.

[0061] The patient app data 231C shown in Figure 5 includes the measured value / measurement date and time 231C1, the reflection / input date and time 231C2, the current step of the treatment plan 231C3, the treatment plan implementation history 231C4, the behavioral goal 231C5, and the target value 231C6. Note that the items exemplified do not need to be all of the patient application data 231C; they may be only a part of it, or other items may be included.

[0062] The measurement / measurement date and time field 231C1 records the health-related values ​​and dates measured by the patient. For example, in a patient app for NASH, the measured weight and the date and time of the weight measurement are recorded. For example, in a patient app for hypertension, the measured blood pressure value and the date and time of the blood pressure measurement are recorded. The blood pressure value is given as systolic blood pressure and diastolic blood pressure. The "Reflection / Input Date & Time 231C2" field records a reflection on the day's activities and the date and time of entry. The reflection may include details such as physical condition level, stress level, sleep duration, alcohol consumption, and the activities undertaken.

[0063] The content of the activity consists of, for example, the category of the activity that was carried out and text input. Recording of the category of activity that was carried out is done by checking buttons labeled with "salt reduction," "weight loss," "exercise," etc. Other labels include, for example, "sleep," "stress," "moderate alcohol consumption," and "other." Needless to say, the content of the behaviors to be recorded varies depending on the disease. Text input allows for the free entry of information and emotions that cannot be recorded by checking buttons.

[0064] The current step 231C3 of the treatment plan records the steps indicating the progress of the treatment plan provided by the patient app. In this embodiment, the treatment plan consists of three steps. These three steps are, for example, the "Knowledge Acquisition" step, the "Implementation of Behavioral Goals" step, and the "Habituation of Behavior" step. These three steps are executed in the order they are listed. For this reason, the "Knowledge Acquisition" step is also called "Step 1," the "Implementation of Behavioral Goals" step is called "Step 2," and the "Habituation of Behavior" step is called "Step 3." The behavioral goals here are examples of sub-goals to be implemented in order to achieve the main goal. Behavioral goals are set for each behavior.

[0065] The treatment plan implementation history 231C4 records the history of learning and behaviors implemented in accordance with the treatment plan. In "Step 1," the learning history records whether or not each learning item has been completed. "Step 1" is also called the basic learning step. The learning record in "Step 1" is an example of a record related to the acquisition of knowledge about diseases.

[0066] In "Step 2," disease-specific information is recorded as a history of behavior. For example, in a patient app for NASH patients, "Step 2" records the progress made in "not overeating," "reducing fried foods," "reducing snacks," and "exercising." For example, in a patient app for hypertension patients, "Step 2" records the progress made in "reducing salt intake," "weight loss," "exercise," "sleep," "stress," "alcohol consumption," and "quitting smoking." "Step 2" is also called habit formation support.

[0067] In "Step 3," the patient's progress in implementing the behaviors they have set as goals is recorded. For patient apps designed for NASH patients, "Step 3" offers two modes: a normal mode and a difficulty-overcoming mode. The normal mode supports the maintenance or continuation of improved lifestyle habits. Therefore, the patient app's homepage displays information to support the recording of daily measurements and behaviors. In the difficulty-overcoming mode, the processing operations of "Step 2" continue. Specifically, progress is displayed using radar charts, etc., for each unit of practice period, and the management indicators that the user struggles with are presented to the user as recommended behaviors. "Step 3" is also called habit-forming management.

[0068] Behavioral objective 231C5 records the actions set by the physician or patient as goals for each period. These goals include, for example, one or more actions selected by the patient from among the goals presented by the patient app as the treatment plan progresses. Specifically, these are the actions set or selected by the patient in "Step 2" or "Step 3" of the treatment plan. The behavioral goals are not limited to those set or selected from the behaviors presented by the patient app; they may also be behaviors set individually by the patient. Furthermore, individual patient behavioral goals may be set by the physician through their screen. An example of this type is a treatment app for alcohol dependence.

[0069] The target value 231C6 records, for example, the value set by the doctor during the examination. However, if the patient can set their own target value, the value set by the patient is recorded in target value 231C6. In the case of NASH, the target value 231C6 records weight. In the case of hypertension, the target value 231C6 records, for example, blood pressure. In all cases, the target value 231C6 is given as a numerical value. In that it is given as a numerical value, the target value is an example of a quantitative target.

[0070] <Physician terminal / Patient terminal> Figure 6 illustrates an example of the hardware configuration of a physician terminal 30 and a patient terminal 40. The hardware configuration of the physician terminal 30 and the patient terminal 40 are basically the same. Therefore, in Figure 6, they are expressed in the format of "code of the elements constituting the physician terminal 30 / code of the elements constituting the patient terminal 40". The physician terminal 30 / patient terminal 40 shown in Figure 6 includes a processor 31 / 41, semiconductor memory 32 / 42, auxiliary storage device 33 / 43, input interface 34 / 44, input device 35 / 45, output interface 36 / 46, output device 37 / 47, and communication interface 38 / 48. Each device is connected via a bus or other signal lines.

[0071] The processors 31 / 41 are devices that perform various functions through program execution. The processors 31 / 41 may consist of multiple CPU cores. In that case, the processor 11 executes the program through the cooperation of the multiple CPU cores. The semiconductor memory 32 / 42 stores UEFI and other information. The semiconductor memory 32 / 42 is also used as an execution area for programs. The processor 31 / 41 and the semiconductor memory 32 / 42 function as a computer. The auxiliary storage devices 33 / 43 consist of, for example, hard disk drives or semiconductor storage devices. The operating system and other programs are stored in the auxiliary storage devices 33 / 43.

[0072] In the case of the physician terminal 30, the auxiliary storage device 33 stores a client certificate for accessing the PDT platform 10 (see Figure 1). In the case of the patient terminal 40, the auxiliary storage device 43 stores the patient application and the patient application data 231C (see Figure 5) recorded through the program. Furthermore, if the physician terminal 30 requires a client certificate to access the PDT server 20, the client certificate for accessing the PDT server 20 is stored in the auxiliary storage device 33. Similarly, if the patient terminal 40 requires a client certificate to access the PDT server 20, the client certificate for accessing the PDT server 20 is stored in the auxiliary storage device 43.

[0073] Input interfaces 34 / 44 can use, for example, USB (Universal Serial Bus) or Bluetooth (registered trademark) to connect to input devices 35 / 45. Input devices 35 / 45 can include, for example, keyboards, mice, or touch panels.

[0074] Output interfaces 36 / 46 can be connected to output devices 37 / 47, for example, using HDMI (High-Definition Multimedia Interface) (registered trademark) or a LAN interface. Output devices 37 / 47 can be, for example, monitors or printers. Communication interfaces 38 / 48 are interfaces for communicating with external terminals over a network. Communication interfaces 38 / 48 are compatible with Ethernet®, Wi-Fi®, mobile communication systems, and other communication standards.

[0075] <Processing Sequence> Figure 7 illustrates an example of a processing sequence in the embodiment. The processing sequence shown in Figure 7 corresponds to the period from the day after the previous examination to the current examination. In Figure 7, the symbol S stands for step. The explanation of the processing sequence shown in Figure 7 assumes a case where a patient with NASH is being examined. The processing sequence shown in Figure 7 is classified into processing in daily life and processing during medical examinations. Steps 101 to 105 correspond to processing in daily life. Steps 111 to 116 correspond to processing during medical examinations.

[0076] <Step 101> Figure 7 assumes a previous consultation in which a patient app was prescribed. Patients who successfully install the patient app begin the initial setup. That is, the patient terminal 40 accepts initial registration for the patient app. In order to enable the patient app, successful authentication of the prescription code by a PDT platform (not shown) is required. During initial registration, for example, initial values ​​for patient attributes and physical information are recorded. Patient attributes include, for example, name, gender, date of birth, patient's biological characteristics, patient's psychological characteristics, patient's social characteristics, and patient's habits.

[0077] In this embodiment, the patient's biological characteristics, psychological characteristics, social characteristics, and habits each consist of multiple items. Each item has multiple choices, and one or more choices selected by the patient are recorded as the answer to the item. Initial physical information recorded during initial registration includes, for example, height, weight, and blood pressure. In subsequent consultations, steps 101 and 102 are skipped, and steps 103 and 104 are repeated.

[0078] <Step 102> Once the patient completes initial registration, the patient terminal 40 begins management based on the treatment plan. The treatment plan in this embodiment consists of three steps: the "Knowledge Acquisition" step, the "Implementation of Behavioral Goals" step, and the "Habituation of Behavior" step. However, this classification is just an example, and the number of steps is not limited to three. For example, there may be two steps, or four or more steps. Also, the names and contents of each step are not limited to those exemplified.

[0079] The "knowledge acquisition" step is also called the learning step. In this embodiment, the "knowledge acquisition" step lasts 12 days. Of course, 12 days is just an example and will be determined according to the disease. Also, even for the same disease, different periods may be set depending on the patient app. In the "Knowledge Acquisition" step, the patient app assists in acquiring basic knowledge about the disease. Knowledge acquisition is monitored, for example, through responses to quizzes. If a question has multiple-choice answers, the one or more options selected by the patient are recorded as the answer. Furthermore, in the "knowledge acquisition" step, the patient app assists with recording daily life measurements (e.g., weight and blood pressure) and recording reflections.

[0080] The "implementation of behavioral goals" step is a step aimed at improving the patient's lifestyle through the implementation of behavioral goals. In this embodiment, the "implementation of behavioral goals" step is approximately 6 months. Of course, 6 months is just an example and will be determined according to the disease. Furthermore, even for the same disease, different periods may be set for each patient application. In this embodiment, the "implementation of behavioral goals" step involves "setting behavioral goals," "learning behavioral goals," "implementation of behavioral goals," and "reflection," all of which are managed with the support of a patient application.

[0081] In this embodiment, the implementation period for the "implementation of behavioral goals" step consists of multiple unit implementation periods. In this embodiment, each unit implementation period is 8 days long. In this embodiment, "setting behavioral goals" and "learning behavioral goals" are allocated to the first day of the unit implementation period, while "implementation of behavioral goals" and "reflection" are allocated to the 7 days from the second to the eighth day of the unit implementation period. Therefore, in the "Implementing Action Goals" step, the following cycle is repeated every eight days: "Setting Action Goals," "Learning about Action Goals," "Implementing Action Goals," and "7-Day Review." The patient app in this embodiment includes a function that suggests behaviors the patient finds difficult as potential behavioral goals. However, the patient themselves ultimately decides which behavioral goals to pursue.

[0082] The "habit formation" step aims to solidify the improved lifestyle habits achieved through the implementation of behavioral goals. However, for patients whose lifestyle habits have not improved sufficiently, the "implementation of behavioral goals" step is essentially repeated. The "habit formation" step in this embodiment also takes approximately 6 months. Of course, 6 months is just one example, and the duration will be determined according to the disease. Furthermore, even for the same disease, different periods may be set for each patient application. When targeting patients aiming to solidify improved lifestyle habits, setting behavioral goals is optional in the "habituation of behavior" step. That is, patients may or may not set behavioral goals. The "habituation of behavior" step for patients aiming to solidify improved lifestyle habits becomes a period of behavioral recording.

[0083] <Step 103> The patient terminal 40 records patient application data 231C (see Figure 5) in the auxiliary storage device 43 (see Figure 6). The patient application data 231C includes information entered by the patient and information recorded by the patient application. The information entered by the patient includes, for example, measured values ​​and daily reflections. The information recorded by the patient application includes, for example, the number of times the patient application has been launched and a history of learning and actions practiced according to the treatment plan. As mentioned above, patient application data 231C may include data obtained by processing these data.

[0084] <Step 104> The patient terminal 40 uploads data collected through the patient application (i.e., patient application data) to the PDT server 20 at a predetermined time. If the patient app is logged into the PDT server 20, the patient terminal 40 uploads patient app data when recording or updating new patient app data. If the patient app is not logged into the PDT server 20, the patient terminal 40 uploads the patient app data when logging into the PDT server 20.

[0085] <Step 105> The PDT server 20 stores the uploaded patient application data 231C. This patient application data constitutes a part of the patient data 231 (see Figure 5). Steps 103 to 104 shown in Figure 7 are repeated due to input operations performed by the patient on the patient application.

[0086] <Step 111> The PDT platform 10 displays a screen for managing the status of prescribed patient apps (hereinafter referred to as the "status management screen") to the physician's terminal 30. Figure 8 is a diagram illustrating an example of the status management screen 300. In this embodiment, the status management screen 300 displays a list of the statuses of patient applications prescribed by a doctor or other medical professional operating the doctor terminal 30. However, the status management screen 300 may also include the status of patient apps prescribed by the medical institution to which the physician operating the physician terminal 30 belongs. In other words, the status management screen 300 may also include the status of patient apps prescribed by other physicians belonging to the same medical institution.

[0087] In addition, the status management screen 300 may also display the status of patient apps prescribed by other medical institutions. This display function is useful, for example, when a patient requests a second opinion. This display can be implemented, for example, by a doctor operating the doctor terminal 30 providing the PDT platform 10 (see Figure 7) with information that identifies the patient being treated (e.g., medical record number and patient name). Furthermore, technically, it is possible to include all patient information managed by the PDT platform 10 in the status management screen 300. However, in that case, it is desirable to enable filtering and sorting of patients displayed on the management screen based on the ID of the physician operating the physician terminal 30.

[0088] The status management screen 300 shown in Figure 8 consists of an information field 301, the current date and time 302, a "Details" button 303, a "New Prescription" button 304, and a "Close" button 305. Information field 301 displays management information for the patient app prescribed to each patient. In Figure 8, information field 301 is displayed in a table format. Specifically, the rows display information for each patient, and the columns display management items for the patient app. Figure 8 shows examples of management items, including medical record number / patient name 301A, application name 301B, usage status 301C, prescription date 301D, and prescription code expiration date 301E.

[0089] The field "Medical Record Number / Patient Name 301A" displays the medical record number and patient name, which are examples of information used to identify a patient prescribed by the patient app. Note that the patient identification information may also include user ID, address, etc. The app name 301B displays the name of the patient app prescribed to the patient. In this embodiment, four apps are displayed: patient app A, patient app B, patient app C, and patient app D. The app name 301B may also include version information.

[0090] If multiple patient apps are approved for the same patient, the information will be displayed on different rows. In addition to the app name 301B, or separately, the name of the disease targeted by the patient app may be displayed. Usage status 301C is used to display the patient's usage status of the application. In Figure 8, usage status 301C displays three options: "Before use," "In use," and "Finished." However, as mentioned above, usage status 301C can also display "Start deadline expired," "Scheduled end," "Period expired," etc.

[0091] The prescription date 301D displays the date the patient app was prescribed by a doctor or other healthcare professional. The prescription code expiration date 301E displays the last day the prescription code is valid. In this embodiment, the prescription code expiration date 301E displays a date three days after the prescription date 301D. The current date and time 302 is the date and time when the status management screen 300 was viewed.

[0092] The "Details" button 303 is used to display the consultation support screen 310 (see Figure 11). The "Details" button 303 is placed for each row corresponding to a patient. When the "Details" button 303 is pressed, the patient data viewing screen for the patient corresponding to the "Details" button 303 is displayed. The "New Prescription" button 304 is used when prescribing a patient app to a patient. When the "New Prescription" button 304 is pressed, a screen appears for entering the app name, patient name, gender, date of birth, etc. The name of the prescribing physician is also registered at the same time. The "Close" button 305 is used to close the status management screen 300 shown in Figure 8. Let's return to the explanation of Figure 7.

[0093] <Step 112> The physician's terminal 30 accepts the patient's selection. Specifically, the physician terminal 30 accepts the operation of the "Details" button 303 (see Figure 8). For example, the physician terminal 30 accepts the operation of the "Details" button 303 corresponding to Ms. M, for whom more than two months have passed since the prescription date. Upon receiving the operation of the "Details" button 303, the physician terminal 30 accesses the PDT server 20 of the patient app prescribed to the patient corresponding to the operated "Details" button 303.

[0094] Furthermore, the physician or other medical professional is assumed to be logged in to the PDT server 20 via the physician terminal 30. During this access, the prescription code of the patient app prescribed to the patient corresponding to the operated "Details" button 303 is notified. Incidentally, the physician terminal 30 may request the PDT platform 10 to issue a one-time token necessary to access the corresponding PDT server 20. In this case, the physician terminal 30 uses the one-time token received in return from the PDT platform 10 to access the PDT server 20. When this method is adopted, physicians and others can access patient application data on the PDT server 20 even if they are not logged in.

[0095] <Step 113> Upon receiving access from the physician's terminal 30, the PDT server 20 retrieves the current step in the treatment plan for the relevant patient. The current step is read from the current step 231C3 of the treatment plan (see Figure 5).

[0096] <Step 114> The PDT server 20 detects the conditions that the patient must meet based on the dialogue support tables 232 and 233 (see Figure 4). The PDT server 20 may detect one or more conditions from the dialogue support tables 232 and 233. The detected conditions are used to generate the medical consultation support screen in step 115, which will be described later. On the other hand, there is a possibility that too much information may be presented to doctors, etc. Therefore, in this embodiment, one condition is detected from each table. In this embodiment, as a mechanism for detecting one condition from each table, a priority is set for the conditions within the table. In this case, if the user has multiple conditions that can be met, the condition with the higher priority takes precedence.

[0097] Priority defines the rank or order among all conditions. Each rank can be a single condition or a combination of multiple conditions. For example, a higher priority indicates a more difficult condition or a higher demand on the user. In this embodiment, the PDT server 20 verifies whether the patient meets the conditions in order of priority, starting with the conditions with the highest priority.

[0098] When the PDT server 20 detects that the patient meets the required conditions, it terminates the verification process at that point. In other words, even if there are unverified conditions remaining, the PDT server 20 does not perform verification on them. Consequently, the PDT server 20 determines that the highest-priority condition among those met by the patient is the condition the patient meets. It should be noted that the conditions that the patient meets may not always be detected. For example, the conditions that the patient meets may not be detected for dialogue support table 232. Similarly, the conditions that the patient meets may not be detected for dialogue support table 233. Furthermore, the conditions that the patient meets may not be detected for both dialogue support table 232 and dialogue support table 233.

[0099] <Step 115> The PDT server 20 reads messages and advice corresponding to the detected conditions and generates a medical consultation support screen. The messages and advice are examples of information that supports interaction with the user. In this embodiment, the messages and advice corresponding to the detected conditions are identified by the detected conditions. Messages and advice corresponding to the detected conditions are read from either or both of the dialogue support tables 232 and 233 (see Figure 4).

[0100] <Step 116> The PDT server 20 presents the generated consultation support screen to the physician's terminal 30. As mentioned above, the consultation support screen includes at least one of a message and / or advice identified based on the health data recorded by the user. As a result, doctors and other medical professionals can use the messages and advice included in the consultation support screen to guide their interactions with users. Since these messages and advice reflect the user's progress, they are also useful for doctors and other medical professionals to understand the user's progress.

[0101] <Examples of dialogue support tables> The following sections will describe specific examples of dialogue support tables 232 and 233 (see Figure 4). <For pointing out positive aspects of the initiative> Figure 9 is a diagram illustrating an example of a dialogue support table 232. The dialogue support table 232 stores messages and advice used to point out good progress, categorized by condition. In other words, the dialogue support table 232 stores messages and advice indicating improvement in one or more management indicators determined according to the disease.

[0102] The dialogue support table 232 shown in Figure 9 consists of priority 232A, type 232B, "condition 1" 232C, "condition 2" 232D, message 232E, and advice point 232F. In Figure 9, priority 232A displays numbers from "1" to "5". "1" indicates the first priority, meaning "1" represents the highest priority. On the other hand, "5" indicates the fifth priority, meaning "5" represents the lowest priority. In Figure 9, for explanatory purposes, "5" is shown as five conditions managed by priority, but it could be seven, ten, fifteen, or even twenty. Of course, these numbers are just examples.

[0103] Category 232B displays the type of condition. For example, priority levels "1" and "2" are assigned to conditions related to weight loss rate. Priority level "3" is assigned to conditions related to habit formation rate. Priority level "4" is assigned to conditions related to behavioral goals. Priority level "5" is assigned to conditions related to launching the patient app (labeled "App Launch" in Figure 9). Note that the types of conditions are not limited to those exemplified.

[0104] Condition 1 (232C) is the first condition. In this embodiment, Condition 1 (232C) is assigned to the current step in the treatment plan. Priority levels "1," "2," and "5" are assigned to "Step 1," "Step 2," and "Step 3," respectively. On the other hand, priority levels "3" and "4" are assigned to "Step 2" and "Step 3," respectively. Therefore, for patients belonging to "Step 1" of the treatment plan, no messages or other information corresponding to priority levels "3" and "4" will be presented.

[0105] "Condition 2" 232D is the second condition. In this embodiment, "Condition 2" 232D is assigned one or more conditions. Priority level "1" is assigned to "Average weight over the past 7 days is below the target weight." In this embodiment, the past 7 days refers to the 7 days up to yesterday. If 7 days ago was before the patient started using the patient app, the average weight is calculated based on the number of days from the start date of the patient app to yesterday. In this embodiment, the average weight is rounded to one decimal place, with the second decimal place being rounded off.

[0106] Priority level "2" is assigned to the following conditions: "The patient's weight at the last visit has decreased compared to the average weight over the past 7 days" and "The patient's last visit was not within the past 7 days." The condition is that the weight has "decreased," so if the weight at the last visit is the same as or exceeds the average weight over the past 7 days, this condition is not met. Also, if the last visit was within the past 7 days, this condition is not met.

[0107] Priority level "3" is assigned to "habit formation challenges that have been ongoing for 30 days or more, with an average habit formation rate of X% or higher." X is set in advance, but may be adjustable by a doctor or other healthcare professional. In this embodiment, the 30 days from the start refer to the 30 days up to yesterday. If 30 days prior is before the patient started using the app, the habit formation rate will be calculated based on the number of days from the start date of using the app to yesterday.

[0108] Incidentally, the habit formation challenge refers to the period during which the patient attempts to implement behavioral goals in "Step 2" and "Step 3" of the treatment plan. For example, behavioral goals for which the implementation rate during the period is X% or higher are considered to have been successfully formed into habits. In this embodiment, the average value of multiple implementation rates corresponding to multiple behavioral targets is compared with a threshold, and it is determined that the condition is met if the average value is equal to or greater than the threshold. In this embodiment, the average value of the implementation rate is rounded to the nearest digit after the number of digits to be displayed on the physician terminal 30 (see Figure 7).

[0109] Priority level "4" is assigned to "Y or more behavioral goals achieved in the past 30 days." Y is set in advance, but may be adjustable by a doctor or other healthcare professional. For example, achieving a behavioral goal could mean performing it for 20 days or more within the given period. Priority level "5" is assigned to "App launches performed at a rate of Z% or higher in the past 30 days." Z is pre-set, but may be adjustable by a doctor or other healthcare professional.

[0110] Message 232E is information that shows the user's progress and is displayed along with corresponding advice. Message 232E is an example of information that supports interaction with the user. Message 232E is an example of the first type of information that supports interaction with the user, based on improvements. Priority level "1" is assigned to "Target weight achieved!". Priority level "2" is assigned to "Weight has decreased (-XXkg) since the last visit!". XX is the amount of weight loss since the last visit. Priority level "3" is assigned to "Lifestyle improvements are progressing well!".

[0111] Priority level "4" is assigned to "Achieving more than YY of behavioral goals in one month." YY will be replaced with a specific numerical value. Priority level "5" is assigned to "Continuously using the app." As described above, message 232E displays only the facts corresponding to each condition. In this embodiment, message 232E is provided only in the dialogue support table 232 regarding points where the user's efforts are good. This is based on the idea that pointing out points where the patient's efforts are good is more suitable for conversation with the patient than pointing out points where there are challenges.

[0112] Advice Point 232F is a positive response to the user's efforts. It is an example of information that supports dialogue with the user. Depending on the conditions, Advice Point 232F may include content that praises the user, encourages continued efforts, or demonstrates the results of the efforts. Advice Point 232F is an example of the first type of information that supports dialogue with the user.

[0113] In Figure 9, priority "1" is assigned to "Let's continue to maintain this weight," and priority "2" is assigned to "You are losing weight little by little." Therefore, for users who meet the conditions of priority "1" or "2," both message 232E and advice point 232F are displayed on the consultation screen.

[0114] In Figure 9, the advice points 232F corresponding to priority levels "3," "4," and "5" are blank. Therefore, only message 232E is displayed on the consultation screen for users who meet the conditions for priority levels "3," "4," and "5." However, it is possible to prepare some kind of text for priority levels "3," "4," and "5" as well. Note that in Figure 9, one priority level is associated with one piece of content (or sentence), but it is also possible to associate multiple pieces of content (or sentences).

[0115] <For pointing out issues regarding the progress of the initiative> Figure 10 is a diagram illustrating an example of a dialogue support table 233. The dialogue support table 233 stores messages and advice used to point out areas where there are challenges in the progress of the initiative, categorized by condition. In other words, the dialogue support table 233 stores messages and advice that indicate challenges related to one or more management indicators determined according to the disease.

[0116] The dialogue support table 233 shown in Figure 10 consists of priority 233A, type 233B, "condition 1" 233C, "condition 2" 233D, message 233E, and advice point 233F. In Figure 10, priority 233A displays numbers from "1" to "5". "1" indicates the first priority, meaning "1" represents the highest priority. On the other hand, "5" indicates the fifth priority, meaning "5" represents the lowest priority. In Figure 10, for explanatory purposes, the number of conditions managed by priority is shown as five, but it could be seven, ten, fifteen, or even twenty. Of course, these numbers are just examples.

[0117] Type 233B displays the type of condition. For example, priority "1" is assigned to a condition related to launching the patient app (labeled "App Launch" in Figure 10). Priority "2" is assigned to a condition related to the weight measurement rate. Priority "3" is assigned to a condition related to the implementation record rate. Priority "4" is assigned to a condition related to behavioral goals. Priority "5" is assigned to a condition related to the weight loss rate. Note that the types of conditions are not limited to those exemplified.

[0118] "Condition 1" 233C is the first condition. In this embodiment, "Condition 1" 233C is assigned to the current step in the treatment plan. Priority levels "1" and "2" are assigned to "Step 1," "Step 2," and "Step 3," respectively. On the other hand, priority levels "3" and "5" are assigned to "Step 1" and "Step 2," respectively. Therefore, patients belonging to "Step 3" of the treatment plan will not be presented with messages corresponding to priority levels "3" and "5." Priority level "4" is assigned only to "Step 2." Therefore, patients belonging to "Step 1" and "Step 3" of the treatment plan will not be presented with messages corresponding to priority level "4."

[0119] "Condition 2" 233D is the second condition. In this embodiment, "Condition 2" 233D is assigned one or more conditions. Priority level "1" is assigned to "App launches performed at a rate of less than P% in the past 30 days." P is set in advance, but may be adjustable by a doctor or other healthcare professional. The past 30 days refers to the 30 days up to yesterday. If the 30 days prior was before the patient started using the app, the implementation rate will be calculated based on the number of days from the start date of app use to yesterday. The implementation rate will be rounded to the nearest whole number.

[0120] Priority level "2" is assigned to "Weight measurement performed at a rate of Q% or less in the past 30 days." Q is set in advance, but may be adjustable by a doctor or other healthcare professional. If 30 days prior to the start of patient app use is before the patient began using the app, the implementation rate will be calculated based on the number of days from the start date of patient app use to yesterday. The implementation rate will be rounded to the nearest whole number. Priority level "3" is assigned to "Implementation records are kept at R% or less over the past 30 days." R is set in advance, but may be adjustable by doctors or other medical professionals. If 30 days prior to the start of patient app use is before the patient started using the app, the implementation rate will be calculated based on the number of days from the start date of the patient app to yesterday. The implementation rate will be rounded to the nearest whole number.

[0121] Priority level "4" is assigned to "S or more failed behavioral goals in the past 30 days." S is set in advance, but may be adjustable by a doctor or other healthcare professional. Priority level "5" is assigned to "Average weight over the past 30 days is higher than the target weight" and "Average weight has increased when comparing the average weight over the past 30 days with the average weight over the past 31 to 60 days."

[0122] If 30 days prior to the start of patient app use is before the patient began using the app, the average weight will be calculated based on the number of days from the start date of patient app use to yesterday. The average weight will be rounded to one decimal place, with the second decimal place rounded off. Since the condition is "heavy," if your average weight over the past 30 days is below your target weight, this condition is not met. Also, even if your average weight over the past 30 days exceeds your target weight, if that average weight has not increased more than your average weight over the past 31 to 60 days, this condition is not met.

[0123] Message 233E is information that helps improve the user's progress and is displayed along with corresponding advice. Message 233E is an example of the second type of information that supports interaction with the user, tailored to the specific issue. However, all of the messages 233E shown in Figure 10 are blank. Therefore, even if issues are found regarding the progress of the initiative, a corresponding message 233E will not be presented.

[0124] Advice Point 233F provides support for improving the challenges in the user's progress. Advice Point 233F is an example of information that supports dialogue with the user. Advice Point 233F includes, for example, content to discuss with the user, content to confirm with the user, content to instruct the user on, content to suggest to the user, content to ask the user questions, content to advise the user on, content to interview the user on, content of unfulfilled goals, proposed solutions to the aforementioned challenges, hints for improving the aforementioned challenges, hints for the interview, points to note during the interview, and the user's current physical condition, depending on the corresponding conditions. Advice Point 232F is an example of the first type of information that supports dialogue with the user.

[0125] In Figure 10, priority level "1" is assigned to the following suggestion: "It is important to use the app every day. Discuss with the patient how they can ensure daily use of the app." The priority level "2" is assigned to: "The weight measurement rate is below QQ%. Please discuss with the patient what they can do to measure their weight every day." and "Continuing to measure your weight is the first step to weight loss. For those who tend to forget, placing the scale in a visible location or putting up a reminder can be effective." The priority level "3" is assigned to: "The rate of completion of implementation records is low. It is important to keep implementation records every day. Please discuss with the patient how to get them to keep implementation records every day," and "Implementation records are used to determine whether behavioral goals and habits have been established."

[0126] Priority level "4" is assigned to "It seems that the behavioral goals are not being achieved very well. Please discuss with the patient what can be done to achieve the goals," and "Behavioral goals that did not go well in the past month and proposed solutions." Incidentally, the solutions are assigned to "TT": TTTT, "UU": UUUU, and "VV": VVVV. The priority level "5" is assigned to "Check the patient's condition from the 'Recent Conditions' section, and ask the patient if there is anything that has been bothering them recently."

[0127] <Example of the display screen for medical consultation support> Figure 11 illustrates an example of the display of the medical consultation support screen 310. The medical consultation support screen 310 is displayed on the physician's terminal 30 (see Figure 1). The medical consultation support screen 310 shown in Figure 11 consists of a patient information field 311, an identification code field 312, a print button 313, a tab field 314, and a window screen 315. However, this does not exclude the inclusion of other information fields. For example, a field for "Things I was able to live consciously" could be included to display a record of the user's actions by category.

[0128] The patient information section 311 displays information about the patient being examined. The identification code field 312 displays the patient's identification code. The print button 313 is used to display the print settings screen. The tab bar 314 displays the tabs for switching between windows 315. In Figure 11, the tab bar 314 displays four tabs: "Dashboard," "Activity Status," "Implementation Record," and "Patient Information." The window 315 displays the information corresponding to the tab selected in the tab bar 314.

[0129] If "Progress" is selected, window screen 315 will display, for example, the goals the patient has achieved in the past month and the progress of their treatment plan. If "Implementation Record" is selected, window screen 315 will display, for example, a list of implementation records entered from the patient app. If "Patient Information" is selected, window screen 315 will display, for example, the patient's height, weight, BMI at the start of treatment, current target weight, prescription code, date the patient app was started, and the status of the scale's integration. In Figure 11, window screen 315 displays information corresponding to the "dashboard".

[0130] The window screen 315 shown in Figure 11 consists of a "Home-Measured Weight" column 320, a "Status for the Past Month" column 321, a "Recent Status" column 322, and a "Usage Status" column 323. The "Home-Measured Weight" section (320) displays the patient's most recent weight, the percentage of weight loss since the start of treatment, their BMI, and a graph showing the weight progression recorded through the patient's app. The progression graph shows the measured weight as a line graph and the target weight as a straight line.

[0131] The "Status for the past month" column 321 displays information detected by cross-referencing with the dialogue support table 232 (see Figure 4). In Figure 11, the "Status for the past month" column 321 consists of the "Message" column 321A, the "Advice Points" column 321B, and the "Previous 'Doctor's Advice'" column 321C. The "Message" field 321A displays the content read from message 232E (see Figure 9) of the dialogue support table 232. In Figure 11, it displays "You have achieved three or more behavioral goals in one month." In this embodiment, the "Message" field 321A is titled "Good" to indicate the improvements made.

[0132] The "Advice Points" column 321B also displays the content read from Advice Points 232F of Dialogue Support Table 232 (see Figure 9) and Advice Points 233F of Dialogue Support Table 233 (see Figure 10). However, the "Advice Points" column 321B shown in Figure 11 only displays content read from Advice Points 233F (see Figure 10) of the Dialogue Support Table 233. This is because the advice point 232F corresponding to the conditions met by the patient data is not registered in the dialogue support table 232. The "Advice from the Doctor" column 321C displays the advice recorded by the doctor or other medical professional during the previous consultation.

[0133] The "Recent Activities" section 322 displays, for example, the contents of the "Daily Reflection" recorded by the patient through the patient app, in chronological order. The "Usage Status" column 323 displays the patient's app usage status. In Figure 11, the patient app usage rate is displayed as "App Usage Rate 50%". The progress of the treatment plan is displayed as "Program Progress 75%". The behavioral retention rate, which is a management indicator, is displayed as "Behavioral Retention Rate 25%". The rate of patient-led monitoring is displayed as "Self-Monitoring Implementation Rate 99%". In addition, the "Usage Status" column 323 may display information such as "Weight Measurement Rate" and "Implementation Record Input Rate" in addition to or replacing some of the items exemplified above.

[0134] <Summary> When using the physician app 230 (see Figure 4) described in this embodiment, the consultation support screen 310 (see Figure 11) displayed on the physician terminal 30 displays information to support dialogue with patients who are using the patient app to treat or prevent their illness. Specifically, the "Status over the past month" section 321 (see Figure 11) displays messages 232E (see Figure 9) and advice points 233F (see Figure 10) indicating the patient's efforts in daily life.

[0135] The "Message" section 321A specifically outlines the numerical values ​​to be managed and the improvements in lifestyle habits. This allows doctors and other medical professionals to gain accurate insights into the patient's efforts and achievements, which may be difficult to discern simply by viewing the raw data recorded by the patient. Furthermore, the content shown in the "Message" section 321A can be used in dialogue with the patient.

[0136] Furthermore, the "Advice Points" section 321B displays specific advice tailored to the patient's progress. This allows doctors and other healthcare professionals to provide patients with appropriate advice based on their daily living activities. Prescribing patient apps allows doctors and other healthcare professionals to access information that patients have recorded in their daily lives. Conversely, the amount of information accessible to doctors and other healthcare professionals increases. However, by adopting the physician app 230 described in this embodiment, physicians and other medical professionals will be able to engage in appropriate conversations with each patient within the limited consultation time.

[0137] <Other Embodiments> (1) Although embodiments of the present disclosure have been described above, the technical scope of the present disclosure is not limited to the embodiments described above. It is clear from the claims that various modifications or improvements to the embodiments described above are also included in the technical scope of the present disclosure.

[0138] (2) The processing in the embodiments described above is performed on any computer. Any computer may be implemented as a processor as hardware, a program as software, or a combination thereof. Any computer may be a general-purpose computer, a computer for a specific purpose, a workstation, or any other system capable of performing each processing.

[0139] The processor is configured to perform various processes in cooperation with the program. The processor can function as each unit or each means in this embodiment. The execution order of the processes performed by the processor is not limited to the order described in this embodiment and can be changed as needed.

[0140] A processor can be configured with one or more hardware components. The types of hardware that make up a processor are not limited to any particular type. For example, a processor may be a CPU (=Central Processing Unit), an MPU (=Micro Processing Unit), a programmable logic device such as an FPGA (=Field Programmable Gate Array), a dedicated circuit for performing specific processing such as an ASIC (=Application Specific Integrated Circuit), a GPU (=Graphic Processing Unit), or hardware such as an NPU (=Neural Processing Unit).

[0141] A processor can be configured not only with a combination of multiple hardware components of the same type, but also with a combination of multiple hardware components of different types. When multiple hardware components are configured to perform one or more processes of a given processor, these components may reside in physically separate devices or in the same device. Hardware is composed of electrical circuits and other components, such as semiconductor elements.

[0142] In any of the embodiments, the execution order of each process by the processor is not limited to the order described in each embodiment, and can be changed as necessary. The program can be firmware, or it can be software such as microcode. The program may be, for example, a group of program modules. Each function constituting the group of program modules may be implemented by a processor configured to execute each function.

[0143] The program in each embodiment may be program code or multiple code segments stored in one or more non-temporary computer-readable media (e.g., semiconductor memory, magnetic or optical storage media, or other storage). The program may be divided and stored on multiple non-temporary computer-readable media located on devices that are physically separated from each other.

[0144] Program code and multiple code segments can be represented by any combination of procedures, functions, subprograms, routines, subroutines, modules, software packages, classes, instructions, data structures, and program statements. Program code or multiple code segments may be connected to other code segments or hardware circuits by sending and receiving information, data, arguments, parameters, or memory contents.

[0145] (3) In the embodiment described above, the "Advice Points" column 321B (see Figure 11) displays only the contents of the advice points 233F (see Figure 10) of the dialogue support table 233 (see Figure 10). However, the "Advice Points" column 321B may only display advice point 232F (see Figure 9) from the dialogue support table 232 (see Figure 9).

[0146] Furthermore, the "Advice Points" column 321B may display both Advice Points 232F (see Figure 9) from Dialogue Support Table 232 (see Figure 9) and Advice Points 233F (see Figure 10) from Dialogue Support Table 233 (see Figure 10). Figure 12 illustrates another example of how to display the "Status for the past month" column 321. Figure 12 is denoted with corresponding symbols for parts that correspond to those in Figure 11. In the case of Figure 12, the patient's engagement corresponds to priority "2" in Dialogue Support Table 232 and priority "2" in Dialogue Support Table 233.

[0147] Therefore, the "Advice Points" column 321B displays "You are losing weight little by little," which was read from the dialogue support table 232, and "Your weight measurement rate is less than 50%. Please talk to the patient about what they can do to measure their weight every day. Continuing to measure your weight is the first step to weight loss. For those who tend to forget, placing the scale in a visible location or putting up a reminder can be effective." In this way, by displaying both advice on areas for improvement and advice on areas for improvement, doctors and other medical professionals can communicate not only affirmative feedback on the patient's efforts but also support for addressing areas for improvement.

[0148] (4) In the embodiment described above, all of the messages 233E (see Figure 10) in the dialogue support table 233 (see Figure 10) are blank. Therefore, the "Message" column 321A of the "Status for the last month" column 321 (see Figure 11) does not display any messages corresponding to the dialogue support table 233. However, the "Message" field 321A may display both messages indicating improvements and messages indicating issues.

[0149] Figure 13 illustrates another example of how to display the "Status for the past month" column 321. Figure 13 is denoted with corresponding symbols for parts that correspond to those in Figure 11. In Figure 13, the "Message" column 321A has the titles "Good" and "Not Good". The message corresponding to the title "Good" is read from dialogue support table 232 (see Figure 9). On the other hand, the message corresponding to the title "Not Good" is read from dialogue support table 233 (see Figure 10).

[0150] Therefore, in Figure 13, "Weight loss is progressing well" is displayed when "Good" is selected, and "It seems that exercise has not become a regular habit" is displayed when "Not Good" is selected. In this way, by presenting not only messages of improvement but also messages of challenges simultaneously, doctors and other healthcare professionals can become aware of the challenges in the patient's efforts. As a result, they can select content in their conversations with patients that is appropriate to the patient's current level of engagement.

[0151] (5) In the above embodiment, conditions that the patient data satisfies are detected in order of priority, and messages and advice corresponding to the detected conditions are displayed on the examination support screen 310 (see Figure 11). However, the messages and advice displayed on the consultation support screen 310 may be determined by other processing methods. For example, the system may detect all conditions that the patient data satisfies and display a message and advice corresponding to the highest-priority condition among those detected on the consultation support screen 310.

[0152] (6) In the above embodiment, the message and advice corresponding to the highest priority condition among the conditions that the patient data satisfies are displayed on the examination support screen 310. However, messages and advice corresponding to multiple conditions that the patient data satisfies may be displayed on the consultation support screen 310. For example, in addition to the message and advice corresponding to the highest priority condition among the multiple conditions that the patient data satisfies, messages and advice corresponding to the second highest priority condition may also be displayed on the consultation support screen 310.

[0153] (7) In the above-described embodiment, the messages and advice to be displayed on the examination support screen 310 are identified in accordance with a predetermined priority order. However, the messages and advice to be displayed on the consultation support screen 310 may be determined based on the priority relationships between predetermined conditions. Here, priority relationships refer to relationships such as, for example, that condition A takes precedence over condition B, and that condition B takes precedence over condition C. Furthermore, these priority relationships may be defined as relationships between multiple messages. Similarly, priority relationships may be defined as relationships between multiple advice.

[0154] (8) In the above-described embodiment, the dialogue support table 232 (see Figure 9) and the dialogue support table 233 (see Figure 10) are used to identify the messages and advice to be displayed on the examination support screen 310. However, the messages and advice to be displayed on the examination support screen 310 (see Figure 11) may be determined by conditional branching or referencing branching rules through program processing.

[0155] (9) In the above-described embodiment, the dialogue support table 232 (see Figure 9) and the dialogue support table 233 (see Figure 10) are used to identify the messages and advice to be displayed on the examination support screen 310. However, a pre-trained model that has learned the correspondence between patient data and messages may be used to identify the messages and advice to be displayed on the consultation support screen 310. Figure 14 illustrates another hardware configuration example for the PDT server 20. Figure 14 uses corresponding reference numerals to indicate parts that correspond to those in Figure 4. In the auxiliary storage device 23 of the PDT server 20 shown in Figure 14, a trained model 234 is stored instead of the dialogue support tables 232 and 233.

[0156] Figure 15 illustrates an example of the input-output relationship of the trained model 234. The trained model 234A shown in Figure 15 has learned the relationship between improvement messages, improvement advice points, and problem advice points when patient data is given as input. Therefore, when patient data is input to this trained model 234A, the same display as the examination support screen 310 (see Figure 11) becomes possible. Note that the relationships to be learned may also include problem messages, and problem messages may be output as part of the output.

[0157] Figure 16 illustrates another example of the input-output relationship of the trained model 234. The trained model 234 shown in Figure 16 consists of trained model 234B and trained model 234C. The trained model 234B shown in Figure 16 has learned the relationship between areas for improvement and areas for improvement when patient data is given as input.

[0158] Furthermore, the trained model 234C shown in Figure 16 has learned the relationship between the improvement message output when improvement points and problem points are given as input, the advice points for improvement points, and the advice points for problem points. Furthermore, the relationships learned by the pre-trained model 234C may include patient attributes. Even if the areas for improvement or issues are the same, differences in patient attributes may result in differences in the expression and content of the output messages and advice points.

[0159] (10) In the above-described embodiment, a patient application for NASH was explained. However, the patient app can be a patient app for other diseases, or even a non-patient app. Incidentally, the other diseases can be lifestyle-related diseases or non-lifestyle-related diseases. Lifestyle-related diseases include, for example, hypertension, alcoholism, dyslipidemia, chronic heart failure, hyperuricemia, diabetes, kidney disease, nicotine addiction, chronic bronchitis, cancer, periodontal disease, attention deficit hyperactivity disorder, depression, tinnitus, delayed grief disorder, opioid-induced constipation, post-mastectomy pain syndrome, nephrotic syndrome, and insomnia. Examples of non-lifestyle-related diseases include headaches and irritable bowel syndrome.

[0160] (11) In the embodiments described above, the case in which the user using the application for recording health data is a patient was described. That is, the patient terminal 40 (see Figure 1) was assumed to be a terminal on which a program that presents the user's status regarding management indicators from data recorded by a user who is working to treat or prevent a disease is installed. However, the app that users who are working to treat or prevent diseases use to record health-related data can be any user app, including so-called healthcare apps. In this case, any user application will have a function to display the user's status regarding management metrics. Any user application could be a diary application, an image application, or an audio application.

[0161] (12) In the above-described embodiment, the case in which patient application data 231C (see Figure 5) is input from the patient terminal 40 (see Figure 1) was described. That is, the case in which the patient application is installed on the patient terminal 40 was described. However, the patient app may run on the PDT server 20. That is, the patient may use a cloud service to record their health data.

[0162] (13) In the above-described embodiment, patient data 231 (see Figure 4) is assumed to be patient application data 231C (see Figure 5) input from the patient terminal 40 (see Figure 1). However, patient data 231 may also include data input through the physician terminal 30 (see Figure 1). For example, it may include advice given to the patient by a physician, or information obtained from the patient during a medical examination or interview.

[0163] (14) In the above embodiment, it is assumed that at least one condition that the patient data satisfies is detected from at least one of the dialogue support table 232 (see Figure 9) and the dialogue support table 233 (see Figure 10). For this reason, if no conditions that the patient data satisfies are found, the "Message" column 321A and the "Advice Points" column 321B of the "Status for the last month" column 321 (see Figure 11) will be left blank. However, even if no conditions are found in the patient data, some kind of message or advice may be displayed in at least one of the "Message" field 321A and the "Advice Points" field 321B in the "Status for the Past Month" field 321 (see Figure 11).

[0164] <Summary> An example of the disclosure described in the above-mentioned embodiment is shown below. (((1))) An information processing device having a processor, the processor acquires health data recorded by a user who is working to treat or prevent a disease, identifies information to support interaction with the user based on the acquired data, and presents the identified information to a terminal operated by a healthcare professional. This information processing device can support interaction with users who are working to treat or prevent diseases using application programs.

[0165] (((2))) The information processing device described in (((1))) is a processor that presents, as information, at least one of the following: content that affirms the user's progress and content that supports the improvement of the challenges in the user's progress. According to this information processing device, the content of support can be set according to the progress of the project.

[0166] (((3))) The information processing device described in (((2))) is a processor that presents at least one of the following as affirmative content regarding the user's efforts: content praising the user, content encouraging the continuation of the efforts, or content showing the results of the efforts. This information processing device can present specific content that affirms the user's efforts.

[0167] ((((4))) The processor is an information processing device as described in (((2))) that presents at least one of the following as supporting the improvement of a problem: content to consult with the user, content to confirm with the user, content to instruct the user, content to suggest to the user, content to ask the user, content to advise the user, content to hear from the user, content of unfulfilled goals, proposed solutions to the problem, hints for improving the problem, hints for the medical interview, points to note during the medical interview, and the current state of the user's physical condition. This information processing device can present specific content to support the improvement of the user's progress and address any challenges.

[0168] (((5))) The information processing device according to any one of (((1))) to (((4))), wherein the processor detects at least one of a predetermined improvement and a predetermined problem appearing in the data, and identifies at least one of one of a predetermined improvement corresponding to the detected predetermined improvement and one of a predetermined problem corresponding to a predetermined problem. This information processing device can identify information that supports interaction with the user in accordance with at least one of a predetermined improvement and a predetermined problem.

[0169] (((6))) The information processing apparatus according to any one of (((1))) to (((5))), wherein the processor detects predetermined improvements and predetermined problems appearing in the data, and identifies one or more pieces of information according to the combination of the detected predetermined improvements and predetermined problems. This information processing device can identify information that supports interaction with the user in accordance with a combination of predetermined improvements and predetermined challenges.

[0170] (((7))) The information processing device according to (((5))) or (((6))), wherein the processor detects a predetermined improvement or a predetermined problem based on one or more indicators determined according to the disease. This information processing device can detect specific improvements and challenges related to indicators specific to a disease.

[0171] (((8))) When there are multiple candidates for the information to be presented, the processor identifies one or more pieces of information based on a predetermined priority or priority relationship, as described in any one of (((1))) to (((7))). This information processing device can identify which information to present even when there are multiple candidates for information that can support interaction with the user.

[0172] (((9))) The information processing device described in any one of (((1))) to (((8))) is an information processing device that uses a trained model that has learned the correspondence between data and information to present information corresponding to the data to the terminal. According to this information processing device, information that supports interaction with the user can be identified by utilizing a pre-trained model.

[0173] (((10))) The processor is an information processing device described in any one of (((1))) to (((9))) that presents information as well as the user's progress in responding to that information. This information processing device can display to medical professionals the status of efforts corresponding to the information supporting the presented dialogue.

[0174] (((11))) The information processing device described in (((10))) when the processor presents information that affirms the user's progress and information that supports the improvement of the issues in the user's progress, presents the user's progress corresponding to the affirmative content of the user's progress, but does not present the user's progress corresponding to the information that supports the improvement of the issues in the user's progress. This information processing device can present healthcare professionals with information that affirms the user's progress.

[0175] (((12))) An information provision method in which a computer performs the following processes: acquiring health data recorded by a user who is working to treat or prevent a disease; identifying information that supports interaction with the user based on the acquired data; and presenting the identified information to a terminal operated by a healthcare professional. This information delivery method allows for support in interacting with users who are using application programs to treat or prevent diseases.

[0176] (((13))) A program for a computer that enables the acquisition of health data recorded by users working to treat or prevent diseases, the identification of information to support interaction with the user based on the acquired data, and the presentation of the identified information to a terminal operated by a healthcare professional. This program allows for support in interacting with users who are using application programs to treat or prevent diseases. [Explanation of symbols]

[0177] 1…Information processing system, 10…PDT platform, 20, 20A, 20B, 20C, 20D, 20E, 20F…PDT server, 30…Physician terminal, 40…Patient terminal, 130…Status management app, 131…Status management data, 230…Physician app, 231…Patient data, 232, 233…Dialogue support table, 234…Trained model

Claims

1. It has a processor, The aforementioned processor, The system acquires health data recorded by users who are working to treat or prevent a disease, identifies information to support interaction with the user based on the acquired data, and presents the identified information on a terminal operated by a healthcare professional. Information processing device.

2. The processor presents, as information, at least one of the following: content that affirms the user's progress and content that supports the improvement of the issues in the user's progress. The information processing apparatus according to claim 1.

3. The processor presents at least one of the following as affirmative content regarding the user's efforts: content praising the user, content encouraging the continuation of the efforts, and content demonstrating the results of the efforts. The information processing apparatus according to claim 2.

4. The processor presents, as content to support the improvement of the problem, at least one of the following: content to consult with the user, content to confirm with the user, content to instruct the user, content to propose to the user, content to ask the user, content to advise the user, content to interview the user, content of unfulfilled goals, proposed solutions to the problem, hints for improving the problem, hints for the interview, points to note during the interview, and the user's current physical condition. The information processing apparatus according to claim 2.

5. The processor detects at least one of a predetermined improvement and a predetermined problem appearing in the data, and identifies at least one of one of the first pieces of information corresponding to the detected predetermined improvement and one of the second pieces of information corresponding to the predetermined problem. The information processing apparatus according to claim 1.

6. The processor detects predetermined improvements and predetermined problems appearing in the data, and identifies one or more pieces of information according to the detected combination of predetermined improvements and predetermined problems. The information processing apparatus according to claim 1.

7. The processor detects the predetermined improvement or the predetermined problem based on one or more indicators determined according to the disease. The information processing apparatus according to claim 5 or 6.

8. If there are multiple candidates for the information to be presented, the processor identifies one or more of the information based on a predetermined priority or priority relationship. The information processing apparatus according to claim 1.

9. The processor uses a trained model that has learned the correspondence between the data and the information to present the information corresponding to the data to the terminal. The information processing apparatus according to claim 1.

10. In addition to the information, the processor presents the user's progress corresponding to the information. The information processing apparatus according to claim 1.

11. When the processor presents both information that affirms the user's progress and information that supports the improvement of issues in the user's progress, it presents the user's progress corresponding to the information that affirms the user's progress, but does not present the user's progress corresponding to the information that supports the improvement of issues in the user's progress. The information processing apparatus according to claim 10.

12. Computers The process of acquiring health data recorded by users who are working to treat or prevent a disease, A process to identify information that supports interaction with the user based on the acquired data, The process of presenting the identified information to a terminal operated by a medical professional, A method for providing information to carry out the task.

13. On the computer, A function to acquire health data recorded by users who are working to treat or prevent diseases, A function to identify information that supports interaction with the user based on the acquired data, A function to display the identified information on a terminal operated by a medical professional, A program to achieve this.

Images