Management server, information provision method, and program

Abstract

To enable central provision of information regarding whether a new prescription of a patient application from a different provider can be issued or not.SOLUTION: A program disclosed herein causes one or more processors of a management server managing usage statuses of prescribed patient applications to centrally manage information indicative of whether patient applications are to be recalled or not or information indicative of whether new prescriptions can be issued or not, and provide information regarding whether a new prescription can be issued or not for each patient application to a terminal of a medical institution.SELECTED DRAWING: Figure 6

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, doctors must stop prescribing it. However, in reality, there is a possibility that variations will occur among manufacturers and distributors.

[0005] One aspect of the present disclosure makes it possible to centrally provide information regarding the acceptability of new prescriptions for patient apps provided by different providers. [Means for solving the problem]

[0006] The invention described in claim 1 is a management server that has one or more processors, and that collectively manages information indicating whether or not a patient app is subject to recall or information indicating whether or not a new prescription is possible, and provides information regarding whether or not a new prescription is possible for the patient app to a terminal of a medical institution, and manages the usage status of the patient app that has been prescribed. The invention described in claim 2 is the management server described in claim 1, wherein, when the patient app set to be collected or the patient app for which new prescriptions have been suspended is detected, the one or more processors display, as information regarding the propriety of the new prescription, a message indicating that there is a patient app for which new prescriptions have been suspended. The invention described in claim 3 is the management server described in claim 1, wherein, when the patient app set to be collected or the patient app for which new prescriptions have been suspended is detected, the one or more processors display information identifying the patient app for which new prescriptions have been suspended as information regarding the propriety of the new prescriptions. The invention described in claim 4 is the management server described in claim 2 or 3, wherein the one or more processors display information regarding the acceptability of the new prescription on the home screen of the server. The invention described in claim 5 is a management server described in claim 2 or 3, wherein the one or more processors display information regarding whether or not the new prescription is acceptable on an operation screen on which an operator for opening a new prescription screen is located. The invention described in claim 6 is the management server described in claim 2 or 3, wherein the one or more processors display information regarding whether the new prescription is acceptable on a new prescription screen. The invention described in claim 7 is the management server described in claim 6, wherein the one or more processors display information regarding whether or not the new prescription is acceptable in a selection field of the patient app for which the prescription is to be made. The invention described in claim 8 is the management server described in claim 6, wherein the one or more processors display the prescription controls in an inactive state or hide them when new prescriptions for the patient app selected as the prescription target are stopped. The invention recited in claim 9 is the management server recited in claim 1, wherein at least some of the patient applications managed by the server are provided by a different source than the other patient applications. The invention described in claim 10 is an information providing method in which a management server that manages the usage status of prescribed patient apps collectively manages information indicating whether or not a patient app is subject to recall or information indicating whether or not a new prescription is possible, and provides information regarding whether or not a new prescription is possible for the patient app to a terminal of a medical institution. The invention described in claim 11 is a program for enabling one or more processors in a management server that manages the usage status of prescribed patient apps to perform a function of centrally managing information indicating whether or not a patient app is subject to recall or information indicating whether or not a new prescription is possible, and a function of providing information regarding whether or not a new prescription is possible for each patient app to a terminal of a medical institution. [Effects of the Invention]

[0007] According to one embodiment of the present disclosure, information regarding the acceptability of new prescriptions for patient apps provided by different providers can be provided 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. 2 is a diagram illustrating an example of the hardware configuration of a PDT server. [Figure 5] 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 6] FIG. 10 is a sequence diagram illustrating a processing operation executed by the APS server. [Figure 7] 7 is a flowchart illustrating an example of a sub-process executed in step 100 of FIG. 6. [Figure 8] FIG. 10 is a diagram showing an example of a management parameter change screen. [Figure 9]7 is a flowchart illustrating an example of a sub-process executed in step 220 of FIG. 6. [Figure 10] 10 is a diagram illustrating an example of a home screen of the APS server displayed on the doctor terminal. FIG. [Figure 11] FIG. 10 is a diagram illustrating an example of a prescription list screen of a doctor terminal. [Figure 12] FIG. 10 is a diagram showing a display example of a new prescription screen. [Figure 13] 7 is a flowchart illustrating an example of a sub-process executed in step 330 of FIG. 6. [Figure 14] FIG. 14 is a diagram illustrating an example of a new prescription screen displayed in step 334 and step 335 of FIG. 13. [Figure 15] FIG. 10 is a diagram illustrating another display example of the prescription list screen. 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 the operation. "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 lines.

