Management server, information provision method, and program

Abstract

To enable central provision of information regarding whether a patient application being used by each patient can be used or not.SOLUTION: A program disclosed herein causes one or more processors of a management server managing patient data entered via patient applications to acquire information indicative of whether prescribed patient applications are to be recalled or not or information indicative of whether the patient applications can be used or not from a management server managing usage statuses of the prescribed patient applications, and provide the information to a terminal of a medical institution or patient terminals.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present disclosure relates to a management server, an information providing method, and a program. [Background technology]

[0002] Currently, medical treatment using programmed medical devices (hereinafter referred to as "patient apps") approved under the Pharmaceutical and Medical Device Act has begun. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6116769 Summary of the Invention [Problem to be solved by the invention]

[0004] The Pharmaceuticals and Medical Devices Act stipulates that manufacturers and distributors of medical devices must recall devices that meet certain conditions. The same applies to patient apps that fall under the category of medical devices. For example, if a patient app is subject to recall, users must immediately stop using it. However, in reality, there is a possibility that responses will vary from manufacturer to manufacturer.

[0005] One embodiment of the present disclosure can centrally provide information regarding whether or not a patient app currently being used by each patient is available. [Means for solving the problem]

[0006] The invention described in claim 1 is a management server that manages patient data input through a patient app, and has one or more processors, and the processors acquire information indicating whether a prescribed patient app is subject to recall or whether it is available for use from a management server that manages the usage status of prescribed patient apps, and provide the information to a medical institution terminal or a patient terminal. The invention described in claim 2 is the management server described in claim 1, wherein the one or more processors display a message to the effect that the patient app is to be withdrawn or is unusable on a terminal of the medical institution when the patient app is to be withdrawn or is unusable. An invention recited in claim 3 is the management server recited in claim 2, wherein the one or more processors, when a new version of the patient app that resolves the cause of recall has already been released, display information on a terminal of the medical institution that prompts the medical institution to update to the new version of the patient app. The invention described in claim 4 is the management server described in claim 2, wherein the one or more processors display on a home screen of the server a message indicating that the patient app is to be withdrawn or is unavailable. The invention described in claim 5 is the management server described in claim 2, wherein the one or more processors display on the patient data viewing screen a message indicating that the patient app is to be withdrawn or is unavailable. The invention described in claim 6 is the management server described in claim 1, wherein the one or more processors display a message to the patient on the patient's terminal if the patient app is to be withdrawn or is unavailable. The invention described in claim 7 is the management server described in claim 6, wherein the one or more processors, when the patient app is to be withdrawn or is unavailable, display on the patient's terminal a message that operation of the patient app is restricted. An invention recited in claim 8 is the management server recited in claim 6, wherein the one or more processors, when a new version of the patient app that resolves the cause of recall has already been released, display information on the patient's terminal prompting the patient to update to the new version of the patient app. The invention described in claim 9 is the management server described in claim 6, wherein the one or more processors restrict operation of the patient app on the patient's terminal when the patient app is to be withdrawn or is unavailable. The invention described in claim 10 is an information providing method in which a management server that manages patient data input through a patient app obtains information indicating whether a prescribed patient app is subject to recall or whether it is available for use from a management server that manages the usage status of the prescribed patient app, and provides the information to a medical institution's terminal or a patient's terminal. The invention described in claim 11 is a program for causing one or more processors in a management server that manages patient data input through a patient app to realize a function of obtaining information indicating whether a prescribed patient app is subject to recall or whether it is available for use from the management server that manages the usage status of the prescribed patient app, and providing the information to a medical institution's terminal or a patient's terminal. [Effects of the Invention]

[0007] According to one embodiment of the present disclosure, it is possible to provide information regarding whether or not a patient app currently being used by each patient can be used in a unified manner. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 10 is a diagram illustrating the connection relationship between an APS server and a PDT server. [Figure 2] FIG. 2 is a diagram illustrating an example of the hardware configuration of an APS server. [Figure 3] 10 is a diagram illustrating an example of status management data stored in an auxiliary storage device of an APS server. FIG. [Figure 4] FIG. 10 is a diagram showing an example of a parameter change screen used to change management parameters. [Figure 5] FIG. 2 is a diagram illustrating an example of the hardware configuration of a PDT server. [Figure 6] 10A and 10B are diagrams illustrating examples of status management data, prescription code lists, and patient data stored in the auxiliary storage device of the PDT server. [Figure 7] FIG. 10 is a sequence diagram illustrating the cooperative operation between the APS server, the PDT server, and the doctor terminal. [Figure 8]10 is a flowchart illustrating an example of a sub-process executed by the PDT server. [Figure 9] FIG. 10 is a diagram showing an example of a home screen of the PDT server that is displayed when a doctor application A corresponding to a patient application A is started. [Figure 10] FIG. 10 is a diagram showing another example of the home screen of the PDT server that is displayed when the doctor application A corresponding to the patient application A is started. [Figure 11] FIG. 10 is a sequence diagram illustrating the cooperative operation between the APS server, the PDT server, and the patient terminal. [Figure 12] 10 is a flowchart illustrating an example of a sub-process executed by the PDT server 20A. [Figure 13] FIG. 10 is a diagram showing an example of an input screen displayed on a patient terminal when a patient application A that is not a collection target is launched. [Figure 14] FIG. 10 is a diagram showing an example of a usage suspension screen displayed on a patient terminal when patient application A to be collected is launched. [Figure 15] FIG. 10 is a diagram illustrating an example of a consultation screen displayed on a doctor terminal. [Figure 16] FIG. 10 is a diagram illustrating an example of a consultation screen to which a warning message is added. DETAILED DESCRIPTION OF THE INVENTION

[0009] <Terminology> First, terms used in the embodiments described below will be explained. "Therapeutic apps" refer to apps that have been approved under the Pharmaceuticals and Medical Devices Act. Therapeutic apps are approved for specific diseases. Diseases for which approval has already been obtained include hypertension, nicotine addiction, and insomnia. Diseases for which therapeutic apps are currently under development include NASH (non-alcoholic steatohepatitis) and kidney disease.

