Planning methods and planning programs

Abstract

To recommend a menu of a service with a high probability of implementation.SOLUTION: A planning apparatus 100 acquires information on a menu of a predetermined service and information on a stakeholder related to the service. The planning apparatus 100 calculates a frequency of change of execution of the menu for a combination of the stakeholder and the menu. The planning apparatus 100 specifies a menu to be recommended on the basis of the calculated frequency of change. The planning apparatus 100 outputs a specified menu to the stakeholder of the calculated combination. For example, for a provider and a user of a service as stakeholders, the frequency of change can be suppressed and a probability of implementation of a menu by the user can be increased by combining the provider and the user having similarity in an overlap of distributions of parameters including a time, a location, an effect, and a difficulty level that indicate expected values regarding implementation of the menu.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] This invention relates to a planning method and a planning program. [Background technology]

[0002] In recent years, with the aim of achieving digital transformation (DX), there has been a growing expectation that various types of information from existing operations will be collected as data, and that this data will be used to improve and streamline existing operations. For example, in various industries, there is a technology that recommends specific menus based on the expectations of all stakeholders involved in the service, in order to support the planning and implementation of the services to be provided. Stakeholders include, for example, those who plan the service, the providers of the service, and the users who receive the service.

[0003] Traditionally, services such as health checkups, treatments, and rehabilitation plans in government offices, hospitals, and nursing homes were performed manually. However, advances in AI and machine learning technologies are making it possible to automatically plan and implement these services, and technologies are being developed to recommend effective service menus based on data.

