Information processing device, information provision method, and program

Abstract

This system provides a mechanism to support the selective review of arrangements made during one or more consultation sessions. [Solution] An information processing device having a processor, the processor accepts user operations to record health-related data and presents the user with arrangements for one or more consultation sessions selected by the user from among multiple consultation sessions.

Description

Technical Field

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

Background Art

[0002] As a means for supporting the improvement of lifestyle habits, the use of application programs executed on user terminals has attracted attention. Currently, various application programs for supporting the improvement of lifestyle habits are publicly available in the app store.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Some application programs have a screen that presents the user with the ability to confirm the current goals and the like. However, the user himself / herself cannot review the decisions made in previous medical examinations.

[0005] This disclosure provides a mechanism to support the selective review of arrangements during one or more consultation sessions. [Means for solving the problem]

[0006] The invention described in claim 1 is an information processing device having a processor, the processor receiving user operations for recording health-related data, and presenting the user with arrangements for one or more consultation sessions selected by the user from among a plurality of consultation sessions. The invention described in claim 2 is the information processing device described in claim 1, wherein the arrangement relates to an index managed by a program used for recording the data. The invention described in claim 3 is an information processing device according to claim 1, wherein the processor presents a list of arrangements for multiple consultation days. The invention described in claim 4 is the information processing device described in claim 1, wherein the arrangement is set through a terminal operated by a medical professional. The invention described in claim 5 is the information processing device described in claim 1, wherein the arrangement is set through a terminal operated by the user. The invention described in claim 6 is the information processing apparatus according to claim 1, wherein the processor provides advice to the user in relation to the arrangement. The invention described in claim 7 is an information processing device according to claim 1, wherein the processor proposes to the user a change to the arrangement currently being worked on if the health data recorded during a corresponding period satisfies a predetermined relationship. The invention described in claim 8 is an information provision method in which a computer performs the following processes: receiving user input to record health-related data; and presenting the user with arrangements for one or more consultation sessions selected by the user from among a plurality of consultation sessions. The invention described in claim 9 is a program for a computer that provides a function to accept user input for recording health-related data, and a function to present to the user arrangements for one or more consultation sessions selected by the user from among multiple consultation sessions. [Effects of the Invention]

[0007] One form of this disclosure can provide a mechanism to support the selective review of arrangements during one or more consultation sessions. [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] This diagram illustrates an example hardware configuration for a PDT server. [Figure 5] This diagram illustrates an example of patient data stored in the auxiliary storage device of a PDT server. [Figure 6] This diagram illustrates an example of the hardware configuration for a physician's terminal and a patient's terminal. [Figure 7] This figure illustrates an example of a processing sequence in the embodiment. [Figure 8] This diagram illustrates an example of the transitions in the consultation review screen. [Figure 9] This diagram further illustrates the example of transitions on the consultation review screen. [Figure 10] This is a diagram illustrating an example of how to display information in a medical record book. [Figure 11] This is a diagram illustrating an example of how to display information in a medical record book. [Figure 12] This is a flowchart explaining the function for suggesting changes to agreements. [Figure 13] This diagram illustrates an example of the output of a screen that proposes a change to the agreement. [Figure 14] This diagram illustrates an example sequence of operations that describes the processing when arrangements for consultations are set through a patient app. [Figure 15]This is a diagram for explaining an example of a sequence for the display processing operation of the agreement at the time of examination by the cooperation between the PDT server and the patient terminal. [Figure 16] This is a diagram for explaining an example of the display of the target of an arbitrary examination session selected by the patient.

Embodiments for Carrying Out the Invention

[0009] <Terms> First, the terms used in the embodiments described below will be explained. The "program for promoting behavior change" refers to a program provided with the intention of promoting the change of human behavior. However, this program does not guarantee the change of human behavior. Whether a person's behavior actually changes depends on the user who uses the program. Therefore, the program for promoting behavior change can also be said to be a program for assisting behavior change.

[0010] This type of program includes a program positioned in a medical device and a program positioned in a non-medical device. The program positioned in a medical device is an example of a program that requires a prescription, and the program positioned in a non-medical device is an example of a program that does not require a prescription. Note that the program positioned in a non-medical device is not limited to a program for promoting behavior change, and may also be a program having a function of recording health-related data. The program for promoting behavior change and the program having a function of recording health-related data include, in addition to the program that can be downloaded from the app store, programs used by private businesses, public organizations, etc. for the health management of employees, etc. The program positioned in a non-medical device also includes a program used in a medical institution.

[0011] The "purpose of the app" refers to the effect to be realized by using the program for promoting behavior change. The purpose of the app differs depending on the disease corresponding to the program for promoting behavior change. For example, the purposes of the app include improvement of lifestyle, continuation of the improved lifestyle, and continuation of the improved numerical values.

[0012] "App goals" refer to the objectives that are aimed for by using a program that encourages behavioral change. Goals are defined from the perspective of achieving the objective. Goals are classified into qualitative and quantitative indicators. Furthermore, goals are 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.

[0013] A "therapeutic app" refers to a program that has received approval under the Pharmaceuticals and Medical Devices Act. A therapeutic app is classified as a medical device. 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.

[0014] A "user" refers to a person who uses a program that has the function of recording health-related data. A person who changes their behavior through the aforementioned behavioral change-promoting program is an example of a user. Users include both users before visiting a medical institution and users who have visited a medical institution. Users who have visited a medical institution include both users who are eligible for medical fee calculation and users who are not eligible for medical fee calculation. "Patient" refers to a user who is receiving treatment at a medical institution. In other words, a patient is a user who has started or is currently receiving treatment at a medical institution.

[0015] 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").

[0016] 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 permissible to set an expiration date even for programs classified as non-medical devices.

[0017] A "doctor app" refers to a program that can be used through a terminal operated by a doctor or other healthcare professional (hereinafter also referred to as a "doctor terminal"). In the embodiment described later, the doctor app runs on a cloud server that can be operated from the doctor terminal. The doctor app is used to view patient data (including patient app data). Healthcare professionals are also referred to as medical personnel.

[0018] "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, and goal achievement status. However, the information recorded as patient data varies depending on the disease, and it does not need to include all of the information exemplified; 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.

[0019] "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, if the disease is hypertension, blood pressure values ​​will be recorded as measured values. Blood pressure values ​​are defined, for example, as 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, the measured values ​​would be carbon monoxide (CO) in exhaled breath and nicotine concentration in saliva.

[0020] "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 also serve as examples of reference diaries. Furthermore, quantitative information from these records is an example of an indicator managed within a patient app.