[0010] Treatment apps include patient apps and doctor apps. A "patient app" is an app that runs on a device operated by a patient (hereinafter also referred to as a "patient device") and is prescribed to the patient by a doctor. In this sense, the patient app is also called a PDT (Prescription Digital Therapeutic). The patient app can be downloaded from, for example, an app store. In the embodiments described below, an app for which a code required for activation (hereinafter referred to as a "prescription code") is issued based on a doctor's prescription is referred to as a patient app. The patient app is used to record patient data (hereinafter also referred to as "patient data") outside of medical institutions.

[0011] A validity period is set for a patient app at the time of approval. This validity period is determined based on, for example, the period during which the public medical insurance system applies. The validity period is determined depending on the type of disease that the patient app covers. For example, the validity period for a patient app for hypertension is six months, counting from the month following the month in which the patient app was prescribed. However, six months is just an example, and it could be, for example, nine months or 12 months. The validity period may also be determined in days, such as 60 days or 180 days, or in weeks, such as eight weeks or 24 weeks. Needless to say, these values are just examples.

[0012] The "Doctor App" is an app that runs on a device operated by a doctor or other medical professional (hereinafter referred to as the "Doctor Terminal") and is used to view patient data entered through the Patient App. "Patient data" includes, for example, patient attributes, measurement values, activity records, mood records, physical condition records, medical examination history, patient app operation history, biological characteristics, psychological characteristics, social characteristics, habits, and goal achievement status. However, the items recorded as patient data vary depending on the disease, and do not necessarily have to be all of the exemplified information, but may be some of the information, or may include other information.

[0013] The "patient attributes" include, for example, the patient's name, gender, and date of birth. These pieces of information are examples of basic patient information. "Measurement value" refers to a numerical value measured using a measuring instrument. The measurement values to be recorded as patient data are specified for each disease. For example, if the disease is hypertension, blood pressure values are recorded as measurement values. Blood pressure values are specified, for example, as systolic blood pressure (i.e., the highest blood pressure value) and diastolic blood pressure (i.e., the lowest blood pressure value). For example, if the disease is nicotine addiction, the measurements recorded would be carbon monoxide (CO) in the breath and nicotine concentration in the saliva.

[0014] The "activity record" is, for example, a patient app operation history, a medication record, a meal record, a smoking record, a drinking record, and an exercise record. The activity record is an example of information about activity. The "mood record" is, for example, a subjective mood. The mood record is an example of information about mood. The "record of physical condition" is, for example, a subjective physical condition or symptom. The record of physical condition is an example of information related to physical condition.

[0015] The "medical examination history" includes, for example, the treatment start date, the consultation date, the content of the treatment, and advice. The medical examination history is an example of information related to medical examinations. The "patient application operation history" is, for example, a history of operations related to starting up the patient application and inputting blood pressure values and reviewing data. "Biological characteristics" include, for example, whether or not the patient has other illnesses, whether or not they have had injuries during treatment, whether or not they have knee or foot pain, whether or not they have had treatment for high blood pressure, the number of years since they were diagnosed with high blood pressure, how strongly seasoned their food is at home, and the amount of food they eat.

[0016] "Psychological characteristics" include, for example, expectations regarding app treatment, willingness to acquire knowledge about hypertension treatment, whether reducing salt intake is difficult, whether one believes one's sense of taste cannot be changed, and psychological resistance to leaving food on one's plate. "Social characteristics" include, for example, wake-up time, bedtime, type of work (e.g., shift work, day shift, night shift), days of the week worked, start time of work, time home from work, regular days off, and whether or not there is a heater in the changing room.

[0017] "Habits" include, for example, exercise habits, weighing oneself, checking the calorie count on food labels, choosing low-fat foods, not consuming caffeine after 4 p.m., eating and drinking after 10 p.m., skipping breakfast, snacking, taking a bath one hour before bedtime, stretching or massaging before bedtime, and sleeping for six hours or more. The "goal achievement status" is, for example, the relationship between the patient's status and the goal set by the doctor for each patient. The above-mentioned information can be classified into subjective information and objective information.

[0018] The "APS (= Application Prescription Service) server" is a server that manages the usage status of patient apps after prescriptions are prescribed. The APS server is an example of a management server. Usage statuses include, for example, "before use started," "in use," and "ended." "Before use started" refers to a state in which the prescription for the patient app has been completed but use on the patient's device has not yet begun. "In use" refers to a state in which the patient app installed on the patient's device has been activated and the patient app can be used. Note that activating the patient app requires the entry of an activation code such as the prescription code mentioned above. "Ended" refers to a state in which the patient app cannot be used, for example, because the validity period has expired.

[0019] The APS server in the embodiment can handle 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 APS server functions as a platform for multiple patient apps, and is therefore also called the PDT platform. The app that runs on the APS server manages the usage status of multiple patient apps for different diseases and service providers on a patient-by-patient basis.

[0020] The "PDT server" is a server that manages patient data entered through the patient app. A PDT server is generally provided for each patient app. Therefore, in order for a doctor to view patient data, they must log in to the corresponding PDT server through the doctor app that is paired with the patient app that prescribed the medication to the patient.

[0021] For example, when a patient uses a patient application A11 for hypertension provided by a service provider A, a doctor needs to log in to a PDT server A21 operated by the service provider A for hypertension. Furthermore, when a patient uses a patient application B11 for hypertension provided by service provider B, the doctor needs to log in to a PDT server B21 operated by service provider B for hypertension.

[0022] Furthermore, if a patient uses a patient application A12 for nicotine addiction provided by service provider A, the doctor needs to log in to a PDT server A22 operated by service provider A for nicotine addiction. It should be noted that multiple patient apps targeting different diseases may share one PDT server. Furthermore, multiple patient apps provided by different service providers may share one PDT server.

[0023] In the embodiments described below, the term "medical institution" refers to a medical institution that is covered by health insurance. More specifically, the medical institution refers to a medical institution that is covered by health insurance and that has a doctor who issues a prescription code required to activate the patient app. However, if, due to deregulation, pharmacists, public health nurses, nurses, nutritionists, hospital staff, and other medical professionals are able to issue prescription codes, the term "medical institution" also includes facilities and organizations that employ such medical professionals. Doctors and other medical professionals (hereinafter referred to as "doctors, etc.") are examples of users who operate medical institution terminals. The issuance of prescription codes is not limited to medical treatment, but may also be for non-insurance treatment (i.e., private treatment) or mixed treatment. Incidentally, medical treatment does not only include face-to-face treatment, but also online treatment.