[0004] Prior art related to menu recommendations for planning includes, for example, a technology that recommends a personalized best menu based on similar past cases, which is expected to maximize the effect on improving the level of care required for the target user. Another technology prioritizes and recommends rehabilitation plan menus by profiling the user, taking into account the user's interests and risks such as illness. Yet another technology recommends rehabilitation menus based on pre-assessment of the user, considering the user's difficulty of implementation and effectiveness. Furthermore, there is a technology that determines the correlation between positive outcomes from patient outcome data and the location data of medical products, and generates medical proposals to modify medical resource usage practices based on this correlation. Additionally, there is a technology that, when a nursing plan is modified, links information such as the nursing plan, nursing performance, evaluation level, the creator of the nursing plan, and the assigned medical professional, stores individual nursing plan information with the number of changes in a database, and extracts individual nursing plan information based on specified conditions for medical professionals. Finally, there is a technology that calculates the probability of improvement in the level of care required for a care recipient using a care plan, modifies the care plan model, and outputs a care plan that is expected to improve the level of care required. Furthermore, for example, there are technologies that update guidance on care plans based on the risk of patient readmission and dissatisfaction, as well as cost evaluations, and optimize the achievement of care plan goals through model learning. Additionally, for example, there are technologies that select patient care plans and monitoring actions based on individual patient actions and lifestyles using patient nursing plans, and adjust the monitoring plan as the patient care plan changes over time. [Prior art documents] [Patent Documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2020-166835 [Patent Document 2] Special Publication No. 2021-509505 [Patent Document 3] Japanese Patent Publication No. 2008-165358 [Patent Document 4] International Publication No. 2018 / 030340 [Patent Document 5] U.S. Patent No. 10923233 [Patent Document 6] U.S. Patent Application Publication No. 2017 / 0300637 [Non-patent literature]

[0006] [Non-Patent Document 1] Makoto Ogawa, Hiroki Matsumoto, "Improvement of a Rehabilitation Menu Recommendation System with Extended Care Level Assessment Period," Journal of the Japan Telemedicine Society, 16(2), 152-155, 2020. [Non-Patent Document 2] "Enabling the proposal of optimal rehabilitation plans tailored to the individual characteristics of each care service user ~ Verification of the effectiveness of individualized optimization technology utilizing digital data in care rehabilitation ~", [Retrieved January 16, 2022], Internet<URL:https: / / www.nttdata-strategy.com / newsrelease / 210701.html> NTT Data Institute of Management Consulting, Inc., et al., July 1, 2021 [Overview of the project] [Problems that the invention aims to solve]

[0007] However, with conventional technology, if a plan changes occur due to, for example, a sudden cancellation or modification of a service, the recommended menu may not be implemented, and the effects initially expected at the time of recommendation may not be achieved. Conventional technology does not take into account the circumstances and situations of the planner, provider, and user, and therefore does not take into account the possibility of changes to the planned menu's implementation. If the recommended menu is not implemented, the effects expected at the time of planning will not be achieved. Conventional technology does not provide menu recommendations that take into account the actual service implementation situation.

[0008] In one aspect, the present invention aims to recommend a menu of services that are likely to be implemented. [Means for solving the problem]

[0009] According to one embodiment, information on a menu of a predetermined service and information on stakeholders related to the service are acquired, the frequency of change in the execution of the menu is calculated for the combination of the stakeholder and the menu, a menu to be recommended is specified based on the calculated frequency of change, and the specified menu is output to the stakeholder of the calculated combination. A planning method and a planning program for a computer to execute the process are proposed.

Effect of the Invention

[0010] According to one aspect, it becomes possible to recommend a menu of a service with high feasibility.

Brief Description of the Drawings

[0011] [Figure 1] FIG. 1 is an explanatory diagram showing an example of an embodiment of a planning method according to an embodiment. [Figure 2] FIG. 2 is a diagram showing a configuration example of a planning system. [Figure 3] FIG. 3 is a block diagram showing a hardware configuration example of a planning device. [Figure 4] FIG. 4 is a block diagram showing a functional configuration example of a planning device. [Figure 5A] FIG. 5A is a chart showing an example of data in a DB held by a client. (Part 1) [Figure 5B] FIG. 5B is a chart showing an example of data in a DB held by a client. (Part 2) [Figure 5C] FIG. 5C is a chart showing an example of data in a DB held by a client. (Part 3) [Figure 6A] FIG. 6A is a chart showing an example of data in a DB held by a planning device. (Part 1) [Figure 6B] FIG. 6B is a chart showing an example of data in a DB held by a planning device. (Part 2) [Figure 6C]Figure 6C is a diagram showing an example of data from the database held by the planning device. (Part 3) [Figure 6D] Figure 6D is a diagram showing an example of data from the database held by the planning device. (Part 4) [Figure 7] Figure 7 is an explanatory diagram illustrating the overview of the processes performed by the planning device. [Figure 8] Figure 8 is an explanatory diagram of the process for estimating the risk of response changes. [Figure 9] Figure 9 is an explanatory diagram of the process for extracting conditions that minimize the risk of response changes. [Figure 10] Figure 10 is an explanatory diagram of the process for calculating expected values, taking the workflow into consideration. [Figure 11] Figure 11 is a flowchart showing an example of the overall processing of the planning system. [Figure 12] Figure 12 is a flowchart showing an example of the process for calculating expected values ​​and response change risks, taking the workflow into consideration. [Figure 13] Figure 13 is a flowchart showing an example of the process for extracting the minimum risk conditions for response changes. [Figure 14] Figure 14 is a flowchart showing an example of the process for scheduling response change risk and expected value. [Figure 15A] Figure 15A is an explanatory diagram showing examples of service users and providers. [Figure 15B] Figure 15B shows examples of planned data and actual data. [Figure 16A] Figure 16A is an explanatory diagram illustrating an example of estimating the risk of response changes. (Part 1) [Figure 16B] Figure 16B is an explanatory diagram illustrating an example of estimating the risk of response changes. (Part 2) [Figure 17] Figure 17 shows an example of estimating expected values ​​for each stakeholder. [Figure 18A] Figure 18A is an explanatory diagram illustrating an example of a combination that minimizes the risk of response changes. [Figure 18B] Figure 18B is an explanatory diagram illustrating an example of a combination that cannot minimize the risk of response changes. [Figure 19] Figure 19 is an explanatory diagram illustrating the similarity of the estimated expected values. [Figure 20A] Figure 20A shows an example of how recommended menu items are displayed. (Part 1) [Figure 20B] Figure 20B shows an example of how recommended menu items are displayed. (Part 2) [Modes for carrying out the invention]

[0012] Embodiments of the planning method and planning program according to the present invention will be described in detail below with reference to the drawings.

[0013] (An embodiment of the planning method according to the embodiment) Figure 1 is an explanatory diagram showing one embodiment of the planning method according to the embodiment. The planning device 100 acquires information on a predetermined service menu and information on stakeholders related to the service. The planning device 100 calculates the frequency of menu execution changes for each combination of stakeholders and menus. Based on the calculated change frequency, the planning device 100 identifies menus to be recommended. Then, the planning device 100 outputs the identified menus to the stakeholders of the calculated combination. The planning device 100 is a computer for performing these processes.

[0014] The planning device 100 may be, for example, a server or a PC (Personal Computer), and may include a control unit that performs control of the planning device 100. The planning device 100 may also be a cloud server, and the functions of the control unit may be arbitrarily located on the cloud.

[0015] In the description of the embodiment, among the stakeholders, the planner plans a service, for example, a menu of rehabilitation plans. The provider outputs the menu of rehabilitation plans planned by the planner to the user. The user performs rehabilitation based on the menu of rehabilitation plans provided by the provider.

[0016] The "plan changes" described in the embodiments refer to changes in the implementation of the planned service menu, and occur at the discretion / intention of the stakeholders involved. Examples of plan changes include the following:

[0017] One user "misunderstood the time" and was unable to receive menu item i, or it took a long time for them to receive it. One user decided against taking menu item i because "it had failed before." One provider stated that "preparation took too long," and they were unable to offer menu item i, or it took a long time to offer it. One provider stopped offering menu item i because "the specialized equipment broke down." One planner changed the location where menu i is offered "for groups (jointly with other users)." In this case, users can no longer receive menu i at the original location. To receive menu i, users would need to move to the changed location, for example. One planner changed the service time for menu i "in accordance with changes in the regulations (coverage of insurance)." In this case, users will no longer be able to receive menu i at the original service time. To receive menu i, users will need to visit again, for example, at the changed service time.

[0018] Furthermore, a "planned menu" is defined as "a plan by a planner to provide a menu of services to a certain user (group) at a certain time (date and time), in a certain place (facility) by a certain provider."

[0019] As mentioned above, the problem is that the service menu is subject to change. For example, a change in the plan refers to a change in the service menu in terms of time and content. Such changes in the plan arise from changes in stakeholders' responses to the service menu. A change in response corresponds to, for example, a situation where, in reality, users do not (or are unable to) implement the service, despite the plan to implement it. If a change in response occurs among any one of the stakeholders—the planner, the provider, or the user—the menu will be subject to change in the plan.

[0020] Based on the above, the inventors focused on the fact that if a service menu could be recommended in a way that does not cause changes in response, changes to the plan could be suppressed and the service could be implemented with the original effect. For this reason, the planning device 100 according to the embodiment focuses on changes in the responses of multiple stakeholders to the service menu, and is designed to recommend a menu that minimizes the risk of changes in response and maximizes the effect.

[0021] In this embodiment, each stakeholder is recommended a menu that maximizes the effect on users who actually implement the menu. For example, users are recommended a combination of menus that minimizes changes in their response. Furthermore, providers are recommended schedules for each user, with the risk of changes in response as a constraint.

[0022] The planning device 100 according to the embodiment includes and implements the following processes 1 to 4 as a planning method.

[0023] 1. Extraction of response change points The planning device 100 extracts menus where a response change has occurred based on the difference between the service plan and past performance. For example, the planning device 100 sequentially stores the history of changes to past service menus in a storage unit. At predetermined timings, for example, at predetermined intervals, the planning device 100 extracts menus where a response change has occurred based on the history of menu changes.

[0024] 2. Calculation of response change risk The planning device 100 calculates the response change risk (frequency of change) for each stakeholder (planner, user, provider) for the extracted menus. For example, the planning device 100 extracts service menus that have been changed and service menus that have not been changed from past data and calculates the response change risk between each stakeholder. Then, the planning device 100 calculates the parameter range for each service menu for each party involved. For example, it classifies the data into groups such as service menus created by planner m, service menus provided by provider p, and service menus used by user u, and calculates the response change risk for each. Note that m is an abbreviation for menu planner, p is an abbreviation for provider, and u is an abbreviation for user.

[0025] 3. Extract the conditions that minimize the risk of response changes. The planning device 100 extracts a combination of service menus that minimizes the risk of response changes for a given menu. For example, if menu i has been frequently changed in a service menu planned by planner m, the planning device 100 determines that planner m's contribution to the risk of response changes for menu i is high. In this case, the planning device 100 does not recommend the service menu planned by planner m to user u who should receive menu i.

[0026] 4. Recommend the menu that maximizes the effect on users based on the extracted conditions. The planning device 100 recommends to users, via display output or other means, the menu that maximizes the effect on users who implement the menu, based on the conditions extracted in 3. above.

[0027] An example of menu recommendation by the planning device 100 will be explained using Figure 1. As shown in Figure 1(a), suppose there are multiple menus 1 to n for a service for a certain user u1. In this case, the planning device 100 determines which of menus 1 to n to recommend to user u1.

[0028] As shown in Figure 1(b), the planning device 100 extracts response change risks (change frequency) for multiple combinations of the implementation of a certain service menu 1 to n. For example, user u1 can implement menus 1 to n, which have been planned by multiple planners m1 to mn, and provided by multiple providers p1 to pn.

[0029] In the example in Figure 1(b), the planning device 100 calculates the response change risk (frequency of change) for each provider p1 and p2 for menus 1 and 2 planned by planner m1 for user u1. In the example in Figure 1(b), it is shown that provider p1 has the highest response change risk (frequency of change) for menu 1.

[0030] Similarly, the planning device 100 calculates the response change risk (frequency of change) for each provider p1 and p2 for menus 3 and 4 planned by planner m2 for user u1. In the example in Figure 1(b), it is shown that provider p2 has the lowest response change risk (frequency of change) for menu 3.

[0031] The planning device 100 then recommends a menu to the user based on a combination of stakeholders with a low risk of response change (frequency of change), as shown in Figure 1(b). In the example in Figure 1(c), the planning device 100 recommends menu 3, planned by planner m2 and provided by provider p2, to user u1. The recommendation of menu 3 to user u1 is based on the low risk of response change (frequency of change) for menu 3 in the combination of planner m2 and provider p2 shown in Figure 1(b). In this case, for example, menu 1 in the combination of planner m1 and provider p1 is not recommended to user u1 because the risk of response change (frequency of change) is high.

[0032] In the example shown in Figure 1(c), the planning device 100, for convenience, recommended to user u1 the single menu that combines stakeholders to minimize the risk of response change (frequency of change), but it is not limited to this. As will be described in detail later, the planning device 100 may recommend to user u1 multiple menus that minimize the risk of response change (frequency of change). The planning device 100 may also present the implementation schedule for each menu. Furthermore, the planning device 100 may recommend the risk of response change for each menu as a constraint to user u1, allowing user u1 to select a menu after understanding the risk of response change.

[0033] According to this embodiment, the planning device 100 recommends menus that can be implemented as planned to stakeholders, based on the risk of response changes (frequency of changes) that may occur before the planned service menus are actually implemented. The planning device 100 can also recommend the optimal menu by considering the expectations of each stakeholder regarding the menus. Furthermore, by using the risk of response changes as a constraint condition for menu assignment, the planning device 100 can perform scheduling that combines more accurately feasible menus.

[0034] (Example of a planning system configuration) Figure 2 shows an example of the configuration of a planning system. In the example shown in Figure 2, the planning device 100 recommends menus from the past plan / performance DB 213 to the user's rehabilitation plan. The planning device 100 includes a server 200 and a menu combination template database (DB) 201. The server 200 is connected to clients 211 of rehabilitation facilities A to N (210) used by the user via a network NW.

[0035] Rehabilitation facilities A-N (210) include a client 211, a hub (HUB) 212 that communicates with the network NW, a past plan / performance DB 213, a menu DB 214, and a stakeholder DB 215. Stakeholders, such as planners, providers, and users, each access client 211 and input information, and the information entered by each stakeholder is stored in the stakeholder DB 215. The past plan / performance DB 213 holds plan data for rehabilitation services that were planned, and performance data for the results of implementing the plan data. The menu DB 214 holds information about rehabilitation menus planned by planners.

[0036] Clients 211 of rehabilitation facilities A-N (210) transmit the information stored in the past plan / performance DB 213, menu DB 214, and stakeholder DB 215 to the server 200 of the planning device 100.

[0037] The server 200 of the planning device 100 performs the above-described processes 1 to 4 based on the information stored in the past plan / performance DB 213, menu DB 214, and stakeholder DB 215 of rehabilitation facilities A to N (210). By performing processes 1 to 4, the planning device 100 creates a menu combination template DB 201. The menu combination template DB 201 holds information on combinations of multiple rehabilitation menus. The menu combination template DB 201 may also include the order in which the menus are performed.

[0038] The planning device 100 recommends menus that can be performed according to the plan to the user, based on the contents stored in the menu combination template DB 201. Specifically, the planning device 100 transmits information about menus that the user can perform to clients 211 of rehabilitation facilities A to N (210). The user receives information about the menus they can perform based on the content displayed on client 211. Client 211 may also be configured to transfer information about the menus they can perform to a smartphone or other device carried by the user.

[0039] (Example of hardware configuration for planning device 100) Next, an example of the hardware configuration of the planning device 100 will be described using Figure 3.

[0040] Figure 3 shows an example of the hardware configuration of a planning device. In Figure 3, the planning device 100 includes a CPU (Central Processing Unit) 301, memory 302, network interface 303, recording medium interface 304, and recording medium 305. It also includes a portable recording medium interface 306 and a portable recording medium 307. Each component is connected by a bus 300. The network NW can be, for example, a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet.

[0041] Here, the CPU 301 is responsible for the overall control of the planning device 100. The memory 302 includes, for example, ROM (Read Only Memory), RAM (Random Access Memory), and flash ROM. Specifically, for example, flash ROM and ROM store various programs, and RAM is used as the work area for the CPU 301. Programs stored in memory 302 are loaded into the CPU 301, causing the CPU 301 to execute the coded processes.

[0042] The network interface 303 connects to the network NW via a communication line and connects to other computers via the network NW. The network interface 303 manages the internal interface with the network NW and controls the input and output of data from other computers. Examples of network interfaces 303 include modems and LAN adapters.

[0043] The recording medium interface (I / F) 304 controls the reading and writing of data to the recording medium (SSD) 305 according to the control of the CPU 301. The recording medium interface (I / F) 304 is, for example, a disk drive, an SSD (Solid State Drive), or a USB (Universal Serial Bus) port. The recording medium (SSD) 305 is a non-volatile memory that stores the data written under the control of the recording medium interface (I / F) 304. Examples of the recording medium (SSD) 305 include magnetic disks and optical disks.

[0044] The portable recording medium interface 306 controls the reading and writing of data to the portable recording medium 307 according to the control of the CPU 301. The portable recording medium 307 stores the data written under the control of the portable recording medium interface 306. Examples of portable recording media 307 include CD (Compact Disc)-ROM, DVD (Digital Versatile Disk), and USB (Universal Serial Bus) memory.

[0045] In addition to the components described above, the planning device 100 may also have, for example, a keyboard, mouse, display, printer, scanner, microphone, speaker, etc. Furthermore, the planning device 100 may have multiple recording media interfaces 304 and recording media 305. Alternatively, the planning device 100 may not have recording media interfaces 304 and recording media 305.

[0046] The hardware configuration example of client 211 shown in Figure 2 is the same as the hardware configuration example of planning device 100 shown in Figure 3, so its explanation is omitted.

[0047] (Examples of planning device functions) Figure 4 is a block diagram illustrating an example of the functional configuration of the planning device. Figure 4 shows the functions of the server 200 shown in Figure 2, as well as multiple databases (DBs). The server 200 includes the functions of a historical data acquisition unit 401, a response change point extraction unit 402, a response change risk estimation unit 403, a minimum risk condition extraction unit 404, and a menu recommendation unit 405. The DBs include the above-mentioned menu combination template DB 201, response change point DB 412, response change risk DB 413, and conditional menu DB 414.

[0048] The historical data acquisition unit 401 to the menu recommendation unit 405, which correspond to the control unit of the server 200 shown in Figure 4, can be implemented by the CPU 301 shown in Figure 3 executing a program stored in memory 302, etc. Furthermore, each DB 412 to 414 of the server 200 shown in Figure 4 can be implemented using memory 302, recording medium 305, etc., as shown in Figure 3. Additionally, each DB 213 to 215 on the rehabilitation facility 210 (client 211) side shown in Figure 4 can be implemented using memory 302, recording medium 305, etc., as shown in Figure 3.

[0049] The historical data acquisition unit 401 accesses clients 211 of each rehabilitation facility A to N (210) to acquire information stored in the past plan / performance DB 213, menu DB 214, and stakeholder DB 215.

[0050] The response change point extraction unit 402 performs the above process 1. Extraction of response change points based on the information acquired by the past data acquisition unit 401. The response change point extraction unit 402 extracts information related to response changes for each menu and stores the extracted information related to response changes in the response change point DB 412.

[0051] The response change risk estimation unit 403 performs the above process 2. Estimation of response change risk based on the response change point information extracted by the response change point extraction unit 402. The response change risk estimation unit 403 refers to the response change point DB 412, estimates the response change risk for each menu, and stores the information related to the estimated response change risk in the response change risk DB 413.

[0052] The Risk Minimization Condition Extraction Unit 404 extracts the conditions for minimizing the response change risk based on the response change risk information estimated by the Response Change Risk Estimation Unit 403. The Risk Minimization Condition Extraction Unit 404 refers to the Response Change Risk DB 413 and extracts the conditions for minimizing the response change risk for each menu, for example, information on combinations of stakeholders. The Risk Minimization Condition Extraction Unit 404 then stores the menus with the extracted conditions for minimizing the response change risk in the Conditional Menu DB 414.

[0053] The menu recommendation unit 405 performs the recommendation of menus that maximize the effect on users based on the conditions extracted in the above process 4. The menu recommendation unit 405 refers to the menu combination template DB 201 and determines the menus to recommend, including information on the order in which multiple menus are combined. The menu recommendation unit 405 also refers to the conditional menu DB 414 and recommends information on conditions that minimize the risk of response changes (such as combinations of stakeholders for each menu) to stakeholders (users and providers).

[0054] (Example data from each database) Figures 5A to 5C are diagrams showing examples of data in the databases held by the clients. We will now explain the data examples in databases 213 to 215 for each rehabilitation facility A to N shown in Figure 2.

[0055] Figure 5A shows the past plan / actual DB 213. The past plan / actual DB 213 includes plan data 213A created by the planner and actual data 213B corresponding to the plan data 213A.

[0056] The plan data 213A is stored as record 213A-a, where information is set in each field based on the information planned by the planner. a is an arbitrary integer. For example, each field stores information such as the record's unique identifier (ID), date and time, facility ID, menu ID, and user ID. For example, record 213A-1 has ID "001", date and time "2021 / 11 / 10 10:00", facility ID "fid001", menu ID "sid001", user ID "uid001", and provider ID "pid001".

[0057] The actual data 213B is stored as record 213B-a, with information set in each field, representing the actual results against the plan data 213A planned by the planner. For example, each field stores information such as the record's identification ID, date and time, facility ID, menu ID, and user ID, similar to the plan data 213A. Here, record 213B-1 indicates that menu ID "sid001" with ID "001" from record 213A-1 of plan data 213A was not performed, and in this case, "Cancel" is set for the date and time.

[0058] Figure 5B shows the menu database 214. The menu database 214 stores information related to the rehabilitation menus devised by the planner, with information set in each field as record 214-a. For example, each field stores information such as menu ID, menu name, required time, standard value, and unit. For example, record 214-1 stores information such as menu ID "sid001", menu name "Walking Training", required time "30 minutes", standard value "10", and unit "step".

[0059] Figure 5C shows the Stakeholder Database 215. For each stakeholder, the Stakeholder Database 215 includes user data 215A, provider data 215B, and planner data 215C.

[0060] User data 215A is stored as record 215A-a, with information set in each field based on the user's information. For example, each field stores information such as user ID, name, age, address, medical history, and care level. For example, record 215A-1 stores information such as user ID "uid001", name "Tokyo Taro", age "75", address "Tokyo XXX", medical history "stroke", and care level "Care Level 1".

[0061] The provider data 215B is stored as record 215B-a, where information is set in each field based on the provider's information. For example, each field stores information such as provider ID, name, and qualifications. For example, record 215B-1 stores information such as provider ID "pid001", name "Tokyo Jiro", and qualifications "trainer".

[0062] The planner data 215C is stored as record 215C-a, with information set in each field based on the planner's information. For example, each field stores information such as planner ID, name, and menu ID. For example, record 215C-1 stores information such as planner ID "mid001", name "Osaka Jiro", and menu ID "sid001".

[0063] Figures 6A to 6D are diagrams showing examples of data in the database held by the planning device. Figure 6A shows the menu combination template DB 201. The menu combination template DB 201 is stored as record 201-a, which has information set in each field based on the workflow information of the rehabilitation menu combination. For example, each field stores information such as workflow ID, workflow name, menu ID, order, and notation. For example, record 201-a stores information such as workflow ID "wid001", workflow name "Dementia Training", menu ID "sid001", order "1", and notation "Event".

[0064] Figure 6B shows the response change point DB 412. The response change point DB 412 is stored as records 412-a, with information set in each field based on the information related to the response change for each menu. For example, each field stores information such as ID, menu ID, change type related to the response change point detected by the response change point extraction unit 402, change amount, and stakeholder ID. For example, record 412-1 stores information such as ID "001", menu ID "sid001", change type "date and time", change amount "24", and stakeholder ID "uid001".

[0065] Figure 6C shows the Response Change Risk DB413. The Response Change Risk DB413 is stored as record 413-a, with information set in each field based on the estimated response change risk information. For example, each field stores information such as ID, menu ID, ID of each stakeholder, and response change risk. For example, record 413-1 stores information such as ID "1", menu ID "sid001", user ID "uid001", provider ID "pid001", planner ID "mid001", and response change risk value "0.2".

[0066] Figure 6D shows the conditional menu DB414. The conditional menu DB414 stores information about menus with conditions that minimize the extracted response change risk, and sets information in each field as record 414-a. For example, each field stores information such as ID, workflow ID, menu ID, IDs of each stakeholder that meets the condition, and condition type. For example, record 414-1 stores information such as ID "1", workflow ID "wid001", menu ID "sid001", user ID "uid001", provider ID "pid001", planner ID "mid001", and condition type "minimize risk".

[0067] Figure 7 is an explanatory diagram illustrating the overview of the processing performed by the planning device. Figure 7(a) shows the above processing 1. Extraction of response change points performed by the response change point extraction unit 402. For example, the response change point extraction unit 402 acquires the past plan / actual DB 213 created by planner m1 and extracts response change points by comparing the plan data 213A and the actual data 213B record by record. In the example of Figure 7(a), the response change point extraction unit 402 extracts as a response change point that the menu (i) for a predetermined date and time that was planned in record 213A-1 of the plan data 213A was canceled in record 213B-1 of the actual data 213B.

[0068] Figure 7(b) shows the above process 2. Estimation of response change risk performed by the response change risk estimation unit 403. In Figure 7(b), the horizontal axis represents stakeholders, the vertical axis represents response change risk (change frequency), and the depth axis represents menus. The response change risk estimation unit 403 obtains the response change risk (change frequency) for each stakeholder for a given menu by extracting the response change points shown in Figure 7(a).

[0069] Figure 7(c) shows the extraction of conditions that minimize the response change risk performed by the risk minimum condition extraction unit 404. The risk minimum condition extraction unit 404 extracts combinations of service menus that minimize the response change risk for a given menu. In Figure 7(c), the thicker the line between each stakeholder, the higher the response change risk. For example, when providing menu i to user u1, the risk minimum condition extraction unit 404 determines that the combination of planner m1 and provider p1 has a high response change risk (frequency of change) for menu i. The risk minimum condition extraction unit 404 extracts combinations of stakeholders with thin lines between them.

[0070] Figure 7(d) shows the menu recommendation performed by the menu recommendation unit 405 in the above process 4. Extracted conditions, which maximizes the effect on the user. Based on the combinations of stakeholders with thin lines between them, extracted by the risk minimum condition extraction unit 404 in Figure 7(c), the menu recommendation unit 405 recommends to the user one or more menus that maximize the effect on the user from among multiple menus. The menu recommendation unit 405 may also present the implementation schedule for each menu.

[0071] Furthermore, the menu recommendation unit 405 may recommend menus to user u1 using the response change risk for each menu as a constraint. For example, the menu recommendation unit 405 may present user u1 with information from the conditional menu DB 414 shown in Figure 6D, and recommend menus in a way that allows user u1 to select a menu while understanding the response change risk for each menu.

[0072] In the above description, the response change risk estimated by the response change risk estimation unit 403 can be expressed, for example, by the following formula (1), and can be processed by the planning device 100.

[0073] Pi(C=1|u,p,m)={Pi(u|C,p,m)×Pi(C|p,m)} / Pi(u|p,m) …(1)

[0074] Equation (1) above shows the probability that a menu i planned by a planner m and intended to be provided by a provider p to a user u will be changed (C=1). Pi(u|C,p,m) can be estimated from the statistics for each user u when, under the planner m's plan, provider p provides menu i and the result is C. Pi(C|p,m) can be estimated from the statistics of change / non-change when, under the planner m's plan, provider p provides menu i. Pi(u|p,m) can be estimated from the statistics for each user u when, under the planner m's plan, provider p provides menu i.

[0075] Then, when the menu recommendation unit 405 recommends a menu that minimizes the risk of response change, it selects the provider p and planner m that maximize Pi(C=0,u|p,m). The menu recommendation unit 405 recommends to user u the "menu i planned by planner m and provided by provider p" which has the lowest risk of response change.

[0076] As described above, the planning device 100 of the embodiment expands the search space by adding attribute values ​​of response change risks from multiple stakeholders to the target menu before outputting the menu to the user u. For example, in the conventional technology, this corresponds to plotting menus on a two-axis search space of effect and frequency (number of uses), and does not consider how (when, who, where) the menu is provided. In contrast, the planning device 100 of the embodiment increases the number of axes in the space by using a three-axis search space consisting of response change risk, effect, and frequency. As a result, the planning device 100 of the embodiment can consider how the menu should be provided as a response change risk.

[0077] (Details of processing performed by each function of the planning device 100) Next, we will explain in detail examples of processing performed by each function of the planning device 100.

[0078] Figure 8 is an explanatory diagram of the process for estimating response change risk. An example of the process 2. Estimation of response change risk performed by the planning device 100 will be explained below. The planning device 100 estimates the response change risk based on the tendency for response changes (frequency of change) to occur when each stakeholder has different expectations for service implementation. Expectations for service implementation refer to various information (parameters such as time, location, effect, difficulty, etc.) regarding service implementation held by each stakeholder. The response change risk increases when the range of expectations differs from that of other stakeholders.

[0079] Let's explain an example where the risk of response changes increases. Example 1: Provider p considered menu (i) to be a moderately challenging workout (medium difficulty). However, user u found it difficult (high difficulty) after actually trying it and frequently canceled menu (i) or switched to a similar menu (ii). Example 2: Planner m believed that menu item (ii) should be implemented in the morning (early time). However, provider p's work schedule limited implementation to the afternoon (late time). Example 3: User u wanted to receive menu (i) on time. However, provider p, who was in charge of user u, took a long time to prepare menu (i), so the start of menu (i) was frequently delayed.

[0080] The planning device 100 refers to the past plan / performance DB 213, calculates the expected value of each parameter for service implementation for each stakeholder at the extracted response change points, and estimates the response change risk from the overlap of the ranges (distributions).

[0081] Each parameter is, for example, time (the time of service implementation, etc.), location (the location and distance of service implementation, etc.), effectiveness (service implementation time, measured value, etc.), and difficulty (the difference between standard value and measured value, the provider's skill set, the user's profile, etc.).

[0082] Figure 8(a) is a chart showing the expected values ​​of each stakeholder for each menu item, where the parameter is time. The expected values ​​(vertical axis) for menu items (i) and (ii) are shown for planner m, provider p, and user u. The horizontal axis is time (e.g., time of day). Planner m, provider p, and user u each have distribution characteristics based on a predetermined time range and the height of their expected values. In the example in Figure 8(a), the planning device 100 estimates that there is a high risk of user u changing their response for menu item (i).

[0083] Figure 8(b) is a chart showing the expected values ​​of each stakeholder for each menu item, where the parameter is the effect. The expected values ​​(vertical axis) for menu items (i) and (ii) are shown for planner m, provider p, and user u. The horizontal axis is time (e.g., service implementation time). Planner m, provider p, and user u each have distribution characteristics based on a predetermined time range and expected value level. In the example in Figure 8(b), the planning device 100 estimates that the risk of change in response from each stakeholder is low for menu items (i) and (ii).

[0084] Figure 8(c) is a chart showing the expected values ​​of each stakeholder for each menu item when the parameter is difficulty. The expected values ​​(vertical axis) for menu items (i) and (ii) are shown for planner m, provider p, and user u. The horizontal axis is time (e.g., service implementation time). Planner m, provider p, and user u each have distribution characteristics based on a predetermined time range and the height of their expected values. In the example in Figure 8(c), the planning device 100 estimates that there is a high risk of response change if user u uses menu items (i) and (ii) provided by provider p.

[0085] Figure 9 is an explanatory diagram of the process for extracting conditions that minimize the risk of response changes. An example of the above process 3. Extracting conditions that minimize the risk of response changes performed by the planning device 100 will be explained. In this embodiment, it is noted that if the combination of stakeholders (planner, provider, user) has the same range of expectations regarding service implementation, response changes are less likely to occur. The planning device 100 groups stakeholders based on the estimated risk of response changes, that is, the similarity of the distribution of expectations regarding service implementation, and recommends menus for each target group.

[0086] Figure 9 is a chart showing the expectations of each stakeholder for each menu item. The vertical axis shows the expectations of planner m, provider p, and user u for menu items (i) and (ii). The horizontal axis represents time. In the example in Figure 9, the planning device 100 determines that the distribution of expectations of planner m1, provider p1, and user u2 are similar for menu item i (solid line in Figure 9). The planning device 100 also determines that the distribution of expectations of planner m2, provider p1, and user u1 are similar for menu item ii (dotted line in Figure 9).

[0087] Furthermore, the planning device 100 utilizes response change risk and expected value in scheduling. Specifically, it focuses on the fact that if the response change risk of provider p to a menu is low, changes during menu implementation can be suppressed. For example, when scheduling provider p's work, the planning device 100 sets the menu to be assigned and provider p's response change risk as constraints, and assigns the menu with the minimum response change risk. The response change risk of the menu and provider p (example of constraints) is shown by the following equation (2).

[0088]

number

[0089] Equation (2) above represents the probability that provider p will provide menu i without changing it (C=0). The planning device 100 assigns menu i to provider p in a way that increases this probability.

[0090] Furthermore, we focus on the fact that user u's expectations for menu i can be used to determine user u's preference for menu i. When scheduling the provision of menu i to user u, the planning device 100 sets constraints such as the range of expected values ​​(upper limit, lower limit, middle limit, etc.) for the time (date and time) and location of the assigned menu. For example, if a schedule for a certain user u is close to the median of their expected value for time, it is determined that a change in that user's response is unlikely. On the other hand, if there are other users u with the same expected value, the assignment can be adjusted to a schedule close to the upper or lower limit.

[0091] Figure 10 is an explanatory diagram of the process for calculating expected values ​​considering the workflow. When recommending menus, the planning device 100 calculates expected values ​​considering the workflow (combination of menus). Depending on the menu, various information regarding service implementation (time, location, effect, difficulty) may be determined by the menus performed before and after it. For example, the previous menu is one in which the number of times is measured, so the end time is ambiguous, while the following menu is a group implementation menu, so the location and start time are precise. The planning device 100 takes such cases into consideration, extracts menu combinations from the plan, and calculates the expected value for each menu for each menu combination.

[0092] Specifically, when estimating the risk of response changes, the planning device 100 extracts menu combination templates from the planning data in advance and calculates the expected value for each menu for each template. The planning device 100 then uses this for grouping when extracting conditions that minimize the risk of response changes. The grouping consists of combinations of menus, users, providers, and planners.

[0093] Figure 10(a) shows the expected values ​​in a menu combination (workflow). In Figure 10(a), the horizontal axis is time, the vertical axis is expected value (e.g., difficulty), and the axis in the direction towards the viewer is the effect. Also, the diamond (◇) represents menu i, the circle (〇) represents menu ii, and the square frame indicates the range of expected values. Multiple menus in a workflow can be combined between the start point (●) and the end point (●), as shown by the arrows. When combining menus, the planning device 100 combines menus i and ii based on the expected value ranges of each menu. For example, in a certain combination, menu i(S1) has a narrow range of expected values ​​and therefore needs to be executed strictly in terms of time, while menu i(S2) has a wide range of expected values ​​and can be executed more loosely in terms of time.

[0094] Figure 10(b) is a chart showing the expected values ​​for each menu in each menu combination 1 to 3 (workflow) when the parameter is time. The expected values ​​(vertical axis) for menu (i) and (ii) are shown for planner m, provider p, and user u. The horizontal axis is time (e.g., time of day). In the example of combination 1, since the expected values ​​for both menu i and ii with respect to time are close to the median, the planning device 100 combines these menus i and ii as a schedule. In the example of combination 2, the expected value of menu i is shifted to the earlier side from the median, and the expected value of menu ii is shifted to the later side from the median, so the planning device 100 combines these menus i and ii as a schedule. In the example of combination 3, the expected value of menu i is shifted to the later side from the median, and the expected value of menu ii is shifted to the earlier side from the median, so the planning device 100 combines these menus i and ii as a schedule.

[0095] (Example of processing by a planning device) Figure 11 is a flowchart showing an example of the overall processing of the planning device. An example of processing performed by the control unit (CPU 301) of the planning device 100 will be described below. The planning device 100 performs the following processing at predetermined intervals, etc. First, the planning device 100 acquires menu and stakeholder information (step S1111). Next, the planning device 100 acquires past data (planning data and actual data) (step S1112).

[0096] Next, the planning device 100 performs the process of extracting response change points (step S1113). Next, the planning device 100 starts loop processing for the number of menus (i) (steps S1114 to S1121). Next, the planning device 100 starts loop processing for the number of stakeholders (j) (steps S1115 to S1120). Next, the planning device 100 starts loop processing for the number of response change points (k) including menu i and stakeholder j (steps S1116 to S1118).

[0097] Next, the planning device 100 counts the response changes as the frequency of menu changes (step S1117). Next, the planning device 100 determines whether the processing for response change points k has been completed (step S1118). If the processing for response change points k has not been completed, the planning device 100 returns to step S1116, and if the processing for response change points k has been completed, it proceeds to the processing in step S1119.

[0098] Next, the planning device 100 performs the process of estimating the response change risk (step S1119). Next, the planning device 100 determines whether the processing for the number of stakeholders j has been completed (step S1120). If the processing for the number of stakeholders j has not been completed, the planning device 100 returns to step S1115, and if the processing for the number of stakeholders j has been completed, it proceeds to the processing in step S1121.

[0099] Next, the planning device 100 determines whether the processing for menu item i has been completed (step S1121). If the processing for menu item i has not been completed, the planning device 100 returns to step S1114; if the processing for menu item i has been completed, it proceeds to step S1122.

[0100] Next, the planning device 100 starts loop processing for menu number (i) (steps S1122 to S1124). Next, the planning device 100 processes the extraction of the minimum response change risk conditions (step S1123). Next, the planning device 100 determines whether the processing for menu number i has been completed (step S1124). If the processing for menu number i has not been completed, the planning device 100 returns to step S1122, and if the processing for menu number i has been completed, it proceeds to the processing in step S1125.

[0101] Next, the planning device 100 starts a loop processing for the number of stakeholders (j) (steps S1125 to S1127). Next, the planning device 100 recommends a menu that maximizes the effect on the user (step S1126). Next, the planning device 100 determines whether the processing for the number of stakeholders j has been completed (step S1127). If the processing for the number of stakeholders j has not been completed, the planning device 100 returns to step S1125, and if the processing for the number of stakeholders j has been completed, it terminates the above processing.

[0102] Figure 12 is a flowchart showing an example of the process for calculating expected values ​​and response change risks while considering the workflow. The process in Figure 12 shows the process shown in Figure 11 with the addition of the process for calculating expected values ​​and response change risks while considering the workflow. Figure 12 corresponds to the processing portion of steps S1114 to S1121 in Figure 11.

[0103] First, the planning device 100 extracts a menu combination template (workflow) after processing response change points (step S1113) (step S1201). Next, the planning device 100 starts a loop processing for the number of workflows (w) (steps S1202 to S1213). Next, the planning device 100 starts a loop processing for the number of menus (i) included in workflow w (steps S1203 to S1212). Next, the planning device 100 starts a loop processing for the number of stakeholders (j) (steps S1204 to S1211). Next, the planning device 100 starts a loop processing for the number of response change points (k) including menu i and stakeholder j (steps S1205 to S1209). Next, the planning device 100 starts a loop processing for the number of parameters (l) (steps S1206 to S1208).

[0104] Next, the planning device 100 calculates the expected value (see Figure 10, step S1207). Next, the planning device 100 determines whether the processing for the number of parameters l has been completed (step S1208). If the processing for the number of parameters l has not been completed, the planning device 100 returns to step S1206; if the processing for the number of parameters l has been completed, it proceeds to step S1209.

[0105] Next, the planning device 100 determines whether the processing for response change points k has been completed (step S1209). If the processing for response change points k has not been completed, the planning device 100 returns to step S1205. If the processing for response change points k has been completed, it proceeds to step S1210. In step S1210, the planning device 100 performs the processing of estimating the response change risk (step S1210).

[0106] Next, the planning device 100 determines whether the processing for the number of stakeholders j has been completed (step S1211). If the processing for the number of stakeholders j has not been completed, the planning device 100 returns to step S1204, and if the processing for the number of stakeholders j has been completed, it proceeds to the processing in step S1212.

[0107] Next, the planning device 100 determines whether the processing for menu item i has been completed (step S1212). If the processing for menu item i has not been completed, the planning device 100 returns to step S1203; if the processing for menu item i has been completed, it proceeds to step S1213.

[0108] Next, the planning device 100 determines whether the processing for workflow number w has been completed (step S1213). If the processing for workflow number w has not been completed, the planning device 100 returns to step S1202. If the processing for workflow number w has been completed, it terminates the above process and proceeds to the process in step S1122 (see Figure 11).

[0109] Figure 13 is a flowchart showing an example of the process for extracting the minimum risk conditions for response changes. Figure 13 shows a detailed example of the process in step S1123 of Figure 11. First, the planning device 100 starts a loop process for the number of menu items (i) (steps S1301 to S1305).

[0110] Next, the planning device 100 calculates the similarity of the estimated expected value distributions (step S1302). Next, the planning device 100 classifies stakeholders based on the similarity (step S1303). Next, the planning device 100 extracts the minimum conditions for response change risk based on the classification (step S1304). Next, the planning device 100 determines whether the processing for menu number i has been completed (step S1305). If the processing for menu number i has not been completed, the planning device 100 returns to step S1301. If the processing for menu number i has been completed, it terminates the above processing and proceeds to the processing in step S1124.

[0111] Figure 14 is a flowchart showing an example of the process for scheduling response change risk and expected value. The process shown in Figure 14 is an example of how it can be used for scheduling response change risk and expected value, and can be executed after the process in step S1127 of Figure 11.

[0112] After processing step S1127 in Figure 11, the planning device 100 starts loop processing for the number of menu items (i) (steps S1401 to S1408). Next, the planning device 100 starts loop processing for the number of stakeholders (j) (steps S1402 to S1407).

[0113] Next, the planning device 100 extracts the minimum value of the response change risk as a constraint condition for the stakeholder j and the parameter t in menu i (step S1403). Next, the planning device 100 starts loop processing of the number of parameters (t) (steps S1404 to S1406).

[0114] Next, the planning device 100 extracts the range of expected values ​​as constraints for the stakeholder j and the parameter t in menu i (step S1405). Then, if the processing for the number of parameters t has not been completed, the planning device 100 returns to step S1404, and if the processing for the number of parameters t has been completed, it proceeds to the processing in step S1407.

[0115] Next, the planning device 100 determines whether the processing related to the number of stakeholders j has been completed (step S1407). If the processing for the number of stakeholders j has not been completed, the planning device 100 returns to step S1402. If the processing for the number of stakeholders j has been completed, it proceeds to step S1408. Next, the planning device 100 determines whether the processing related to the number of menus i has been completed (step S1408). If the processing for the number of menus i has not been completed, the planning device 100 returns to step S1401. If the processing for the number of menus i has been completed, it terminates the above processing (progresses to END in Figure 11).

[0116] (Specific examples of processing by a planning device) Next, a specific example of processing by the planning device 100 will be explained. Figure 15A is an explanatory diagram showing examples of service users and providers.

[0117] Figure 15A(a) shows an example of a service. For example, the planning device 100 provides a service to one user u with one provider p. In this case, the stakeholders are the user u and the provider p.

[0118] Figure 15A(b) shows the user response models. The planning device 100 uses different response models for each user u and provider p. The planning device 100 randomly determines combinations of user u and provider p, and determines the service to be provided based on the responses of user u and provider p for each determined combination. Multiple users u (ID=0~2) and providers p (ID=03~5) each have values ​​for time violation sensitivity α and β (indicated as greater or lesser in Figure 15A(b)). Details of α and β will be described later.

[0119] Figure 15B shows an example of planned data and actual data. In Figure 15B, the horizontal axis represents time (date), and the vertical axis represents each user u (ID=0~2) and provider p (ID=3~5) as shown in Figure 15A. In Figure 15B, ○ represents the plan data of provider p, △ represents the plan data of user u, and □ represents the actual data. The planning device 100 presents user u with dates on which provider p's plan data ○ and user u's plan data △ coincide. In response, user u indicates with □ the date on which they actually used the service from the presented dates.

[0120] For example, on the date (20), the plan data ○ of provider p (ID=5) and the plan data △ of user u (ID=0) match, so the planning device 100 presents user u with information on service usage on this date. The actual data □ showing that user u actually used the service on this date is then displayed.

[0121] In contrast, on date (21), since the planned data 〇 of provider p (ID = 4) and the planned data △ of user u (ID = 0) match, the planning device 100 presented the information on service usage on this date to user u. However, it is shown that user u did not actually use the service (there is no actual data □).

[0122] FIGS. 16A and 16B are explanatory diagrams of an example of estimating response change risk. The planning device 100 estimates the response change risk using the sensitivity regarding time violation as an expected value (parameter). As shown in FIG. 16A, the response change risk of stakeholder i with respect to target s at time t is y , , , i , t-1 ,

[0124] , i , t-1 as shown in Equation (3) of. The cumulative violation is v t,s,i as shown in Equation (4) of. α i and β<​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​Here, as shown in Figure 16B(b), when the horizontal axis is v and the vertical axis is y, the characteristic curve is a function of response change y = f(v). On the characteristic curve, when both y and v are large, it corresponds to 1. User i is thinking of stopping using the service. When both y and v are in the central range, it corresponds to 2. User i is thinking of stopping using the service, for example, because they were kept waiting (a large time violation) last time. When both y and v are small, it corresponds to 3. User i is thinking of using the service as usual.

[0125] In Figure 16B(b), the larger the cumulative violation v, the higher the risk of response change y. When the intercept β is exceeded, the number of users who stop using the service increases. The slope α and intercept β, which represent the sensitivity to time violations, differ for each stakeholder. The sensitivity to violations (slope α, intercept β) has a predetermined distribution characteristic with a width of σ relative to the median μ, when the horizontal axis is time violations relative to time and the vertical axis is the ratio.

[0126] Figure 17 shows examples of expected value estimations for each stakeholder. It shows examples of estimated expected values ​​(parameters) α and β for users u (ID=0~2) and providers p (ID=3~5). The distribution characteristics of the expected values ​​(parameters) α and β differ for users u (ID=0~2) and providers p (ID=3~5).

[0127] Figure 18A is an explanatory diagram of combination examples that minimize the risk of response change. Figure 18A(a) shows a state in which people (stakeholders) with the same response change risk parameters are combined. In the embodiment, the planning device 100 combines user u (ID=0) with provider p (ID=3) whose α: large and β: small. The planning device 100 also combines user u (ID=1) with provider p (ID=4) whose α: medium and β: medium. The planning device 100 also combines user u (ID=2) with provider p (ID=5) whose α: small and β: large.

[0128] Figure 18A(b) shows the planned and actual data for the combination shown in Figure 18A(a). In this combination, the percentage of plan changes is 0% for user u (ID=1) and 4% for user u (ID=0), demonstrating that the discrepancy (response change) between the planned and actual data can be suppressed.

[0129] Figure 18B is an explanatory diagram illustrating examples of combinations where the risk of response change cannot be minimized. Figure 18B is an explanatory diagram for comparison with Figure 18A. For example, as shown in Figure 18B(a), suppose we combine people with different parameters for the risk of response change. For example, suppose we combine user u (ID=0) with α: high, β: low and provider p (ID=5) with α: low, β: high. Also, suppose we combine user u (ID=1) with α: medium, β: medium and provider p (ID=3) with α: high, β: low. Also, suppose we combine user u (ID=2) with α: low, β: high and provider p (ID=4) with α: medium, β: medium.

[0130] Figure 18B(b) shows the planned and actual data for the combination shown in Figure 18B(a). In this combination, the percentage of plan changes was 20% for user u (ID=1) and 20% for user u (ID=0). Thus, when people with different response change risk parameters are combined, a discrepancy (response change) occurs between the planned data and the actual data, making it impossible to minimize the response change risk.

[0131] Figure 19 is an explanatory diagram of the similarity of the estimated expected values. Figure 19(a) shows α and β for each user u and provider p. Figure 19(b) plots each user u (ID=0~2) on the vertical axis and each provider p (ID=3~5) on the horizontal axis, showing the similarity (discrepancy in distribution) of the parameter distributions between them. Similarity can be calculated, for example, based on KL divergence or JS divergence.

[0132] As shown in Figure 19(b), for example, the planning device 100 determines that provider p (ID=3) has a value of "0.04" and provider p (ID=5) has a value of "0.01" for user u (ID=1), and that these are similar. The planning device 100 also determines that provider p (ID=4) has a value of "0.16" for user u (ID=0), and that these are similar.

[0133] Figures 20A and 20B show examples of how recommended menus are displayed. The planning device 100 generates screen data and outputs the screen data to the user or provider's client 211.

[0134] Figure 20A shows the display screen 2001 of the menu recommended to the user. For example, the planning device 100 displays and outputs the combination of menus that minimizes the risk of response changes. The planning device 100 displays various information about the user (name "Tokyo Taro", age, medical history, etc.) in the user field 2011 on the left side of the display screen 2001. The planning device 100 displays information about the menus planned for dementia training for user "Tokyo Taro" in the menu fields 2012 in the center and on the right side of the display screen 2001. The planning device 100 displays the name of the planner, graphs 2013 showing the goals and results for each menu (walking training, nutritional guidance, cognitive training, etc.), and a schedule table 2014 showing the instructors and schedules for each menu by day of the week in the menu field 2012.

[0135] Figure 20B shows the display screen 2002 of the menu recommended to the provider. For example, the planning device 100 displays menu combinations to the provider, with response change risk as a constraint. On the display screen 2002, the planning device 100 displays each user on the vertical axis and the schedule table 2021 of each user's menu on the horizontal axis (January 2022). The planning device 100 displays the menus in the user and date cells of the schedule table 2021, and also displays the response change risk value (see Figure 6C). Furthermore, the planning device 100 indicates that the risk of executing the menu in the corresponding cell (user and date) is high, for example, by displaying the corresponding cell in a darker color the higher the response change risk value. The provider can schedule by considering the risk for each menu recommended by the planning device 100 displayed in the schedule table 2021.

[0136] In the above-described embodiment, the planning device 100 was explained using an example in which it recommends a rehabilitation menu for a user as a service. However, the planning device 100 can be similarly applied to various training and exercise menus for various skills, menus for medical examinations and treatments at hospitals, menus for various services provided by the government, and so on.

[0137] As explained above, the planning device 100 acquires information on a predetermined service menu and information on stakeholders related to the service, calculates the frequency of menu changes for each stakeholder-menu combination, identifies recommended menus based on the calculated change frequency, and outputs the identified menus to the stakeholders of the calculated combination. This enables the planning device 100 to recommend menus that are highly likely to be implemented to stakeholders.

[0138] Furthermore, according to the planning device 100, the acquisition process acquires planning data for the execution of service menus and actual data for the menus in the planning data that were actually executed. The calculation process extracts change points for menu execution based on the difference between the acquired planning data and the actual data, calculates the change frequency for each stakeholder for menus with change points, and identifies combinations of stakeholders with a low change frequency for menus. As a result, the planning device 100 can recommend menus that are more likely to be implemented to stakeholders based on past planning data and actual data.

[0139] Furthermore, according to the planning device 100, the process for calculating the frequency of changes is based on the overlap of the distribution of parameters, including time, location, effect, and difficulty, which indicate the expected value of each stakeholder regarding the implementation of the menu. In this way, considering the tendency for the frequency of changes to occur when each stakeholder has different expectations for service implementation, the planning device 100 becomes able to recommend the optimal menu among multiple stakeholders.

[0140] Furthermore, according to the planning device 100, a specific process combines stakeholders whose expected value distributions are similar. This allows the planning device 100 to recommend the optimal menu for each of the combined stakeholders.

[0141] Furthermore, according to the planning device 100, a specific process determines a workflow that combines multiple menus based on the distribution of expected values ​​for each of the multiple menus. As a result, the planning device 100 can recommend a service flow that combines multiple menus that make up a service, all of which are highly likely to be implemented.

[0142] Furthermore, stakeholders include planners who develop service menus, service providers, and users who utilize the services. According to the planning device 100, a specific process may include combining providers and users whose expected value distributions are similar. This enables the planning device 100 to recommend menus that are highly likely to be implemented for both providers and users.

[0143] Furthermore, according to the planning device 100, if the frequency of changes by the provider for a menu is low, a specific process is performed to assign the menu with a low frequency of changes, using the frequency of changes by the provider for that menu as a constraint. As a result, the planning device 100 can be used for scheduling by combining service menus, improving the feasibility of scheduling by the provider.

[0144] Furthermore, according to the planning device 100, a specific process assigns menus based on the distribution of users' expectations for those menus as a constraint. This allows the planning device 100 to improve the feasibility of users executing multiple menus.

[0145] Furthermore, according to the planning device 100, the output processing involves displaying and outputting combinations of menus that are infrequently changed to the user. This allows the planning device 100 to specifically recommend menu combinations that are highly feasible to users of the service.

[0146] Furthermore, the planning device 100 processes the output by displaying a schedule for each user, with the frequency of changes as a constraint. This allows service providers using the planning device 100 to specifically recommend menu combinations that are highly feasible for each user, according to the service provision situation.

[0147] Furthermore, according to the planning device 100, the processing of the display output may include information on the frequency of changes for each menu item. This allows the planning device 100 to specifically present to the provider the feasibility of each menu item in the recommended schedule, enabling the provider to create a schedule with an understanding of the feasibility of each menu item.

[0148] The planning method described in this embodiment can be implemented by executing a pre-prepared program on a computer such as a PC or workstation. The planning program described in this embodiment is recorded on a computer-readable recording medium and executed by reading it from the recording medium by the computer. The recording medium can be a hard disk, flexible disk, CD (Compact Disc)-ROM, MO (Magneto Optical Disc), DVD (Digital Versatile Disc), etc. Furthermore, the planning program described in this embodiment may be distributed via a network such as the Internet.

[0149] With regard to the embodiments described above, the following additional information is disclosed.

[0150] (Note 1) Obtain information on the menu of the specified service and information on stakeholders related to the said service. For the combination of the aforementioned stakeholders and the aforementioned menu, calculate the frequency of changes in the execution of the menu. Based on the calculated change frequency, identify the menu items to recommend, To the stakeholders of the calculated combination, the identified menu is output. A planning method characterized by having a computer perform the processing.

[0151] (Note 2) The acquisition process described above is: The system acquires planning data for the execution of the menu items of the aforementioned service, and actual data for the execution of the menu items in the planning data. The process for the aforementioned calculation is as follows: Based on the difference between the acquired plan data and the actual data, the points of change in whether or not the menu was executed are extracted. The frequency of change for each stakeholder with respect to the menu having the aforementioned change point is calculated. The aforementioned specific process is, To identify the combination of stakeholders with a low frequency of change for the aforementioned menu, The planning method described in Appendix 1, characterized by the features described herein.

[0152] (Note 3) The process for calculating the frequency of change is as follows: This is calculated based on the overlap of the distribution of parameters, including time, location, effect, and difficulty, that indicate the expected value of implementing the menu for each of the aforementioned stakeholders. The planning method described in Appendix 2, characterized by the features described herein.

[0153] (Note 4) The aforementioned specific process is The stakeholders whose distribution of expected values ​​is similar are combined. The planning method described in Appendix 3, characterized by the features described herein.

[0154] (Note 5) The aforementioned specific process is Based on the distribution of the expected values ​​for each of the multiple menus, a workflow combining the multiple menus is determined. A planning method as described in Appendix 3 or 4, characterized by the features described herein.

[0155] (Note 6) The aforementioned stakeholders include the planner who formulates the menu of the services, the provider of the services, and the users who utilize the services. The aforementioned specific process is, This process includes combining the provider and the user whose distributions of expected values ​​are similar. The planning method described in Appendix 4, characterized by the features described herein.

[0156] (Note 7) The aforementioned specific process is If the provider's frequency of changes to the menu is low, the provider's frequency of changes to the menu is used as a constraint to assign the menu with a low frequency of changes. The planning method described in Appendix 6, characterized by the features described herein.

[0157] (Note 8) The aforementioned specific process is Assign the menus using the distribution of the user's expected values ​​for the menus as a constraint. The planning method described in Appendix 6, characterized by the features described herein.

[0158] (Note 9) The processing of the above output is as follows: To the user, display and output the combination of the menus that are changed infrequently. The planning method described in Appendix 8, characterized by the features described herein.

[0159] (Note 10) The processing of the above output is as follows: The provider is instructed to display and output a schedule for each user, combining the menus, with the frequency of changes as a constraint. The planning method described in Appendix 7, characterized by the features described herein.

[0160] (Note 11) The processing of the above display output is as follows: Including information on the frequency of changes for each of the aforementioned menu items, The planning method described in Appendix 10, characterized by the features described herein.

[0161] (Note 12) Obtain information on the menu of the specified service and information on stakeholders related to the said service. For the combination of the aforementioned stakeholders and the aforementioned menu, calculate the frequency of changes in the execution of the menu. Based on the calculated change frequency, identify the menu items to recommend, To the stakeholders of the calculated combination, the identified menu is output. A planning program characterized by having a computer execute the processing.

[0162] (Note 13) Obtain information on the menu of the specified service and information on stakeholders related to the said service. For the combination of the aforementioned stakeholders and the aforementioned menu, calculate the frequency of changes in the execution of the menu. Based on the calculated change frequency, identify the menu items to recommend, A control unit is provided that outputs the identified menu to the stakeholders of the calculated combination. A planning device characterized by the following features.

[0163] (Note 14) The control unit is, The information of the aforementioned menu and the information of stakeholders related to the aforementioned service are obtained from the clients of the aforementioned stakeholders. The estimated menu is output to the client. A planning device as described in Appendix 13, characterized by the features described herein. [Explanation of Symbols]

[0164] 100 Planning device 200 servers 201 Menu Combination Template DB 210 rehabilitation facilities 211 Clients 213 Past Plans / Performance Database 214 Menu Database 215 Stakeholder Database 301 CPU 302 memory 303 Network I / F 305 Recording media 401 Historical Data Acquisition Unit 402 Response change point extraction unit 403 Response Change Risk Estimation Unit 404 Risk Minimum Condition Extraction Unit 405 Menu Recommendation Department 412 Response change point DB 413 Response Change Risk DB 414 Conditional Menu Database 2001, 2002 represent the image. m The person who filed the case p provider u users

Claims

1. Obtaining planning data which plans the execution of a predetermined menu of services to be provided to stakeholders, actual data which shows that the menu in the planning data has been actually executed, and information of the stakeholders related to the services, For each combination of the aforementioned stakeholders and the aforementioned menu, the frequency of changes in the execution of the aforementioned menu for each stakeholder is calculated. Based on the calculated change frequency, the menu items to be recommended to the stakeholders are identified. The process includes outputting the identified menu to the stakeholders of the calculated combination, The process for the aforementioned calculation is as follows: Based on the difference between the acquired plan data and the actual data, change points indicating whether or not the menu was executed are extracted. The frequency of change for each stakeholder in relation to the menu having the aforementioned change points is calculated based on the overlap of the distribution of parameters for each stakeholder, including time, location, effect, and difficulty, which indicate the expected value regarding the implementation of the menu. A planning method characterized by having a computer perform the processing.

2. The specific processing is, The stakeholders whose distribution of expected values ​​is similar are combined. The planning method according to feature 1.

3. The specific processing is, Based on the distribution of the expected values ​​for each of the multiple menus, a workflow combining the multiple menus is determined. The planning method according to feature 1 or 2.

4. The stakeholders include a planner who plans the service menu, a provider who provides the service, and a user who uses the service, The aforementioned specific process is, This process includes combining the provider and the user whose distributions of expected values ​​are similar. The planning method according to feature 2.

5. The specific processing is, If the provider's frequency of changes to the menu is low, the provider's frequency of changes to the menu is used as a constraint to assign the menu with a low frequency of changes. The planning method according to feature 4.

6. The specific processing is, Assign the menus using the distribution of the user's expected values ​​for the menus as a constraint. The planning method according to feature 4.

7. The processing of the output is: To the user, display and output the combination of the menus that are changed infrequently. The planning method according to feature 6.

8. The processing of the output is: The provider is instructed to display and output a schedule for each user, combining the menus, with the frequency of changes as a constraint. The planning method according to feature 5.

9. The processing of the display output is as follows: Including information on the frequency of changes for each of the aforementioned menu items, The planning method according to feature 8.

10. Obtaining planning data which plans the execution of a predetermined menu of services to be provided to stakeholders, actual data which shows that the menu in the planning data has been actually executed, and information of the stakeholders related to the services, For each combination of the aforementioned stakeholders and the aforementioned menu, the frequency of changes in the execution of the aforementioned menu for each stakeholder is calculated. Based on the calculated change frequency, the menu items to be recommended to the stakeholders are identified. The process includes outputting the identified menu to the stakeholders of the calculated combination, The process for the aforementioned calculation is as follows: Based on the difference between the acquired plan data and the actual data, change points indicating whether or not the menu was executed are extracted. The frequency of change for each stakeholder in relation to the menu having the aforementioned change points is calculated based on the overlap of the distribution of parameters for each stakeholder, including time, location, effect, and difficulty, which indicate the expected value regarding the implementation of the menu. A planning program characterized by having a computer execute the processing.

Images