[0021] "Medical history" includes, for example, the start date of treatment, the date of the consultation, the content of the treatment, agreements between the doctor and the patient, and advice given by the doctor to the patient. Medical history is just one example of information related to a medical consultation. "Patient app operation history" refers to, for example, the history of operations related to launching the patient app, inputting measurement values ​​and reflections, etc. "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.

[0022] "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.

[0023] "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. "Goal achievement status" refers to information indicating the progress toward goals set by a doctor for each patient. It could also refer to the progress toward goals set by the patient themselves. Furthermore, it could refer to the progress toward goals presented by a patient app for each patient. Furthermore, the information mentioned above can be classified into subjective information and objective information.

[0024] 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 may include personal information. Health-related data may include data recorded through programs that encourage behavioral change, as well as data obtained by processing such data.

[0025] The processed data includes, for example, processed data, data obtained through statistical processing, and summaries of patient data generated by artificial intelligence (AI). The processed data may also include, for example, the mean, the maximum and minimum values ​​within a given period, the data distribution for each given period, and the difference from the baseline. Health-related data may include data related to programs other than those that have the functionality to record health data or programs that encourage behavioral change. For example, it may include user accounts used to access various services and privacy-related information.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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."

[0030] "Before use begins" refers to a state where the prescription for the patient app has been processed, but the patient has not yet started using it on their device. For example, it refers to a state where the patient has not yet entered the prescription code into their device. "Expired start date" refers to a situation where the prescription code was not entered within the period during which the prescription code is valid (for example, within 4 days including the prescription date).

[0031] "In Use" refers to the state where the patient app installed on the patient's device has been activated and is available for use. Note that activating the patient app requires entering an activation code, such as the prescription code mentioned above. "Scheduled to end" refers to a state in which a medical institution has designated a patient as no longer subject to management within the validity period. For example, this state is set for patients who do not receive follow-up appointments.

[0032] "Termination" refers to a state where the patient app becomes unusable, for example, due to the expiration of its validity period. "Expiration of the period" indicates that a specified period has elapsed since the prescription date. The specified period is set to be longer than the validity period. For example, if the validity period is 6 months, the specified period is set to 8 months. "Selective Medical Treatment" is displayed when the validity period has expired but the treatment is still eligible for selective medical treatment. Selective medical treatment refers to a medical service that allows patients enrolled in social insurance to receive treatment not covered by insurance in conjunction with treatment covered by insurance, by bearing the additional cost.

[0033] 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.

[0034] 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 "physicians, etc.") to issue prescription codes, then the term "healthcare institution" will also include facilities and organizations where these healthcare professionals are located.

[0035] 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.

[0036] <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.

[0037] 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 cooperate to provide the services of the PDT platform 10. 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.).

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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. The patient terminal 40 is an example of a user terminal. The patient terminal 40 is also an example of an information processing device. The patient terminal 40 may be, for example, a smartphone, smart glasses, a desktop computer, a laptop computer, or a tablet computer.

[0044] <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.

[0045] 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 information such as UEFI (Unified Extensible Firmware Interface). 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.

[0046] The auxiliary storage device 13 is composed of, for example, a hard disk drive or a semiconductor storage. The auxiliary storage device 13 stores an operating system and other programs. The other programs include, for example, a program for listing the usage status of the patient app. In addition, the auxiliary storage device 13 also stores data for managing the status management data 130 by prescription code prescribed by a medical institution. 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 is compatible with communication standards such as Ethernet (registered trademark), Wi-Fi (registered trademark), and mobile communication systems.

[0047] <Management data of the PDT platform> FIG. 3 is a diagram for explaining an example of the status management data 130 stored in the auxiliary storage device 13 (see FIG. 2) of the PDT platform 10 (see FIG. 1). The status management data 130 shown in FIG. 3 stores a prescription code 130A, a patient ID / patient name 130B, a prescription date / consultation date 130C, a medical institution ID / prescriber ID 130D, a patient app name 130E, and a usage status 130F. 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 number, and version of the patient app may be stored.

[0048] The prescription code 130A is issued every time a prescription is notified from the doctor terminal 30 (see FIG. 1). [[ID=十七]] The patient ID / patient name 130B is the patient ID and patient name registered at the time of prescribing the patient app. In the case of FIG. 3, the patient name of patient ID "12543" is "Mr. A", the patient name of patient ID "12544" is "Mr.B", and the patient name of patient ID "12545" is "Mr.C".

[0049] The prescription date / consultation date 130C 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 / 2 / 24". The Medical Institution ID / Prescriber ID 130D 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.

[0050] Patient app name 130E 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. Patient C is prescribed patient app D. Usage status 130F 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.

[0051] <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.

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

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

[0054] In addition, the patient data 230 recorded through the patient app is also recorded in the auxiliary storage device 23. The communication interface 24 is an interface for communicating with external terminals such as the PDT platform 10 through a network. The communication interface 24 is compatible with communication standards such as Ethernet (registered trademark), Wi-Fi (registered trademark), and mobile communication systems.

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

[0056] In the case of this embodiment, the patient app data 230C means the management data of the patient app and the data recorded by the user through the patient app. Prescription code 230A records prescription code 130A (see Figure 3) issued by the PDT platform 10 (see Figure 1). Prescription code 130A 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 230B 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.

[0057] The patient app data 230C shown in Figure 5 includes measurement values / measurement date and time 230C1, reflection / input date and time 230C2, current step of the treatment program 230C3, treatment program implementation history 230C4, behavioral goals 230C5, target values ​​230C6, agreements made during consultations 230C7, and medication records 230C8. Note that the items exemplified do not need to be all of the patient app data 230C; they may be only a part of it, or other items may be included.

[0058] The measurement / measurement date and time field 230C1 records the health-related values ​​and date and time measured by the patient. For example, in a patient app for hypertension, the measured blood pressure value and the date and time the blood pressure was measured are recorded. The blood pressure value is given as systolic blood pressure and diastolic blood pressure. The "Reflection / Input Date & Time 230C2" field records a reflection on the day's activities along with the input date and time. The review process records things like physical condition level, stress level, sleep duration, weight, alcohol consumption, activities undertaken, and a diary (user's thoughts on the day's activities, etc.). For example, sleep duration, weight, and alcohol consumption are examples of results recorded as health-related data.

[0059] The content of the actions consists of the genre of the action that was performed and text input. Incidentally, other possible labels include, for example, "sleep," "stress," "moderate alcohol consumption," and "other." In this embodiment, the genre of the action that was performed is recorded by checking buttons labeled with "salt reduction," "weight loss," "exercise," etc. Text input allows users to freely enter content, emotions, etc., that cannot be recorded by checking buttons.