[0024] "Recall" refers to the taking back of pharmaceuticals, medical devices, etc. that have been manufactured, sold, or approved by manufacturers, etc., and includes "modification" as described below. "Modification" refers to repairing, improving, adjusting, disposing of, or monitoring a medical device that is manufactured, sold, or approved by a medical device manufacturer, etc., without physically moving it to another location. In addition, modification of a therapeutic app refers to replacing or modifying a program with a new one that does not pose any problems in quality, effectiveness, or safety.

[0025] <Overall system> Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. FIG. 1 is a diagram illustrating the connection relationship between an APS server 10 and PDT servers 20 (20A, 20B, 20C, . . . 20F).

[0026] 1 shows only one APS server 10, but there may be multiple APS servers 10. The APS server 10 may also be realized by multiple servers connected via a network. In this case, the multiple servers work together to provide services as an APS server. The APS server 10 and the PDT server 20 are communicably connected via a network (not shown), which may be, for example, a LAN (Local Area Network), the Internet, or a mobile communication system (4G, 5G).

[0027] The PDT servers 20A, 20B, 20C, . . . 20F are servers that perform patient authentication, store patient data input through the patient application, and provide patient data to a doctor terminal (not shown). In the case of FIG. 1, the PDT server 20A is a server that manages patient data of a patient application (hereinafter referred to as "patient application A") provided by company A for patients with hypertension. The PDT server 20B is a server that manages patient data of a patient application (hereinafter referred to as "patient application B") provided by company B for patients with hypertension.

[0028] The PDT server 20C is a server that manages patient data of a patient application (hereinafter referred to as "patient application C") provided by Company A for patients with nicotine addiction. The PDT server 20D is a server that manages patient data of a patient application (hereinafter referred to as "patient application D") provided by Company B for patients with post-mastectomy pain syndrome. The PDT server 20E is a server that manages patient data of a patient application (hereinafter referred to as "patient application E") provided by Company C for patients with NASH. The PDT server 20F is a server that manages patient data of a patient application (hereinafter referred to as "patient application F") provided by Company D for patients with insomnia.

[0029] 1, a PDT server 20 is prepared for each combination of a disease targeted by a patient app and a service provider that provides the patient app. Therefore, even if the service provider that provides the patient app is the same, if the targeted diseases are different, a different PDT server 20 is prepared. Furthermore, even if the target disease is the same, if the service provider that provides the patient app is different, a different PDT server 20 will be prepared.

[0030] However, it is also possible to provide one PDT server 20 for a plurality of patient applications with different combinations. The APS server 10 and the PDT server 20 do not necessarily have to be operated by the same operator, but may be operated by different operators. For example, some of the PDT servers 20 may be operated by the same operator as the APS server 10.

[0031] <Server hardware configuration> <APSサーバ> FIG. 2 is a diagram illustrating an example of the hardware configuration of the APS server 10. As shown in FIG. 2 has a processor 11, a ROM (=Read Only Memory) 12 in which a BIOS (=Basic Input Output System) and the like are stored, a RAM (=Random Access Memory) 13 used as a work area for the processor 11, an auxiliary storage device 14, an input interface 15, an input device 16 connected to the input interface 15, an output interface 17, an output device 18 connected to the output interface 17, and a communication interface 19. Each device is connected via a bus or other signal line.

[0032] The processor 11 is a device that realizes various functions by executing programs. The processor 11, the ROM 12, and the RAM 13 function as a computer. The auxiliary storage device 14 is configured by, for example, a hard disk device or semiconductor storage. The auxiliary storage device 14 stores data for managing status management data 140 for each prescription code prescribed at a medical institution and status management data 141 for each patient application.

[0033] The input interface 15 uses, for example, USB (=Universal Serial Bus) or Bluetooth (registered trademark) for connection to the input device 16. The input device 16 may be, for example, a keyboard, a mouse, or a touch panel. The output interface 17 may be, for example, an HDMI (=High-Definition Multimedia Interface) (registered trademark) or a LAN interface for connection to an output device 18. The output device 18 may be, for example, a monitor or a printer. The communication interface 19 is an interface for communicating with an external terminal such as the PDT server 20 through a network. The communication interface 19 is compatible with Ethernet (registered trademark), Wi-Fi (registered trademark), mobile communication systems, and other communication standards.

[0034] <Management data of the APS server> FIG. 3 is a diagram for explaining an example of status management data 140 and 141 stored in the auxiliary storage device 14 (see FIG. 2) of the APS server 10. The status management data 140 shown in FIG. 3 stores a prescription code 140A, a patient ID (patient name) 140B, a prescription date (medical treatment date) 140C, a medical institution ID (prescriber ID) 140D, a patient app name (version) 140E, and a usage status 140F. However, these are just examples, and for example, the patient's gender, age, the last month of the validity period of the patient app, the type of insurance card, and the insurance number may be stored.

[0035] The prescription code 140A is issued for each patient app that has received a prescription notification from a medical institution terminal. For a patient who has successfully authenticated the prescription code 140A, an activation code is notified. The patient ID (patient name) 140B is an identification code and patient name for identifying the patient for whom the patient app is prescribed. The patient ID is assigned, for example, when a new patient is registered based on the prescription code. Note that the patient name is stored only when there is registration from the patient terminal. In the case of FIG. 3, the patient name of the patient ID "12543" is "Mr. A".

[0036] The prescription date (medical treatment date) 140C is the date on which the doctor treated the patient. In the present embodiment, the medical treatment date on which the doctor prescribed the patient app is denoted as the "prescription date" to distinguish it from other medical treatment dates. In the case of FIG. 3, only the prescription date is stored. In the case of FIG. 3, the prescription date is "January 31, 2024". The medical institution ID (prescriber ID) 140D is an ID that identifies the medical institution and prescriber that prescribed the patient app. In the case of Figure 3, the prescription codes "12345" and "23456" were prescribed by the same doctor at the same medical institution.

[0037] The patient app name (version) 140E is the name and version of the patient app prescribed by a doctor or the like. However, as long as it is possible to identify the patient app, an identification code of the patient app may be stored. The version is stored when it is acquired through communication with the PDT server 20 (see FIG. 1). The usage status 140F is information indicating the usage status of the patient application. The usage status stores one of "before use started," "in use," and "ended."

