Information processing device, information provision method, and program

Abstract

This system provides a mechanism to restrict healthcare professionals' access to health-related data, including data recorded through user terminals. [Solution] An information processing device having a processor, the processor detects when a user who has changed their behavior visits a medical institution, and after detecting the visit, outputs health-related data, including data recorded through a user terminal that executes a program corresponding to the disease, to the medical institution's terminal.

Description

Technical Field

[0006] , ,

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

Background Art

[0002] Today, there are application programs (hereinafter also referred to as "programs") that can be used for health promotion and medical treatment. Programs that do not require approval under the Pharmaceutical Affairs Law are called, for example, healthcare apps. On the other hand, programs that require approval under the Pharmaceutical Affairs Law are called treatment apps.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] User data including data recorded through healthcare apps and treatment apps may contain various information related to daily life. Therefore, there is also a desire to restrict access to the data for medical staff except during medical examinations.

[0005] The present disclosure provides a mechanism for restricting medical staff's access opportunities to health-related data including data recorded through a user terminal.

Means for Solving the Problems

[0006] The invention described in claim 1 is an information processing device having a processor, the processor detecting a visit to a medical institution by a user who is changing their behavior, and after the detection of the visit, outputting health-related data, including data recorded through a user terminal that executes a program corresponding to the disease, to the terminal of the medical institution. The invention described in claim 2 is the information processing device described in claim 1, wherein the processor treats the input of the consultation date as the detection of the consultation. The invention described in claim 3 is an information processing device according to claim 1, wherein the processor treats the user terminal being located within a predetermined location range for the medical institution as the detection of a medical visit. The invention described in claim 4 is an information processing device according to claim 3, wherein the processor treats the user terminal being located within the location range for a predetermined period of time or longer as the detection of receiving a call. The invention described in claim 5 is an information processing device according to claim 1, wherein the processor treats the user terminal's permission to access the health data as the detection of a medical visit. The invention described in claim 6 is an information processing device according to any one of claims 1 to 5, wherein the processor outputs the health-related data to the terminal of the medical institution, in addition to detecting the medical examination, provided that the viewing conditions set through the terminal of the medical institution are met. The invention described in claim 7 is an information processing device according to claim 1, wherein the processor displays the health data on the terminal of the medical institution after detecting the medical examination. The invention described in claim 8 is an information processing device according to claim 1, wherein the processor permits printing of the health data on the terminal of the medical institution after detection of the medical examination. The invention described in claim 9 is an information provision method in which a computer performs the following processes: detecting a visit to a medical institution by a user whose behavior has been altered; and, after the detection of the visit, outputting health-related data, including data recorded through a user terminal that executes a program corresponding to the disease, to a terminal of the medical institution. The invention described in claim 10 is a program for a computer that enables the following functions: a function to detect a visit to a medical institution by a user whose behavior has been altered; and a function to output health-related data, including data recorded through a user terminal that executes a program corresponding to the disease, to a terminal of the medical institution after the detection of the visit. [Effects of the Invention]

[0007] One form of this disclosure provides a mechanism to restrict healthcare professionals' access to health-related data, including data recorded through user terminals. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram illustrates an example of the overall configuration of the information processing system according to Embodiment 1. [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 Embodiment 1. [Figure 8] This diagram illustrates an example of a management screen for managing the usage status of patient applications, which is displayed on the output device of a physician's terminal. [Figure 9] This diagram illustrates an example of a viewing screen display with the patient data display area masked. [Figure 10] This diagram illustrates the consultation date registration screen and the viewing screen with the masked image removed. [Figure 11]This is a diagram for explaining another display example of a browsing screen in which the display area of patient data is masked. [Figure 12] This is a diagram for explaining an example of a processing sequence in Embodiment 2. [Figure 13] This is a diagram for explaining an example of display control of a browsing screen in Embodiment 2. [Figure 14] This is a diagram for explaining an example of a processing sequence in Embodiment 3. [Figure 15] This is a diagram for explaining an example of an operation for permitting access to patient data. [Figure 16] This is a diagram for explaining an example of display control of a browsing screen in Embodiment 3. [Figure 17] This is a diagram for explaining an example of a processing sequence in Embodiment 3. [Figure 18] This is a diagram for explaining an example of a screen display for requesting permission to view patient data. [Figure 19] This is a diagram for explaining an example of a processing sequence in Embodiment 5. [Figure 20] This is a diagram for explaining an example of a setting screen for setting restrictions on viewing patient data. [Figure 21] This is a diagram for explaining an example of a screen displayed on a doctor's terminal that has instructed viewing of patient data or on a terminal of a doctor or the like who has set viewing restrictions. [Figure 22] This is a diagram for explaining an example of a setting screen for setting a time zone during which viewing of patient data is permitted. [Figure 23] This is a diagram for explaining an example of a screen displayed on a doctor's terminal that has instructed viewing of patient data or on a terminal of a doctor or the like who has set a time zone during which viewing is permitted. [Figure 24] This is a diagram for explaining an example of a processing sequence in other embodiments. [Figure 25] This is a diagram for explaining an embodiment in which "health-related data" recorded through a non-patient app and "health-related data" recorded through a patient app are used in combination. [Figure 26]This diagram illustrates another embodiment that uses both "health data" recorded through a non-patient app and "health data" recorded through a patient app. [Modes for carrying out the invention]

[0009] <Terminology> First, we will explain the terminology used in the embodiments described later. A "program designed to encourage behavioral change" refers to a program intended to encourage a change in a person's behavior. However, this program does not guarantee a change in a person's behavior. Whether or not a person's behavior actually changes depends on the user of the program. Therefore, a program designed to encourage behavioral change can also be described as a program that supports behavioral change.

[0010] This type of program includes programs classified as medical devices and programs classified as non-medical devices. Programs classified as medical devices are examples of programs that require a prescription, while programs classified as non-medical devices are examples of programs that do not require a prescription. Furthermore, programs classified as non-medical devices are not limited to programs that encourage behavioral change; they may also include programs that have a function to record health-related data. Programs that encourage behavioral change or have a function to record health data include programs that can be downloaded from app stores. These types of programs may also be used by private companies, public organizations, etc., for the health management of their employees.

[0011] Some programs classified as non-medical devices are used in medical institutions. The "purpose of the app" refers to the effect that should be achieved by using a program that promotes behavioral change. The purpose of the app varies depending on the disease to which the program that promotes behavioral change corresponds. For example, the purpose of the app may include improving lifestyle habits, maintaining improved lifestyle habits, and maintaining 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.

[0021] "Medical history" includes, for example, the date treatment began, the date of consultation, the content of the treatment, and advice given. 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 showing the progress toward goals set by a doctor for each patient, for example. "Goal achievement status" may also refer to information showing the progress toward goals set by the patient themselves, for example. "Goal achievement status" may also refer to information showing the progress toward goals presented by a patient app for each patient, for example. 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 diagnosis and treatment 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 1> <Overall System> Figure 1 is a diagram illustrating an example of the overall configuration of the information processing system 1 according to Embodiment 1. 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 PDT platform services. The PDT platform 10 and the PDT server 20 are connected via a network (not shown) that enables communication. For reference, the network could include, for example, a LAN (Local Area Network), the Internet, or a mobile communication system (4G, 5G, etc.).

[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 hypertension. 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. The physician terminal 30 is an example of an information processing device. 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 is an example of an information processing device. The patient terminal 40 uploads patient application data recorded through the patient application to the corresponding PDT server 20. Figure 1 shows only one patient terminal 40 as a representative example. Note that the patient terminal 40 is an example of a user terminal. The patient terminal 40 may be, for example, a smartphone, smart glasses, a desktop computer, a laptop computer, or a tablet computer.

[0044] <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 is an example of an information processing device. 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 device 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 displaying a list of usage statuses of the patient app. In addition, the auxiliary storage device 13 also stores data for managing 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] <PDT Platform Management Data> FIG. 3 is a diagram for explaining an example of 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 / medical treatment 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 company number, and version of the patient app may be stored.

[0048] The prescription code  130A is issued each time a prescription is notified from the doctor terminal 30. 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. 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 11 executes the program through the cooperation of the multiple CPU cores. The semiconductor memory 22 stores UEFI and other information. 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.