[0060] The current step 230C3 of the treatment program records the steps indicating the progress of the treatment program provided by the patient app. In this embodiment, the treatment program consists of three steps. These three steps consist of, for example, "acquiring knowledge," "implementing behavioral goals," and "habituating behavior." The treatment program implementation history 230C4 records the history of learning and behavior practiced in accordance with the treatment program. For example, in the case of a patient app for hypertension, "Step 1" records the learning history, including whether or not each learning item has been completed. "Step 2" records the behavior history, including the progress towards goals such as "salt reduction," "weight loss," "exercise," "sleep," "stress," "alcohol consumption," and "smoking cessation." "Step 3" records the progress towards behaviors set as goals by the patient.

[0061] Behavioral objective 230C5 records the behaviors that the patient has set as goals. These goals include one or more behavioral objectives selected by the patient from among the goals presented by the patient app as the treatment program progresses. For example, behavioral objective 230C5 records the behavioral objective set by the patient in step 2 or 3 of the treatment program. A behavioral objective refers to the action that must be taken in order to achieve the target. Furthermore, behavioral goals are not limited to those selected from the behaviors presented by the patient app; they may also include behaviors set individually by the patient.

[0062] The target value 230C6 is recorded as the value set by the doctor or other medical professional during the examination. Examples of quantitative targets include blood pressure target values, daily alcohol intake, number of alcohol-free days, and body weight, all of which are given numerically. The agreement made during the consultation (230C7) records the agreement with the doctor, the doctor's advice, the date of the next consultation, the timing of medication, etc. Incidentally, the agreement with the doctor also serves as the goal until the next consultation. Appointments with doctors and other healthcare professionals include records of promises regarding either actions to be taken or outcomes to be achieved before the next appointment, or both. These actions and outcomes will vary depending on the patient's illness. The actions and outcomes described here are just examples of indicators managed within the patient app.

[0063] For example, in the case of a patient with alcohol dependence, both the "behavior" and the "outcome" of the agreement are related to the amount of alcohol consumed. Incidentally, the amount of alcohol consumed as a behavior could be, for example, the amount of alcohol consumed in one instance or per day, or the average amount of alcohol consumed over a week. On the other hand, the amount of alcohol consumed as an outcome is the amount of alcohol actually consumed. For example, in the case of a patient with hypertension, the "behaviors" that are the subject of the promise include reducing salt intake, exercising, getting enough sleep, moderate alcohol consumption, and quitting smoking. On the other hand, the "outcomes" that are the subject of the promise are blood pressure levels and weight. Agreements made during consultations can only be recorded through the doctor's app. In other words, agreements made during consultations can only be set through the doctor's terminal 30 (see Figure 1). Medication record 230C8 contains information about the taking of prescribed medications.

[0064] <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.

[0065] The processors 31 / 41 are devices that perform various functions through program execution. The processors 31 / 41 may consist 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 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.

[0066] 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) and a client certificate for accessing the PDT server 20 (see Figure 1). In the case of the patient terminal 40, the auxiliary storage device 43 stores a client certificate for accessing the PDT server 20 (see Figure 1). The auxiliary storage device 43 also stores the patient application and the patient application data 230C (see Figure 5) recorded through the program.

[0067] 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. 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.

[0068] <Processing Sequence> Figure 7 illustrates an example of a processing sequence in an embodiment. The processing sequence shown in Figure 7 corresponds to the period between one examination and the next. The symbol S in Figure 7 represents a step. The explanation of the processing sequence shown in Figure 7 assumes a case where a patient with alcohol dependence is being examined.

[0069] <Before consultation> <Step 101> The patient, following the instructions on the patient app's interface, inputs information such as their daily alcohol intake, daily reflections, behavioral goals, target values, agreements made during consultations, and medication records. The patient terminal 40 records the input information as patient app data. As mentioned above, the patient app data may also include data processed from this data. Incidentally, the processing of the patient app data is performed by the patient app.

[0070] <Step 102> At predetermined times, the patient terminal 40 uploads patient application data. One predetermined time is when new data is recorded or updated. This upload is performed when the patient application remains logged into the PDT server 20. Another predetermined time is when the patient logs into the PDT server 20. This upload is performed when the patient application is logged out of the PDT server 20 and then logs back into the PDT server 20.

[0071] <Step 103> The PDT server 20 stores the uploaded patient application data. This patient application data constitutes a part of the patient data 230 (see Figure 5). Steps 101 to 103, shown in Figure 7, are executed in response to the patient's input of measurement values ​​and other information into the patient application.

[0072] <When visiting the doctor> Steps 104 to 109, shown in Figure 7, are performed as a result of the patient visiting a medical institution. <Step 104> When a physician logs into the PDT platform 10 via the physician terminal 30, the PDT platform 10 displays a screen to the physician terminal 30 showing the usage status of patient applications. This screen displays a list of the usage statuses of patient applications prescribed to patients by the physician operating the physician terminal 30. However, the management screen may also display a list of the usage statuses of patient applications prescribed by the medical institution to which the physician operating the physician terminal 30 belongs. In other words, the management screen may include the usage statuses of patient applications prescribed by other physicians belonging to the same medical institution.

[0073] In addition, the management screen may display the usage status of patient apps prescribed by other doctors or 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 with information that identifies the patient being treated (e.g., medical record number or patient name).

[0074] Furthermore, technically, it is possible to include information on all patients managed by the PDT platform 10 in the management screen. 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. If multiple patient apps are prescribed to a single patient, the usage status will be displayed for each patient app. For example, if patient "Patient A" is prescribed patient app A and patient app B, the management screen will display the usage status for each patient app. For instance, patient app A will be displayed as "In Use," and patient app B as "Not Yet Started."

[0075] <Step 105> The physician terminal 30 accepts patient selection on the aforementioned management screen. Note that patient selection also includes the selection of the patient application associated with that patient. Upon receiving the selection operation, the physician terminal 30 accesses the PDT server 20 of the patient app prescribed to the selected patient. Furthermore, physicians and other medical professionals are assumed to be logged in to the PDT server 20 via the physician terminal 30. This access also includes information such as the prescription code issued when a prescription is issued via the patient app.

[0076] 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.

[0077] <Step 106> Upon receiving notification of patient selection from the physician's terminal 30, the PDT server 20 outputs a consultation support screen. In this embodiment, the PDT server 20 outputs a consultation support screen specifically for the patient being examined, based on the patient data. The consultation support screen is prepared for each disease. For example, in the case of alcohol dependence, a dedicated consultation support screen is displayed for each consultation. For example, in the case of hypertension, the same layout of the consultation support screen is displayed every time. In other words, in the case of hypertension, the same layout of the consultation support screen is displayed regardless of the consultation.