[0032] The processor 11 is a device that realizes various functions through program execution. The processor 11, ROM 12, and RAM 13 function as a computer. The auxiliary storage device 14 is composed of, for example, a hard disk device or a semiconductor storage. The auxiliary storage device 14 stores data such as status management data 140 by prescription code prescribed by a medical institution and status management data 141 by patient application.

[0033] For connection to the input device 16, the input interface 15 uses, for example, USB (= Universal Serial Bus), Bluetooth (registered trademark). The input device 16 uses, for example, a keyboard, a mouse, or a touch panel. For connection to the output device 18, the output interface 17 uses, for example, HDMI (registered trademark) (= High-Definition Multimedia Interface), a LAN interface. The output device 18 uses, 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), a mobile communication system, and other communication standards.

[0034] <Management data of APS server> FIG. 3 is a diagram for explaining an example of the 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 application 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 expiration period of the patient application, the type of insurance card, and the insurance number may be stored.

[0035] The prescription code 140A is issued for each patient app that receives a prescription notification from a medical institution's terminal. An activation code is notified to a patient whose prescription code 140A has been successfully authenticated. The patient ID (patient name) 140B is an identification code and patient name that the patient app uses to identify the patient to whom the prescription is given. The patient ID is assigned, for example, when a new patient is registered based on a prescription code. The patient name is stored only when registration is made from the patient's terminal. In the case of Figure 3, the patient name for patient ID "12543" is "Mr. A."

[0036] The prescription date (treatment date) 140C is the date on which the doctor examined the patient. In this embodiment, the treatment date on which the doctor prescribed the patient app is referred to as the "prescription date" to distinguish it from other 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 withdrawal status 141B, a new prescription status 141C, and a display text for a doctor 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] 3 shows only patient applications A, B, and C, but in this embodiment, patient applications D, E, and F are also managed. Due to space limitations, only one version is recorded for each patient application in FIG. 3, but multiple versions may be recorded for each patient application. In this case, patient applications with different versions are recorded in separate 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, "recalled" and "usable" are recorded in the withdrawal status 141B. "Recalled" 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. In this embodiment, the collection status 141B is registered by a person in charge of the service provider who manages the APS server 10. However, the collection status 141B may also be obtained through communication from the PDT server 20 that manages the status.

[0041] The new prescription status 141C is an example of information indicating whether new prescriptions for a patient app are possible. Naturally, prescriptions for a patient app that is subject to recall will not be permitted until the cause is resolved. In the case of Figure 3, the recall status 141B records "Permitted" and "Suspended." Needless to say, "Permitted" indicates that new prescriptions for the patient app are possible. Furthermore, "Suspended" indicates that new prescriptions for the patient app are temporarily suspended. In this embodiment, the new prescription status 141C is registered by a person in charge of the service provider who manages the APS server 10.

[0042] The doctor terminal display text 141D is text to be displayed on the doctor terminal when a patient app for which a new prescription is temporarily suspended is detected. The content of the displayed text may be a standard phrase, or may be freely input by the person in charge of managing the APS server 10. For example, the doctor terminal display text 141D records a standard phrase selected by the person in charge of managing the APS server 10.

[0043] The text content may be prepared for each screen to be displayed. In this embodiment, two types of text are prepared: one for display on the home screen and one for display on the new prescription screen. 3, the doctor 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.

[0044] <PDTサーバ>

[0045] FIG. 4 is a diagram illustrating an example of the hardware configuration of the PDT server 20. As shown in FIG. 4 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.

[0046] 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. The auxiliary storage device 24 is configured by, for example, a hard disk device or semiconductor storage. The auxiliary storage device 24 stores status management data 240 for each patient application, a prescription code list 241, patient data 242 recorded through the patient application, and the like. The communication interface 25 is an interface for communicating with external terminals such as the APS server 10 via a network. The communication interface 25 is compatible with Ethernet (registered trademark), Wi-Fi (registered trademark), mobile communication systems, and other communication standards.

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

[0048] The prescription code list 241 stores a prescription code 241A, a patient ID (patient name) 241B, and a patient app name (version) 241C. Valid prescription codes are stored in this prescription code list 241. 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 controls the stop of the operation of the patient app, it is regarded as the end of the insurance medical treatment period.

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