[0052] 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. For example, there is a doctor app among the other programs. The doctor app is a program that generates a browsing screen for patient data corresponding to patients treated by doctors and the like.

[0053] In addition, the auxiliary storage device 23 also records 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 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.

[0054] <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. Note that the patient data 230 shown in FIG. 5 assumes data of a hypertension patient. In the patient data 230 shown in FIG. 5, measured values and other information recorded through a program for hypertension are stored. In the case of this embodiment, the program for hypertension assumes a patient app as a medical device.

[0055] 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. In the case of this embodiment, the patient app data 230C means management data of the patient app and data recorded by the patient through the patient app. The prescription code 230A records the prescription code 130A (see FIG. 3) issued by the PDT platform 10 (see FIG. 1). The prescription code 130A is registered by the patient at the start of using the patient app (that is, at the time of new registration). 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.

[0056] The patient app data 230C shown in Figure 5 includes measurement value / measurement date and time 230C1, reflection / input date and time 230C2, current step of the treatment program 230C3, treatment program implementation history 230C4, behavioral goal 230C5, target value 230C6, outpatient record 230C7, and medication record 230C8. Note that the items shown as examples do not have to be all of the patient app data 230C; some may be included, or other items may be included as well. 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.

[0057] The "Review / Input Date & Time 230C2" field records a review of the day's activities and the input date and time. The review includes, for example, the level of physical condition, stress level, length of sleep, weight, amount of alcohol consumed, and the content of the activities performed. The content of the activities consists of the genre of the activity performed and text input. Other possible labels include, for example, "sleep," "stress," "moderate alcohol consumption," and "other." In this embodiment, the genre of the activity performed is recorded by checking buttons labeled with "salt reduction," "weight loss," "exercise," etc. Text input allows for free input of content, emotions, etc., that cannot be recorded by checking buttons.

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

[0059] 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 those presented by the patient app as the treatment program progresses. For example, behavioral objective 230C5 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.

[0060] The target value 230C6 is recorded in the "Target Blood Pressure Value" column 322 (see bottom of Figure 11) on the patient data viewing screen 310 (see bottom of Figure 11), where the value set by the physician or other medical professional is recorded. The "Target Blood Pressure Value" column 322 is an example of a quantitative target, as it is given as a numerical value. Outpatient record 230C7 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 30 (see Figure 1). Medication record 230C8 contains information about the taking of prescribed medications.

[0061] <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, communication interface 38 / 48, and position sensor 49. Each device is connected via a bus or other signal lines.

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

[0063] 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 patient application data 230C (see Figure 5). 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.

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

[0065] The position sensors 39 / 49 are sensor devices that acquire the current location of each terminal. For example, the position sensors 39 / 49 may be sensors that receive radio waves from GPS (Global Positioning System) satellites to acquire the current location. However, the position sensors 39 / 49 may also be sensors that support other acquisition methods. Other location acquisition methods include, for example, Wi-Fi positioning, beacon positioning, and base station positioning. Wi-Fi positioning uses beacon signals transmitted from a Wi-Fi access point to determine the current location. Beacon positioning uses BLE (Bluetooth Low Energy) beacon signals. Base station positioning uses information from a telecommunications carrier's base station to determine the current location. The position sensors 39 / 49 do not need to be limited to a single method, and may support multiple methods.

[0066] <Processing Sequence> The following section describes the control of patient data output to the physician terminal 30 (see Figure 1) using Figures 7 to 10. Figure 7 is a diagram illustrating an example of a processing sequence in Embodiment 1. In Figure 7, the symbol S represents a step.

[0067] <Step 101> The patient records measurements and other data from the patient app's operation screen. For example, the patient records measurements, reflections, behavioral goals, target values, outpatient records, and medication records. This data is stored as patient app data in the semiconductor memory 42 (see Figure 6) and auxiliary storage device 43 (see Figure 6). As mentioned above, the patient app data may also include data obtained by processing this data.

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

[0069] <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 as a result of the patient recording operations on the patient app.

[0070] <Step 104> When a doctor or other medical professional logs into the PDT platform 10 via the doctor's terminal 30, the PDT platform 10 displays a screen on the doctor's terminal 30 showing the status of the patient's application usage. Figure 8 illustrates an example of a patient application usage status management screen 300 displayed on the output device 37 (see Figure 6) of the physician terminal 30 (see Figure 1).

[0071] The management screen 300 shown in Figure 8 is an example of a management screen that displays a list of usage statuses of patient applications prescribed to patients by a physician or other person operating the physician terminal 30. Furthermore, the management screen 300 may display only the usage status of patient apps prescribed by the physician operating the physician terminal 30, or it may display the usage status of patient apps prescribed by the medical institution to which the physician operating the physician terminal 30 belongs. In other words, the management screen 300 may also include the usage status of patient apps prescribed by other physicians belonging to the same medical institution.

[0072] In addition, the management screen 300 may also 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). Furthermore, technically, it is possible to include all patient information managed by the PDT platform 10 in the management screen 300. However, in that case, it is desirable to enable filtering and sorting of patients displayed on the management screen based on the ID of the physician operating the physician terminal 30.

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

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

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

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

[0077] The "Details" button 303 is used to display the patient data viewing screen 310 (see Figure 10, lower section). The "Details" button 303 is placed for each row corresponding to a patient. When the "Details" button 303 is pressed, the patient data viewing screen for the patient corresponding to the "Details" button 303 is displayed. The "New Prescription" button 304 is used when prescribing a patient app to a patient. When the "New Prescription" button 304 is pressed, a screen appears for entering the app name, patient name, gender, date of birth, etc. The name of the prescribing physician is also registered at the same time. The "Close" button 305 is used to close the administration screen 300 shown in Figure 8.

[0078] <Step 105> Let's return to the explanation of Figure 7. The physician terminal 30 accepts patient selection on the aforementioned management screen 300 (see Figure 8). Specifically, the physician terminal 30 accepts operation of the "Details" button 303 (see Figure 8). For example, the physician terminal 30 accepts operation of the "Details" button 303 corresponding to Ms. M, for whom more than five months have passed since the prescription date. Upon receiving the operation of the "Details" button 303, the physician terminal 30 accesses the PDT server 20 of the patient app prescribed to the patient corresponding to the operated "Details" button 303.

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

[0080] <Step 106> Upon receiving access from the physician terminal 30, the PDT server 20 outputs a viewing screen 310 (see Figure 9) with the patient data display area masked to the physician terminal 30. In this embodiment, the viewing screen 310 with the patient data display area masked is provided as the initial screen of the physician application. For example, the entire display area corresponding to the patient application data is subject to masking. In this embodiment, information portions common to the management screen 300 (see Figure 8) are excluded from the masking. However, information portions common to the management screen 300 (see Figure 8) may also be subject to masking.

[0081] Figure 9 illustrates an example of the display of the viewing screen 310 with the patient data display area masked. The upper part of the viewing screen 310 shown in Figure 9 contains the patient information field 311. In Figure 9, the patient information field 311 displays that the medical record number is "16345", the patient's name is "Ms. M", it has been 5 months since the prescription was issued, and the prescription date is "2024.1.18". This information can also be confirmed on the management screen 300 (see Figure 8).

[0082] In addition, most of the viewing screen 310 is obscured by a masking image 312. In the case of Figure 9, the masking image 312 obscures the entire area except for the patient information field 311 and the operation button 313 labeled "Go to consultation date registration screen". The masked image 312 shown in Figure 9 displays the messages "Please enter the consultation date" and "You can view the data once you enter the consultation date." This indicates that entering the consultation date is a requirement for viewing patient data. In other words, this message prompts the user to enter the consultation date.

[0083] <Step 107> Let's return to the explanation of Figure 7. The physician's terminal 30 accepts input of the consultation date. Input of the consultation date is performed through the consultation date registration screen 320 (see Figure 10), which is opened by operating the operation button 313 (see Figure 9) on the viewing screen 310 (see Figure 9). Figure 10 illustrates the consultation date registration screen 320 and the viewing screen 310 with the masking image 312 (see Figure 9) removed. Figure 10 is denoted with corresponding reference numerals for parts that correspond to those in Figure 9.