[0078] <Step 107> Doctors and other medical professionals determine the actions and outcomes that the patient should undertake between appointments, based on information from patient app data recorded through the patient app and the content of conversations with the patient. The determined actions and outcomes are entered as agreements during the appointment through the consultation support screen. In other words, the doctor's terminal 30 accepts input of agreements for the appointment. The accepted agreements are uploaded from the doctor's terminal 30 to the PDT server 20.

[0079] <Step 108> When the PDT server 20 receives the consultation arrangement from the physician's terminal 30, it updates the corresponding patient data 230 (see Figure 5). Specifically, the PDT server 20 updates the consultation arrangement 230C7 (see Figure 5).

[0080] <Step 109> The PDT server 20 notifies the corresponding patient terminal 40 of the newly configured arrangement. This notification to the patient terminal 40 may be via push notification or when the patient terminal 40 accesses the terminal (for example, when uploading application data). Steps 104 through 109, as described above, are performed during the patient's examination.

[0081] <From the end of the consultation until the next consultation> Steps 101-103 and steps 110-114 are executed. Basically, steps 101-103 are executed due to the operation of recording patient app data. On the other hand, steps 110-114 are executed due to the operation of confirming the agreement made during the medical examination.

[0082] In Figure 7, steps 110 to 114 are executed after steps 101 to 103, but steps 101 to 103 may also be executed after steps 110 to 114. Steps 110 through 114 are explained below.

[0083] <Step 110> The patient terminal 40 accepts requests to display a review of the medical examination. The medical examination review screen can be accessed, for example, from the home screen of the patient app. <Step 111> When the patient terminal 40 receives a request to display a review of the consultation, it displays the current arrangements. In other words, the patient terminal 40 displays the arrangements made during the most recent consultation. These arrangements include, for example, agreements with the doctor, advice from the doctor, the date of the next consultation, and the timing of medication.

[0084] <Step 112> The patient terminal 40 accepts requests to display the medical record book. In this embodiment, the medical record book is a screen used to review the arrangements for one or more medical consultations. The medical record book in this embodiment is provided with a function to display the arrangements for each medical consultation and a function to display a list of arrangements for multiple medical consultations.

[0085] <Step 113> The patient terminal 40, upon receiving the display of the medical record book, accepts the selection of the consultation session. In this embodiment, it is possible to select any one consultation session or all of the selected sessions. <Step 114> The patient terminal 40 displays the arrangement for the selected consultation session. In this embodiment, once the confirmation of the arrangement for the selected consultation session is complete, the display returns to the home screen.

[0086] <Example of transitions on the consultation review screen> Figure 8 illustrates an example of the transitions in the consultation review screen. Screens 400 and 410 shown in Figure 8 correspond to steps 110 (see Figure 7) and 111 (see Figure 7) described above.

[0087] Screen 400 is the initial screen of the "Consultation Review" screen. Screen 400 is an example of a screen displayed in step 110. The screen 400 shown in Figure 8 displays a message 401 from the assistant character, a "back" button 402, and a "forward" button 403.

[0088] The message 401 shown in Figure 8 displays "Thank you for your consultation!", "How was it?", and "Let's review the goals we agreed on with the doctor." The goals here are just one example of what was agreed upon during the consultation. When the "Back" button 402 is pressed, the home screen (not shown) is displayed. On the other hand, when the "Forward" button 403 is pressed, screen 410 is displayed.

[0089] Screen 410 is an example of the screen displayed in step 111. Screen 410 displays the agreement details 411 and an "OK" button 412. The agreement details 411 shown in Figure 8 consist of a target section 411A and a message section 411B. Each item displayed in the agreement details 411 is an example of an agreement. The goal column 411A shown in Figure 8 corresponds to the fourth consultation. Therefore, the title is "Goals set on the fourth consultation day (5 / 23)".

[0090] In addition, in the goal section 411A, it is indicated that the current goal (i.e., from the previous (4th) consultation to the next consultation) is "reducing alcohol consumption." "Reducing alcohol consumption" is an example of a qualitative indicator. Additionally, sub-goals include the amount of alcohol consumed per day, the number of alcohol-free days per week, and the average daily alcohol consumption per week (i.e., the average weekly alcohol consumption).

[0091] Specifically, the target daily alcohol intake is 52.8g, the target number of alcohol-free days per week is 2, and the target average daily alcohol intake per week is 37.7g. Incidentally, the amount of alcohol consumed per drinking session and the number of alcohol-free days are just a few examples of quantitative indicators. The numerical values ​​corresponding to each target can be calculated from the patient's app data.

[0092] In the message field 411B shown in Figure 8, the subtitle "Message from the doctor" and the message text "Taro, please do your best to reduce your alcohol intake! I'm rooting for you!!!" are displayed. As mentioned above, the message text is entered through the doctor's terminal 30 (see Figure 1). When the "OK" button 412 is pressed, the screen switches to screen 420 (see Figure 9).

[0093] Figure 9 is a diagram illustrating the continuation of the example transitions in the consultation review screen. Screens 420 and 430 shown in Figure 9 both correspond to step 112 (see Figure 7). Screen 420 is displayed by operating the "OK" button 412 (see Figure 8) on screen 410 (see Figure 8).

[0094] Screen 420 displays a message from the assistant character 421, a "back" button 422, and a "forward" button 423. Message 421, shown in Figure 9, reads, "You can check the goals decided during this consultation and the date of your next consultation by opening your medical record book." When the "Back" button 422 is pressed, screen 410 (see Figure 8) is displayed. On the other hand, when the "Next" button 423 is pressed, screen 430 is displayed. Therefore, pressing the "Next" button 423 corresponds to step 112 (see Figure 7).

[0095] Screen 430 is displayed by pressing the "Next" button 423. Screen 430 displays messages 431 and 432 from the assistant character, as well as a "back" button 433 and a "forward" button 434. In Figure 9, message 431 displays "Open the medical record book," and message 432 displays "Understood." When the "Back" button 433 is pressed, screen 420 is displayed. On the other hand, when the "Forward" button 434 is pressed, the screen switches to the medical record book 440 (see Figure 10).