[0050] <Processing Operations of APS Server> FIG. 6 is a sequence diagram for explaining the processing operations executed in the APS server 10. Note that in the figure, the symbol ST means stage and the symbol S means step. The processing operations shown in FIG. 6 are represented from the viewpoints of collection management and new prescription management of the patient app. The processing operations shown in FIG. 6 are composed of three stages ST1, ST2, and ST3. Below, the processing operations executed in each stage will be individually explained.

[0051] <ST1: Setting of Recovery Target> First, the APS server 10 receives a parameter change through an input operation on the input device 16 (see FIG. 2) (step 100). FIG. 7 is a flowchart for explaining an example of a sub-process executed in step 100 (see FIG. 6). First, the APS server 10 receives a change in the management parameters of the patient application through the change screen (step 101).

[0052] FIG. 8 is a diagram showing an example of the management parameter change screen 180. The management parameter change screen 180 shown in FIG. 8 is displayed on a monitor as the output device 18 (see FIG. 2). The management parameter change screen 180 shown in FIG. 8 is composed of a title bar 181, an input field 182 for the target application, an input field 183 for the new prescription status, an input field 184 for the target version, an input field 185 for the recovery status, an input field 186 for the display text for the doctor terminal, a "Cancel" button 187, and an "OK" button 188.

[0053] In the case of FIG. 8, the title bar 181 displays "Change of Management Parameters". The input field 182 for the target application displays "Patient Application A", the input field 183 for the new prescription status displays "Suspended", the input field 184 for the target version displays "2", and the input field 185 for the recovery status displays "Recovery". For example, in the input fields 182 for the target application, 183 for the new prescription status, and 185 for the recovery status, items selected from the pull-down menus of each field are displayed. Also, in the input field 184 for the target version, a person in charge of the service provider that manages the APS server 10 inputs the version of the patient application designated as the recovery target.

[0054] The input field 186 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 "Cancel" button 187 is used to cancel the changes, and operating this button closes the management parameter change screen 180. On the other hand, operating the "Confirm" button 188 confirms the contents entered on the management parameter change screen 180.

[0055] Returning to the explanation of Figure 7. When the acceptance of the change of the management parameters is confirmed, the APS server 10 acquires the valid prescription code list 241 (see FIG. 5) from the PDT server 20 (see FIG. 1) that manages the patient data of the patient application that is the target of the change (step 102). Next, the APS server 10 extracts one unprocessed prescription code from the prescription code list 241 (step 103). Thereafter, the APS server 10 determines whether the version corresponding to the prescription code to be processed is the same as the version to be collected (step 104).

[0056] If the versions are the same, a positive result is obtained in step 104. In this case, the APS server 10 changes the status of the status management data 141 (see FIG. 3) to the received parameter value (step 105). Specifically, the APS server 10 changes the withdrawal status 141B (see FIG. 3) to "withdrawn" and the new prescription status 141C (see FIG. 3) to "suspended." On the other hand, if the versions are different, a negative result is obtained in step 104. In this case, the APS server 10 transitions to step .

[0057] Now, if a negative result is obtained in step 104, or after step 105 is executed, the APS server 10 determines whether or not processing of all valid prescription codes has been completed (step 106). If there are unprocessed prescription codes in the valid prescription codes, a negative result is obtained in step 106. In this case, the APS server 10 returns to step 103. On the other hand, if the processing of all prescription codes of the valid prescription codes is completed, an affirmative result is obtained in step 106. In this case, the process related to receiving the parameter change by the processor 11 ends.

[0058] <ST2: When logging in from the doctor terminal> Return to the description of FIG. 6. The processing operation of stage ST2 is started by logging in from the doctor terminal 30 (step 200). The APS server 10 logged in from the doctor terminal 30 authenticates whether a doctor or the like has access authority (step 210). The authentication result (that is, success (OK) or failure (NG)) is notified from the APS server 10 to the doctor terminal 30.

[0059] If the authentication is successful (OK), the APS server 10 checks the new prescription status of the patient application handled by the login source (step 220). FIG. 9 is a flowchart for explaining an example of the sub-process executed in step 220 (see FIG. 6). First, the APS server 10 identifies the medical institution of the login source (step 221). Instead of the medical institution of the login source, a doctor or the like logged in through the doctor terminal 30 (see FIG. 6) may be identified.