[0084] The consultation date registration screen 320 shown in the upper part of Figure 10 consists of a patient information field 311, a masking image 314, a "Register Consultation Date" field 315, a "Consultation History" field 316, a "Return to Previous Screen" button 317, and an "End Consultation" button 318. In the consultation date registration screen 320 shown in Figure 10, the left half of the screen is obscured by a masking image 314. The area obscured by the masking image 314 displays, for example, the content of an agreement made between patient M and the doctor during a past consultation. In this embodiment, the agreement between the doctor and the patient is an example of patient app data recorded through the patient app. However, if the agreement between the doctor and the patient is recorded through the doctor's terminal 30, the masking image 314 may be hidden.

[0085] In Figure 10, the "Register Examination Date" field 315 displays the date of the current examination and a selection button indicating whether or not insurance coverage is desired for this examination. In Figure 10, the examination date can be entered from a calendar, and "2024 / 6 / 15" is entered. In Figure 10, doctors can choose whether or not to claim insurance coverage for this consultation. In the case of "Registration of Consultation Date" column 315 shown in Figure 10, "Yes" is selected to claim insurance coverage. However, even if a doctor wants to claim insurance coverage, if the patient's record of patient data does not meet the calculation requirements, the medical fee will not be charged.

[0086] The "Medical Examination History" column 316 shown in Figure 10 displays multiple medical examination dates, including the most recent examination date, and the results of the insurance calculation. The "Return to previous screen" button 317 is used to return to the patient data viewing screen 310 (see Figure 9). The "End Consultation" button 318 is used to close the consultation date registration screen 320 and end the consultation. Closing the consultation date registration screen 320 also means closing the patient data viewing screen 310.

[0087] <Step 108> Let's return to the explanation of Figure 7. When the date of the consultation is entered in the "Registration of Consultation Date" field 315 (see Figure 10), the doctor's terminal 30 notifies the PDT server 20. When the PDT server 20 confirms the input of the consultation date, it sets a consultation flag. In this embodiment, the PDT server 20 considers the input of the consultation date as "detection of a consultation."

[0088] <Step 109> Next, the PDT server 20 outputs the unmasked viewing screen 310 (see Figure 10). That is, the PDT server 20 displays the unmasked viewing screen 310 on the physician's terminal 30. In this embodiment, "detection of a visit" is confirmed in step 108. Therefore, the display of the browsing screen 310 in step 109 is performed "after detection of a visit".

[0089] The viewing screen 310 shown in the lower part of Figure 10 consists of a patient information section 311, a measurement results display section 321, a "blood pressure target value" section 322, a "reflection" section 323, an "activity record" section 324, a "go to consultation date registration screen" button 313, and a "print" button 325. The measurement results display area 321 shown in Figure 10 displays the average blood pressure measured at home as both a numerical value and a graph. Daily measurements are recorded through the patient app.

[0090] In Figure 10, the average values ​​for two intervals are shown: "8 weeks ago to 4 weeks ago" and "4 weeks ago to the previous day." Here, "the previous day" refers to the day before the current date and time when the viewing screen 310 was opened. Doctors and other medical professionals can check the progress of treatment by viewing the values ​​displayed in the "measurement results display area" 321. Figure 10 shows that the blood pressure target value 322 indicates a target systolic blood pressure of less than 125 mmHg and a target diastolic blood pressure of less than 75 mmHg for home blood pressure measurements. Note that blood pressure targets may vary depending on gender, co-existing medical conditions, age, and other factors.

[0091] In Figure 10, the blood pressure target value column 322 has a "Change Target Value" button. Only doctors or other qualified medical professionals can change the target value. The "Reflection" section 323 shown in Figure 10 displays records of mood and physical condition. Reflection information is recorded in diary format through the patient app. In Figure 10, three days' worth of reflections are displayed. For example, on June 14th, it is recorded that the mood was normal and the physical condition was poor. On June 13th, it is recorded that the mood was normal and that soup was left uneaten during a meal. On June 12th, it is recorded that the mood was extremely bad and the physical condition was also poor.

[0092] The "Activity Record" section 324 shown in Figure 10 displays activity records such as the number of days the patient app was used, the number of days salt reduction in meals was recorded, and the number of days weight loss was recorded. When the "Print" button 325 is pressed, a print screen (not shown) opens. On the print screen, you can select a "Printer" or "Data File" as the output destination. Data files include, for example, PDF (Portable Document Format) files. PDF is a registered trademark. As described above, once a doctor or other medical professional enters the date of the consultation, they can view the information recorded by the patient M, who is the subject of the consultation, through the patient app via the viewing screen 310, which has the masking image 312 (see Figure 9) removed, as shown in Figure 10.

[0093] <Step 110> Let's return to the explanation of Figure 7. In this embodiment, the physician terminal 30 accepts the operation of the print button 325 (see Figure 10) while viewing the viewing screen 310. This operation is notified to the PDT server 20 via the viewing screen 310.

[0094] <Step 111> The PDT server 20 permits printing if the reception flag is set, and denies printing if the reception flag is not set. In other words, the PDT server 20 permits printing on the condition that the reception flag is set. In this embodiment, the reception flag is set in step 108. Therefore, the PDT server 20 permits printing.

[0095] <Step 112> When the physician's terminal 30 receives permission from the PDT server 20, it executes a print command. This allows the viewer to print the viewing screen 310 or output it to a data file.

[0096] <Summary> In this embodiment, a doctor or other medical professional examining patient M cannot view patient M's patient data unless they enter the examination date through the examination date registration screen 320 (see upper part of Figure 10). In other words, unless patient M's visit is detected, the display area for patient M's patient data is hidden by a masking image 312 (see Figure 9). On the other hand, once the consultation date is entered by a doctor or other medical professional, the masking is removed, and the display area of ​​the patient data that was hidden by the masking image 312 becomes viewable.

[0097] In other words, the information processing system 1 in this embodiment treats the input of the consultation date by a doctor or other medical professional as "detection of a consultation." The consultation date entered through the consultation date registration screen 320 (see upper part of Figure 10) is recorded in the PDT server 20 (see Figure 1) as part of the patient data 230 (see Figure 4), for example. Furthermore, even if the entered consultation date can be deleted afterward, a record of the deletion history is stored in the PDT server 20.

[0098] Therefore, it is unlikely that a consultation date will be entered unrelated to an actual consultation. In other words, entering a consultation date suggests a high probability of having visited a medical institution. Thus, in this embodiment, access to highly confidential patient data can be restricted except during medical examinations while viewing patient data. In other words, opportunities for healthcare professionals to access patient data for purposes other than medical examinations can be restricted. By adopting this system, we can increase the sense of security for users who do not wish for their patient data to be used outside of consultations.

[0099] For example, doctors can make patients feel that their data is being protected by showing them that the masked image 312 (see Figure 9) on the viewing screen 310 (see Figure 9) will not be removed unless they enter the date of their consultation. Furthermore, limiting access to patient data to consultations is expected to reduce the risk to doctors and other medical professionals regarding the leakage of patient data.

[0100] <Other screen examples> In the case described above, doctors and other medical professionals were required to input the consultation date through the consultation date registration screen 320 (see upper part of Figure 10). Specifically, doctors and other medical professionals were required to display the consultation date registration screen 320 (see upper part of Figure 10) by operating the operation button 313 (see Figure 9) that was not obscured by the masking image 312 (see Figure 9). However, it is also possible to input the consultation date on a masking image 312A (see Figure 11) that hides the patient data portion of the viewing screen 310 (see Figure 9).

[0101] Figure 11 illustrates another example of the viewing screen 310 with the patient data display area masked. In the case of the viewing screen 310 shown in Figure 11, the consultation date can be entered on the masked image 312A. The masked image 312A shown in Figure 11 also displays the messages, "Please enter the date of your consultation" and "Once you enter the date of your consultation, you will be able to view the data." This display content is the same as that of masked image 312 (see Figure 9).