[0038] The status management data 141 shown in FIG. 3 stores a patient application name (version) 141A, a collection status 141B, a display text for the doctor terminal 141C, and a display text for the patient terminal 141D. The patient application name (version) 141A is the name and version of the patient application that is managed by the APS server 10. The version is expressed by a numerical value.

[0039] Although only patient applications A and B are shown in Fig. 3, in the present embodiment, patient applications C, D, E, and F are also managed. In Fig. 3, two versions are recorded for patient application A. In this way, if multiple versions of the same patient application A are released, multiple versions are recorded for one patient application. As shown in Fig. 3, patient applications of different versions are recorded in different rows as different patient applications.

[0040] The withdrawal status 141B is an example of information indicating whether or not the patient app is subject to withdrawal. In the case of FIG. 3, "retired" and "usable" are recorded in the withdrawal status 141B. "Retired" indicates that the patient app is subject to withdrawal and there is a problem with using the patient app. "Usable" indicates that the patient app is not subject to withdrawal and there is no problem with using the patient app. Therefore, the withdrawal status 141B is also an example of information indicating whether or not the patient app is usable. The collection status 141B may be registered by a person in charge of the service provider who manages the APS server 10, or may be obtained via communication from the PDT server 20 that manages the same status.

[0041] The doctor terminal display text 141C is text to be displayed on the doctor terminal of the medical institution that prescribed the patient app to be collected. The content of the displayed text may be a standard phrase, or may be freely input by a person in charge of the service provider that manages the APS server 10. For example, a standard phrase selected by a person in charge of the service provider that manages the APS server 10 is recorded in the doctor terminal display text 141C.

[0042] In the case of Figure 3, the row for version 2 of the patient app A, for which the withdrawal status 141B is "recalled," contains the following sentences: "Patient app A is being withdrawn and is currently unavailable." and "Please encourage users to update to the new version." 3, the doctor terminal display text 141C can be freely input for each patient application. For example, different texts may be recorded for patient application A and patient application B.

[0043] The patient terminal display text 141D is text to be displayed on the patient terminal that is using the patient app to be collected. The content of the text to be displayed may be a fixed phrase, or may be freely input by the person in charge of managing the APS server 10. For example, a fixed phrase selected by the person in charge of managing the APS server 10 is recorded in the patient terminal display text 141D.

[0044] In the case of Figure 3, the row for version 2 of the patient app A, for which the recall status 141B is "recalled," contains the sentences "The use of the patient app A is restricted by instructions from the authorities." and "Please update to a newer version." 3, the patient terminal display text 141D can be freely input for each patient application. For example, different texts may be recorded for patient application A and patient application B.

[0045] Fig. 4 is a diagram showing an example of a parameter change screen 180 used to change management parameters. The parameter change screen 180 shown in Fig. 4 is displayed on a monitor serving as the output device 18 (see Fig. 2). The parameter change screen 180 shown in Figure 4 is composed of a title field 181, an input field 182 for the target application, an input field 183 for the target version, an input field 184 for the collection status, an input field 185 for the text to be displayed on the doctor's terminal, an input field 186 for the text to be displayed on the patient's terminal, a "Cancel" button 187, and a "Confirm" button 188.

[0046] In the case of Fig. 4, "Change of management parameters" is displayed in the title field 181. "Patient application A" is displayed in the input field 182 for the target application, "2" is displayed in the input field 183 for the target version, and "Recalled" is displayed in the input field 184 for the recall status. For example, an item selected from a pull-down menu in each field is displayed in the input field 182 for the target application and the input field 184 for the withdrawal status. Also, in the input field 183 for the target version, a person in charge of the service provider managing the APS server 10 inputs the version of the patient application designated as the subject of withdrawal.

[0047] The input field 185 for the text to be displayed on the doctor terminal of the medical institution that prescribed the patient app to be recalled is used to set the text to be displayed on the doctor terminal of the medical institution that prescribed the patient app to be recalled. The text here may be selectable from fixed phrases prepared as a pull-down menu, or may be freely entered. The input field 186 for the text to be displayed on the patient terminal using the patient app to be collected is used to set the text to be displayed on the patient terminal. The text here may also be selectable from fixed phrases prepared as a pull-down menu, or free text may be entered.

[0048] Note that the provision of information after the use of the patient app on the patient terminal has begun is normally the responsibility of the PDT server 20. However, in this embodiment, the provision of information related to collection and information regarding availability of use is collectively managed by the APS server 10. For this reason, the parameter change screen 180 is provided with an input field 186 for display text for the patient terminal. Therefore, when the PDT server 20 provides the patient terminal with information related to collection and information regarding availability of use, it is not necessary to display the input field 186 for the display text for the patient terminal. The "Cancel" button 187 is used to cancel the changes, and operating this button closes the parameter change screen 180. On the other hand, operating the "Confirm" button 188 confirms the contents entered on the parameter change screen 180.

[0049] <PDTサーバ>

[0050] FIG. 5 is a diagram illustrating an example of the hardware configuration of the PDT server 20. As shown in FIG. 5 includes a processor 21, a ROM 22 storing the BIOS and the like, a RAM 23 used as a work area for the processor 21, an auxiliary storage device 24, and a communication interface 25. Each device is connected via a bus or other signal lines. The processor 21 is a device that realizes various functions by executing programs. The processor 21, the ROM 22, and the RAM 23 function as a computer.

[0051] The auxiliary storage device 24 is composed of, for example, a hard disk drive or a semiconductor storage. The auxiliary storage device 24 stores status management data 240 for each patient app, a prescription code list 241, patient data 242 recorded through the patient app, and the like. The communication interface 25 is an interface for communicating with an external terminal such as the APS server 10 through a network. The communication interface 25 is compatible with Ethernet (registered trademark), Wi-Fi (registered trademark), mobile communication systems, and other communication standards.

[0052] <Management data of the PDT server> FIG. 6 is a diagram for explaining an example of status management data 240, a prescription code list 241, and patient data 242 stored in the auxiliary storage device 24 (see FIG. 5) of the PDT server 20. The status management data 240 shown in FIG. 6 stores a patient app name 240A, a version 240B, and a collection status 240C. Note that the status management data 240 may be obtained not only when a service provider providing the patient app manages it, but also through communication with the APS server 10 (see FIG. 1) that manages the same data.