[0060] Next, the APS server 10 determines whether there is an application with the new prescription status 141C (see FIG. 3) on hold among the patient applications handled by the login source (step 222). "Handled" may include not only patient applications with prescription records but also patient applications with handling contracts with the operator or the like operating the APS server 10.

[0061] If a patient app with a new prescription status of suspended is detected, a positive result is obtained in step 222. In this case, the APS server 10 generates a home screen including display text for the doctor terminal (step 223). The home screen is the screen that is first displayed when you have successfully logged in. The doctor terminal display text is the text set in the doctor terminal display text input field 186 (see FIG. 8). If a patient app with a new prescription status of suspended is not detected, a negative result is obtained in step 222. In this case, the pre-prepared home screen is displayed as is.

[0062] Returning to the explanation of Figure 6. After step 220, the APS server 10 provides the doctor terminal 30 with a home screen according to the confirmation result (step 230). FIG. 10 is a diagram illustrating an example of a home screen 300 of the APS server 10 (see FIG. 1) displayed on the doctor terminal 30 (see FIG. 6). 10 is a display example when a patient app with a paused new prescription status 141C (see FIG. 3) is detected. Therefore, a warning message 301 is displayed in the footer of the home screen 300.

[0063] The warning message 301 in Figure 10 displays "Patient app A has stopped new prescriptions." By using this warning message 301, doctors and other medical professionals can be made aware that new prescriptions cannot be made for patient app A at the time of login. In addition, it may be possible to display a message notifying the reason for the suspension of new prescriptions, such as "Patient App A has been subject to recall." If this message is adopted, doctors and other related parties can be made aware at the time of login that Patient App A is being recalled. Alternatively, it may be possible to notify only the existence of a patient app for which new prescriptions have been suspended, such as "There is a patient app for which new prescriptions have been suspended." If this content is adopted, doctors and other medical professionals can be made aware of the existence of a patient app for which new prescriptions have been suspended at the time of logging in.

[0064] <When receiving the display of the new prescription screen> Return to the explanation of FIG. 6. The processing operation of stage ST3 is started by the display operation of the new prescription screen from the doctor terminal 30. FIG. 11 is a diagram for explaining an example of the prescription list screen 310 of the doctor terminal 30. On the prescription list screen 310 shown in FIG. 11, an information column 311, the current date and time 312, a "Details" button 313, and a "New Prescription" button 314 are arranged.

[0065] In the information column 311, the management information of the patient apps prescribed for each patient is displayed. The information column 311 shown in FIG. 11 is displayed in a table format. Incidentally, information for each patient is displayed in rows, and the management items of the patient app are displayed in columns. In the case of FIG. 11, as management items, patient ID / patient name 311A, patient app name 311B, usage status 311C, prescription date 311D, and expiration date of the prescription code 311E are exemplified.

[0066] The patient ID / patient name 311A is a display column for information identifying the patient for whom the patient app was prescribed. The patient app name 361B is a display column for the name of the patient app prescribed for the patient. The usage status 311C is a display column for the usage status of the patient app after prescription. Three states, "Before use", "In use", and "Ended", are displayed.

[0067] The prescription date 311D is a display column for the date on which the patient app was prescribed. The expiration date of the prescription code 311E is a display column representing the last day of the period during which the prescription code issued at the time of prescribing the patient app is valid. In the case of this embodiment, the date three days after the prescription date is displayed. The current date and time 312 represents the viewing date and time of the prescription list screen 310. The "Details" button 313 is a button used to display a patient data viewing screen. In other words, the "Details" button 313 is a button that launches a browser or window that displays patient data.

[0068] The "New Prescription" button 314 is a button used when prescribing a patient application. When the "New Prescription" button 314 is operated, a new prescription screen for inputting the patient application name, patient name, sex, date of birth, etc. is displayed. Therefore, the "New prescription" button 314 is an example of an operator for opening a new prescription screen. Therefore, the prescription list screen 310 is an example of an operation screen on which an operator for opening a new prescription screen is arranged.