[0102] The differences between masking image 312A and masking image 312 are that masking image 312A includes an input field 321A1 for the date of consultation and a "Confirm" button 312A2, and that masking image 312A also hides the operation button 313. In the case of Figure 11, the consultation date can also be entered from the calendar. When the doctor or other medical professional operates the "Confirm" button 312A2, the doctor or other medical professional's entry of the consultation date is confirmed.

[0103] In Figure 11, when the "Confirm" button 312A2 is pressed, the screen switches to the viewing screen 310 with the masked image 312A removed. In this example, the number of screen transitions is one less compared to displaying the dedicated consultation date registration screen 320.

[0104] <Embodiment 2> Embodiment 2 will now be described. The information processing system according to this embodiment is the same as the information processing system 1 (see Figure 1) described in Embodiment 1. In this embodiment, we will describe a case where the presence of a patient terminal 40 (see Figure 1) carried by the patient within a medical institution for a predetermined period of time or longer is treated as "detection of a medical visit."

[0105] <Processing Sequence> The following section describes the control of patient data output to the physician terminal 30 (see Figure 1) using Figures 12 to 13. Figure 12 is a diagram illustrating an example of a processing sequence in Embodiment 2. Note that parts in Figure 12 are denoted by reference numerals corresponding to those in Figure 7.

[0106] <Steps 101-105> Steps 101 to 105 are the same as in Embodiment 1. That is, the patient records measurements, reflections, etc., through a patient application running on the patient terminal 40. The patient terminal 40 then uploads the patient application data to the PDT server 20. The PDT server 20 also stores the patient application data. Furthermore, doctors and other medical professionals access the PDT platform 10 through the physician terminal 30 and select a patient from its management screen 300 (see Figure 8).

[0107] <Step 121> When the PDT server 20 receives access from the physician's terminal 30, it generates a patient data viewing screen 310 (see lower part of Figure 10). In this embodiment, even though the PDT server 20 generates the viewing screen 310, it does not output the generated viewing screen 310 to the physician's terminal 30 at this stage. One reason is that the viewing screen 310 generated in step 121 does not have a masking image 312 (see Figure 9) attached to it. Another reason is that the PDT server 20 in this embodiment may detect the patient's examination using a different mechanism than in Embodiment 1.

[0108] <Step 122> The PDT server 20 requests information about the patient terminal 40's current location. This information is provided, for example, by latitude and longitude, or by latitude, longitude, and altitude. <Step 123> The patient terminal 40 sends back the information of its current location, acquired by the position sensor 49 (see Figure 6), to the PDT server 20.

[0109] <Step 124> The PDT server 20 outputs a patient data viewing screen to the physician terminal 30 if the current location meets the output conditions, and notifies the physician terminal 30 that viewing is not permitted if the current location does not meet the output conditions. The output conditions are an example of a state that is considered to be "detection of a medical visit". In this embodiment, there are two output conditions: a position condition and a time condition. The location condition is that the current location of the patient terminal 40 carried by the patient falls within a predetermined location range.

[0110] In this embodiment, the location range is defined as a section within a plane determined based on the location of the medical institution. The information defining the section may include altitude. Altitude is useful, for example, for distinguishing the number of floors within a building. The location range may be defined, for example, by the business entity operating the PDT server 20, by each medical institution, or by a doctor or other medical professional. The area and shape of the location range may be determined for each medical institution. A margin is permitted in the location range based on positioning accuracy, etc. In this sense, it also depends on the positioning environment within and around the medical institution.

[0111] The location of a medical institution may be determined, for example, based on the medical institution's premises. When using the premises as the basis, the location range may include not only the inside but also the outside of the premises. The location of a medical facility may be determined based on, for example, the location of the building. When using the building as the basis, the location range may include not only the inside but also the outside of the building. The location of a medical facility may be determined based on a specific floor or room (e.g., waiting room, examination room) within a building. When using a specific floor or room as the basis, the location range may include not only the inside of that floor or room but also the outside (e.g., elevator hall, corridor).

[0112] It is also possible to consider a visit to the hospital as "detected" based solely on location conditions. However, this raises the possibility of detecting a visit to a medical facility as merely passing by one's vicinity. However, the likelihood of doctors or other medical professionals accidentally accessing patient data while passing by a medical facility is small. Therefore, this effectively restricts access to patient data by doctors and other medical professionals outside of consultations. However, in this embodiment, in order to achieve more stringent operation, in addition to satisfying the positional conditions, the time conditions are also required to be satisfied.

[0113] The time condition is that the current location of the patient terminal 40 carried by the patient is within the aforementioned location range for a predetermined period of time or longer. The predetermined period of time here is the threshold required to satisfy the time condition. The designated time could be, for example, 1 minute, 3 minutes, or 5 minutes. Of course, these are just examples, and other times are also acceptable. Note that the longer the time, the higher the level of protection for patient data. On the other hand, if the designated time is made too long, a problem may arise where access to patient data is not permitted even after the consultation has started. By defining time conditions, it is expected that the accuracy of determining whether a visit to the doctor has occurred will improve.

[0114] <Steps 110-112> Steps 110 to 112 are the same as in Embodiment 1. That is, when a doctor or other medical professional presses the print button, the PDT server 20 permits printing on the condition that the consultation flag is set.

[0115] Figure 13 illustrates an example of display control of the browsing screen 310 in Embodiment 2. Figure 13 is denoted with reference numerals corresponding to the parts that correspond to those in Figure 9. Figure 13 illustrates three cases. "Case 1" is a case where patient M is near a medical institution but is outside the area considered to be within the scope of a medical institution visit (the area enclosed by the dashed line). This area enclosed by the dashed line corresponds to the location range defined by the location condition. In "Case 1," the display area for patient data on the viewing screen 310 is obscured by a masking image 312. In Figure 13, the masking image 312 displays the messages "Ms. M is not currently being examined" and "You cannot view Ms. M's patient data."

[0116] "Case 2" is the case where patient M is located within the area considered to be a medical visit, and the duration of stay exceeds the threshold. In other words, it is the case where both the location condition and the time condition are met. Therefore, the entire viewing screen 310 is viewable. "Case 3" is the case where patient M passes the area considered to be a medical visit. Here, "passing the area" means that the time spent in the area considered to be a medical visit is less than the threshold. In "Case 3," as in "Case 1," the display area of ​​the patient data on the viewing screen 310 is obscured by the masking image 312.

[0117] <Summary> In this embodiment, unless the patient is located within a predetermined range of locations for a medical institution for a specified period of time or longer, even doctors and other medical professionals cannot freely access the patient's data. By adopting this system, we can increase the sense of security for users who do not wish for their patient data to be used outside of medical consultations. Furthermore, limiting access to patient data by doctors and other medical professionals to only during consultations is expected to reduce the risk to doctors and other medical professionals from the leakage of patient data. Furthermore, as mentioned above, even if a system is adopted that considers "detection of a medical visit" to be based solely on the fulfillment of location conditions, similar effects to those of this embodiment can be expected.

[0118] <Embodiment 3> Embodiment 3 will now be described. The information processing system according to this embodiment is the same as the information processing system 1 (see Figure 1) described in Embodiment 1. This embodiment describes a case where a patient's permission for a doctor or other medical professional to access their patient data is treated as "detection of a medical consultation." This embodiment can be used not only when a patient actually visits a medical institution, but also when a consultation is received via the internet (i.e., online consultation).

[0119] <Processing Sequence> The following section describes the control of patient data output to the physician terminal 30 (see Figure 1) using Figures 14 to 16. Figure 14 is a diagram illustrating an example of the processing sequence in Embodiment 3. Note that Figure 14 is denoted with reference numerals corresponding to the parts shown in Figures 7 and 12. <Steps 101-105> Steps 101 to 105 are the same as in Embodiment 1. That is, the patient records measurements, reflections, etc., through a patient application running on the patient terminal 40. The patient terminal 40 then uploads the patient application data to the PDT server 20. The PDT server 20 also stores the patient application data. Furthermore, doctors and other medical professionals access the PDT platform 10 through the physician terminal 30 and select a patient from its management screen 300 (see Figure 8).

[0120] <Step 121> Step 121 is the same as in Embodiment 2. That is, the PDT server 20, upon receiving access from the physician terminal 30, generates a patient data viewing screen 310 (see lower part of Figure 10).