[0053] The prescription code list 241 stores a prescription code 241A, a patient ID (patient name) 241B, and a patient app name (version) 241C. This prescription code list 241 stores valid prescription codes. A prescription code being "valid" means, for example, that the insurance medical treatment period started by prescribing the patient app has not ended. Note that even during the insurance medical treatment period, if a doctor or the like stops the operation of the patient app, it is regarded as the end of the insurance medical treatment period. The patient data 242 stores a prescription code 242A, a patient ID (patient name) 242B, a measurement date and time 242C, and a measurement value (blood pressure value) 242D. In the case of FIG. 6, an app for hypertension is assumed as the patient app. Therefore, the maximum blood pressure value and the minimum blood pressure value are stored as the measurement values.

[0054] <Processing operation of PDT server> <When inquiring from doctor terminal> FIG. 7 is a sequence diagram for explaining the cooperation operation among the APS server 10, the PDT server 20A, and the doctor terminal 30. Incidentally, S in the symbols shown in the figure means step. In the case of FIG. 7, the PDT server is "PDT server 20A". The reason is that the doctor application launched on the doctor terminal 30 is "doctor application A".

[0055] Therefore, if the doctor application launched on the doctor terminal 30 is different, the PDT server that becomes the communication partner of the doctor terminal 30 also changes. The cooperation operation shown in FIG. 7 is started by the launch of doctor application A on the doctor terminal 30 (step 100). Incidentally, doctor application A is a dedicated program used for viewing patient data recorded through patient application A.

[0056] When doctor application A is launched, a login screen for logging in to the corresponding PDT server 20A is displayed. When a doctor or the like inputs login data on the login screen, the doctor terminal 30 logs in to the PDT server 20A (step 110). The PDT server 20A logged in from the doctor terminal 30 authenticates whether a doctor or the like has access authority (step 120). The result of the authentication (that is, success (OK) or failure (NG)) is notified from the PDT server 20A to the doctor terminal 30.

[0057] If the authentication is successful (OK), the doctor terminal 30 inquires the PDT server 20A about the recovery status of patient application A (step 130). In the case of the present embodiment, the inquiry to the PDT server 20A corresponding to patient application A is automatically executed by the doctor terminal 30 that has confirmed the launch of doctor application A. This inquiry is executed, for example, as a part of the function of doctor application A. Upon receiving an inquiry from the authenticated doctor terminal 30, the PDT server 20A queries the APS server 10 about the collection status of the patient app A (step 140). This query also serves the purpose of double-checking between the PDT server 20A and the APS server 10.

[0058] Upon receiving the inquiry, the APS server 10 reads out the collection status 141B of the patient app A (see Fig. 3) and responds with the read collection status (step 150). Upon receiving the response of the collection status, the PDT server 20A responds with the collection status etc. to the doctor terminal 30 which is the inquiry source (step 160). For example, the response status and the home screen corresponding to the response status are notified. The doctor terminal 30 which is the destination displays the home screen received from the PDT server 20A (step 170). By displaying the home screen, doctors etc. can confirm that they have successfully logged in to the PDT server 20A.

[0059] <Processing Operation of PDT Server> Subsequently, the detailed operation of the PDT server 20A during the cooperation operation will be described. Fig. 8 is a flowchart for explaining an example of the sub-process executed by the PDT server 20A. In Fig. 8, the reference numerals corresponding to the corresponding parts in Fig. 7 are shown. The sub-process shown in Fig. 8 is composed of step 140 and step 160. First, as the processing of step 140, the PDT server 20A determines whether there is an inquiry about the collection status from the doctor terminal 30 (step 141). If there is no inquiry about the collection status, a negative result is obtained in step 141. In this case, the PDT server 20A repeatedly executes the determination in step 141.

[0060] On the other hand, if there is an inquiry about the collection status, a positive result is obtained in step 141. In this case, the PDT server 20A identifies the version of the patient application that is the subject of the inquiry (step 142). The version of the patient application is included in the inquiry from the doctor terminal 30. Next, the PDT server 20A requests the APS server 10 for the withdrawal status regarding the identified version of the patient app (step 143). The above is the content of the sub-processing executed in step 140. After this, the PDT server 20A transitions to a state of waiting for a response from the APS server 10. In other words, it enters a state of waiting for execution of step 160.

[0061] Upon receiving a response from the APS server 10, step 160 is initiated. When step 160 starts, the PDT server 20A determines whether the collection status is "collected" (step 161). If the collection status is "available", a negative result is obtained in step 161. In this case, the PDT server 20A responds "available" to the doctor terminal 30 (step 162).

[0062] On the other hand, if the withdrawal status is "retired", a positive result is obtained in step 161. In this case, the PDT server 20 determines whether the version in which the cause of withdrawal has been resolved has been published (step 163). The existence of a version for which the cause of recall has been resolved may be obtained from the APS server 10 or from within the server itself. If a version exists for which the cause of withdrawal has been resolved, a positive result is obtained in step 163. In this case, the PDT server 20 responds to the doctor terminal 30 with a text message informing the doctor that the current version is subject to withdrawal, but that a version for which the cause of withdrawal has been resolved exists (step 164). This text message is provided by the APS server 10 together with the withdrawal status.

[0063] On the other hand, if there is no version in which the cause of withdrawal has been resolved, a negative result is obtained in step 163. In this case, the PDT server 20 responds to the doctor terminal 30 with a text message notifying that the version is subject to withdrawal (step 165). The text here is also provided by the APS server 10 along with the collection status. FIG. 9 is a diagram showing an example of the home screen of the PDT server 20A that is displayed when the doctor application A corresponding to the patient application A is started. 9 is an example of a screen displayed when the collection status is “Available.” Note that information such as “Not eligible for collection” or “Available” may also be displayed on the home screen 300A.

[0064] A home screen 300B shown in Fig. 9 is an example of a screen that is displayed when the collection status is “collected.” In Fig. 9, a warning message 301 is displayed in the footer portion of the home screen 300. 9 states, "Patient application A has been subject to withdrawal and is currently unavailable." By employing this warning message 301, doctors and other personnel can be made aware that patient application A has been subject to withdrawal at the time of logging in to the PDT server 20A.