[0069] Returning to the explanation of Figure 6. In step 300, it is assumed that the operation of the "New Prescription" button 314 (see FIG. 11) has been accepted. Upon receiving the operation of the "New Prescription" button 314, the APS server 10 displays a new prescription screen on the doctor terminal 30 (step 310). Fig. 12 is a diagram showing a display example of a new prescription screen 320. The new prescription screen 320 shown in Fig. 12 has a title field 321, a patient application name input field 322, a medical record number input field 323, and a prescription button 324 arranged thereon.

[0070] 12 is an initial screen. Therefore, the patient application name input field 322 and the medical record number input field 323 are both blank. In addition, the prescription button 324 is labeled "Prescribe." A doctor or the like operating the doctor terminal 30 selects the name of the patient application to be prescribed from, for example, a pull-down menu in the patient application name input field 322. The selected patient application name is notified from the doctor terminal 30 to the APS server 10.

[0071] The APS server 10, which has received the notification of the patient application name, displays a new prescription screen corresponding to the new prescription status 141C of the received patient application on the doctor terminal 30 (step 330). FIG. 13 is a flowchart illustrating an example of the sub-processing executed in step 330 (see FIG. 6). First, the APS server 10 receives the selection of a patient application for a new prescription (step 331).

[0072] Next, the APS server 10 determines whether the new prescription status 141C is temporarily suspended (step 332). If the new prescription status 141C is "OK", a negative result is obtained in step 332. In this case, the APS server 10 displays the new prescription screen 320 on which the prescription button 324 can be operated (step 333). On the other hand, if the new prescription status 141C is "suspended," a positive result is obtained in step 332. In this case, the APS server 10 controls the prescription button on the new prescription screen to an inactive state (step 334), and displays the new prescription screen including a warning message indicating that the new prescription is suspended (step 335).

[0073] Figure 14 is a diagram illustrating an example of new prescription screens 320A and 320B displayed in step 334 (see Figure 13) and step 335 (see Figure 13). In Figure 14, parts corresponding to those in Figure 12 are assigned the same reference numerals. The new prescription screen 320A shows an example of a display screen when a patient app with a new prescription status of "OK" is selected. Incidentally, "Patient app B" is displayed in the patient app name input field 322. Since patient app B is available for prescription, the prescription button 324 is also displayed as operable. Incidentally, in FIG. 14, the operable state is represented by a solid line.

[0074] The new prescription screen 320B shows an example of a display screen when a patient app with a new prescription status of "suspended" is selected. Incidentally, "Patient app A" is displayed in the patient app name input field 322. Since the prescription for patient app A is suspended, the words "Prescription suspended" are also displayed along with the patient app name. This display allows doctors and others to know from the screen display that patient app A cannot be prescribed. In addition, the new prescription screen 320B displays information indicating that new prescriptions cannot be made in addition to the patient app name input field 322.

[0075] First, the prescription button 324 is displayed in an inoperable state. For example, the prescription button 324 is displayed in a grayed-out state, and is in an inoperable state both physically and visually. Incidentally, in FIG. 14, the inoperable state is represented by a dashed line. The prescription button 324 in this display state is an example of an inactive state. Note that the prescription button 324 may also be hidden. Additionally, a warning message 325 is added to the new prescription screen 320B. In the case of Fig. 14, the warning message 325 includes the explanatory text "Patient application A has stopped new prescriptions."

[0076] The warning message 325 may display content notifying the reason why new prescriptions have been suspended, such as "Patient app A has been subject to recall." If this content is adopted, it is possible to notify doctors and others that patient app A has reasons for recall at the time of prescribing a new patient app.

[0077] <Summary> By adopting the APS server 10 (see Figure 1) assumed in this embodiment, it becomes possible to inform doctors and others operating the doctor terminal 30 of the existence of patient apps that cannot be newly prescribed and the names of the target patient apps at the time of logging in or prescribing a new patient app. Incidentally, the home screen 300 (see FIG. 10) and the new prescription screen 320 of the APS server 10 are screens that are checked on a daily basis in order to prescribe a new patient app to a patient.

[0078] These screens are also used in common by multiple patient apps. Therefore, doctors and other medical professionals can centrally check whether a new prescription is possible for multiple patient apps that have the potential for prescriptions on the management screen of the APS server 10 (see FIG. 1) without having to individually access the PDT server 20 (see FIG. 1) that manages the patient data for each patient app.

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

