Information processing device, information provision method, and program

Abstract

This system provides a mechanism to streamline the initial setup process for medical device programs performed by users. [Solution] An information processing device having a processor, the processor detects the activation of a medical device program on a terminal operated by a user whose behavior is being altered, and uses at least a portion of the data of a non-medical device program associated with the user for the initial setup of the medical device program.

Description

Technical Field

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

Background Art

[0002] Currently, for nicotine dependence and hypertension, prescriptions of application programs (hereinafter referred to as treatment apps) approved under the Pharmaceutical Affairs Law have been started. Incidentally, treatment apps include a patient app operated by the user himself / herself and a doctor app operated by a doctor or other medical staff.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Users who start using the patient app are required to input attribute information and the like. Performing these instructions during the consultation time places a burden on the medical institution side. On the other hand, users who are using application programs (hereinafter referred to as "health apps") classified as non-medical devices before receiving a prescription for the patient app may feel that it is a waste of effort to input attribute information and the like for the patient app.

[0005] The present disclosure provides a mechanism for streamlining the initial setting work of medical device programs by users.

Means for Solving the Problems

[0006] The invention described in claim 1 is an information processing device having a processor, the processor detecting the activation of a medical device program on a terminal operated by a user who changes their behavior, and using at least a portion of the data of a non-medical device program associated with the user for the initial setup of the medical device program. The invention described in claim 2 is an information processing device according to claim 1, wherein the processor controls the initial settings based on the result of determining whether or not there is data for the non-medical device program associated with the user. The invention described in claim 3 is an information processing device according to claim 1 or 2, wherein the processor uses attribute information recorded through the non-medical device program for initial settings of the medical device program. The invention described in claim 4 is an information processing device according to claim 1 or 2, wherein the processor uses information relating to a medical history recorded through the non-medical device program for initial settings of the medical device program. The invention described in claim 5 is an information processing device according to claim 1 or 2, wherein the processor uses information about physical characteristics recorded through the non-medical device program for initial settings of the medical device program. The invention described in claim 6 is an information processing device according to claim 1 or 2, wherein the processor uses information regarding the acquisition status of knowledge about diseases recorded through the non-medical device program for the initial setup of the medical device program. The invention described in claim 7 is an information processing device according to claim 1 or 2, wherein the processor uses the measured values ​​recorded through the non-medical device program for initial settings of the medical device program. The invention described in claim 8 is an information processing device according to claim 1 or 2, wherein the processor uses the behavioral records recorded through the non-medical device program for initial setup of the medical device program. The invention described in claim 9 is an information processing device according to claim 1 or 2, wherein the processor uses the feedback on the behavior recorded through the non-medical device program for the initial setup of the medical device program. The invention described in claim 10 is an information processing device according to claim 1 or 2, wherein the processor uses information about lifestyle habits recorded through the non-medical device program for initial settings of the medical device program. The invention described in claim 11 is an information processing device according to claim 1 or 2, wherein the processor presents the user with a screen that accepts the selection of data for the non-medical device program to be used for initial setup of the medical device program. The invention described in claim 12 is an information processing device according to claim 1 or 2, wherein the processor presents the user with a screen requesting confirmation of the data that becomes available through the initial setup. The invention described in claim 13 is an information provision method in which a computer performs the following processes: detecting the activation of a medical device program on a terminal operated by a user whose behavior is altered; and using at least a portion of the data of a non-medical device program associated with the user in the initial settings of the medical device program. The invention described in claim 14 is a program for enabling a computer to detect the activation of a medical device program on a terminal operated by a user who changes their behavior, and to use at least a portion of the data of a non-medical device program associated with the user in the initial settings of the medical device program. [Effects of the Invention]

[0007] According to one form of this disclosure, the initial setup work of medical device programs by the user can be streamlined. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram illustrates an example of the overall configuration of the information processing system assumed in the 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 is a diagram for explaining an example of the hardware configuration of a PDT server. [Figure 5] This is a diagram for explaining an example of patient data stored in the auxiliary storage device of a PDT server. [Figure 6] This is a diagram for explaining an example of the hardware configuration of a health app server. [Figure 7] This is a diagram for explaining an example of health data stored in the auxiliary storage device of a health app server. [Figure 8] This is a diagram for explaining an example of the hardware configuration of a doctor terminal and a user terminal. [Figure 9] This is a diagram for explaining an example of a processing sequence in the usage stage of a health app. [Figure 10] This is a diagram for explaining an example of a processing sequence in the prescription stage of a patient app. [Figure 11] This is a diagram for explaining an example of a processing sequence in the initial setting stage of a patient app. [Figure 12] This is a diagram for explaining another example of a processing sequence in the initial setting stage of a patient app. [Figure 13] This is a diagram for explaining the first half of an example of screen transition when installing a patient app on a user terminal. [Figure 14] This is a diagram for explaining the second half of an example of screen transition when installing a patient app on a user terminal. [Figure 15] This is a diagram for explaining another embodiment example of a processing sequence in the initial setting stage of a patient app. [Figure 16] This is a diagram for explaining another embodiment example of a processing sequence in the initial setting stage of a patient app.

Embodiments for Carrying Out the Invention

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

[0010] This type of program includes programs classified as medical devices and programs classified as non-medical devices. A program classified as a medical device is an example of a program that requires a prescription, and a program classified as a non-medical device is an example of a program that does not require a prescription. Note that a program classified as a non-medical device (so-called health app) may not only be a program for promoting behavior change but also a program with a function of recording health-related data. Programs for promoting behavior change and programs with a function of recording health-related data include programs that can be downloaded from an app store. This type of program may also be a program used by private businesses, public organizations, etc. for the health management of employees, etc. Programs classified as non-medical devices also include programs used in medical institutions.