[0121] <Step 131> Figure 14 illustrates a scenario in which a patient, while receiving medical treatment, operates their patient terminal 40 to send permission to access their patient data to the PDT server 20. However, the timing of a patient sending permission to access their patient data is not limited to during a medical consultation. For example, it is possible to send permission to access one's patient data while on the way to a medical institution. It is also possible to send permission to access one's patient data when making an appointment at a medical institution. Furthermore, it is possible to send permission to access one's patient data during an online consultation. In this embodiment, the timing of when the patient sends permission to access their patient data to the PDT server 20 via the patient application is arbitrary.

[0122] Figure 15 illustrates an example of the procedure for granting access to patient data. The upper part of Figure 15 shows the home screen 401 displayed on the patient terminal 40. A three-line icon 402 is located in the upper left corner of the home screen 401. The three-line icon 402 is used to access the menu screen 403. The lower part of Figure 15 shows the state when menu screen 403 is displayed.

[0123] In the menu screen 403 shown in the lower part of Figure 15, the options "Allow data viewing" and "Do not allow data viewing" are displayed following the item "Consultation". In Figure 15, "Allow data viewing" is selected. Furthermore, the "Allow Data Viewing" setting is linked to the patient app. Therefore, generally, only the medical institution that prescribed the patient app can view patient data.

[0124] However, in cases such as when a patient visits another medical institution because their primary care provider is closed, when a patient transfers to another medical institution, or when a patient seeks a second opinion from another medical institution, if the physician's terminal 30 (see Figure 1) at the other medical institution is able to access the patient data, then the patient data will also be accessible at those medical institutions. Incidentally, if "Allow data viewing" is selected, a submenu may open, allowing the patient to select which medical institutions or doctors they are permitted to view the data. When this type of system is adopted, only medical institutions or doctors authorized by the patient can view patient data.

[0125] <Step 132> Returning to the explanation of Figure 14. If the PDT server 20 receives permission to access patient data from the target patient terminal, it displays a screen for viewing patient data; otherwise, it notifies the physician terminal that viewing is not permitted. Figure 16 is a diagram illustrating an example of display control of the browsing screen 310 in Embodiment 3. Figure 16 is denoted with reference numerals corresponding to the parts that correspond to those in Figure 10.

[0126] The upper part of Figure 16 shows a case where M has granted permission for doctors and other personnel to access M's patient data. The entire viewing screen 310 is displayed in the upper part of Figure 16. The lower part of Figure 16 shows a situation where access to Ms. M's patient data by a doctor or other professional is not permitted by Ms. M. In the example shown in the lower part of Figure 16, the display area of ​​the patient data on the viewing screen 310 is obscured by a masking image 312. In Figure 16, the masking image 312 displays "Access to Ms. M's patient data is not permitted."

[0127] If removing the masked image 312 is necessary for the examination, the doctor or other medical professional should request permission from the patient to access their patient data during the examination. On the other hand, even if a doctor or other medical professional were to access patient data for purposes other than medical examination, they would not be able to view M's patient data unless the patient themselves had given permission for access to their own data.

[0128] <Steps 110-112> Steps 110 to 112 are the same as in Embodiment 1. That is, when a doctor or other medical professional presses the print button, the PDT server 20 permits printing on the condition that the consultation flag is set.

[0129] <Summary> In this embodiment, unless the patient has given permission for access to their own patient data, even doctors and other medical professionals cannot freely view the patient data. By adopting this system, we can increase the sense of security for users who do not wish for their patient data to be used outside of medical consultations. Furthermore, by limiting access to patient data by doctors and other medical professionals to cases where the patient grants permission, it is expected that the risk to doctors and other medical professionals from the leakage of patient data will be reduced.

[0130] <Embodiment 4> Embodiment 4 will now be described. The information processing system according to this embodiment is the same as the information processing system 1 (see Figure 1) described in Embodiment 1. In this embodiment, we will describe a case where the patient terminal 40 (see Figure 1) is notified that the physician terminal 30 (see Figure 1) has accessed patient data, and the patient's permission to access their own patient data in response to this notification is treated as "detection of a medical visit." Similar to Embodiment 3, the mechanism described in this embodiment can be used not only when a patient actually visits a medical institution, but also when they receive information via the internet (i.e., online medical consultation).

[0131] <Processing Sequence> The following section describes the control of patient data output to the physician terminal 30 (see Figure 1) using Figures 17 and 18.

[0132] Figure 17 is a diagram illustrating an example of the processing sequence in Embodiment 3. Note that Figure 17 is denoted with reference numerals corresponding to the parts shown in Figures 7 and 14. <Steps 101-105> Steps 101 to 105 are the same as in Embodiment 1. That is, the patient records measurements, reflections, etc., through a patient application running on the patient terminal 40. The patient terminal 40 then uploads the patient application data to the PDT server 20. The PDT server 20 also stores the patient application data. Furthermore, doctors and other medical professionals access the PDT platform 10 through the physician terminal 30 and select a patient from its management screen 300 (see Figure 8).

[0133] <Step 121> Step 121 is the same as in Embodiment 3. That is, the PDT server 20, upon receiving access from the physician terminal 30, generates a patient data viewing screen 310 (see Figure 10).

[0134] <Step 141> In Figure 17, the PDT server 20 sends a push notification to the patient terminal 40 associated with the selected patient, inquiring about whether or not the patient data can be viewed. Furthermore, the PDT server 20 has already obtained the account and other information of the patient terminal 40 as the destination during the process in which the patient terminal 40 logs in to the PDT server 20 using a client certificate.

[0135] <Step 142> Upon receiving a push notification from the PDT server 20, the patient terminal 40 displays a screen 411 (see Figure 18) requesting permission to view patient data. Figure 18 illustrates an example of the display of screen 411, which requests permission to view patient data. The screen 411 shown in Figure 18 is displayed as a pop-up in the center of the patient terminal 40 screen. The screen 411 shown in Figure 18 displays the message, "ABC Hospital has requested permission to view data recorded by the XX app." This screen 411 allows patients to know in real time if ABC Hospital is requesting access to their patient data.

[0136] <Step 143> Returning to the explanation of Figure 17. The patient terminal 40, which has displayed screen 411 as a pop-up, enters a state where it awaits selection input from the patient and sends a message to the PDT server 20 indicating whether or not it is permitted to access the patient data. For example, a patient who anticipates access to their patient data, such as in an online medical consultation, will press the "Allow" button 411A (see Figure 18). On the other hand, patients who received the notification unexpectedly press the "Disallow" button 411B (see Figure 18).

[0137] <Step 132> If the PDT server 20 receives permission to access patient data from the target patient terminal, it displays a screen for viewing patient data; otherwise, it notifies the physician terminal that viewing is not permitted. If the patient terminal 40 does not respond with the "Allow" button 411A (see Figure 18), the PDT server 20 considers that a response of the "Deny" button 411B (see Figure 18) has been received.

[0138] If access to patient data accessed by a doctor or other medical professional is permitted, the entire viewing screen 310 will be displayed, as shown in the upper part of Figure 16. On the other hand, if access to patient data accessed by a doctor or other professional is denied, the display area of ​​the patient data on the viewing screen 310 is obscured by a masking image 312, as shown in the lower part of Figure 16.

[0139] <Steps 110-112> Steps 110 to 112 are the same as in Embodiment 1. That is, when a doctor or other medical professional presses the print button, the PDT server 20 permits printing on the condition that the consultation flag is set.

[0140] <Summary> In this embodiment, unlike embodiment 3, when a physician or other medical professional accesses the patient data of a patient selected through the physician terminal 30, this fact is notified to the patient terminal 40 in real time, and in response, the patient terminal 40 sends a message to the PDT server 20 indicating whether access is permitted or not. In other words, in this embodiment, access permission or denial is implemented as a passive response. However, even when adopting this system, it can enhance the sense of security for users who do not wish for their patient data to be used outside of medical consultations. Furthermore, by limiting access to patient data by doctors and other medical professionals to cases where the patient grants permission, it is expected that the risk to doctors and other medical professionals from the leakage of patient data will be reduced.