[0096] Figure 10 illustrates examples of how to display the medical record books 440 and 450. The medical record books 440 and 450 shown in Figure 10 are displayed in steps 113 and 114 (see Figure 7). The medical examination record 440 is the initial screen. In this embodiment, the initial screen displays the details of the agreement made during the most recent (i.e., fourth) medical examination. The medical record book 440 shown in Figure 10 displays the arrangements for the three most recent medical appointments in a tabbed screen format. Therefore, tab 441 has page titles such as "2nd appointment," "3rd appointment," and "4th appointment," from left to right.

[0097] In the case of the medical record book 440, tab 441, which represents the most recent "4th appointment," is displayed in the selected state. Therefore, patients using the patient app can understand that the currently selected appointment is the 4th appointment. Needless to say, by selecting tab 441, it is possible to switch or select the appointment. In Figure 10, under tab 441, the consultation theme 442 is displayed.

[0098] Consultation theme 442 includes, for example, behavioral issues that the patient should address during each consultation. Consultation theme 442 is an example of advice associated with the arrangements for each consultation. In Figure 10, under consultation theme 442, it states: "The theme for the fourth consultation is 'Reflecting on how well it's going.' While continuing to keep records and complete homework, let's reflect on how well your challenge to change your drinking habits is going."

[0099] Below the consultation theme 442, a reflection information section 443 corresponding to the fourth consultation is displayed. The content displayed in the reflection information section 443 shown in Figure 10 is the same as the agreement content 411 (see Figure 8) on the "Consultation Reflection" screen 410 (see Figure 8) corresponding to the fourth consultation. Although not shown in Figure 10, the reflection information section 443 may also include the display of the message section 411B (see Figure 8). In this embodiment, the "View History" button 443A is a button for displaying a list of quantitative goals set in one or more past consultation sessions.

[0100] Medical Record 450 is displayed when tab 451, which has the page title "Second Appointment," is selected. In other words, Medical Record 450 is displayed through a selection operation by a patient who wants to specifically review the arrangements for their second appointment. Incidentally, the date of the second appointment is April 1st. In the case of the medical record book 450 shown in Figure 10, tab 451 corresponding to "2nd visit" is displayed in the selected state.

[0101] In Figure 10, consultation theme 452 displays the message: "The theme for the second consultation is 'Let's record your alcohol consumption with an app.' Continuing to keep accurate records will lead to a definite reduction or abstinence from alcohol." Consultation theme 452 is another example of advice associated with the arrangements for each consultation. The display of consultation topic 452 allows patients to pinpoint and review the consultation topics for their second consultation.

[0102] According to the reflection information section 453, the target daily alcohol intake was 70.1g, the target number of alcohol-free days per week was 1 day, and the target average daily alcohol intake per week was 46.4g. It can be confirmed that all of these figures were higher than the target values ​​for the most recent session (i.e., the target values ​​during the current effort). The reflection information section 453 may also include the display in the message section 411B (see Figure 8). This review information section 453 also includes a "View History" button 453A, which allows users to access a list of quantitative goals from past consultation sessions.

[0103] Figure 11 illustrates examples of how to display the medical records 460 and 470. Figure 11 includes corresponding reference numerals for parts that correspond to those in Figure 10. Medical records 460 and 470, shown in Figure 11, are also displayed in steps 113 and 114 (see Figure 7).

[0104] Medical Record 460 is displayed when tab 461, which has the page title "Third Appointment," is selected. In other words, Medical Record 460 is displayed through a selection operation by a patient who wants to specifically review the arrangements for the third appointment. Incidentally, the date of the third appointment is April 25th. In the case of the medical record book 460 shown in Figure 11, tab 461 corresponding to "3rd visit" is displayed in the selected state.

[0105] In Figure 11, consultation theme 462 displays the following: "The theme for the third consultation is 'reflecting on how well it's going.' As you continue keeping records and doing homework, reflect on how well your challenge to change your drinking habits is going." Consultation theme 462 is another example of advice associated with the arrangements for each consultation. Incidentally, the goal for the third consultation is the same as the goal for the fourth consultation. The display of 462 consultation themes allows patients to pinpoint and review the specific consultation themes from their third consultation.

[0106] According to the review section 463, the target daily alcohol intake is 52.8g, the target number of alcohol-free days per week is 2, and the target average daily alcohol intake per week is 37.7g. The target alcohol intake is lower than at the second consultation, and the target number of alcohol-free days has increased by one day. This review information section 463 also includes a "View History" button 463A, which allows users to access a list of quantitative goals from past consultation sessions.

[0107] The medical record book 470 is displayed when the "View History" button 443A (see Figure 10) or similar is operated. The upper section of the medical examination logbook 470 displays a title field 471 titled "Goals to Date." Below the title field 471, the goal fields 471A, 471B, and 471C set for the most recent medical examination are displayed. In Figure 11, due to display area limitations, the entirety of goal fields 471A and 471B, and a portion of goal field 471C are displayed.

[0108] The list-like display of objectives 471A, 471B, and 471C allows patients to compare and review the continuation of the qualitative indicator, "reduced alcohol consumption," with the changes in the quantitative indicator at each consultation. Incidentally, in the medical record book 470 shown in Figure 11, for example, if the patient swipes upwards on the screen, the goal section for the first consultation appears, and the goal section for the fourth consultation 471A disappears from the display area.

[0109] <Proposed changes to the agreement> The patient app described in this embodiment includes a function to suggest changes to the agreement currently being worked on (i.e., the agreement being worked on until the next consultation). Ideally, matters agreed upon with a doctor or other medical professional should not be changed until the next appointment. On the other hand, if the patient is making good progress, maintaining goals that are too low may hinder the achievement of treatment goals. For example, complacency may occur, leading to an increase in failure to meet agreed-upon targets. Conversely, if the patient is not making good progress, maintaining goals that are too high may hinder the achievement of treatment goals. For example, feelings of frustration may increase the likelihood of giving up on treatment.

[0110] Therefore, the patient app according to this embodiment is provided with a function that suggests changes to the agreement, on the condition that the patient app data within the period of the currently ongoing initiative satisfies a predetermined relationship. Figure 12 is a flowchart illustrating the function for presenting changes to the agreement. The processing operations shown in Figure 12 are implemented as a function of the patient application executed on the patient terminal 40.

[0111] The processing actions shown in Figure 12 are executed independently of the processing actions described above. The processing actions shown in Figure 12 are executed, for example, when new reflections are entered, at predetermined times (e.g., 12:00), on predetermined days of the week (e.g., Monday), once a week from the date of prescription in the patient app, once a week from the start of using the patient app, and when the patient app signs in to the PDT server 20. Note that the processing actions shown in Figure 12 may also be triggered by the patient opening their medical record book.