[0080] (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 operations of the processors are performed is not limited to the above-described order, and may be changed individually.

[0081] (3) In the above-described embodiment, in step 220, the new prescription status 141C (see FIG. 3) is checked for the patient apps handled by the login source, and the home screen 300 (see FIG. 10) corresponding to the check result is provided to the doctor terminal 30. However, the new prescription status 141C may be checked for all patient apps handled by the APS server 10, and the home screen 300 corresponding to the check result may be provided to the doctor terminal 30. In this case, the doctor or the like can learn information related to new prescriptions for patient apps other than those handled by the doctor or the medical institution to which the doctor or the like belongs.

[0082] (4) In the above-described embodiment, new prescription status 141C (see FIG. 3) is checked in step 220 (see FIG. 6), but withdrawal status 141B (see FIG. 3) may also be checked. This is because the withdrawal status 141B being “recalled” means that new prescriptions are stopped.

[0083] (5) In the above-described embodiment, new prescription status 141C (see FIG. 3) is checked in step 330 (see FIG. 6), but withdrawal status 141B (see FIG. 3) may also be checked. This is because the withdrawal status 141B being “recalled” means that the new prescription is stopped.

[0084] (6) In the above embodiment, the APS server 10 manages both the collection status 141B (see FIG. 3) and the new prescription status 141C (see FIG. 3), but it may manage only one of the statuses. This is because, as described above, if either the collection status 141B or the new prescription status 141C is known, it is possible to determine whether a new prescription is acceptable.

[0085] (7) In the above-described embodiment, the home screen 300 (see FIG. 10) and the new prescription screen 320 (see FIG. 12) are used to display information regarding whether a new prescription is available, but the prescription list screen 310 (see FIG. 11) may also be used to display information regarding whether a new prescription is available. Fig. 15 is a diagram for explaining another display example of the prescription list screen 310. In Fig. 15, parts corresponding to those in Fig. 11 are assigned the same reference numerals.

[0086] A warning message 315 has been added to the prescription list screen 310 shown in FIG. 15. In the case of FIG. 15, the warning message 315 displays "Patient app A has stopped new prescriptions." If this warning message 315 is displayed, it is possible to notify a doctor or the like that patient app A cannot prescribe before operating the "New prescription" button 314. The contents of the warning message 315 can be various, similar to the warning message 301 (see FIG. 10) described above.

[0087] (8) In the above-described embodiment, the APS server 10 (see Figure 1) that received the change in the management parameters obtained the prescription code list 241 (see Figure 5) from the PDT server 20 and changed each parameter in the status management data 141 (see Figure 3). However, each parameter in the status management data 141 (see Figure 3) may also be changed without communicating with the PDT server 20.

[0088] (9) 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.

[0089] <Summary> The disclosed examples described in the above-mentioned embodiments are shown below. (((1))) A management server that has one or more processors, which collectively manages information indicating whether or not a patient app prescribed to a patient is subject to recall or information indicating whether or not a new prescription is possible, and provides information regarding whether or not a new prescription of a patient app is possible to a terminal of a medical institution, and manages the usage status of prescribed patient apps. This management server can provide information on whether new prescriptions can be accepted for patient apps provided by different providers in a unified manner.

[0090] (((2))) The information processing system described in (((1)))), wherein, when a patient app that has been set as a subject of withdrawal or a patient app for which new prescriptions have been suspended is detected, the one or more processors display, as information regarding whether or not new prescriptions can be issued, a message indicating that a patient app for which new prescriptions have been suspended exists. This management server makes it possible to check on the operation screen of a doctor's terminal whether there are any patient apps that fall under the grounds for recall under the Pharmaceutical and Medical Device Act.

[0091] (((3))) The management server described in (((2)))), wherein, when a patient app set to be collected or a patient app for which new prescriptions have been suspended is detected, the one or more processors display information identifying the patient app for which new prescriptions have been suspended as information regarding the propriety of new prescriptions. This management server makes it possible to identify patient apps that are subject to recall under the Pharmaceutical and Medical Device Act on the operation screen of a doctor's terminal.

[0092] (((4))) The management server according to (((2))) or (((3))), wherein the one or more processors display information regarding whether a new prescription can be made on a home screen of the server. This management server allows information to be checked on the home screen of the server itself.