[0141] <Embodiment 5> Embodiment 5 will now be described. The information processing system according to this embodiment is the same as the information processing system 1 (see Figure 1) described in Embodiment 1. In this embodiment, even if the consultation date is entered or the patient grants permission to access their own patient data, a mechanism is described in which the display area of ​​the patient data is hidden with a masking image if it falls under the viewing restrictions set through the medical institution's terminal.

[0142] Access restrictions are the conditions under which access is restricted. Therefore, satisfying access restrictions means that access is not permitted, i.e., access is restricted. Conversely, not satisfying access restrictions means that access is permitted. In other words, in addition to the mechanisms described in Embodiments 1 to 4 above, we will now explain a mechanism for determining whether the access restrictions for specific doctors and other personnel examining patients have been met.

[0143] <Processing Sequence> The following section describes the control of patient data output to the physician terminal 30 (see Figure 1) using Figures 19 to 21. Figure 19 is a diagram illustrating an example of a processing sequence in Embodiment 5. Note that parts in Figure 19 are denoted by reference numerals corresponding to those in Figure 7. That is, the processing sequence shown in Figure 19 is based on the processing sequence described in Embodiment 1. However, the processing sequence shown in Figure 19 can also be applied to embodiments 2 to 4.

[0144] For example, in Embodiment 2, if the current location satisfies the output conditions in step 124 (see Figure 12), then steps 151 to 153 should be executed (in addition to detecting the reception). For example, in Embodiments 3 and 4, if access permission for patient data is received in step 132 (see Figure 14), steps 151 to 153 should be executed (in addition to detecting the visit).

[0145] <Steps 101-105> Steps 101 to 105 are the same as in Embodiment 1. That is, the patient records measurements, reflections, etc., through a patient application running on the patient terminal 40. The patient terminal 40 then uploads the patient application data to the PDT server 20. The PDT server 20 also stores the patient application data. Furthermore, doctors and other medical professionals access the PDT platform 10 through the physician terminal 30 and select a patient from its management screen 300 (see Figure 8).

[0146] <Step 151> Upon receiving a patient selection from the physician's terminal 30, the PDT server 20 checks whether access restrictions are set for the patient data viewing screen. In this embodiment, access restrictions apply to all patients. However, it is also possible to set access restrictions on a patient-by-patient basis. In the following, if there are access restrictions set, it will be indicated as "access restrictions are in place," and if there are no access restrictions set, it will be indicated as "access restrictions are not in place." The settings for access restrictions are stored, for example, in the auxiliary storage device 23 (see Figure 4).

[0147] Figure 20 illustrates an example of a screen for setting restrictions on access to patient data. The access restriction settings screens 330 and 331 shown in Figure 20 are displayed, for example, on the doctor's terminal 30. However, the settings screens 330 and 331 shown in Figure 20 may also be displayed on the doctor's smartphone or tablet device.

[0148] The access restriction settings screen 330 shown in the upper part of Figure 20 displays the title "Setting access restrictions for patient data," the explanation "You can set access restrictions for patient data," and the buttons "Set" 330A and "Remove" 330B. When the "Settings" button 330A is pressed, the settings screen 330 switches to the settings screen 331. When the "Cancel" button 330B is pressed, the screen switches to an unshown screen, and the user can select the browsing restriction to be canceled.