[0112] <Step 121> The patient terminal 40 retrieves the currently ongoing agreement. For example, if the most recent consultation is the second consultation, the agreement from the second consultation is read from the auxiliary storage device 43 (see Figure 6).

[0113] <Step 122> The patient terminal 40 acquires patient application data for a corresponding period. In this embodiment, the corresponding period refers to the period from the date of the most recent medical examination to the day before the current date. For example, if the date of the most recent medical examination is July 22, 2024, and the current date is August 5, 2024, then patient application data for the 14 days from July 22 to August 4 will be acquired by the patient terminal 40.

[0114] <Step 123> The patient terminal 40 determines whether the current implementation status of the agreement being pursued meets the first negative condition. In this embodiment, the first negative condition means that the practical situation is in a low degree of non-achievement. The first negative condition is an example of a predetermined relationship.

[0115] The first negative condition is met if, for example, the daily alcohol intake exceeds the agreed-upon amount for three or more consecutive weeks, or if there are two or fewer alcohol-free days for two consecutive weeks. However, these conditions are just examples. If the first negative condition is met, a positive result is obtained in step 123. On the other hand, if the first negative condition is not met, a negative result is obtained in step 123.

[0116] <Step 124> If a negative result is obtained in step 123, the patient terminal 40 determines whether the current implementation of the agreement being pursued meets the first positive condition. In this embodiment, the first positive condition means that the practical situation is in a good state, exceeding the standard level. The first positive condition is also an example of a predetermined relationship. The first positive condition is met if, for example, the number of days per week in which the daily alcohol intake is below the agreed-upon amount is five or more for two consecutive weeks, or if there are five or more alcohol-free days for two consecutive weeks. However, these conditions are just examples.

[0117] If the first positive condition is met, a positive result is obtained in step 124. On the other hand, if the first positive condition is not met, a negative result is obtained in step 124. Incidentally, if a negative result is obtained in step 124, the patient terminal 40 terminates the series of processes without proposing any changes to the arrangement to the patient. In most cases, a negative result is obtained in step 124.

[0118] <Step 125> If a positive result is obtained in step 124, the patient terminal 40 proposes a change to a more difficult arrangement. Suggestions for changes to a more difficult arrangement include, for example, a suggestion to lower the target amount of alcohol per day, or the addition of alcohol-free days. Please note that this is a suggestion, and the decision to actually change the arrangement rests with the patient. After the suggestion is made, the patient makes a selection, and the process is completed.

[0119] <Step 126> If a positive result is obtained in step 123, the patient terminal 40 determines whether the current implementation of the agreement being pursued meets the second negative condition. In this embodiment, the second negative condition signifies a state of severe underachievement in practice. That is, the second negative condition represents a more severe degree of underachievement than the first negative condition. The second negative condition is an example of a predetermined relationship.

[0120] The second negative condition is met if, for example, the daily alcohol intake exceeds the agreed-upon amount for six or more days per week for two consecutive weeks, or if there are no alcohol-free days for two consecutive weeks. However, these conditions are just examples. If the second negative condition is met, a positive result is obtained in step 126. On the other hand, if the second negative condition is not met, a negative result is obtained in step 126. Note that even if the second negative condition is not met, the first negative condition is still met.

[0121] <Step 127> If a negative result is obtained in step 126, the patient terminal 40 suggests changing to an arrangement with one level of difficulty. For example, it may suggest reducing the amount of alcohol consumed per day or the average amount of alcohol consumed per day over a week. After the proposal is made and the patient is selected, the entire process is completed.

[0122] <Step 128> If a positive result is obtained in step 126, the patient terminal 40 suggests changing to an arrangement that is two levels less difficult. For example, it suggests switching to a sobriety goal. After the proposal is made and the patient is selected, the entire process is completed.

[0123] <Example output of a screen proposing a change to the agreement> Figure 13 illustrates an example of the output of a screen that proposes a change to the agreement. Figure 13 shows three example proposal screens 480, 490, and 500. In this embodiment, proposal screens 480, 490, and 500 are displayed when "Weekly Review" is selected. Note that the current treatment goal when proposal screens 480, 490, and 500 shown in Figure 13 are displayed is "Reduce Alcohol Consumption".

[0124] Proposal screen 480 is an example of a screen displayed in step 125 (see Figure 12). In other words, proposal screen 480 is presented when the first positive condition is met. Therefore, in the case of the suggestion screen 480 shown in Figure 13, the message field 481 displays, "You have been successfully achieving your alcohol reduction goal for the past two weeks. Would you like to consider adding to your target alcohol reduction amount or number of alcohol-free days?"

[0125] Message field 481 contains the reason or cause for the display of proposal screen 480, and the proposed content. However, it is also possible to display the content of a proposed change to the agreement without indicating the reason or cause. The same applies to the other proposal screens 490 and 500. At the bottom of the suggestion screen 480, two selection buttons 482 and 483 are displayed. Selection button 482 is labeled "Review your alcohol reduction goal." On the other hand, selection button 483 is labeled "Continue with your current alcohol reduction goal." In this embodiment, it is also possible to choose to maintain the current alcohol reduction goal, which is the amount of alcohol consumed and the number of alcohol-free days.

[0126] Proposal screen 490 is an example of a screen displayed in step 127 (see Figure 12). In other words, proposal screen 490 is presented when the first negative condition is met, but the second negative condition is not. Therefore, in the case of the suggestion screen 490 shown in Figure 13, the message field 491 displays, "It seems that the number of days you have achieved your alcohol reduction goal has decreased over the past two weeks. Why not revise your alcohol reduction goal to an amount that is easier to achieve?"

[0127] Message field 491 also contains the reason or cause for the display of the suggestion screen 490, as well as the content of the suggestion. At the bottom of the suggestion screen 490, two selection buttons 492 and 493 are displayed. Selection button 492 is labeled "Review your alcohol reduction goal." On the other hand, selection button 493 is labeled "Continue with your current alcohol reduction goal." Even if the first negative condition is met, it is still possible to choose to maintain the current alcohol reduction goal.

[0128] Proposal screen 500 is an example of a screen displayed in step 128 (see Figure 12). In other words, proposal screen 500 is presented when the second negative condition is met. Therefore, in the case of the suggestion screen 500 shown in Figure 13, the message field 501 displays, "It seems you haven't been able to have many alcohol-free days in the last two weeks. How about switching to a goal of abstinence from alcohol next week and aiming to reduce your alcohol consumption?"