[0065] Fig. 10 is a diagram showing another example of the home screen of the PDT server 20A that is displayed when the doctor application A corresponding to the patient application A is started up. In Fig. 10, parts corresponding to those in Fig. 9 are assigned the same reference numerals. FIG. 10 shows another example of the warning message 301. Home screen 300C shows an example of a display in which a version for which the cause of the recall has been resolved is currently being prepared. For this reason, the warning message 301 includes the following sentence: "A version for which the cause of the recall has been resolved is currently being prepared."

[0066] On the other hand, home screen 300D is an example of a display when a version that resolves the cause of the recall has already been released. For this reason, the warning message 301 includes the sentence "Please encourage users to update to the new version." When home screen 300C or home screen 300D is used, it is possible to reduce the burden on doctors and the like of having to check again whether there is a patient app for which the cause of recall has been resolved. In addition, it is expected that information will be provided to patients who are using patient app A through doctors and the like.

[0067] <When making an inquiry from a patient's device> Fig. 11 is a sequence diagram illustrating the cooperative operation between the APS server 10, the PDT server 20A, and the patient terminal 40. In Fig. 11, the symbol S in the figure also means a step. In this embodiment, the patient terminal 40 is a smartphone. 11, the PDT server is also the "PDT server 20A." The reason is that the patient application started on the patient terminal 40 is the "patient application A."

[0068] Therefore, if the patient application started on the patient terminal 40 is different, the PDT server with which the patient terminal 40 communicates also changes. 11 is also started by the activation of the patient application A by the patient terminal 40 (step 200). It is assumed that the activation of the patient application A here occurs when recording measurement values measured at home or the like. When the patient application A is started, a login screen for logging in to the corresponding PDT server 20A is displayed, or login is performed using a saved account and password (step 210).

[0069] The PDT server 20A that is logged in from the patient terminal 40 authenticates whether the patient has access authority (step 220). The authentication result (i.e., success (OK) or failure (NG)) is notified to the patient terminal 40 from the PDT server 20A. When the authentication is successful (OK), the patient terminal 40 inquires the PDT server 20A about the collection status of the patient application A (step 230). In the case of this embodiment, the inquiry to the PDT server 20A corresponding to the patient application A is automatically executed by the patient terminal 40 that has confirmed the activation of the patient application A. This inquiry is executed, for example, as part of the functions of the patient application A.

[0070] <00>< / 000368>The PDT server 20A that has received the inquiry from the patient terminal 40 with successful authentication inquires the APS server 10 about the collection status of the patient application A (step 240). This inquiry also has the meaning of double-check between the PDT server 20A and the APS server 10. The APS server 10 that has received the inquiry reads out the collection status 141B (see FIG. 3) of the patient application A and responds with the read collection status (step 250).

[0071] The PDT server 20A that has received the response of the collection status responds to the patient terminal 40 that is the inquiry source with the collection status and the like (step 260). For example, the collection status and the home screen according to the collection status are presented. The patient terminal 40 that is the destination displays an input screen or a use stop screen (step 270). When the input screen is displayed, the patient can input measurement values and the like. On the other hand, the use stop screen is a screen that notifies the patient of the suspension of the use of the patient application A. The use stop screen is displayed unless the latest patient application A with the resolved collection cause is installed on the patient terminal.

[0072] <Processing operation of PDT server> Subsequently, the detailed operation of the PDT server 20A during the cooperation operation will be described. FIG. 12 is a flowchart for explaining an example of a sub-process executed by the PDT server 20A. In FIG. 12, the parts corresponding to those in FIG. 11 are denoted by corresponding reference numerals. The sub-process shown in FIG. 12 is composed of step 240 and step 260. First, as the process of step 240, the PDT server 20A determines whether or not an inquiry about the collection status has been received from the patient terminal 40 (step 241). If there is no inquiry about the collection status, a negative result is obtained in step 241. In this case, the PDT server 20A executes the determination in step 241 repeatedly.

[0073] On the other hand, if there is an inquiry about the collection status, a positive result is obtained in step 241. In this case, the PDT server 20A identifies the version of the patient application that is the subject of the inquiry (step 242). The version of the patient application is included in the inquiry from the patient terminal 40. Next, the PDT server 20A requests the APS server 10 for the withdrawal status regarding the identified version of the patient app (step 243). The above is the content of the sub-processing executed in step 240. After this, the PDT server 20A transitions to a state of waiting for a response from the APS server 10. In other words, it enters a state of waiting for execution of step 260.

[0074] Upon receiving a response from the APS server 10, step 260 is initiated. When step 260 starts, the PDT server 20A determines whether the collection status is "collected" (step 261). If the collection status is "available", a negative result is obtained in step 261. In this case, the PDT server 20A instructs the display of a patient data input screen (step 262).

[0075] On the other hand, if the withdrawal status is "retired", a positive result is obtained in step 261. In this case, the PDT server 20 determines whether the version in which the cause of withdrawal has been resolved has been published (step 263). The existence of a version for which the cause of recall has been resolved may be obtained from the APS server 10 or from within the server itself. If a version exists for which the cause of withdrawal has been resolved, a positive result is obtained in step 263. In this case, the PDT server 20 responds to the patient terminal with a suspension screen informing the patient that the current version is subject to withdrawal and cannot be used, but that a version for which the cause of withdrawal has been resolved exists (step 264). This text, together with the withdrawal status, is provided by the APS server 10.

[0076] On the other hand, if there is no version for which the cause of withdrawal has been resolved, a negative result is obtained in step 263. In this case, the PDT server 20 responds to the patient terminal with a suspension screen notifying that the current version is subject to withdrawal and therefore cannot be used (step 265). This text is also provided by the APS server 10 together with the withdrawal status.

[0077] FIG. 13 is a diagram showing an example of an input screen 400 displayed on the patient terminal 40 when the patient application A that is not the collection target is launched. In the case of FIG. 13, the measurement date is Wednesday, January 31, 2024, and the blood pressure input time is 8:00 p.m. The systolic blood pressure was 135 mmHg, the diastolic blood pressure was 85 mmHg, and the pulse rate was 70 bpm.

[0078] FIG. 14 shows examples of the use suspension screens 410 and 420 displayed on the patient terminal 40 when the patient application A to be collected is started. The suspension screen 410 is made up of a title field 411, an explanation 412, and a "close" button 412.