[0149] The access restriction settings screen 331 shown in the lower part of Figure 20 displays the title "Setting access restrictions for patient data (new)," the explanation "Please set the date and time to restrict access," the setting items (consultation date 331A, setting time 331B, doctor's name 331C), the explanation "Pressing the 'Yes' button will activate the setting," the "Yes" button 331D, and the "Close" button 331E. In Figure 20, the consultation date 331A can be entered from the calendar. In Figure 20, "2024 / 6 / 15" and "2024 / 6 / 16" are set as consultation dates 331A.

[0150] In Figure 20, the setting time 331B is defined by the start and end times of the period during which access is restricted. In Figure 20, it is set from "13:00" on "2024 / 6 / 15" to "8:00" on "2024 / 6 / 16". In Figure 20, the physician name 331C is entered as "Taro Nippon". The physician name 331C can be entered by selecting from a pull-down menu, for example, or by using an identifier that can identify the physician.

[0151] <Step 152> Returning to the explanation of Figure 19. If there are access restrictions set on the browsing screen, the PDT server 20 checks whether the current browsing falls under those restrictions. Figure 21 illustrates an example of a screen displayed on a physician's terminal 30 that has been instructed to view patient data, or on a physician's terminal that has set viewing restrictions. The upper part of Figure 21 shows screen 332, which notifies the user of the existence of access restriction settings. Screen 332 is also displayed when "Taro Nippon"'s client certificate is used to log in to the PDT server 20 (see Figure 1). This is to clarify the responsibility of "Taro Nippon" for setting access restrictions, even if "Taro Nippon"'s client certificate is shared by multiple people within the medical institution.

[0152] The screen 332 shown in the upper part of Figure 21 displays the title "Caution!" followed by "Access to patient data is restricted due to access restriction settings," "To view patient data, the access restriction must be removed by the person who set the access restriction (Taro Nippon)," and "Do you want to remove the access restriction settings?". The screen 332 shown in Figure 21 also has a "Yes" button 332A and a "No" button 332B. If the "No" button 332B is pressed, the browsing restriction will not be lifted. In other words, the browsing restriction will remain in place.

[0153] The screen 333 shown in the lower part of Figure 21 is displayed when the "Yes" button 332A is pressed. In this embodiment, two-factor authentication is required at least when lifting access restrictions. Of course, two-factor authentication may also be required when setting access restrictions. The screen 332 shown in Figure 21 is displayed on "Taro Nippon's" smartphone or similar device. The screen 333 shown in the lower part of Figure 21 displays the title "Remove Access Restrictions," followed by "You are being asked to remove the access restrictions that were set from 13:00 on 2024 / 6 / 15 to 8:00 on 2024 / 6 / 16," and "Do you want to remove them?". Furthermore, the screen 333 shown in Figure 21 displays a "Yes" button 333A and a "Close" button 333B.

[0154] The access restrictions displayed on screen 333 are identified by comparing the current date and time when access to patient data occurred with the time set in the access restriction. Specifically, access restrictions whose set time includes the current date and time will be displayed on screen 333. Alternatively, a list of multiple settings may be displayed on screen 333 for selection. In this case, one or more settings to be deactivated will be selected by "Taro Nippon".

[0155] If the "Yes" button 333A is pressed, the corresponding browsing restriction setting is removed, and then screen 333 is closed. On the other hand, if the "close" button 333B is pressed, screen 333 is closed without the corresponding browsing restriction settings being removed. Needless to say, if the "close" button 333B is pressed, the browsing restriction settings are maintained.

[0156] <Step 153> Returning to the explanation of Figure 19. The PDT server 20 outputs a viewing screen with unmasked patient data if there are no viewing restrictions, and outputs a viewing screen with masked patient data to the physician terminal 30 if there are viewing restrictions. If there are no restrictions on viewing (including cases where the restrictions were lifted in step 152), the PDT server 20 displays the entire viewing screen 310 on the physician's terminal 30, as shown in the upper part of Figure 16. If access restrictions apply, the PDT server 20 displays a viewing screen 310 on the physician's terminal 30, in which the display area of ​​the patient data is obscured by a masking image 312, as shown in the lower part of Figure 16.

[0157] <Steps 110-112> Steps 110 to 112 are the same as in Embodiment 1. That is, when a doctor or other medical professional presses the print button, the PDT server 20 permits printing on the condition that the consultation flag is set.

[0158] <Summary> In this embodiment, even if "detection of a medical examination" is formally confirmed, access to patient data by the physician or other medical professional will be restricted if it falls under the access restrictions set by the physician or other medical professional. In other words, in this embodiment, in addition to the external condition of "detection of medical consultation," the scope of responsibility of doctors and other personnel regarding access to patient data can be clarified. For example, even if the environment is outwardly set up to allow access to patient data, access to patient data can be restricted unless the responsible doctor or other personnel explicitly authorizes access. By adopting this system, it is expected that not only will the sense of security of users who do not wish for their patient data to be used outside of medical consultations be enhanced, but the risk to doctors and others from the leakage of patient data will also be reduced.

[0159] <Other screen examples> The screens 330, 331 (see Figure 20), 332, and 333 (see Figure 21) used in the above explanation assume that viewing is restricted, but it is also possible to set the time periods during which viewing is permitted. Figure 22 illustrates an example of a screen for setting the time period during which patient data can be viewed. The settings screens 334 and 335 for the time period during which viewing is permitted, as shown in Figure 22, are displayed on, for example, the doctor's terminal 30. However, the settings screens 334 and 335 shown in Figure 22 may also be displayed on the doctor's smartphone or tablet device.

[0160] The upper part of Figure 22 shows the settings screen 334 for the time period during which viewing is permitted, which is titled "Setting the time period during which patient data can be viewed," has the explanation "You can set the time period during which patient data can be viewed," and displays a "Set" button 334A and a "Remove" button 334B. When the "Settings" button 334A is pressed, the settings screen 330 switches to the settings screen 335. When the "Cancel" button 334B is pressed, the screen switches to an unshown screen, and the user can select the setting to be canceled.

[0161] The lower part of Figure 22 shows the setting screen 335 for the time period during which viewing is permitted. This screen displays the title "Setting the time period during which patient data can be viewed (new)," the explanation "Please set the date and time during which viewing is permitted," the setting items (consultation date 335A, set time 335B, doctor's name 335C), the explanation "Pressing the 'Yes' button will activate the setting," the "Yes" button 335D, and the "Close" button 335E. In Figure 22, the setting date 335A can be entered from the calendar. In Figure 22, "2024 / 6 / 15" is set as the setting date 335A.

[0162] In Figure 22, the setting time 335B is defined by the start and end times of the period during which access is restricted. In Figure 22, it is set from "8:00" to "13:00". This setting means that access to patient data is permitted only during morning consultations, but not in the afternoon. For example, this could be used when the clinic is closed in the afternoon or when the person in charge is out of the office. In Figure 22, the name of the physician 335C is entered as "Taro Nippon". The input for the physician name 335C can be, for example, selected from a pull-down menu, or it can be an identifier that can identify the physician.

[0163] Figure 23 illustrates an example of a screen displayed on a physician's terminal 30 that has been instructed to view patient data, or on a physician's terminal that has set the time period during which viewing is permitted. The upper part of Figure 23 shows screen 336, which notifies the user of the existence of settings related to viewing. Screen 336 is also displayed when "Taro Nippon"'s client certificate is used to log in to the PDT server 20 (see Figure 1). This is to clarify the responsibility of "Taro Nippon" for setting viewing restrictions, even if "Taro Nippon"'s client certificate is shared by multiple people within the medical institution.

[0164] The screen 336 shown in Figure 23 displays the title "Caution!" followed by "Access to patient data is restricted due to viewing settings," "To view patient data, the settings for permitted viewing times must be changed by the person who set them (Taro Nippon)," and "Do you want to change the settings?". The screen 336 shown in Figure 23 also has a "Yes" button 336A and a "No" button 336B. If the "No" button 336B is pressed, the setting for permitted viewing times will not be removed. In other words, the current settings will remain in place.

[0165] The screen 337 shown in the lower part of Figure 23 is displayed when the "Yes" button 336A is pressed. In this embodiment, at least two-factor authentication is required to disable the setting. Of course, two-factor authentication may also be required to set the time period during which viewing is permitted. The screen 337 shown in Figure 23 is displayed on "Taro Nippon's" smartphone or similar device.

[0166] The screen 337 shown in Figure 23 displays the title "Changing the time period for which browsing is permitted," followed by "Current setting: 2024 / 6 / 15 8:00-13:00," "New setting: 2024 / 6 / 15 8:00-19:00," and "Is this OK?". Note that the final time for permitted browsing has already been changed from "13:00" to "19:00" on screen 337 in Figure 23. Furthermore, the screen 337 shown in Figure 23 displays a "Yes" button 337A and a "Close" button 337B.

[0167] The settings displayed on screen 337 are identified by comparing the current date and time when access to patient data occurred with the time set in the viewing restriction. Specifically, settings where the set time includes the current date and time will be displayed on screen 337. However, a list of multiple settings may be displayed on screen 337 for selection. In this case, one or more settings to be deactivated will be selected by "Taro Nippon".

[0168] If the "Yes" button 337A is pressed, the corresponding setting is canceled, and then screen 337 is closed. Once the setting is canceled, free browsing is permitted within the same day. On the other hand, if the "Close" button 337B is pressed, screen 337 is closed without the corresponding settings being reset. Needless to say, when the "Close" button 337B is pressed, the current settings are maintained. In other words, viewing patient data during time periods that are not set is not permitted.

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

[0170] (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.

[0171] (3) In the above-described embodiment, the portion of the patient data display area that is obscured by the masking image 312 (see Figure 9) is uniformly defined, but the patient may individually set which portion is obscured by the masking image 312 and which portion is permitted to be viewed.

[0172] (4) In the above-described embodiment, the case in which the PDT server 20 (see Figure 1), which manages patient data uploaded from the patient terminal 40 (see Figure 1), controls the display format of the viewing screen 310 (see Figure 11) on the physician terminal 30 (see Figure 1) was explained. However, at least a portion of the control of the display format described above may be performed on the physician's terminal 30. Figure 24 illustrates an example of a processing sequence in another embodiment. Figure 24 is denoted with reference numerals corresponding to the parts that correspond to those in Figure 7.

[0173] However, the processing sequence shown in Figure 24 can also be applied to embodiments 2 to 4. For example, steps 121, 122, and 124 in Embodiment 2 (see Figure 12) can be performed on the physician's terminal 30. For example, steps 121 and 132 in Embodiment 3 (see Figure 14) can be performed on the physician's terminal 30. For example, Steps 121, 141, and 132 (see FIG. 17) in Embodiment 4 may be executed on the doctor terminal 30.

[0174] <Steps 101 to 106> Steps 101 to 106 are the same as those in Embodiment 1. That is, the patient records measurement values, reviews, etc. through the patient application operating on the patient terminal 40. Then, the patient terminal 40 uploads the patient application data to the PDT server 20. Also, the PDT server 20 stores the patient application data. Also, a doctor or the like accesses the PDT platform 10 through the doctor terminal 30 and selects a patient from the management screen 300 (see FIG. 8). Thereafter, the PDT server 20 outputs a browsing screen 310 (see FIG. 9) with the display area of the patient data masked to the doctor terminal 30.

[0175] <Step 161> In the case of FIG. 24, the doctor terminal 30 detects the input of the examination date. The input of the examination date by a doctor or the like is performed through the examination date registration screen 320 (see FIG. 10) or the masking image 312A (see FIG. eleven). <Steps 109 to 110, 112> In the case of FIG. 24, Steps 109 to 110, 112 are executed on the doctor terminal 30. That is, upon detecting the input of the examination date, the doctor terminal 30 outputs a browsing screen 310 (see FIG. 10) with the masking removed (unmasked). Also, when an operation of the print button is received, the doctor terminal 30 executes printing.

[0176] (5) In the above-described embodiment, a browsing screen of blood pressure values recorded through a patient application prescribed for the treatment of hypertension is assumed. However, for other diseases, browsing screens of different measurement values are prepared. For example, in the case of nicotine dependence, browsing screens of, for example, nicotine intake, the number of times of intake of a medium containing nicotine, the number of intakes of a medium containing nicotine, measured values of CO concentration in exhaled breath, etc. are prepared.

[0177] Also, in the case of alcohol dependence, for example, a screen for viewing the measured value of alcohol intake is prepared. Also, in the case of NASH or obesity, for example, a screen for viewing the measured value of body weight is prepared. Also, in the case of insomnia, for example, a screen for viewing the record of the dosage of sleeping pills and the total score of the Pittsburgh Sleep Quality Index (PSQI) defined by 24 items is prepared. Other diseases are also assumed, such as kidney disease, cancer, chronic heart failure, attention deficit hyperactivity disorder, depression, tinnitus, prolonged grief disorder, opioid-induced constipation, pain syndrome after mastectomy, bronchial asthma, and nephrotic syndrome.

[0178] (6) In the above-described embodiment, it is assumed that all of the patient data displayed on the viewing screen 310 (see FIG. 10) is recorded through a program located in a medical device. However, all or part of the patient data displayed on the viewing screen 310 may be recorded through a program located in a non-medical device. <(

[0179] A program located in a non-medical device is also a program used for recording health-related data. Hereinafter, a program located in a non-medical device is referred to as a "non-patient app". FIG. 25 is a diagram for explaining an embodiment in which "health-related data" recorded through a non-patient app and "health-related data" recorded through a patient app are used in combination.

[0180] The horizontal axis in FIG. 25 is a time axis. The right end of the time axis is the examination date, and the left end is the past tense. In FIG. 25, it is drawn up to 7 months ago. In the case of Figure 25, the prescription date for the patient app is between three and four months prior. Before being prescribed the patient app, the patient (i.e., the user) records "health data" through the non-patient app. The "health data" may be recorded on the patient terminal 40 alone, on the management server 50 alone, or on both the patient terminal 40 and the management server 50. The management server 50 is, for example, a server operated by the company that provides the non-patient app.

[0181] Non-patient apps in this context are sometimes called healthcare apps. Healthcare apps are programs primarily intended for recording health information and are not medical devices. In the case of Figure 25, "health data" recorded through a non-patient app before the patient app is prescribed is imported from the patient terminal 40 or management server 50 to the PDT server 20. Of course, user identity is verified through user accounts, etc., during the import process.

[0182] Therefore, on the day of the consultation, the PDT server 20 stores not only the "health data" for approximately four months after the patient app was prescribed, but also the "health data" for approximately three months before the patient app was prescribed. In other words, the PDT server 20 has accumulated approximately seven months' worth of the patient's "health data". In this case, the PDT server 20 can display a viewing screen 310 (see Figure 10) that includes "health data" from before the patient started treatment using the patient app.

[0183] (7) In the embodiments described above, it is assumed that the consultation date falls within the period of health insurance coverage. However, it may also be possible to display the viewing screen 310 (see Figure 10) containing "health-related data" recorded through a program classified as a non-medical device even after the period of health insurance coverage has ended. Figure 26 illustrates another embodiment that uses both "health data" recorded through a non-patient app and "health data" recorded through a patient app.

[0184] The horizontal axis in Figure 26 represents the time axis. The right end of the time axis represents the date of the examination, and the left end represents the past tense. Figure 26 shows events up to 7 months ago. In Figure 26, the prescription date in the patient app is seven months prior, and the insured treatment period expired within two months prior to the consultation date. Furthermore, in Figure 26, after the expiration of the insured treatment period, a period of treatment not covered by insurance (i.e., outside the insured treatment period) begins.

[0185] Figure 26 illustrates a scenario where the patient app continues to be used to record "health data" outside the insurance coverage period, even after its validity period has expired. In other words, it assumes that the patient app continues to be used as a non-patient app after its validity period has expired. For this reason, not only "health data" during the insurance coverage period but also "health data" outside the insurance coverage period are recorded on the PDT server 20.

[0186] However, it is also acceptable to use a non-patient application, different from the patient application used during the insurance-covered medical treatment period, to record "health-related data" on the patient terminal 40 or management server 50. If "health-related data" recorded through the non-patient application is not stored on the PDT server 20, the "health-related data" will be imported from the patient terminal 40 or management server 50 to the PDT server 20.

[0187] (8) In the embodiments described above, the case in which the application used to record health-related data is a patient application or a healthcare application was explained. 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.

[0188] (9) In the above-described embodiment 1, the doctor or other person enters the date of the consultation, but automatic input through integration with other systems is also acceptable. Examples of other systems include a patient registration system and an electronic medical record system.

[0189] <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 detecting a visit to a medical institution by a user who transforms behavior, and outputting health-related data including data recorded through a patient terminal that executes a program according to a disease to a terminal of the medical institution after detecting the visit. According to this information processing device, a mechanism for restricting the access opportunity of medical staff to health-related data including data recorded through a patient terminal can be provided.

[0190] (((2))) The information processing device according to (((1))), wherein the processor treats the input of the examination date as the detection of the visit. According to this information processing device, access to health-related data can be enabled only in a state where there is a high possibility of a visit.

[0191] (((3))) The information processing device according to (((1))), wherein the processor treats the patient terminal being located within a predetermined position range with respect to the medical institution as the detection of the visit. According to this information processing device, access to health-related data can be enabled only in a state where there is a high possibility of a visit.

[0192] (((4))) The information processing device according to (((3))), wherein the processor treats the patient terminal being located within the position range for a predetermined time or more as the detection of the visit. According to this information processing device, access to user data can be enabled only in a state where there is a high possibility of a visit.

[0193] (((5))) The information processing device according to (((1))), wherein the processor treats the permission to access user data from the patient terminal as the detection of the visit. According to this information processing device, access to health-related data can be enabled only when permission is obtained from the patient terminal.

[0194] (((6))) The processor is an information processing device described in any one of (((1))) to (((5))) that, in addition to detecting a medical visit, outputs health-related data to the terminal of a medical institution, provided that the viewing conditions set via the terminal of the medical institution are met. According to this information processing device, access to health-related data can be enabled only if the conditions set from the medical institution's terminal are also met.

[0195] (((7))) The processor is an information processing device described in (((1))) that displays health-related data on the medical institution's terminal after detecting a medical visit. According to this information processing device, the display of health-related data can be limited to after a medical examination has been detected.

[0196] (((8))) The information processing device described in (((1))) is a processor that, after detecting a medical visit, allows printing of health data on the medical institution's terminal. According to this information processing device, printing of health-related data can be limited to after a medical examination has been detected.

[0197] (((9))) An information provision method in which a computer performs the following processes: detecting a visit to a medical institution by a user whose behavior has changed; and, after the visit is detected, outputting health-related data, including data recorded through a patient terminal that runs a disease-specific program, to a terminal of the medical institution. This information provision method provides a mechanism to restrict healthcare professionals' access to health-related data, including data recorded through patient terminals.

[0198] (((10))) A program to enable a computer to perform the following functions: detect visits to medical institutions by users whose behavior has changed; and, after a visit is detected, output health-related data, including data recorded via a patient terminal that runs a disease-specific program, to a terminal at the medical institution. This program provides a mechanism to restrict healthcare professionals' access to health-related data, including data recorded through patient terminals. [Explanation of Symbols]

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

Claims

1. It has a processor, The aforementioned processor, Detecting users who change their behavior and visit medical institutions, After detecting the aforementioned medical visit, health-related data, including data recorded through a user terminal running a program corresponding to the disease, is output to the medical institution's terminal. Information processing device.

2. The information processing apparatus according to claim 1, wherein the processor treats the input of the consultation date as the detection of the consultation.

3. The information processing apparatus according to claim 1, wherein the processor treats the user terminal being located within a predetermined location range for the medical institution as detection of a medical visit.

4. The information processing apparatus according to claim 3, wherein the processor treats the user terminal being located within the location range for a predetermined period of time or longer as detection of receiving a call.

5. The information processing apparatus according to claim 1, wherein the processor treats the user terminal's permission to access the health data as the detection of a medical visit.

6. The information processing device according to any one of claims 1 to 5, wherein the processor, in addition to detecting the medical visit, outputs the health-related data to the terminal of the medical institution on the condition that the viewing conditions set through the terminal of the medical institution are met.

7. The information processing apparatus according to claim 1, wherein the processor displays the health data on the medical institution's terminal after detecting the medical examination.

8. The information processing apparatus according to claim 1, wherein the processor permits printing of the health data on the medical institution's terminal after detecting the medical visit.

9. Computers A process for detecting visits to medical institutions by users whose behavior has changed, After detecting the aforementioned medical visit, the process involves outputting health-related data, including data recorded through a user terminal that runs a program corresponding to the disease, to the terminal of the medical institution. A method for providing information to carry out the task.

10. On the computer, A function to detect users who change their behavior and visit medical institutions, After detecting the aforementioned medical visit, the function outputs health-related data, including data recorded through a user terminal that runs a program corresponding to the disease, to the terminal of the medical institution. A program to achieve this.

Images