[0129] Message field 501 also contains the reason or cause for the display of the suggestion screen 500, as well as the content of the suggestion. At the bottom of the suggestion screen 500, two selection buttons 502 and 503 are displayed. Selection button 502 is labeled "Review your sobriety goal." On the other hand, selection button 503 is labeled "Continue with your current alcohol reduction goal." Even if the second negative condition is met, it is possible to choose to maintain the current alcohol reduction goal.

[0130] <Summary> By adopting the patient application described in this embodiment, patients can selectively review only the agreements made during specific consultations out of multiple consultations to date. For example, they can pinpoint and review the agreements made during the "second" consultation, such as in the consultation logbook 450 (see Figure 10). In the consultation logbook 450, patients can review not only quantitative target values ​​such as the amount of alcohol per day, but also advice given during the consultation. Furthermore, in the consultation logbook 450, patients can also review messages 411B from the doctor (not shown in the illustration) (see Figure 8).

[0131] Furthermore, by employing the patient application described in this embodiment, patients can review the quantitative target values ​​set during multiple consultations in a single list. By reviewing the target values ​​arranged chronologically, patients can easily confirm any changes in their own treatment arrangements. Furthermore, the patient app described in this embodiment presents a suggestion screen 480 (see Figure 13) or the like to prompt the patient to change the current agreement if the patient app data recorded during the period corresponding to the current agreement meets predetermined conditions.

[0132] This presentation feature allows patients to have the opportunity to change their arrangements to suit their current situation without waiting for their next appointment. As a result, it helps prevent complacency and decreased motivation compared to when advice or messages that don't match the progress of treatment are applied until the next appointment. In other words, when progress is going well, it can encourage challenging higher goals to accelerate behavioral change. On the other hand, when progress is not going well, adjusting goals can help maintain intrinsic motivation.

[0133] <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.

[0134] (2) The processor in the embodiments described above refers to a processor in a broad sense, and includes not only general-purpose processors (e.g., CPUs) but also specialized processors (e.g., GPUs (=Graphical Processing Units), ASICs (=Application Specific Integrated Circuits), FPGAs (=Field Programmable Gate Arrays), programmable logic devices, etc.). Furthermore, the processor operations in each of the embodiments described above are not limited to a single processor, but may be performed collaboratively by multiple processors or multiple CPU cores. Also, the order in which each operation is executed in the processor is not limited to the order described above, but may be changed individually.

[0135] (3) In the above embodiment, the case in which the doctor sets the arrangements for the consultation in the doctor app via the doctor terminal 30 (see Figure 7) was described. However, the arrangements for consultations can be set by the patient themselves through a patient app. Figure 14 illustrates an example sequence of operations when consultation arrangements are set through a patient application. Figure 14 includes corresponding reference numerals for parts corresponding to those in Figure 7. <Before consultation> The pre-consultation processing is the same as in the embodiment described above. Specifically, steps 101 to 103 are executed in the patient app.

[0136] <During the examination> In the case of Figure 14, steps 104 to 106 are performed between the PDT platform 10, the PDT server 20, and the physician's terminal 30. In this embodiment, the arrangements made during the consultation are recorded by the patient themselves through the patient app after the consultation. Therefore, steps 107 to 109 (see Figure 7) are not performed.

[0137] <From the end of the consultation until the next consultation> <Step 131> In the case of Figure 14, the patient terminal 40 records the agreement made during the consultation. That is, the patient themselves inputs the agreement made during the consultation. The content of the input agreement is recorded as part of the patient application data in the auxiliary storage device 43 (see Figure 6) of the patient terminal 40. Furthermore, the patient terminal 40 uploads the entered agreement to the PDT server 20 as part of the patient application data. As a result, the PDT server 20 can output the agreement entered by the patient to the doctor terminal 30 as part of the consultation support screen. The processing operations of steps 110 to 114 are the same as in the embodiment described above, so their explanation will be omitted.

[0138] (4) In the above-described embodiment, the patient application performs all of the display processing on the patient terminal 40 as agreed upon during the medical examination. However, the display processing on the patient terminal 40 as agreed upon during the medical examination may be implemented as a processing sequence in which the PDT server 20 and the patient terminal 40 cooperate. Figure 15 illustrates an example sequence illustrating the display processing operation of the agreement during a medical examination through the cooperation between the PDT server 20 and the patient terminal 40. In Figure 15, parts corresponding to those in Figure 7 are indicated with corresponding numerals.

[0139] Figure 15 shows the processing sequence from the end of one consultation to the next. In Figure 15, steps 101 to 108 (see Figure 7) are the same as in the previously described embodiment. In Figure 15, the consultation arrangements are managed only by the PDT server 20. That is, the notification of the consultation arrangements to the patient terminal 40 in step 109 (see Figure 7) is not performed. In this case, the patient terminal 40 that receives the request to display the review of the medical examination notifies the PDT server 20 of this fact (step 110A).

[0140] Upon receiving the notification, the PDT server 20 outputs the current arrangement set for the patient to the patient terminal 40 (step 141). The patient terminal 40 displays the received current arrangement (step 111A). Next, when the patient terminal 40 receives a request to display the medical record book, it notifies the PDT server 20 of this (step 112A). Upon receiving the notification, the PDT server 20 outputs the patient's medical record (step 142). As a result, the medical record is displayed on the patient terminal 40. Furthermore, the patient terminal 40 accepts the selection of the consultation time and notifies the PDT server 20 of this (step 113A).

[0141] Upon receiving the notification, the PDT server 20 outputs the arrangement for the selected consultation time (step 143). As a result, the patient terminal 40 displays the arrangement for the selected consultation time (step 114). As shown in Figure 15, the display of the consultation arrangements on the patient terminal 40 may be implemented as a process on the PDT server 20 side. In this case, the patient application on the patient terminal 40 functions as a so-called input / output device.

[0142] (5) In the above-described embodiment, when an operation such as the "View History" button 443A (see Figure 10) is received, the goals corresponding to all consultation sessions are displayed in a list on the patient terminal 40. However, a system could be adopted that selectively displays only the goals for the consultation sessions selected by the user.

[0143] Figure 16 illustrates an example of displaying goals for any consultation session selected by the patient. Medical records 510 and 520 are also displayed in steps 113 and 114 (see Figure 7).

[0144] The medical record 510 is displayed by operations such as clicking the "View History" button 443A (see Figure 10). The medical record 510 shown in Figure 16 has a message 511, a selection field 512, and a "Display" button 513. Message 511 displays "Please select the number of consultations to display (multiple selections are possible)," indicating that multiple consultations can be selected. The selection field 512 shown in Figure 16 displays checkboxes corresponding to four consultation sessions. Since they are checkboxes, it is possible to select one or more.