[0079] The title field 411 displays "Notice." Incidentally, the use suspension screen 410 is displayed when the patient app for which the cause of recall has been resolved is not published. For this reason, the explanation 412 displays "Patient app A has been designated as a target for recall by instructions from the authorities." The display of this use suspension screen 410 allows the patient to know the reason why they cannot enter patient data. This explanation 412 is an example of information indicating whether the patient app is a target for recall.

[0080] Although the explanation 412 only notifies that the service is unavailable, it may also include information about the current progress or the release date of the compatible version, such as "We are currently in preparation" or "We plan to provide a compatible version around February 10, 2024." By including this type of information on the use suspension screen 410, the patient can more easily predict the time until use of the patient application A can be resumed.

[0081] On the other hand, the suspension screen 420 is made up of a title field 421, an explanation 422, and an “update” button 423. In the case of the suspension screen 420, the title field 421 also displays "Notice." Incidentally, the usage suspension screen 420 is displayed when the patient app whose cause for recall has been resolved has already been released.

[0082] For this reason, the explanatory text 422 displays the sentence "The use of the current version of patient app A is restricted by instructions from the authorities," the sentence "However, it can continue to be used by updating to a new version," and the sentence "Please update to a new version." The display of these usage suspension screens 420 lets the patient know that they can simply update the patient app. Needless to say, when the usage suspension screen 410 or 420 is displayed, the operation of the patient app on the patient terminal 40 is restricted. Specifically, input of patient data, etc. is controlled to be unexecutable. The explanation 422 is an example of information indicating whether the patient application is subject to withdrawal or not, and is also an example of information indicating whether the application is usable or not. In the case of the usage suspension screen 420, operating the "Update" button 423 starts the download and installation of the patient app for which the cause of recall has been resolved.

[0083] <Summary> By employing the PDT server 20 (see FIG. 1) assumed in this embodiment, it becomes possible to notify a doctor or the like operating a doctor terminal 30 (see FIG. 7) that a patient app corresponding to a launched doctor app is subject to recall. It also becomes possible to notify the patient via the doctor or the like. In addition, for patients who have launched the patient app to enter patient data, the suspension screens 410, 420 (see Figure 14) can be displayed on the patient terminal 40 (see Figure 11) to inform them of the reason why they cannot use the patient app and the operations required to use it.

[0084] Furthermore, in this embodiment, a mechanism is adopted in which the PDT server 20 can provide information regarding the "withdrawal" of patient apps to the doctor terminal 30 and the patient terminal 40 through cooperation with the APS server 10 (see FIG. 1). This makes it possible to eliminate variations in management status due to differences in the service providers managing the PDT server 20. In other words, as explained in this embodiment, if the PDT server 20 is equipped with a mechanism for cooperation with the APS server 10, it becomes possible to uniformly prevent omissions or delays in communication with doctors and patients. In other words, information regarding the availability of patient apps can be provided in a unified manner.

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

[0086] (2) The processor in the above-described embodiments refers to a processor in a broad sense, and includes general-purpose processors (e.g., CPUs (=Central Processing Units)) as well as dedicated processors (e.g., GPUs (=Graphical Processing Units), ASICs (=Application Specific Integrated Circuits), FPGAs (=Field Programmable Gate Arrays), programmable logic devices, etc.). Furthermore, the operations of the processors in each of the above-described embodiments may be performed by multiple processors working together, rather than by a single processor. The order in which the processors perform the operations is not limited to the order described above, and may be changed individually.

[0087] (3) In the above-described embodiment, when a doctor app corresponding to a patient app to be collected is launched (i.e., when logging in to the corresponding PDT server 20), a warning message 301 (see FIGS. 9 and 10) is additionally displayed on the home screen 300A (see FIG. 9). However, the warning message 301 may also be displayed on a screen for viewing the patient data of a patient who is using the patient app to be collected (hereinafter referred to as the “patient data screen”).

[0088] 15 is a diagram illustrating an example of a consultation screen 310 displayed on the doctor terminal 30. The consultation screen 310 shown in FIG. 15 is displayed based on the patient data 242 of "Tokyo Taro" (see FIG. 6) read from the PDT server 20. The patient data field on the examination screen 310 shown in FIG. 15 is made up of a display field 311 for changes in average blood pressure, a display field 312 for review information, a display field 313 for activity records, and an end button 314.

[0089] In the case of FIG. 15, the displayed date on the consultation screen is January 21, 2024. Therefore, display field 311 displays the average blood pressure, average pulse rate, and blood pressure measurement rate calculated from patient data from 8 weeks to 4 weeks before the display date (December 3rd to December 23rd, 2023), and the average blood pressure, average pulse rate, and blood pressure measurement rate calculated from patient data from 4 weeks before the display date to the day before (December 24th, 2023 to January 20th, 2024).

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

[0091] Fig. 16 is a diagram illustrating an example of a consultation screen 310 to which a warning message 315 has been added. In Fig. 16, parts corresponding to those in Fig. 15 are assigned the same reference numerals. In the case of FIG. 16, the footer of the consultation screen 310 displays the following: "Patient app A used by Tokyo Taro is being recalled." and "A version that resolves the reason for recall is currently being prepared." In the above-described embodiment, a warning message 301 (see FIG. 9) is displayed on the home screen 300B (see FIG. 9) or the like that is displayed when the doctor app is started, but by displaying a warning message 315 on the examination screen 310, it is possible to reduce omissions of information to the patient during the examination. Note that the wording of the warning message 301 is an example, and it is also possible to present information about the existence of a patient app whose cause for recall has been resolved or to encourage updating, as on a usage suspension screen 420 (see FIG. 14) of the patient terminal 40 (see FIG. 14).

[0092] (4) In the above-described embodiment, the PDT server 20A presents information indicating whether the patient app A corresponding to the doctor app A launched by the doctor or the like is subject to withdrawal through the home screen 300B (see FIG. 9), the home screens 300C and 300D (see FIG. 10), and the suspension screens 410 and 420 (see FIG. 14). However, the PDT server 20A may also notify the user that the patient app A is unavailable.

[0093] (5) In the above-described embodiment, the recovery status of the patient app is confirmed in steps 130, 140, etc. (see FIG. 7) and steps 230, 240, etc. (see FIG. 11). However, a mechanism for inquiring about a status indicating whether the patient app can be used (different from the usage status 140F in FIG. 3) may be employed. Of course, it is assumed that the status indicating whether the patient app can be used is managed by the APS server 10. The status here is a "status regarding whether the patient app can be used" and is different from the usage status 140F indicating the usage status of the patient app by the patient. The "status regarding whether the patient app can be used" is an example of information indicating whether the patient app can be used.