[0093] (((5))) The management server according to (((2))) or (((3))), wherein the one or more processors display information regarding whether a new prescription is possible on an operation screen on which an operator for opening a new prescription screen is located. According to this management server, it is possible to check information on an operation screen on which an operator for opening a new prescription screen is arranged.

[0094] (((6))) The management server according to (((2))) or (((3))), wherein the one or more processors display information regarding whether a new prescription is acceptable on a new prescription screen. This management server makes it possible to check information on a new prescription screen.

[0095] (((7))) The management server according to (((6))), wherein the one or more processors display information regarding whether a new prescription is possible in a selection field of the patient app for which the prescription is to be made. This management server makes it possible to check whether a prescription is possible in the selection field of the patient app for which a new prescription is being given.

[0096] (((8))) The management server described in (((6))) wherein the one or more processors display the prescription controls in an inactive state or hide them when new prescriptions for the patient app selected as the prescription target are stopped. This management server can physically disable prescriptions for patient apps for which new prescriptions have been suspended.

[0097] (((9))) The management server according to (((1))), wherein at least some of the patient apps managed by the management server are provided by different sources than other patient apps. This management server allows for centralized management of information regarding the acceptability of new prescriptions for patient apps provided by different providers.

[0098] (((10))) An information providing method in which a management server that manages the usage status of prescribed patient apps collectively manages information indicating whether patient apps prescribed to patients are subject to recall or information indicating whether new prescriptions are possible, and provides information regarding whether new prescriptions are possible for patient apps to a terminal of a medical institution. According to this information provision method, information regarding the availability of new prescriptions for patient apps provided by different providers can be provided in a unified manner.

[0099] (((11))) A program for realizing, in one or more processors in a management server that manages the usage status of prescribed patient apps, a function for centrally managing information indicating whether patient apps prescribed to patients are subject to recall or information indicating whether new prescriptions are possible, and a function for providing information regarding whether new prescriptions are possible for each patient app to a terminal at a medical institution. This program allows for centralized provision of information on whether new prescriptions can be accepted for patient apps from different providers. [Explanation of symbols]

[0100] 10...APS server, 20, 20A, 20B, 20C, 20D, 20E, 20F...PDT server, 30...doctor'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 one or more processors: The information indicating whether or not a patient app prescribed to a patient is subject to recall or whether or not a new prescription is available is centrally managed, Providing information on whether a new prescription is available for the patient app to a medical institution's terminal; A management server that manages the usage status of the prescribed patient app.

2. the one or more processors: When the patient app that has been set as a subject of collection or the patient app for which new prescriptions have been stopped is detected, Displaying information indicating that there is a patient app for which new prescriptions have been suspended as information regarding the availability of the new prescription. The management server according to claim 1 .

3. the one or more processors: When the patient app that has been set as a subject of collection or the patient app for which new prescriptions have been stopped is detected, displaying information identifying the patient app for which new prescriptions have been suspended as information regarding the availability of the new prescription; The management server according to claim 1 .

4. the one or more processors: Displaying information regarding whether the new prescription is acceptable on the home screen of the server. The management server according to claim 2 or 3.

5. the one or more processors: The information regarding whether the new prescription is acceptable or not is displayed on an operation screen on which an operator for opening a new prescription screen is located. The management server according to claim 2 or 3.

6. the one or more processors: Displaying information regarding whether the new prescription is acceptable or not on a new prescription screen. The management server according to claim 2 or 3.

7. the one or more processors: Displaying information regarding whether the new prescription is acceptable or not in a selection field of the patient app for which the prescription is to be made; The management server according to claim 6.

8. the one or more processors: When a new prescription for the patient application selected as a prescription target is stopped, the prescription operation button is displayed in an inactive state or is not displayed. The management server according to claim 6.

9. At least some of the patient apps managed by the server are provided by different sources than other patient apps. The management server according to claim 1 .

10. The management server that manages the usage status of prescribed patient apps The system centrally manages information indicating whether a patient app prescribed to a patient is subject to recall or information indicating whether a new prescription is available, Provide information on whether new prescriptions can be made from the patient app to medical institution terminals. Information provision method.

11. One or more processors in a management server that manages the usage status of prescribed patient apps, A function to centrally manage information indicating whether or not a patient app prescribed to a patient is subject to recall or information indicating whether or not a new prescription is available; The function to provide information on whether or not new prescriptions are available for each patient app to medical institution terminals, A program to achieve this.

Images