[0145] In the case of Figure 16, out of "1st session 2024 / 3 / 18", "2nd session 2024 / 4 / 1", "3rd session 2024 / 4 / 25", and "4th session 2024 / 5 / 23", the 3rd and 4th consultations are selected. When the "Display" button 513 is pressed, the selection of the consultation date is confirmed, and the display screen switches to the consultation record 520.

[0146] The upper section of the medical record book 520 displays a title field 521 labeled "Goals to Date." Below the title field 521, goal fields 521A and 521B are displayed, corresponding to the agreements made for the third and fourth consultations selected in the medical record book 510. In other words, the medical record book 520 displays only the goal values ​​set for the consultations selected by the patient.

[0147] Furthermore, since any number of consultation sessions can be combined, it is possible to display, for example, two goal columns from the first and fourth consultation sessions in a comparative manner. Incidentally, it may be possible to allow users to switch between a method that selectively displays the arrangements for the number of consultations and a method that displays all the arrangements for the number of consultations in a list.

[0148] Furthermore, the selection field 512 shown in Figure 6 may also be used to display the medical record book 440 (see Figure 10), etc. In other words, when the "Next" button 423 (see Figure 9) on screen 430 (see Figure 9) is operated, a selection screen containing multiple medical appointments as options may be displayed, and the arrangements for the selected medical appointment may be displayed. This selection screen may have radio buttons that allow only one option to be selected. However, checkboxes may also be used on the selection screen to allow the arrangements for the selected medical appointment to be switched and displayed in order.

[0149] (6) In the above-described embodiment, the decision of whether or not to propose a change to the agreement was made using patient app data from the most recent consultation date to the day before the present. However, it is also acceptable to use only the most recent patient app data to determine whether or not to propose a change to the agreement. In this case, for example, only the patient app data from the most recent two weeks may be used. For example, if the most recent consultation date was July 22, 2024, and the current date is August 12, 2024, then patient app data for the 14 days from July 29 to August 11 would be used. The period used for the assessment is not limited to two weeks; it could be one week, ten days, or any other period.

[0150] (7) In the embodiments described above, a change to the arrangement was proposed using one positive condition and two negative conditions. However, there may be multiple positive conditions. Alternatively, there may be only one negative condition. Furthermore, there may be three or more positive and negative conditions.

[0151] (8) In the embodiments described above, if any of the conditions are met, a change in the arrangement will be proposed to the patient. However, if any of the conditions are met, a system may be adopted that automatically changes the arrangement to one corresponding to the condition and notifies the patient of the change.

[0152] (9) In the above-described embodiment, a patient application for alcohol dependence was explained. However, an app that has a selective presentation function for one or more appointment schedules may be a patient app for other diseases or a non-patient app. Incidentally, the other diseases may be lifestyle-related diseases or non-lifestyle-related diseases. Lifestyle-related diseases include, for example, hypertension, dyslipidemia, chronic heart failure, hyperuricemia, diabetes, NASH, 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.

[0153] (10) In the above-described embodiment, a patient app or a healthcare app is assumed to be used as the app for recording health-related data. However, the type of app used to record health-related data is not restricted. For example, it could be a diary app, a photo app, or an audio app.

[0154] <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 receiving user input to record health-related data, and presenting the user with arrangements for one or more consultation sessions selected by the user from among multiple consultation sessions. This information processing device can support the selective review of arrangements made during one or more consultation sessions.

[0155] (((2))) The agreement pertains to the information processing device described in (((1))) concerning the indicators managed by the program used to record data. This information processing device allows for the review of agreements in conjunction with health-related data.

[0156] (((3))) The processor is an information processing device as described in (((1))) or (((2))) that presents a list of arrangements for multiple consultation days. This information processing device allows you to check multiple appointments with different consultation dates at once.

[0157] (((4))) The arrangement is set via a terminal operated by a medical professional, using one of the information processing devices described in (((1))) to (((3))). This information processing device can assist users in reviewing arrangements entered by medical professionals.

[0158] (((5))) The arrangement is set through a terminal operated by the user, and is an information processing device described in any one of (((1))) to (((4))). This information processing device can assist users in reviewing the agreements they have entered.

[0159] (((6))) The processor is an information processing device according to any one of (((1))) to (((5))) that provides advice to the user in relation to the aforementioned arrangement. This information processing device can support the user's efforts.

[0160] (((7))) The information processing device according to any one of (((1))) to (((6))), wherein the processor proposes to the user a change to the arrangement currently under consideration if the health data recorded during the corresponding period satisfies a predetermined relationship. This information processing device can support changes to agreements based on the user's progress.

[0161] (((8))) An information provision method in which a computer performs the following processes: accepting user input to record health-related data, and presenting the user with arrangements for one or more consultation sessions selected by the user from among multiple consultation sessions. This information delivery method can support the selective review of arrangements corresponding to one or more consultation sessions.

[0162] (((9))) A program for a computer that enables the user to input data related to health, and to present the user with arrangements for one or more medical consultations selected by the user from among several consultations. This program can support the selective revision of arrangements corresponding to one or more consultation sessions. [Explanation of symbols]

[0163] 1…Information processing system, 10…PDT platform, 20, 20A, 20B, 20C, 20D, 20E, 20F…PDT server, 30…Physician terminal, 40…Patient terminal

Claims

1. It has a processor, The aforementioned processor, It accepts user input to record health-related data and presents the user with arrangements for one or more consultation sessions selected by the user from among multiple consultation sessions. Information processing device.

2. The aforementioned arrangement concerns the indicators managed by the program used to record the aforementioned data. The information processing apparatus according to claim 1.

3. The aforementioned processor presents a list of arrangements for multiple consultation days. The information processing apparatus according to claim 1.

4. The aforementioned arrangement is set through a terminal operated by a medical professional. The information processing apparatus according to claim 1.

5. The aforementioned arrangement is set through the terminal operated by the user. The information processing apparatus according to claim 1.

6. The processor provides advice to the user in relation to the arrangement. The information processing apparatus according to claim 1.

7. The processor, with respect to the arrangement currently being worked on, proposes to the user a change to the arrangement if the health data recorded during the corresponding period satisfies a predetermined relationship. The information processing apparatus according to claim 1.

8. Computers A process that accepts user input to record health-related data, A process that presents the user with the arrangements for one or more consultation sessions selected by the user from among multiple consultation sessions, A method for providing information to carry out the task.

9. On the computer, A function that accepts user input to record health-related data, A function that presents the user with the arrangements for one or more consultation sessions selected by the user from among multiple consultation sessions, A program to achieve this.

Images