[0094] (6) In the above-described embodiment, hypertension, nicotine addiction, insomnia, NASH (non-alcoholic steatohepatitis), and kidney disease are given as examples of diseases for which therapeutic apps have been approved or are under development, but this does not exclude other diseases. For example, the app can be applied to alcoholism, cancer, chronic heart failure, attention deficit hyperactivity disorder, type 2 diabetes, depression, tinnitus, delayed grief disorder, opioid-induced constipation, post-mastectomy pain syndrome, bronchial asthma, obesity, and nephrotic syndrome.

[0095] <Summary> The disclosed examples described in the above-mentioned embodiments are shown below. (((1))) A management server that manages patient data input through a patient app, which has one or more processors, and which acquires information indicating whether a prescribed patient app is subject to recall or whether it is available for use from a management server that manages the usage status of prescribed patient apps and provides the information to a medical institution's terminal or a patient's terminal. This management server can provide information on whether or not each patient can use the patient app in use in a centralized manner.

[0096] (((2))) The management server according to (((1))), wherein the one or more processors, when the patient app is subject to withdrawal or is unavailable, display a message to that effect on a terminal of the medical institution. This management server can notify the patient via a doctor or the like that the patient app they are using is being withdrawn or is no longer available for use.

[0097] (((3))) The management server described in (((2)))), wherein, when a new version of the patient app that resolves the cause of recall has already been released, the one or more processors display information on the terminal of the medical institution urging the medical institution to update to the new version of the patient app. This management server can notify patients via their doctors or other personnel that the patient app they are using needs to be updated.

[0098] (((4))) The management server according to (((2))), wherein the one or more processors display on a home screen of the server a message indicating that the patient app is subject to withdrawal or is unavailable. This management server makes it possible to check information on the home screen of the server itself.

[0099] (((5))) The management server according to (((2))), wherein the one or more processors display on a patient data viewing screen a message indicating that the patient app is subject to withdrawal or is unavailable. This management server can reduce the number of missed communications with patients during their consultations. (((6))) The management server according to (((1))), wherein the one or more processors, when the patient app is subject to withdrawal or is unavailable, display a message to that effect on the patient's terminal. This management server can directly notify patients that the patient app they are using is being withdrawn.

[0100] (((7))) The management server according to (((6))), wherein the one or more processors, when the patient app is subject to withdrawal or is unavailable, display on the patient's terminal a message indicating that the operation of the patient app will be restricted. This management server can notify the patient that the patient application in use is subject to withdrawal by restricting its operation.

[0101] (((8))) The management server according to (((6))), wherein, if a new version of the patient app that resolves the cause of recall has already been released, the one or more processors display information on the patient's device urging the patient to update to the new version of the patient app. This management server can directly notify patients that the patient app they are using needs to be updated.

[0102] (((9))) The management server according to (((6))), wherein the one or more processors restrict operation of the patient app on the patient's terminal when the patient app is subject to withdrawal or is unavailable. This management server makes it possible to forcibly restrict the use of patient apps that are subject to recall.

[0103] (((10))) An information provision method in which a management server that manages patient data entered through a patient app obtains information indicating whether a prescribed patient app is subject to recall or whether it is available for use from a management server that manages the usage status of the prescribed patient app, and provides the information to a medical institution's terminal or a patient's terminal. According to this information providing method, information regarding whether or not the patient app currently being used by each patient can be provided in a unified manner.

[0104] (((11))) A program for enabling one or more processors in a management server that manages patient data entered through patient apps to realize a function of obtaining information indicating whether a prescribed patient app is subject to recall or whether it is available for use from the management server that manages the usage status of prescribed patient apps, and providing the information to a medical institution's terminal or a patient's terminal. This program allows for centralized provision of information regarding the availability of patient apps currently being used by each patient. [Explanation of symbols]

[0105] 10...APS server, 20, 20A, 20B, 20C, 20D, 20E, 20F...PDT server, 30...doctor's terminal, 40...patient's terminal, 140...status management data by prescription code, 141, 240...status management data by patient app, 241...prescription code list, 242...patient data

Claims

1. having one or more processors; The processor: obtains information indicating whether a prescribed patient app is subject to recall or whether it is available for use from a management server that manages the usage status of prescribed patient apps, and provides the information to a medical institution's terminal or a patient's terminal; A management server that manages patient data entered through the patient app.

2. the one or more processors: If the patient app is subject to recall or is unavailable, a message to that effect is displayed on the medical institution's terminal. The management server according to claim 1 .

3. the one or more processors: If a new version of the patient app that resolves the cause of the recall has already been released, displaying information on the terminal of the medical institution that encourages the patient to update to a new version of the patient app; The management server according to claim 2 .

4. the one or more processors: Displaying on the home screen of the server a message that the patient app is subject to withdrawal or is unavailable. The management server according to claim 2 .

5. the one or more processors: Displaying on the patient data viewing screen a message that the patient app is subject to withdrawal or is unavailable. The management server according to claim 2 .

6. the one or more processors: If the patient app is subject to withdrawal or is unavailable, a message to that effect is displayed on the patient's device. The management server according to claim 1 .

7. the one or more processors: If the patient app is subject to withdrawal or is unavailable, a message indicating that the operation of the patient app will be restricted is displayed on the patient's device. The management server according to claim 6.

8. the one or more processors: If a new version of the patient app that resolves the cause of the recall has already been released, displaying information on the patient's device prompting the patient to update to a new version of the patient app; The management server according to claim 6.

9. the one or more processors: If the patient app is subject to recall or is unavailable, restricting the operation of the patient app on the patient's device. The management server according to claim 6.

10. The management server that manages patient data entered through the patient app obtains information indicating whether a prescribed patient app is subject to recall or whether it is available for use from a management server that manages the usage status of prescribed patient apps, and provides the information to a medical institution's terminal or a patient's terminal; Information provision method.

11. One or more processors in a management server that manages patient data input through the patient app A program for realizing the function of obtaining information indicating whether a prescribed patient app is subject to recall or whether it is available for use from a management server that manages the usage status of prescribed patient apps, and providing this information to a medical institution's terminal or a patient's terminal.

Images