[0011] The "purpose of the app" refers to the effect to be achieved by using a program for promoting behavior change. The purpose of the app varies 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 a user who is changing their behavior (hereinafter also referred to as a "user 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 (i.e., activation) (hereinafter referred to as the "prescription code") is issued by a doctor's 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. Needless to say, 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, patient name, gender, and date of birth. This information is just one example of basic patient information. Patient attributes are recorded as "attribute information" in patient app data or health app data, for example. "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 include carbon monoxide (CO) in exhaled breath and nicotine concentration in saliva. These measured values ​​would then be recorded as "measured values" in patient app data or health app data, for example.

[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. Activity records are recorded as "behavioral records" in patient app data and health app data, for example. A "mood record" is, for example, a record of the user's perceived mood. A mood record is an example of information related to mood. Mood records are recorded as "reflections" in patient app data or health app data, for example. "Health records" are, for example, records of the user's perceived physical condition or symptoms. Health records are just one example of information related to health. Health records are recorded as "reflections" in patient app data or health app data, for example.

[0021] "Medical history" includes, for example, the treatment start date, the date of the consultation, the content of the treatment, and the advice given. Medical history is just one example of information related to a medical consultation. Medical history is recorded as "outpatient records" in patient app data or health app data, for example. "Patient app operation history" refers to the history of operations such as launching the patient app and inputting measurements and reflections. Patient app operation history is recorded as "activity record" in patient app data or health app data, for example. "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. Biological characteristics are recorded, for example, as "medical history," "treatment history," and "attribute information" in patient app data or health app data.

[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 uneaten. Psychological characteristics are recorded as "attribute information" in patient app data or health app data, for example. "Social characteristics" include, for example, work patterns (e.g., shift work, day shift, night shift), working days, start time of work, end time of work, regular days off, and whether or not there is a heater in the changing room. Social characteristics are recorded as "attribute information" in patient app data or health app data, for example.

[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 avoiding caffeine after 4 PM, eating habits after 10 PM, skipping breakfast habits, snacking habits, bathing habits one hour before bedtime, stretching or massage habits 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. Habits are recorded as "lifestyle habits records" in patient app data or health app data, for example.

[0024] "Goal achievement status" refers to information indicating the progress toward goals set by a doctor for each patient, for example. "Goal achievement status" may also refer to information indicating the progress toward goals set by the patient themselves, for example. "Goal achievement status" may also refer to information indicating the progress toward goals presented by a patient app for each patient, for example. Goal achievement status is recorded in patient app data or health app data as "current step of treatment program," "treatment program implementation history," "medication record," and "behavioral record," for example. Furthermore, the information mentioned above can be classified into subjective information and objective information.

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

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

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

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

[0029] 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, multiple patient apps for different diseases (for example, a patient app for hypertension and a patient app for nicotine addiction) may be shared on a single PDT server. Furthermore, multiple patient apps provided by different service providers may share a single PDT server.

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

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

[0032] 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 for activating 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.

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

[0034] <Embodiment> <Overall System> Figure 1 is a diagram illustrating an example of the overall configuration of the information processing system 1 assumed in the embodiment. The information processing system 1 shown in Figure 1 consists of a PDT platform 10, a PDT server 20, a health application server 30, a doctor's terminal 40, and a user terminal 50. These terminals are connected to each other via a network N. Network N can use, for example, a LAN (=Local Area Network), the Internet, or a mobile communication system (4G, 5G, etc.).

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

[0036] Figure 1 depicts only one PDT server 20. However, multiple PDT servers 20 may exist. The PDT server 20 may also consist of multiple servers connected via a network. In this case, the multiple servers cooperate to provide the PDT server 20 service. The PDT server 20 performs tasks such as patient authentication, management of patient application data entered through the patient application, and provision of patient data to the physician's terminal 40. The PDT server 20 is an example of an information processing device.

[0037] In this embodiment, the PDT server 20 is provided for each combination of disease that the patient application corresponds to and the business operator that provides the patient application. For example, if two different businesses provide patient apps for the same disease, two PDT servers 20 will be provided. For example, if one provider offers patient apps for two different diseases, two PDT servers 20 will be set up.

[0038] However, it is also possible to operate in a way that a single PDT server 20 is shared by different combinations of users. For example, multiple service providers can share a single PDT server 20. Furthermore, it is possible to operate multiple patient applications on a single PDT server 20.

[0039] Figure 1 depicts only one health application server 30. However, multiple health application servers 30 may exist. The health application server 30 may also consist of multiple servers connected via a network. In this case, the multiple servers will cooperate to provide the health application server 30 service. The health app server 30 performs tasks such as patient authentication and managing health app data entered through the health app. The health app server 30 is an example of an information processing device. In this embodiment, the health application server 30 is intended to work in conjunction with the PDT server 20. Here, "working in conjunction" refers to a relationship that enables data exchange.

[0040] The physician terminal 40 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 40 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 40 can be, for example, a desktop computer, a laptop computer, a tablet computer, a smartphone, smart glasses, or a server.

[0041] The user terminal 50 is a terminal operated by a user whose behavior is being modified. The user terminal 50 is an example of an information processing device. Figure 1 shows only one user terminal 50 as a representative example. In this embodiment, the user terminal 50 runs both a health application and a patient application. Specifically, it is assumed that the patient application is prescribed to a user who is using the health application. The user terminal 50 uploads the health application data recorded through the health application to the health application server 30, and uploads the patient application data recorded through the patient application to the PDT server 20. User terminal 50 may be, for example, a smartphone, smart glasses, a desktop computer, a notebook computer, or a tablet computer.

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

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

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

[0045] <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(=identifier) / 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, insurer number, and version of the patient app may be stored.

[0046] The prescription code 130A is issued every time a prescription is notified from the doctor terminal 40. 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".

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

[0048] 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 is information indicating the usage status of the patient app. 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, the patient apps for "Patient A," "Patient B," and "Patient C" are in the "in use" status. As mentioned above, "not yet started" means that the prescription for the patient app has been completed, but it has not yet started to be used on the user's terminal.

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

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

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

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

[0053] <Management data of the PDT server> FIG. 5 is a diagram for explaining an example of 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 measurement 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.

[0054] In the case of FIG. 5, the patient data 230 stores a prescription code 230A, a user ID 230B, an "Apple ID or Google account" 230C, a "patient ID and patient name" 230D, a gender 230E, a date of birth 230F, and patient app data 230G. Note that the patient data 230 may further include information such as the presence or absence of a spouse or partner, the presence or absence of a job, the type of job, medical history and diseases under treatment, and physical constitution. In this embodiment, patient application data 230G means patient application management data and data recorded by the user through the patient application.

[0055] 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). User ID 230B is a user management ID issued during the initial registration of the patient application.

[0056] "Apple ID or Google account" 230C is information used by a provider of an OS (=Operating System) or an app store operator to identify a user on a user terminal 50 (see Figure 1) as a mobile device. In this embodiment, identification information for Apple® and Google® is assumed. Apple's identification information is an Apple ID. An Apple ID is, for example, an email address provided by Apple's email service. Google's identification information is a Google account. A Google account can be any email address.

[0057] "Patient ID and Patient Name" 230D refers, for example, to the patient ID and patient name at the medical institution that prescribed the patient app. The patient ID and patient name are obtained, for example, from the PDT platform 10 (see Figure 1) when the prescription code is authenticated. Gender 230E is physical sex. In this embodiment, unregistered gender is permitted. The date of birth (230F) represents the year and month of birth. Alternatively, you may register a date of birth that includes the day of birth.

[0058] The patient app data 230G shown in Figure 5 includes "measured values ​​and measurement date and time" 230G1, "review and input date and time" 230G2, "current step of the treatment program" 230G3, "treatment program implementation history" 230G4, behavioral goals 230G5, target values ​​230G6, outpatient records 230G7, and medication records 230G8. Note that the items exemplified do not need to be all of the 230GB of patient app data; they may be only a portion, or other items may be included.

[0059] The "Measured Values ​​and Measurement Date / Time" section (230G1) records the health-related values ​​and dates 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 "Review and Input Date / Time" section (230G2) records a review of the day's activities and the date and time of entry. The review may include details such as physical condition level, stress level, sleep duration, weight, alcohol consumption, and the activities performed.

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

[0061] The "Current Step of the Treatment Program" 230G3 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, "Knowledge Acquisition," "Implementation of Behavioral Goals," and "Habituation of Behavior." The "Treatment Program Implementation History" (230G4) records the history of learning and behavior practiced in accordance with the treatment program. For example, in 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 behavioral 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.

[0062] Behavioral objective 230G5 records the behaviors that the patient has set as goals. These goals include one or more behavioral objectives selected by the patient from those presented by the patient app as the treatment program progresses. For example, behavioral objective 230G5 records the behavioral objectives set by the patient in step 2 or 3 of the treatment program. A behavioral objective refers to the action that must be taken to achieve the target goal. 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.

[0063] The target value 230G6 is recorded as the value set by the doctor or other medical professional during the examination. Target value 230G6 is an example of a quantitative target, as it is given as a numerical value. Outpatient record 230G7 records appointments with the doctor, the date of the next appointment, medication timing, etc. The appointments with the doctor record what the patient should do or be careful about before the next consultation. In this embodiment, appointments with the doctor can only be recorded through the patient app. Alternatively, appointments with the doctor may only be recorded from the doctor's terminal 40 (see Figure 1). Medication record 230G8 contains information about the taking of prescribed medications.

[0064] <Health app server> Figure 6 illustrates an example of the hardware configuration of the health application server 30. The health application server 30 shown in Figure 6 includes a processor 31, semiconductor memory 32, auxiliary storage device 33, and communication interface 34. Each device is connected via a bus or other signal lines.

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

[0066] The auxiliary storage device 33 is composed of, for example, a hard disk drive or semiconductor storage. The auxiliary storage device 33 stores the operating system and other programs. In addition, the auxiliary storage device 33 also stores health data 330 recorded through the health app. The communication interface 34 is an interface for communicating with external terminals such as the PDT platform 10 (see Figure 1) via the network. The communication interface 24 supports Ethernet®, Wi-Fi®, mobile communication systems, and other communication standards.

[0067] <Management data for the health app server> Figure 7 illustrates an example of health data 330 stored in the auxiliary storage device 33 (see Figure 6) of the health application server 30. The health data 330 shown in Figure 7 stores measurements and other information recorded through the health app. The content of the information recorded as health data 330 varies depending on the disease that the health app, as a non-medical device, addresses.

[0068] In Figure 7, the health data 330 stores the user ID 330A, the "Apple ID or Google account" 330B, and the health app data 330C. In this embodiment, the health app data 330C refers to the management data of the health app and the data recorded by the user through the health app.

[0069] User ID 330A is a user management ID issued during the initial registration of the health app. "Apple ID or Google account" 330B is information used by the provider of the OS running on the user terminal 50 (see Figure 1) as a mobile device, or by the operator of the app store, to identify the user. In this embodiment, we assume the identification information of Apple® and Google®.

[0070] The health app data 330C shown in Figure 7 includes attribute information 330C1, "medical history or diseases currently being treated" 330C2, constitution 330C3, "disease learning stage" 330C4, measured values ​​330C5, behavioral records 330C6, "reflection records" 330C7, and "lifestyle records" 330C8.

[0071] Note that the items listed as examples do not need to be all of the Health App Data 330C; they may be only a portion, or other items may be included. Attribute information 330C1 may include, for example, the username, gender, age, date of birth, marital status (spouse or partner), and employment status. Section 330C2, "Medical History or Current Illnesses," records past illnesses and injuries, as well as illnesses and injuries currently being treated. Constitution type 330C3 is associated with allergies, asthma, rashes, hives, food-induced abdominal pain and diarrhea, and other symptoms. Other symptoms include facial redness after drinking alcoholic beverages.

[0072] The "Disease Learning Stage" 330C4 records information indicating the level of knowledge acquired regarding the disease. For example, it records the content and completion date of completed stages, as well as the content of stages currently being studied. The measurement value 330C5 records the patient's measured health values ​​and the date and time. In the case of a patient app for hypertension, the measurement value 330C5 records weight, blood pressure, etc. Blood pressure is given as both systolic and diastolic blood pressure. In the case of a patient app for nicotine addiction, the measurement value 330C5 records carbon monoxide concentration. Other measurement values ​​in the 330C5 include, for example, weight and pulse rate. In the case of a patient app for diabetes, weight, blood glucose levels, etc., are recorded.

[0073] The activity log 330C6 records daily activities. In the case of a health app for alcohol dependence, the activity log 330C6 includes records of drinking and records of alcohol-free days. Records of drinking include, for example, where you drank, who you drank with, how you felt while drinking, type of alcohol, amount consumed, and satisfaction with drinking. Records of alcohol-free days include, for example, who you were with, location, circumstances, and your thoughts. Incidentally, in the case of health apps for people with hypertension, the activity log 330C6 includes "sleep," "stress," "moderate alcohol consumption," and "other." Other includes "salt reduction," "weight loss," "exercise," and "smoking."

[0074] The "Reflection Record" (330C7) records reflections on the day's activities. These reflections may include, for example, physical condition, stress levels, sleep duration, weight, meals, exercise, and alcohol consumption. They may also include, for example, events of the day, and thoughts or questions about those events. The "Lifestyle Habits Record" 330C8 includes, for example, exercise habits, weight measurement habits, habits of checking calorie information on food labels, salt intake tendencies, habits of choosing low-fat foods, habits of not consuming caffeine after 4 PM, eating and drinking habits after 10 PM, skipping breakfast habits, snacking habits, bathing habits one hour before bedtime, stretching or massage habits before bedtime, smoking habits, drinking habits, sleep habits of more than 6 hours, snoring, waking up in the middle of the night, and difficulty falling asleep.

[0075] <Physician terminal / User terminal> Figure 8 illustrates an example of the hardware configuration of a physician terminal 40 and a user terminal 50. The hardware configuration of the physician terminal 40 and the user terminal 50 are basically the same. Therefore, in Figure 8, they are expressed in the format of "code of the elements constituting the physician terminal 40 / code of the elements constituting the user terminal 50". The physician terminal 40 / user terminal 50 shown in Figure 8 includes a processor 41 / 51, semiconductor memory 42 / 52, auxiliary storage device 43 / 53, input interface 44 / 54, input device 45 / 55, output interface 46 / 56, output device 47 / 57, and communication interface 48 / 58. Each device is connected via a bus or other signal lines.

[0076] The processor 41 / 51 is a device that realizes various functions through the execution of a program. The processor 41 / 51 may be composed of multiple CPU cores. In that case, the processor 41 executes the program through the cooperation of the multiple CPU cores. The semiconductor memory 42 / 52 stores UEFI and other information. The semiconductor memory 42 / 52 is also used as an execution area for programs. The processor 41 / 51 and the semiconductor memory 42 / 52 function as a computer. The auxiliary storage devices 43 / 53 consist of, for example, hard disk drives or semiconductor storage devices. The auxiliary storage devices 43 / 53 store the operating system and other programs.

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

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

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

[0080] <Processing Sequence> In the following, the processing sequence of Information Processing System 1 (see Figure 1) will be explained by dividing it into the following stages: "Health App Usage Stage," "Patient App Prescription Stage," "Patient App Initial Setup Stage (if Health App is not being used)," and "Patient App Initial Setup Stage (if Health App is being used)."

[0081] <Stages of using health apps> Figure 9 illustrates an example of a processing sequence in the usage stage of a health app. In Figure 9, the symbol S represents a step. The usage stage of a health app begins with the user downloading the health app.

[0082] <Step 101> The user terminal 50 downloads a health app from the app store. The app store has health apps available for download from various businesses and organizations. The user installs the downloaded health app on the user terminal 50 and starts the new user registration process by following the on-screen instructions. <Step 102> The user terminal 50 signs up to the health app site (i.e., the health app server 30) using the user's Apple ID or Google account. The identification information used for signup depends on the operating system running on user terminal 50.

[0083] <Step 103> For users who sign up, the health app server 30 issues a user ID 330A (see Figure 7). User ID 330A is used by the health app server 30 to identify users who use the health app. <Step 104> Next, the health app server 30 associates the issued user ID 330A with the user's Apple ID or Google account. <Step 105> Once the linking is complete, the health app server 30 notifies the user terminal 50 that the signup is complete.

[0084] <Step 106> Upon receiving the signup completion notification, the user terminal 50 enters the required information (attribute information, evaluation indicators, learning status of the target disease, etc.) according to the user information registration screen of the health app. The required information may be only a part of the example information. At least attribute information 330C1 (see Figure 7) is entered as required information. <Step 107> Once the input of the required information is confirmed, the user terminal 50 uploads the required information to the health app site (i.e., the health app server 30).

[0085] <Step 108> Upon receiving the specified information, the health application server 30 performs a simple diagnosis, risk assessment, etc., based on the specified information. However, performing the simple diagnosis and risk assessment is optional. Therefore, the process in step 108 is performed only on the health application server 30 that has the function to perform a simple diagnosis and risk assessment based on the input specified information. <Step 109> Once the results of the preliminary diagnosis and risk assessment are obtained, the health app server 30 provides the preliminary diagnosis results, risk assessment results, etc., to the user terminal 50. This completes the processing steps required to start using the health app.

[0086] <Prescription stage in patient app> Figure 10 illustrates an example of a processing sequence in the prescription stage of a patient app. The prescription stage for the patient app begins with a diagnosis of treatment initiation using the patient app.

[0087] <Step 201> Step 201 involves preparing for the consultation. The physician terminal 40 accepts the sign-in operation. Upon accepting the sign-in operation, the physician terminal 40 sends the recorded client certificate to the PDT platform 10. <Step 202> Upon successful sign-in, the PDT platform 10 displays a screen on the physician's terminal 40 confirming the patient app usage status. The above processes are performed during the preparation phase for the examination.

[0088] <Step 203> Here, we assume that a doctor or other medical professional has diagnosed the need to initiate treatment using the patient app for a patient being examined. In this case, the doctor's terminal 40 accepts the operation of the "New Prescription" button. The "New Prescription" button is located on the "Usage Status Confirmation Screen" mentioned above. The acceptance of the operation of the "New Prescription" button is notified from the doctor's terminal 40 to the PDT platform 10.

[0089] <Step 204> Upon receiving the input of the new prescription button, the PDT platform 10 issues prescription code 230A (see Figure 5) and notifies the physician's terminal 40. Prescription code 230A is required to activate (i.e., enable) the patient app. Since the patient app is a program classified as a medical device, it cannot be used unless authentication with prescription code 230A is successful. A physician or other medical professional who has received notification of prescription code 230A will, for example, hand the patient a document with prescription code 230A printed on it.

[0090] <Initial setup stage for the patient app (if a health app is not being used)> Figure 11 illustrates an example of the processing sequence for the initial setup stage of a patient app. The processing sequence shown in Figure 11 is executed when a patient who is performing the initial setup of the patient app is not using a health app.

[0091] <Step 301> The user terminal 50 downloads the patient app from the app store based on the patient's actions. The patient installs the downloaded patient app on the user terminal 50 and begins the new user registration process by following the on-screen instructions. <Step 302> The user terminal 50 signs up to the PDT server 20 from the patient app. An Apple ID or Google account is used for the signup. Incidentally, authentication using the user ID of the health app is also possible. However, in the case of Figure 11, we assume that the patient starting to use the patient app is not using the health app, so the user ID of the health app is excluded from the information used to identify the user.

[0092] <Step 303> The PDT server 20 authenticates the patient based on the information notified from the user terminal 50. If an Apple ID is used for signup, the PDT server 20 authenticates the patient requesting signup using Apple's authentication system. On the other hand, if a Google account is used for signup, the PDT server 20 authenticates the patient requesting signup using Google's authentication system.

[0093] <Step 304> After successful authentication, the PDT server 20 generates a user ID 230B (see Figure 5) for the patient application. User ID 230B is used by the PDT server 20 to identify the user using the patient application. <Step 305> Next, the PDT server 20 requests the user terminal 50 to enter prescription code 230A (see Figure 5). For example, a screen prompting the user to enter prescription code 230A is displayed on the user terminal 50's operation screen. <Step 306> The user terminal 50 receives the input of prescription code 230A and notifies the PDT server 20.

[0094] <Step 307> Upon receiving prescription code 230A from user terminal 50, the PDT server 20 authenticates the received prescription code 230A. Specifically, the PDT server 20 verifies, in cooperation with the PDT platform 10 (see Figure 10) that issued prescription code 230A, whether the prescription code 230A has not expired. Prescription code 230A, like prescription drugs, has an expiration date. The expiration date is, for example, three days starting from the day after the issue date. Entering prescription code 230A after its expiration date will be treated as invalid.

[0095] <Step 308> After successful authentication, the PDT server 20 instructs the user terminal 50 to activate the patient application. <Step 309> Upon receiving the activation command, the user terminal 50 activates the patient app. Once activation is complete, the patient can use the patient app. <Step 310> Next, the user terminal 50 queries the PDT server 20 for health data. In this embodiment, the health data query is automatically sent by the activated patient application.

[0096] <Step 311> This step is performed by the PDT server 20, which instructs the user terminal 50 to activate the patient application. The PDT server 20 detects that the patient application has been activated on the user terminal 50, either through the instruction to activate the patient application or through the response from the user terminal 50. Upon receiving a request for health data from the user terminal 50, the PDT server 20 queries the health app server 30 to determine whether there is any health data associated with the signed-up patient's Apple ID or Google account. In this embodiment, the contact point is the health application server 30, which has a pre-configured cooperative relationship.

[0097] <Step 312> In the case of Figure 11, the health app server 30 responds to the PDT server 20 with "None". <Step 313> If there is no response, the PDT server 20 requests the user terminal 50 to enter new user information. As a result, the user terminal 50 displays a screen for entering new user information. On the input screen, the user is requested to enter information such as gender, date of birth, marital status or partner status, employment status, medical history or current illnesses, and physical characteristics.

[0098] <Step 314> The user terminal 50 uploads the information entered through the input screen to the PDT server 20. <Step 315> The PDT server 20 registers the entered information as patient data 230 (see Figure 5).

[0099] <Initial setup stage for the patient app (if a health app is being used)> Figure 12 illustrates another example of the processing sequence for the initial setup stage of a patient application. Figure 12 is denoted with corresponding reference numerals for parts corresponding to those in Figure 11. The processing sequence shown in Figure 12 is executed when a patient who is performing the initial setup of the patient app is using the health app.

[0100] <Steps 301-311> The processing steps 301 to 311 are basically the same as the processing sequence explained in Figure 11. However, the patient in Figure 12 was using the health app before being prescribed the patient app. Therefore, in step 302, in addition to the Apple ID or Google account, the user ID of the health app can be used.

[0101] <Step 321> In the case of Figure 12, the health app server 30 has health data 330 (see Figure 7) associated with the patient. Therefore, the health app server 30 notifies the PDT server 20 of the attribute name and corresponding attribute value of the health app data 330C (see Figure 7).

[0102] <Step 322> Next, the PDT server 20 provides the user terminal 50 with a screen for selecting import candidates. On the selection screen, for example, the "attribute name" and the corresponding "attribute value" notified from the health app server 30 are displayed as import candidates. In this embodiment, instead of displaying all "attribute names" and corresponding "attribute values" notified from the health app server 30 as import candidates on the selection screen, only "attribute names" that are identical or corresponding to "attribute names" that exist on the patient app side are selected as import candidates. In other words, in this embodiment, filtering of import candidates is performed at the stage when the selection screen is displayed.

[0103] By presenting import candidates, patients can review the "attribute names" and "attribute values" of the candidates before performing the import. As a result, unwanted information can be prevented from being imported. In this embodiment, all import candidates are initially unselected on the selection screen.

[0104] <Step 323> The user terminal 50 receives the selection of import candidates from the patient and notifies the PDT server 20. <Step 324> The PDT server 20 imports the selected import candidates into the patient data 230 (see Figure 5).

[0105] <Screen transitions during initial setup> Figure 13 illustrates the first half of an example of screen transitions displayed when installing a patient application on the user terminal 50. First, once the patient app installation is complete, the initial screen 500 will be displayed. The initial screen 500 displays a "First-time user" button 501 and an "Existing user" button 502.

[0106] In this embodiment, the "First-time user" button 501 is pressed, and the new registration screen 510 is displayed. The new registration screen 510 is displayed in step 302 (see Figure 12). The new registration screen 510 includes an "Sign in with Apple" button 511, an "Other" button 512, and an "Already using this service?" button 513.

[0107] In Figure 13, signing in with an Apple ID is the default. Therefore, the "Sign in with Apple" button 511 is displayed at the very top. The "Other" button 512 is used when the patient wishes to sign in with a Google account or with the health app user ID 330A (see Figure 7).

[0108] If authentication via Apple ID or similar is successful, the account creation screen 520 will be displayed. The account creation screen 520 is a screen that notifies the user that an account (i.e., a user ID 330A for the patient app) has been created. Therefore, the account creation screen 520 shown in Figure 13 displays the explanatory text 521 that says "Your account has been created" and "If you have a prescription code received from a medical institution, you can start treatment," as well as a "Get Started" button 522.

[0109] Figure 14 illustrates the latter half of an example of screen transitions displayed when installing a patient application on the user terminal 50. When the "Start" button 522 (see Figure 13) is pressed, the initial setup screen 530 is displayed. This initial setup screen 530 corresponds to steps 305 to 306 (see Figure 12). The initial setup screen 530 shown in Figure 14 includes an explanatory text 531, a "Scan QR code (registered trademark)" button 532, a "Prescription code input field" 533, and a "Submit prescription code" button 534. Note that instruction 531 states, "Please enter the prescription code received from the medical institution using one of the following methods."

[0110] After reading this instruction 531, the patient can choose to either scan the QR code or manually enter the prescription code. Incidentally, the "QR code reading" button 532 is labeled "Activate camera and read QR code." When the "QR code reading" button 532 is pressed, the camera is activated, and it becomes possible to read a QR code containing the prescription code and the URL (=Uniform Resource Locator) information of the PDT server 20.

[0111] The QR code to be read is printed on a document handed to the patient by a doctor or other medical professional during the consultation. When the QR code is read correctly, prescription code 330A is sent to the PDT server 20 (see Figure 12). When manually entering the prescription code, the patient enters the received prescription code 330A into the "Prescription Code Input Field" 533 and operates the "Send Prescription Code" button 534. The prescription code 330A is then sent to the PDT server 20.

[0112] When prescription code 330A is sent to the PDT server 20 by any method, the PDT server 20 performs an authentication process for prescription code 330A. This process corresponds to step 307 (see Figure 12). If authentication is successful, the query in step 311 (see Figure 12) will be executed. If health data linked to a patient who has been prescribed the patient app is found, the data import screen 540 is displayed. The data import screen 540 corresponds to the selection screen in step 322 (see Figure 12).

[0113] The data import screen 540 displays an explanatory text 541 that describes the existence of importable data and the tasks required of the patient. In the case of Figure 14, the explanatory text 541 reads, "Data has been detected. Importing this data will input it into the subsequent medical interview. Please check if the data is correct." In addition, on the data import screen 540, "ABC Health App" is displayed as the name of the app from which the data was imported 542. Furthermore, the last update date and time is displayed as 543, with "2024.06.20 19:01".

[0114] By verifying the name of the source app (542) and the last modified date (543), patients can determine whether the data being imported is appropriate. Displaying the name of the source app (i.e., the name of the health app) allows for verification by the patient, unlike when the import is performed with the source health app remaining a black box.

[0115] Furthermore, the display of the last modified date (543) makes it easier to determine the relevance of the imported data, unlike when the import is performed without knowing the last modified date. For example, if the last modified date is more than a year ago and there have been significant changes in the patient's life or physical condition during that time, it becomes easier to notice that the imported data does not match the current state or situation.

[0116] The data import screen 540 displays the import candidate selection field 545. This field displays the import candidate data detected from the source, indicated by attribute name and attribute value. Each import candidate also displays a check box for selection. Figure 14 shows six import candidates. In Figure 14, the attribute names corresponding to each import candidate are "Physical Sex," "Date of Birth," "Marital Status / Partnership," "Occupation," "Medical History, Current Illnesses," and "Does your face turn red when you drink?"

[0117] In Figure 14, the "physical sex" is "male," and it is selected as the import target. The "Date of Birth" is "January 1970," and it has been selected for import. "Marriage / Partner" is set to "Yes" and is selected as an import target. "Work" means "having a job." However, it is not selected as an import target. The "medical history and current illnesses" are "hypertension, diabetes." However, these are not selected for import. The question "Does drinking it make your face red?" is answered "Yes, it makes your face red," and it has been selected for import.

[0118] In addition, the data import screen 540 displays a button 546 labeled "Import checked items" and a button 547 labeled "Do not import". When button 546, labeled "Import checked items," is pressed, the selected (i.e., checked) import candidate data is imported into patient data 230 (see Figure 5). If you click button 547, which is labeled "Do not import," the import will not be performed, and the data import screen 540 will be closed. In this case, the new user information input screen will be displayed.

[0119] <Summary> In this embodiment, patients who have been using the health app before starting to use the patient app can skip entering at least some of the information during the initial setup of the patient app by reusing the information recorded through the health app. In other words, they can avoid having to perform redundant initial setup procedures for both the health app and the patient app. As a result, patients can smoothly begin treatment using the patient app. In other words, the time required for the initial setup is reduced.

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

[0121] (2) The processor in the above-described embodiment refers to a processor in a broad sense and includes general-purpose processors (for example, CPUs, as well as specialized processors (for example, 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.

[0122] (3) In the embodiment described above, the attribute names and attribute values ​​of the health data to be imported are displayed in the import candidate selection field 545 (see Figure 14). However, you may use the attribute names from the patient data source for the import when specifying the attribute names.

[0123] (4) In the embodiment described above, the selection field 545 for import candidates (see Figure 14) assumes that the patient selects the import targets one by one. However, the patient may also remove the import candidates that they do not want to import one by one from a state where all import candidates are targets for import.

[0124] (5) In the above-described embodiment, the PDT server 20 (see Figure 1) obtains import candidate data from the health application server 30 (see Figure 1). However, the data for import candidates may also be obtained from the user terminal 50 (see Figure 1) operated by the patient who starts using the patient app. Figure 15 illustrates another embodiment of the processing sequence for the initial setup stage of the patient application. In Figure 15, parts corresponding to those in Figure 12 are indicated by corresponding reference numerals.

[0125] Steps 301 to 309 in Figure 15 are the same as in Figure 12. In Figure 15, the PDT server 20, after enabling the patient application on the user terminal 50, queries the user terminal 50 to inquire whether or not it is using the health application (step 331). This query is also executed after detecting that the patient application has been enabled on the user terminal 50. This query may be executed automatically as an exchange between the PDT server 20 and the user terminal 50. In this case, the query exchange will not be displayed on the user terminal 50's display screen.

[0126] However, the patient may be notified of the inquiry through a pop-up display. For example, an inquiry screen requesting permission to access the health app's data may be displayed between the initial setup screen 530 (see Figure 14) and the data import screen 540 (see Figure 14). In the case of Figure 15, the patient who received a prescription for the patient app has a history of using the health app. Therefore, the user terminal 50 notifies the PDT server 20 of the attribute name and corresponding attribute value of the health app data 330C (see Figure 7) (step 332). The subsequent processing steps (i.e., steps 322 to 324) are the same as in Figure 12.

[0127] (6) In the above-described embodiment and other embodiments (5), the import of health data 330 (see Figure 7) into the patient application is controlled by the PDT server 20 (see Figure 1). However, the patient app may also have a function to control the import of health data 330 into the patient app and its upload to the PDT server 20. Figure 16 illustrates another embodiment of the processing sequence for the initial setup stage of the patient application. In Figure 16, parts corresponding to those in Figure 12 are indicated by corresponding reference numerals.

[0128] Steps 301 to 309 in Figure 16 are the same as in Figure 12. In the case of Figure 16, when the patient app is activated (the activation of the patient app is detected), the user terminal 50, as a function of the patient app, checks whether or not the health app is being used on its own terminal (step 341). In this case as well, the process may be executed as an internal process of the patient app. That is, it is possible to design the app so that it does not require the patient to confirm whether or not they are using the health app on their device or to grant permission to access their health data. Alternatively, a screen requesting permission to access the health data 330 may be displayed on the user terminal 50's display screen.

[0129] If the user has previously used the health app, the user terminal 50 retrieves the attribute names and corresponding attribute values ​​of the health app data (step 342) and displays a screen for selecting the data to import (step 343). For example, the user terminal 50 displays the data import screen 540 (see Figure 14). Next, the user terminal 50 imports the selected data into the patient data (step 344).

[0130] Furthermore, the user terminal 50 uploads the imported data to the PDT server 20 (step 345). Note that the timing of the data upload is arbitrary and could be, for example, at the next time the patient signs in to the patient app. The PDT server 20 imports the uploaded data into the patient data 230 (see Figure 5) managed on its own terminal (step 346).

[0131] (7) In the above-described embodiment, the diseases targeted by the health app and the patient app are arbitrary. That is, the diseases targeted by the health app and the patient app may be lifestyle-related diseases or non-lifestyle-related diseases. Lifestyle-related diseases include, for example, alcohol dependence, 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.

[0132] (8) In the aforementioned data import screen 540, "physical sex," "date of birth," "marriage / partner," "occupation," "medical history, diseases being treated," and "whether your face turns red when you drink" are listed as import candidates, but other data in the health app data 330C (see Figure 7) may also be listed as import candidates. For example, "Disease Learning Stages" 330C4 (see Figure 7), which is an example of information related to acquiring knowledge about diseases, could be considered as an import candidate.

[0133] Alternatively, the measured value 330C5 (see Figure 7) may be used as an import candidate. Alternatively, activity log 330C6 (see Figure 7) may be used as an import candidate. Additionally, "Reflection Record" 330C7 (see Figure 7), which is an example of a reflection on an action, may be considered as an import candidate. Alternatively, "Lifestyle Record" 330C8 (see Figure 7), which is an example of information related to lifestyle habits, may be considered as an import candidate.

[0134] (9) In the embodiments described above, a patient app or a health 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.

[0135] (10) In the above embodiment, it is assumed that the health app server 30 (see Figure 1) which is the source of the import and the PDT server 20 (see Figure 1) which is the destination of the import are different. However, the health app server 30 from which the data is imported and the PDT server 20 to which the data is imported can be the same server.

[0136] (11) In the embodiments described above, the process of making at least a portion of the health data associated with the patient (i.e., the user) that has been prescribed by the patient app available for use in the patient app was described as "import." Import here means so-called copying, but it may also mean data movement.

[0137] <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 detects the activation of a medical device program on a terminal operated by a user whose behavior is altered, and uses at least a portion of the data of a non-medical device program associated with the user for the initial setup of the medical device program. This information processing device provides a mechanism that reduces the effort required for users to perform initial setup of medical device programs.

[0138] (((2))) The processor is an information processing device as described in (((1))), which controls the initial settings based on the result of determining whether or not data for a non-medical device program associated with the user is available. This information processing device can perform initial setup depending on whether or not data for non-medical device programs is available.

[0139] (((3))) The information processing device described in (((1))) or (((2))) is an information processing device that uses attribute information recorded through a non-medical device program for the initial setup of a medical device program. This information processing device reduces the effort required for users to input attribute information.

[0140] (((4))) The information processing device described in (((1))) or (((2))) is an information processing device that uses information about medical history recorded through a non-medical device program for the initial setup of a medical device program. This information processing device reduces the effort required for users to input information about their medical history.

[0141] (((5))) The processor is an information processing device as described in (((1))) or (((2))) that uses information about a person's constitution recorded through a non-medical device program for initial setup of a medical device program. This information processing device reduces the effort required for users to input information about their physical constitution.

[0142] (((6))) The information processing device described in (((1))) or (((2))) is an information processing device that uses information regarding the acquisition status of knowledge about diseases recorded through a non-medical device program for the initial setup of a medical device program. This information processing device reduces the effort required for users to input information regarding their knowledge acquisition status of diseases.

[0143] (((7))) The processor is an information processing device as described in (((1))) or (((2))) that uses measurements recorded through a non-medical device program for initial setup of a medical device program. This information processing device reduces the effort required for users to input measurement values.

[0144] (((8))) The information processing device described in (((1))) or (((2))) is a processor that uses behavioral records recorded through a non-medical device program for the initial setup of a medical device program. This information processing device reduces the effort required for users to input their activity records.

[0145] (((9))) The information processing device described in (((1))) or (((2))) is an information processing device that uses the processor's impressions of actions recorded through a non-medical device program for the initial setup of a medical device program. This information processing device can reduce the effort required for users to input their feedback on their actions.

[0146] (((10))) The information processing device described in (((1))) or (((2))) is an information processing device that uses information about lifestyle habits recorded through a non-medical device program for the initial setup of a medical device program. This information processing device can reduce the effort required for users to input information about their lifestyle habits.

[0147] (((11))) The processor is an information processing device as described in (((1))) or (((2))), which presents the user with a screen that accepts the selection of data for a non-medical device program to be used for the initial setup of a medical device program. According to this information processing device, the user can select the data to be used in the initial setup.

[0148] (((12))) The processor is an information processing device as described in (((1))) or (((2))) that presents the user with a screen requesting confirmation of data that will be available through initial setup. This information processing device allows for verification of the accuracy of the data that was initially set before its use began.

[0149] (((13))) A method for providing information in which a computer performs the following processes: detecting the activation of a medical device program on a terminal operated by a user whose behavior is altered; and using at least a portion of the data of a non-medical device program associated with the user for the initial setup of the medical device program. This information provision method allows for the creation of a system that streamlines the initial setup process for medical device programs performed by users.

[0150] (((14))) A program that enables a computer to detect the activation of a medical device program on a terminal operated by a user whose behavior is altered, and to use at least some of the data from a non-medical device program associated with the user in the initial settings of the medical device program. This program provides a mechanism to streamline the initial setup process for medical device programs performed by users. [Explanation of symbols]

[0151] 1…Information processing system, 10…PDT platform, 20…PDT server, 30…Health application server, 40…Doctor terminal, 50…User terminal

Claims

1. It has a processor, The aforementioned processor, Detect the activation of a medical device program on a terminal operated by a user whose behavior is being altered. At least a portion of the data of the non-medical device program associated with the user is used in the initial setup of the medical device program. Information processing device.

2. The aforementioned processor, The initial settings are controlled based on the result of determining whether or not data for the non-medical device program associated with the user is available. The information processing apparatus according to claim 1.

3. The aforementioned processor, The attribute information recorded through the non-medical device program is used in the initial setup of the medical device program. The information processing apparatus according to claim 1 or 2.

4. The aforementioned processor, The medical history information recorded through the non-medical device program is used in the initial setup of the medical device program. The information processing apparatus according to claim 1 or 2.

5. The aforementioned processor, The information regarding physical characteristics recorded through the non-medical device program is used in the initial setup of the medical device program. The information processing apparatus according to claim 1 or 2.

6. The aforementioned processor, Information regarding the acquisition status of knowledge about diseases, recorded through the non-medical device program, is used in the initial setup of the medical device program. The information processing apparatus according to claim 1 or 2.

7. The aforementioned processor, The measured values ​​recorded through the non-medical device program are used in the initial settings of the medical device program. The information processing apparatus according to claim 1 or 2.

8. The aforementioned processor, The behavioral records recorded through the non-medical device program are used in the initial setup of the medical device program. The information processing apparatus according to claim 1 or 2.

9. The aforementioned processor, The feedback on the actions recorded through the non-medical device program is used in the initial setup of the medical device program. The information processing apparatus according to claim 1 or 2.

10. The aforementioned processor, The lifestyle information recorded through the non-medical device program is used in the initial setup of the medical device program. The information processing apparatus according to claim 1 or 2.

11. The aforementioned processor, The system presents the user with a screen that allows them to select data for the non-medical device program to be used for the initial setup of the medical device program. The information processing apparatus according to claim 1 or 2.

12. The aforementioned processor, The system presents the user with a screen requesting confirmation of the data that will become available through the initial setup described above. The information processing apparatus according to claim 1 or 2.

13. Computers A process for detecting the activation of a medical device program on a terminal operated by a user whose behavior is being altered, A process that uses at least a portion of the data of the non-medical device program associated with the user in the initial setup of the medical device program, A method for providing information to carry out the task.

14. On the computer, A function to detect the activation of a medical device program on a terminal operated by a user whose behavior is being altered, A function to use at least a portion of the data of the non-medical device program associated with the user in the initial settings of the medical device program, A program to achieve this.

Images