Proposal system and method for making proposals for risk reduction

The proposal system addresses the limitations of existing risk prediction technologies by personalizing recommendations for multiple controllable features, improving risk reduction strategies through a predictive model and time-bound adjustments.

JP7778052B2Active Publication Date: 2025-12-01HITACHI LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2022156843
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2022-09-29
Publication Date
2025-12-01
Estimated Expiration
2042-09-29

AI Technical Summary

Technical Problem

Existing risk prediction technologies, such as Patent Document 1, focus primarily on body weight but fail to address how to improve multiple characteristics beyond weight to reduce health and nursing care risks effectively.

Method used

A proposal system that acquires entity data from historical records, uses a predictive model to identify controllable features, and generates personalized recommendations for modifying these features to reduce predicted risks, incorporating time constraints and domain knowledge to ensure feasibility.

Benefits of technology

The system provides high feasibility for risk reduction by offering tailored proposals that consider multiple controllable features and their changes over time, enhancing the effectiveness of risk mitigation strategies.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007778052000001
    Figure 0007778052000001
  • Figure 0007778052000002
    Figure 0007778052000002
  • Figure 0007778052000003
    Figure 0007778052000003
Patent Text Reader

Abstract

To provide a high possibility of realization of risk reduction.SOLUTION: A system acquires, from history data, entity data similar to target entity data, which is data including the respective feature values of plural features regarding a target entity. History data includes entity data of each previous time point for each of the entities. For each entity, the entity data of a time point in the past includes the feature value of the time point for the features of the entity. The system makes a proposition to change a feature value to reduce a predicted risk by inputting the target entity data into a prediction model on the basis of the statistic of plural feature values in related event data as data including entity data similar to the target entity data for each of controllable ones of the plural features regarding the target entity, and provides a UI (User Interface) which displays the proposition.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates generally to data processing techniques that provide risk reduction recommendations. [Background technology]

[0002] In recent years, while healthy life expectancy and working life expectancy have been extended, rising medical and nursing care costs have become a concern due to changes in the population structure, such as a declining birthrate and an aging population. For this reason, it is desirable to predict risks, such as the occurrence or worsening of health, medical, and nursing care issues, and to propose appropriate countermeasures. Patent Document 1 discloses a technology relating to the prediction of future risks or proposals for risk reduction. Patent Document 1 discloses a technology for proposing a method for patients to lose weight in order to reduce the risk of disease. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2022-64113 Summary of the Invention [Problem to be solved by the invention]

[0004] Patent Document 1 describes body weight, a factor that can be directly controlled by improving lifestyle habits, but does not disclose how to handle multiple characteristics, including multiple characteristics other than weight, and which characteristics should be improved. [Means for solving the problem]

[0005] The proposal system acquires entity data similar to target entity data, which is data including each feature value of multiple features related to a target entity, from historical data. The historical data includes entity data for each of the multiple entities at each past point in time. For each entity, the entity data for the past point in time includes feature values ​​for each feature of the entity at that time. The proposal system inputs the target entity data into a predictive model, based on statistics of multiple feature values ​​in related case data, which is data including entity data similar to the target entity data, for each controllable feature among the multiple features related to the target entity, to create a proposal for changing the feature value to reduce the predicted risk. The predictive model is a model that inputs data including each feature value of multiple features related to the entity and outputs risk. The proposal system provides a UI (User Interface) that displays the proposal created for the target entity. [Effects of the Invention]

[0006] The present invention provides a high degree of feasibility for risk reduction. [Brief explanation of the drawings]

[0007] [Figure 1] 1 illustrates an example of the configuration of a proposed system according to an embodiment. [Figure 2] 10 shows an example of the structure of a feature table. [Figure 3] 10 shows an example of the configuration of a patient extraction table. [Figure 4] 10 shows an example of the configuration of a time constraint table set. [Figure 5] An example of the domain DB configuration is shown below. [Figure 6] 1 shows an example of the overall processing flow according to an embodiment. [Figure 7] An example of the processing flow of S603 in FIG. 6 is shown below. [Figure 8] An example of the processing flow of S702 in FIG. 7 is shown below. [Figure 9]An example outline of creating a basic proposal for one feature is shown below. [Figure 10] Examples of time boundaries are shown below. [Figure 11] 10 shows an example of a flow of a proposal creation process. [Figure 12] 10 shows an example outline of determining a risk reduction goal corresponding to a user desired target. [Figure 13] An example of an outline of alternatives creation is shown below. [Figure 14] Examples of generic proposals developed to achieve risk reduction goals are presented. [Figure 15] 10 shows an example of a flow of a domain-specific proposal creation process. [Figure 16] An example of a patient GUI is shown. [Figure 17] An example of a constraint setting GUI is shown below. [Figure 18] 1 shows an example of an alternative selection GUI. DETAILED DESCRIPTION OF THE INVENTION

[0008] In the following description, an "interface apparatus" may refer to one or more interface devices, which may be at least one of the following: An I / O interface device is one or more I / O (Input / Output) interface devices. The I / O interface device is an interface device for at least one of an I / O device and a remote display computer. The I / O interface device for the display computer may be a communications interface device. The at least one I / O device may be a user interface device, for example, either an input device such as a keyboard and a pointing device, or an output device such as a display device. A communication interface apparatus that is one or more communication interface devices. The one or more communication interface devices may be one or more homogeneous communication interface devices (e.g., one or more NICs (Network Interface Cards)) or two or more heterogeneous communication interface devices (e.g., an NIC and an HBA (Host Bus Adapter)).

[0009] In the following description, "memory" refers to one or more memory devices, which are an example of one or more storage devices, and may typically be a primary storage device. At least one memory device in the memory may be a volatile memory device or a non-volatile memory device.

[0010] In the following description, a "persistent storage device" may refer to one or more persistent storage devices, which are an example of one or more storage devices. A persistent storage device may typically be a non-volatile storage device (e.g., an auxiliary storage device), and specifically may be, for example, a hard disk drive (HDD), a solid state drive (SSD), a non-volatile memory express (NVME) drive, or a storage class memory (SCM).

[0011] In the following description, the term "storage device" may refer to at least one of memory and persistent storage device.

[0012] Furthermore, in the following description, a "processor" may refer to one or more processor devices. The at least one processor device may typically be a microprocessor device such as a CPU (Central Processing Unit), but may also be another type of processor device such as a GPU (Graphics Processing Unit). The at least one processor device may be a single-core or multi-core. The at least one processor device may also be a processor core. The at least one processor device may also be a processor device in a broader sense, such as a circuit that is a collection of gate arrays written in a hardware description language that performs some or all of the processing (for example, an FPGA (Field-Programmable Gate Array), a CPLD (Complex Programmable Logic Device), or an ASIC (Application Specific Integrated Circuit)).

[0013] In the following description, processing may be described using a "program" as the subject; however, since a program is executed by a processor to perform a predetermined process using a storage device and / or an interface device as appropriate, the subject of the processing may also be the processor (or a device or system having the processor). A program may be installed in a device such as a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable recording medium (e.g., a non-transitory recording medium). In the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs.

[0014] In the following description, information that provides an output for an input may be described using expressions such as "xxx table." However, this information may be data of any structure (for example, structured data or unstructured data), or may be a neural network that generates an output for an input, or a learning model such as a genetic algorithm or random forest. Therefore, the "xxx table" may be referred to as "xxx information." In the following description, the structure of each table is an example, and one table may be divided into two or more tables, or all or part of two or more tables may be one table.

[0015] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0016] FIG. 1 shows an example of the configuration of a proposed system according to an embodiment.

[0017] The proposal system 100 according to this embodiment proposes how to modify controllable features to reduce the risk predicted by the prediction model 150. The proposal system 100 also estimates a time boundary and sets a risk reduction goal that can be achieved within a specified time based on the estimated time boundary. The proposal system 100 also generates proposals based on domain knowledge. The proposal system 100 also filters (excludes) conflicting proposals from the generated proposals. In this embodiment, "risk" refers to the probability of a defined event occurring. For example, in the medical field, the risk may be the probability that an inpatient will be readmitted, and in the manufacturing field, the risk may be the probability that a part will fail. Hereinafter, as an example, the risk is the probability that a hospitalized patient will be readmitted within 30 days if they are currently discharged.

[0018] The proposed system 100 may be an information processing terminal such as a personal computer, a physical computer system consisting of one or more physical computers, or a logical computer system based on a physical computer system (e.g., a cloud computing system). The proposed system 100 has an interface device 101, a storage device 102, and a processor 103 connected thereto.

[0019] The interface device 101 may communicate with a user terminal 110, for example, via a communication network 120. The proposed system 100 may be a server system, and the user terminal 110 may be a client system. The user terminal 110 may be an information processing terminal such as a personal computer or a smartphone. The "user" is typically a doctor, but may be a nurse, public health nurse, medical therapist, or other such person. The user terminal 110 may be an example of an input / output console that includes an input device (e.g., a keyboard and a pointing device) and a display device.

[0020] The storage device 102 stores a prediction model 150. The prediction model 150 may be a machine learning model that takes patient data as input and data representing risk as output. The prediction model 150 may be a neural network or a gradient boosting model. Both (or either) risk and time may be objective variables, and multiple features may be explanatory variables.

[0021] The storage device 102 stores data such as a history DB (database) 160, a feature table 171, a patient extraction table 172, a time constraint table set 173, and a domain DB 180. The history DB 160 contains data on the past health of each patient (specifically, data including past feature values ​​for each of a plurality of features of each patient), and a portion of this data and / or data different from this data is used as a training DS (dataset) 161 for the prediction model 150. The domain DB 180 includes a proposal table 181, a proposal conflict table 182, and a patient conflict table 183.

[0022] The storage device 102 stores computer programs such as a learning program 151, an inference program 152, and a proposal creation program 153. The learning program 151 uses a training DS 161 to learn a prediction model 150. The inference program 152 inputs patient data into the learned prediction model 150 to predict (infer) the risk of the patient. The proposal creation program 153 proposes a method for reducing the predicted risk. The proposal creation program 153 can receive a user-desired risk reduction goal from the user terminal 110.

[0023] FIG. 2 shows an example of the structure of the feature table 171.

[0024] The feature table 171 indicates whether each of a plurality of features of a patient is controllable. The feature table 171 has an entry for each feature. The entry has data such as a feature name 201 and controllable 202. The feature name 201 indicates the name of the feature. The controllable 202 indicates whether the feature is controllable. The feature table 171 may be a list of the feature names of the controllable features.

[0025] FIG. 3 shows an example of the configuration of the patient extraction table 172.

[0026] The patient extraction table 172 may be generated based on data extracted from the history DB 160, and represents how the patient's features have changed over time. The patient extraction table 172 has an entry for each patient-feature pair. The entry has data such as a patient ID 301, a feature name 302, an action 303, and a change over time 304.

[0027] Patient ID 301 represents the patient's ID. Feature Name 302 represents the name of the patient's feature. Action 303 represents whether the feature value is increased or decreased. Change over time 304 represents the change in the feature value over time.

[0028] FIG. 4 shows an example of the configuration of the time constraint table set 173.

[0029] The time constraint table set 173 includes a first time constraint table 400A and a second time constraint table 400B.

[0030] The first time constraint table 400A represents the amount of change that can occur per time for each patient characteristic. The first time constraint table 400A has an entry for each characteristic. The entry has data such as a feature name 401, an action 402, and a maximum change over time 403. The feature name 401 represents the name of the characteristic. The action 402 represents whether the value of the characteristic is to increase or decrease. The maximum change over time 403 represents the maximum change that can be achieved over time.

[0031] The second time constraint table 400B represents minimum and maximum values ​​for each patient feature. The second time constraint table 400B has an entry for each feature. The entry has data such as a feature name 411, a minimum allowed value 412, and a maximum allowed value 413. The feature name 411 represents the name of the feature. The minimum allowed value 412 represents the minimum allowed feature value for the feature. The maximum allowed value 413 represents the maximum allowed feature value for the feature.

[0032] The time constraint table set 173 may be created by a user (for example, a doctor). For example, the time constraint table set 173 is a table input from the user terminal 110. Furthermore, the time constraint table set 173 may be prepared for each patient.

[0033] FIG. 5 shows an example of the configuration of the domain DB 180. As shown in FIG.

[0034] The domain DB 180 may be created by a user (for example, a doctor), and includes the proposal table 181, the proposal conflict table 182, and the patient conflict table 183, as described above.

[0035] The proposal table 181 has an entry for each proposal. The entry has data such as proposal ID 501, feature name 502, action 503, domain proposal 504, and average change over time 505. The proposal ID 501 represents the ID of the domain proposal. The feature name 502 represents the name of the feature. The action 503 represents whether the action is to increase or decrease the value of the feature. The domain proposal 504 represents a detailed proposal. The average change over time 505 represents the average value of the change in the value of the feature per time.

[0036] The proposal conflict table 182 represents conflicts between domain proposals. The proposal conflict table 182 has an entry for each pair of a domain proposal and a conflicting domain proposal. The entry includes data such as a proposal ID 521 and a conflict proposal ID 522. The proposal ID 521 represents the ID of the domain proposal, and the conflict proposal ID 522 represents the ID of the domain proposal that conflicts with the domain proposal. For example, if a domain proposal called "exercise" conflicts with a domain proposal called "rest," the IDs of those domain proposals are set in the same entry.

[0037] The patient conflict table 183 represents a conflict between a patient and a domain proposal. The patient conflict table 183 has an entry for each pair of a patient and a conflicting domain proposal. The entry has data such as a patient ID 511 and a conflict proposal ID 512. The patient ID 511 represents the patient's ID. The conflict proposal ID 512 represents the ID of the domain proposal that conflicts with the patient. For example, if a domain proposal of a patient who is allergic to a certain medicine and taking that medicine conflicts, the IDs of the patient and the domain proposal are set in the same entry.

[0038] FIG. 6 shows an example of the overall processing flow according to the embodiment.

[0039] In S601, the learning program 151 trains the prediction model 150 using the training DS 161. The inference program 152 inputs patient data of a target patient into the trained prediction model 150 to predict the patient's risk (the probability that the hospitalized patient will be readmitted within 30 days if currently discharged). The training DS 161 may include, for each of multiple patients, data representing one or more dates and times, data including values ​​of multiple features related to the patient at each date and time, and data representing the date and time of readmission if the patient is readmitted. The history DB 160 may be used as the training DS 161. The multiple patient features may be multiple attribute items related to the patient, and may include, for example, personal attribute items such as age, gender, and blood type, and vital parameter items such as heart rate and SpO2 measured during hospitalization. The patient data (patient data of the target patient) input into the trained prediction model 150 may include current values ​​of each of the multiple features related to the target patient.

[0040] In S602, the proposal creation program 153 searches the history DB 160 for related case data, which is data representing cases related to the patient data of the target patient, based on the patient data of the target patient. For example, the history DB 160 may contain data for each patient, including feature values ​​for each feature at each of multiple past time points. The related case data may be patient data for each patient other than the target patient, including feature values ​​for each feature at each of one or more past time points. That is, the related case data may include patient data for each of one or more patients other than the target patient, including patient data for each of one or more past time points. Furthermore, the patient data included in the related case data may be patient data similar to the patient data of the target patient (e.g., feature values ​​of one or more features), for example, patient data whose distance (e.g., cosine similarity or Euclidean distance) from the patient data of the target patient is equal to or less than a threshold. Furthermore, the related case data may include patient data having feature values ​​similar to the feature values ​​of the target patient for one or more features (or features excluding the one or more features) identified using an explanation calculation method such as SHAP (Sharpley Additive exPlanations). Different weights may be assigned to different features (for example, coefficients of features as explanatory variables). The method of searching for related case data is not limited to these examples.

[0041] In S603, the proposal creation program 153 identifies one or more controllable features of the target patient from among multiple patient features based on the extracted related case data and the feature table 171, and creates a basic proposal that proposes increasing or decreasing the feature value for each of the one or more features if a change in the feature value of the feature is necessary to reduce risk. Details of S603 will be described later with reference to Figures 7 to 9.

[0042] In S604, the proposal creation program 153 estimates the time boundary using at least one of the patient extraction table 172 and the time constraint table set 173. Details of S604 will be described later with reference to FIG.

[0043] In S605, the proposal creating program 153 determines whether or not the user has specified constraints regarding at least one of risk and time. If the determination result in S605 is true (S605: Yes), the proposal creating program 153 determines in S606 whether or not the user-specified constraints are feasible. If the determination result in S606 is false (S606: No), the proposal creating program 153 determines an alternative to the constraints (in other words, an alternative target proposal) in S607. If the determination result in S605 is false (S605: No), the proposal creating program 153 calculates the constraints in S608. If the determination result in S606 is true (S606: Yes), after S607 or S608, in S609, the proposal creating program 153 creates a generic proposal as a quantitative proposal. Details of S605-S609 will be described later with reference to FIG. 11.

[0044] In S610, the proposal creating program 153 determines whether or not the domain DB 180 is valid. Whether or not the domain DB 180 is valid may be, for example, one of the following. If there is setting data indicating whether the domain DB 180 is enabled or disabled, the data indicates whether the domain DB 180 is enabled or disabled. If the patient data of the target patient includes data indicating whether or not the domain DB 180 is being used, whether or not the data indicates whether or not the domain DB 180 is being used. ·Whether or not there is data on the target patient in the domain DB180.

[0045] If the determination result in S610 is false (S610: No), in S613, the proposal creation program 153 provides patient proposal information (display information) including information representing the generic proposal to the user terminal 110. As a result, a patient GUI (Graphical User Interface) displaying the patient proposal information is displayed on the user terminal 110. Another type of UI (User Interface) may be provided instead of a GUI.

[0046] If the determination result of S610 is true (S610: Yes), in S611, the proposal creation program 153 identifies a domain proposal corresponding to the generic proposal of the target patient from the domain DB 180. In S612, the proposal creation program 153 checks whether the identified domain proposal has a conflict, and if there is a domain proposal with a conflict, filters the domain proposal (details of S611-S612 will be described later with reference to FIG. 15). Thereafter, in S613, the proposal creation program 153 provides the user terminal 110 with patient proposal information (display information) including information indicating the generic proposal of the quantitative proposal and the domain proposal that was not filtered. As a result, a patient GUI displaying the patient proposal information is displayed on the user terminal 110.

[0047] The process shown in FIG. 6 will be described in detail below.

[0048] FIG. 7 shows an example of the processing flow of S603 in FIG.

[0049] In S701, the proposal creation program 153 identifies controllable features based on the feature table 171. For each identified controllable feature, the proposal creation program 153 classifies the feature cases represented by the related case data into a low-risk distribution and a high-risk distribution.

[0050] Here, taking one feature as an example ("target feature" in the explanation of FIG. 7), the feature cases, low risk distribution, and high risk distribution are as follows:

[0051] A "feature instance" is a set of feature values ​​of a target feature. That is, if the related case data includes patient data of multiple patients, and the patient data of each patient includes a feature value of the target feature, the feature instance of the target feature includes the feature value of the target feature in each patient data.

[0052] A "low risk distribution" is a distribution (e.g., normal distribution) of the feature values ​​of the target feature in patient data corresponding to low risk among the feature instances of the target feature. "Patient data corresponding to low risk" is patient data corresponding to a risk equal to or lower than the risk predicted for the target patient. The "risk corresponding to patient data" may be a risk associated with the patient data (e.g., a risk predicted in the past for the patient data, or a risk defined based on the predicted risk and the actual performance represented by the patient data (e.g., whether or not there was readmission and the date and time of readmission)), or it may be a risk obtained by inputting the patient data into the prediction model 150.

[0053] A "high-risk distribution" is a distribution (e.g., normal distribution) of the feature values ​​of a target feature in patient data corresponding to a high risk among feature instances of the target feature. "Patient data corresponding to a high risk" is patient data corresponding to a risk higher than the predicted risk for the target patient.

[0054] The method for determining whether a risk falls into the "low risk" or "high risk" category is not limited to the above-described method. For example, the overall average risk value may be used as a standard to determine whether the risk is above or below the average, or whether it is low risk or high risk.

[0055] In S702, the proposal creation program 153 determines a base proposal for each controllable feature, if necessary. A "base proposal" is a proposal to increase or decrease a feature value. Specifically, a "base proposal" is a proposal to bring the feature value of a target feature closer to a low-risk distribution (for example, a proposal aimed at positioning the feature value of a target feature in a low-risk distribution).

[0056] Figure 8 shows an example of the processing flow of S702 in Figure 7. Figure 9 shows an example of the outline of creating a basic proposal for one feature. Take one feature as an example (referred to as the "target feature" in the explanations of Figures 8 and 9). In addition, for convenience, the feature value of the target feature of the target patient will be referred to as the "current feature value" in the explanations of Figures 8 and 9.

[0057] For the low-risk distribution and the high-risk distribution, the horizontal axis represents the feature value and the vertical axis represents the probability density.

[0058] In S801, the proposal creation program 153 determines whether there is a significant difference (e.g., a difference that satisfies the first condition) between the current feature value and the low-risk distribution. For example, the proposal creation program 153 performs a statistical t-test to compare the current feature value with the low-risk distribution. If the result of S801 is false (S801: No), the proposal creation program 153 maintains the status quo (or makes no proposal). This is because the feature value of the target feature is already located in (or close to) the low-risk distribution, so there is no need for a basic proposal.

[0059] If the result of S801 is true (S801: Yes), for example, if a significant difference is found at a certain confidence level, in S802, the proposal creation program 153 determines whether there is a significant difference (e.g., a difference that satisfies the second condition) between the low-risk distribution and the high-risk distribution. For example, the proposal creation program 153 performs a t-test to determine whether there is a significant difference between the low-risk distribution and the high-risk distribution. If the result of S802 is false (S802: No), the proposal creation program 153 makes no proposal. This is because a basic proposal that brings the feature value of the target feature closer to the low-risk distribution may also bring the feature value closer to the high-risk distribution.

[0060] If the result of S802 is true (S802: Yes), in S803 the proposal creation program 153 creates a basic proposal as necessary. Specifically, for example, it is as follows. Of the following, the third and fourth examples correspond to the examples of S801: No, and therefore may be examples that do not exist in S803. (First example) If the statistical value (e.g., mean value) of the feature value is larger in the high-risk distribution than in the low-risk distribution, and the current feature value is closer to the high-risk distribution (e.g., located in the high-risk distribution) than to the low-risk distribution, the basic proposal is to decrease the current feature value in order to bring the current feature value closer to the low-risk distribution. (Second example) If the feature value statistics are smaller in the high-risk distribution than in the low-risk distribution, and the current feature value is closer to the high-risk distribution than to the low-risk distribution (e.g., located in the high-risk distribution), the base proposal is to increase the current feature value, in order to bring the current feature value closer to the low-risk distribution. (Third example) If the statistical value of the feature value is larger in the high-risk distribution than in the low-risk distribution, and the current feature value is closer to the low-risk distribution than to the high-risk distribution (for example, located in the low-risk distribution), then there will be no base proposal (or the base proposal can be a proposal to maintain the status quo). (Fourth example) If the statistical value of the feature value is smaller in the high-risk distribution than in the low-risk distribution, and the current feature value is closer to the low-risk distribution than to the high-risk distribution (for example, located in the low-risk distribution), there will be no basic proposal (or the basic proposal can be a proposal to maintain the status quo).

[0061] FIG. 10 shows an example of a time boundary.

[0062] The estimated time boundary can be expressed in a Cartesian coordinate system, which shows the relationship between time and risk. The x-axis (an example of a first axis) corresponds to time, and the y-axis (an example of a second axis perpendicular to the first axis) corresponds to risk. The unit of time is days in the example shown in FIG. 10, but it is not limited to this and may be other units such as years, months, hours, minutes, or seconds.

[0063] The current point 1001 on the vertical axis represents the target patient's risk at time 0, specifically the risk predicted using the predictive model 150 .

[0064] The time boundary divides the Cartesian coordinates into a feasible region 1004 and an unfeasible region 1005. The time boundary is a boundary that divides risk-time pairs into feasible pairs and unfeasible pairs. Specifically, for example, the time boundary is composed of a first boundary portion 1002 and a second boundary portion 1003.

[0065] A first boundary 1002 represents the minimum risk for the target patient, which is the risk that would be achieved if the target patient were to achieve an optimal value for each controllable characteristic based on the predictive model 150.

[0066] The second boundary portion 1003 represents the maximum reduction amount, which is the maximum risk reduction amount per time. The maximum reduction amount is calculated by both or one of the following two methods (i.e., it is calculated based on at least one of the patient extraction table 172 and the time constraint table set 173). Note that in the following method, it is sufficient to refer to entries in the patient extraction table 172 and the time constraint table set 173 that correspond to controllable features identified in the previous processing, and entries that correspond to features that were not identified as controllable features in the previous processing may not be referenced. The proposal creation program 153 calculates the maximum reduction amount based on the patient extraction table 172. For example, the proposal creation program 153 estimates the relationship between the predicted risk reduction amount and time based on two or more patient feature names 302, actions 303, and changes over time 304, and the prediction model 150. The estimated relationship is the maximum reduction amount. The proposal creation program 153 calculates the maximum reduction amount based on the time constraint table set 173. For example, the proposal creation program 153 calculates the maximum change amount for each controllable feature based on the maximum change over time 403, the minimum acceptable value 412, and the maximum acceptable value 413, and estimates the relationship between the predicted risk reduction amount and time based on the maximum change amount for each controllable feature and the prediction model 150. The estimated relationship is the maximum reduction amount.

[0067] FIG. 11 shows an example of the flow of the proposal creation process.

[0068] In S1101, the proposal creation program 153 displays a GUI and waits for input from the user. The GUI displayed here may display, for example, orthogonal coordinates that represent an estimated time boundary. The user may specify a desired location on the orthogonal coordinates.

[0069] In S1102, the proposal creation program 153 determines whether or not both risk and time constraints have been specified. This determination may be, for example, whether or not a location in the area on the Cartesian coordinate system illustrated in FIG. 10 has been specified.

[0070] If the determination result in S1102 is false (S1102: No), in S1103, the proposal creation program 153 determines whether or not one of the risk and time constraints has been specified. This determination may be made by determining whether or not a location on any axis of the Cartesian coordinate system has been specified.

[0071] If the determination result in S1103 is false (S1103: No), in S1104, the proposal creation program 153 selects an arbitrary risk reduction target for the target patient (for example, a target based on a time series of past feature values ​​related to the target patient's controllable features). A "risk reduction target" is a target for how much risk should be reduced by when, that is, a set of time and the amount of risk reduction. In an orthogonal coordinate system of the time axis and the risk axis, the point corresponding to the risk reduction target is on the time boundary or on the feasible region 1004.

[0072] If the determination result of S1103 is true (S1103: Yes), the constraint specified by the user is a risk constraint or a time constraint. As illustrated in FIG. 12, the risk constraint is a constraint corresponding to point 1201 on the risk axis (in other words, a risk target), and the time constraint is a constraint corresponding to point 1203 on the time axis (in other words, a time target). In S1105, the proposal creation program 153 selects a risk reduction target that satisfies the constraint specified by the user. Specifically, the following may be selected. When the constraint is a risk constraint, as illustrated in Fig. 12, the risk reduction target is point 1202, which is a point on the time boundary or on the feasible region 1004 and has the same y-coordinate as point 1201. In the example shown in Fig. 12, point 1202 is a point on the second boundary portion 1003. In other words, the risk reduction target is the target corresponding to the shortest feasible time that satisfies the risk constraint specified by the user. When the constraint is a time constraint, as illustrated in Fig. 12, the risk reduction target is point 1204, which is a point on the time boundary or on the feasible region 1004 and has the same x-coordinate as point 1203. In the example shown in Fig. 12, point 1204 is a point on the first boundary portion 1002. In other words, the risk reduction target is a target that corresponds to the minimum risk among the feasible risks that satisfy the time constraint specified by the user.

[0073] If the determination result in S1102 is true (S1102: Yes), in S1106, the proposal creating program 153 determines whether the constraint specified by the user corresponds to a point on the time boundary or the feasible region 1004.

[0074] If the determination result in S1106 is false (S1106: No), in S1107, the proposal creation program 153 presents several alternative goal plans and accepts the user's desired alternative goal plan. For example, as illustrated in FIG. 13, assume that the constraint specified by the user is point 1301 on the infeasible region 1005. The proposal creation program 153 calculates the following three alternative goal plans. The first alternative goal plan is a goal plan corresponding to point 1302, which corresponds to the minimum risk reduction among the risk reductions that can be achieved within the time specified by the user. Point 1302 may be a point on the feasible region 1004 on a line (a line parallel to the y-axis) that passes through point 1301, instead of a point on the time boundary. The second alternative target plan is a target plan corresponding to point 1304, which corresponds to the shortest time possible to achieve the risk reduction specified by the user. Point 1304 may be a point on the feasible region 1004 on a line (a line parallel to the x-axis) passing through point 1301, instead of a point on the time boundary. The third alternative goal proposal is an intermediate goal proposal between the first alternative goal proposal and the second alternative goal proposal, specifically, for example, a goal proposal corresponding to the intersection 1303 of the perpendicular line passing through point 1301 and the time boundary. Point 1303 may be a point on the feasible region 1004 of the perpendicular line passing through point 1301 instead of a point on the time boundary.

[0075] If the determination result of S1106 is true (S1106: Yes), or if S1107 is performed, the risk reduction goal has been determined. In S1108, the proposal creation program 153 uses, for example, the prediction model 150 to create a generic proposal for each controllable feature identified in the previous process (S603 in FIG. 6) in order to achieve the determined risk reduction goal. As illustrated in FIG. 14, for each controllable feature, the generic proposal is a quantitative proposal of how much to reduce or increase the feature value within the time represented by the risk reduction goal (by the target deadline represented by the risk reduction goal).

[0076] The correspondence between FIG. 11 and FIG. 6 is, for example, as follows: S1101 and S1102 in Figure 11 correspond to S605 in Figure 6. S1103-S1105 in Figure 11 correspond to S608 in Figure 6. S1106 in Figure 11 corresponds to S606 in Figure 6. S1107 in Figure 11 corresponds to S607 in Figure 6. S1108 in Figure 11 corresponds to S1108 in Figure 6.

[0077] FIG. 15 shows an example of the flow of the domain-specific proposal creation process.

[0078] In S1501, the proposal creation program 153 extracts a domain proposal for each controllable feature identified in the previous process (S603 in FIG. 6) from the domain DB 180. For example, an entry having the feature name 502 corresponding to the controllable feature is extracted from the proposal table 181 of the domain DB 180.

[0079] In S1502, the proposal creation program 153 filters out domain proposals extracted in S1501 that do not match the current case (generic proposal created for the target patient). For example, the following domain proposals are filtered out: Domain proposals with feature names that do not match the feature names of any generic proposals. A domain proposal with a feature name that matches a feature name in one of the generic proposals, but with an action that does not match the action (decreasing or increasing the feature value) of that generic proposal.

[0080] In S1503, the proposal creation program 153 checks the domain proposals remaining in S1502 for conflicts between the domain proposals and between the target patient and the domain proposals, and filters out the domain proposals that have conflicts. For example, the following is performed. The proposal creation program 153 determines whether or not a conflict proposal ID 512 corresponding to the patient ID of the target patient is present in the patient conflict table 183. If the determination result is true, the proposal creation program 153 filters the domain proposal identified from the conflict proposal ID 512, if any. The proposal creation program 153 determines whether a conflict proposal ID 522 corresponding to the proposal ID of the domain proposal exists in the proposal conflict table 182. If the determination result is true, the proposal creation program 153 filters the domain proposal if there is a domain proposal identified from the conflict proposal ID 522.

[0081] The correspondence between FIG. 15 and FIG. 6 is, for example, as follows: S1501 and S1502 in Figure 15 correspond to S611 in Figure 6. S1503 in Figure 15 corresponds to S612 in Figure 6.

[0082] FIG. 16 shows an example of a patient GUI.

[0083] Figure 16 The patient GUI 1600 displays general patient information 1601 , predicted risk information 1602 , risk reduction goal information 1603 , and proposal information 1604 .

[0084] The patient general information 1601 includes information such as the name, age, sex, and length of hospitalization of the target patient. The patient general information 1601 may also include characteristic values ​​of uncontrollable characteristics of the target patient. When the button 1611 is pressed, more detailed information of the target patient may be obtained from the history DB 160 and / or other DBs and displayed.

[0085] The predicted risk information 1602 represents the risk predicted for the subject patient using the prediction model 150 .

[0086] The risk reduction target information 1603 indicates the risk reduction target, that is, the risk and time constraints. When the button 1631 is pressed, the proposal creation program 153 displays a constraint setting GUI 1700, an example of which is shown in FIG.

[0087] The proposal information 1604 represents proposals for methods for achieving the risk reduction goals represented by the risk reduction goal information 1603, for each controllable feature. The proposals include at least one of generic proposals 1641 and domain proposals 1642. In the proposal information 1604, an arrow represents an action for each controllable feature. A downward arrow indicates a decrease in the feature value, and an upward arrow (not shown) indicates an increase in the feature value.

[0088] FIG. 17 shows an example of a constraint setting GUI 1700.

[0089] The constraint setting GUI 1700 has GUI components for inputting a risk constraint (e.g., a text box 1701 and an arrow button 1702) and GUI components for inputting a time constraint (e.g., a text box 1703 and an arrow button 1704). The constraint setting GUI 1700 accepts input of a risk constraint and a time constraint. When button 1705 is pressed after inputting at least one of the risk constraint and the time constraint, processing from S1102 onwards in FIG. 11 is performed, and the display may transition to the patient GUI 1600 illustrated in FIG. 16. The constraint setting GUI 1700 may also display a Cartesian coordinate system representing a time boundary, and a user-desired constraint (goal) may be input via the Cartesian coordinate system.

[0090] FIG. 18 shows an example of an alternative selection GUI.

[0091] The alternative selection GUI 1800 is displayed, for example, when the constraints input via the constraint setting GUI 1700 correspond to the unfeasible region 1500. In other words, the alternative selection GUI 1800 displays the calculated first to third alternative goal plans (the three alternative goal plans described with reference to FIG. 13) in a selectable manner.

[0092] When a radio button corresponding to one of the alternative goal proposals is designated and button 1803 is pressed, the patient GUI 1600 shown in Fig. 16 is displayed, and risk reduction goal information 1603 of the patient GUI 1600 is information representing the selected alternative goal proposal. Also, when button 1802 is pressed, the alternative goal proposal may be manually input.

[0093] For example, when information such as the name of a target patient is specified, the patient GUI 1600 may be displayed with the display fields for the risk reduction goal information 1603 and the proposal information 1604 blank, or an arbitrary risk reduction goal for the target patient (e.g., a goal selected in S1104 of FIG. 11 ) and a proposal identified for that risk reduction goal (e.g., a proposal obtained in S1108 of FIG. 11 or in FIG. 15 ) may be displayed in the patient GUI 1600. Furthermore, when a constraint is input via the constraint setting GUI 1700 or an alternative goal proposal is selected or input via the alternative selection GUI 1800, the risk reduction goal information 1603 in the patient GUI 1600 may be updated, and the proposal information 1604 may be updated to information representing a proposal for a method for achieving the risk reduction goal represented by the updated risk reduction goal information 1603.

[0094] Although one embodiment has been described above, these are merely examples for explaining the present invention, and the scope of the present invention is not limited to these embodiments. The present invention can be implemented in various other forms. For example, the risk is not limited to the probability of a patient's readmission, but may be other risks related to medical care or risks related to fields other than medical care (e.g., the probability of a product malfunction). In other words, the risk may be the probability of a defined event occurring. Furthermore, the entity is not limited to a patient, but may be a physical entity such as a product or equipment, or a logical entity such as a virtual machine. Furthermore, the user terminals may include a doctor's information processing terminal and a patient's information processing terminal. The domain DB 180 may be constructed by the doctor's information processing terminal, and a GUI such as the patient GUI 1600 may be provided to one or both of the doctor's information processing terminal and the patient's information processing terminal.

[0095] The above description can be summarized, for example, as follows: The following summary may include supplementary explanations and explanations of modifications of the above description.

[0096] The proposed system 100 includes an interface device 101 communicatively connected to a user terminal 110 (an example of an input / output console), a storage device 102 storing a prediction model 150 and a history DB 160 (an example of history data), and a processor 103 connected to the interface device 101 and the storage device 102. The prediction model 150 is a model that receives data including feature values ​​for multiple features related to a patient (an example of an entity) as input and outputs risk, and the history DB 160 includes patient data (an example of entity data) for each past point in time for each of multiple patients. For each patient, the patient data for a past point in time includes feature values ​​for each feature of the patient at that time.

[0097] The processor 103 acquires patient data similar to the target patient data, which is data including feature values ​​for each of a plurality of features related to the target patient (an example of a target entity), from the history DB 160. The processor 103 creates a proposal for changing the feature values ​​for each controllable feature among the plurality of features related to the target patient, based on statistics of a plurality of feature values ​​in related case data, which is data including patient data similar to the target patient data, to reduce the risk predicted by inputting the target patient data into the prediction model 150. The processor 130 provides the user terminal 110 with a patient GUI 1600 (an example of a UI) that displays the proposal created for the target patient.

[0098] In this way, suggestions are provided for how to change the feature values ​​for each controllable feature in the predictive model 150 to reduce the predicted risk, thereby providing a high feasibility of risk reduction. For example, statistical analysis using relevant case data can be performed to provide suggestions for reducing the predicted risk by considering all controllable features that may affect the risk.

[0099] For each controllable feature related to the target patient, the processor 103 classifies multiple feature values ​​in the related case data into a first distribution and a second distribution having a statistically higher risk value than the first distribution. If the relationship between the current feature value in the target patient data and the first distribution satisfies a first condition (e.g., S801: Yes) and the relationship between the first distribution and the second distribution satisfies a second condition (e.g., S802: Yes), the processor 103 may generate a proposal to bring the current feature value closer to the first distribution, that is, a proposal to decrease or increase the current feature value. This makes it possible to provide a proposal to decrease or increase the controllable feature value to reduce risk without requiring any particular domain knowledge. An example of the first distribution may be a low-risk distribution, and an example of the second distribution may be a high-risk distribution. The low-risk distribution may be a distribution of feature values ​​in patient data corresponding to low risk (risk lower than the predicted risk for the target patient). The high-risk distribution may be a distribution of feature values ​​in patient data corresponding to high risk (risk higher than the predicted risk for the target patient).

[0100] The processor 103 may generate a quantitative proposal for each controllable feature of the target patient, representing a time constraint and an increase or decrease in the feature value, based on a time boundary, which is a boundary that distinguishes between feasible and infeasible pairs of risk and time, and a risk reduction goal, which is a target for the extent and by when risk should be reduced. The patient GUI 1600 may display a quantitative proposal for each controllable feature of the target patient. This displays, for each controllable feature, how and by when the feature value should be changed to achieve the risk reduction goal, making it easier for the target patient to understand the actions they should take, thereby increasing the feasibility of risk reduction. Furthermore, because there is a time boundary, quantitative proposals can be provided, such as proposals for achieving risk reduction in the shortest possible time or proposals for achieving the largest possible amount of risk reduction.

[0101] When the processor 103 receives a specification of either a risk constraint, which is a risk target, or a time constraint, which is a time target, for the target patient (e.g., S1103: Yes), the processor 103 may determine that the other of the risk constraint and the time constraint is a time boundary constraint or a constraint in a feasible set. A pair of one constraint and the other constraint may be a risk reduction target. This allows for the setting of an appropriate risk reduction target in which the other constraint is determined to satisfy the specified one constraint to the extent possible.

[0102] When the processor 103 receives the specification of both a risk constraint, which is a risk target, and a time constraint, which is a time target, for the target patient (e.g., S1102: Yes), it may determine whether the pair of the risk constraint and the time constraint corresponds to either a time boundary or a feasible pair. If the result of the determination is true (e.g., S1106: Yes), the specified pair of the risk constraint and the time constraint may be a risk reduction target. This makes it possible to avoid setting an inappropriate risk reduction target that is impossible to achieve.

[0103] On the other hand, if the result of the determination is false (for example, S1106: No), the processor 103 creates one or more alternative goal plans and displays the alternative plan selection GUI 1800 displaying the one or more alternative goal plans on the user terminal 110. Provided to and may accept the designation of an alternative goal proposal, which is a selection of one or more alternative goal proposals (or manual input of an alternative goal proposal). The alternative goal proposal may be a goal proposal in which one and / or both of a pair of risk constraints and time constraints are changed so that they fall on a time boundary or are a feasible pair. The designated alternative goal proposal may be a risk reduction goal. In this way, when an unfeasible goal is designated, it is possible to provide a feasible alternative goal proposal by changing at least one of the risk constraint and the time constraint. The created alternative goal proposal may be at least one of a plan in which the specified time constraint is maintained but the risk constraint is changed, a plan in which the specified risk constraint is maintained but the time constraint is changed, and a plan in which both the time constraint and the risk constraint are changed.

[0104] The storage device 102 may store a domain DB 180 (an example of domain data). The domain DB 180 may include a proposal table 181 (an example of proposal data). The proposal table 181 may include data representing a domain proposal, which is a proposal of a specific method for realizing an action for each pair of a feature and an action, whether the action is to decrease or increase the feature value. If the proposal table 181 contains data representing a feature-action pair that matches the feature-action pair in the created proposal, the processor 103 may identify a domain proposal corresponding to the pair from the proposal table 181. If a domain proposal is identified among the created proposals, the patient GUI 1600 may display the identified domain proposal 1642. In this way, domain-based proposals can be added, for example, as options, to provide suggestions for specific actions to reduce risk. For example, if the created proposal includes a proposal to reduce the target patient's heart rate, a domain proposal regarding what medication to prescribe to reduce the heart rate is expected to be provided.

[0105] The domain DB 180 may include a proposal conflict table 182 (an example of proposal conflict data) that is data indicating, for each domain proposal, domain proposals that conflict with the domain proposal. For each identified domain proposal, the processor 103 may filter out, if a domain proposal that conflicts with the identified domain proposal is identified from the identified domain proposal based on the proposal conflict table 182. The patient GUI 1600 may display the domain proposals that remain unfiltered. This makes it possible to avoid providing another domain proposal that conflicts with the domain proposal.

[0106] The domain DB 180 may include a patient conflict table 183 (an example of entity conflict data) that is data representing, for each patient, domain proposals that conflict with the patient. If a domain proposal that conflicts with the target patient is identified from the identified domain proposals based on the patient conflict table 183, the processor 103 may filter the conflicting domain proposals. The patient GUI 1600 may display the domain proposals that remain unfiltered. This makes it possible to avoid providing domain proposals that conflict with the patient. [Explanation of symbols]

[0107] 100: Proposal System

Claims

1. an interface device communicatively connected to the input / output console; a storage device that stores the prediction model and historical data; a processor connected to the interface device and the storage device; Equipped with The prediction model is a model that receives data including feature values ​​of a plurality of features related to an entity as input and outputs a risk, the historical data includes entity data for each of a plurality of entities at each past point in time; For each entity, the entity data at the past time point includes feature values ​​at the past time point for each feature of the entity; The processor: acquiring entity data similar to the target entity data, which is data including each feature value of a plurality of features related to the target entity, from the history data; For each controllable feature among the plurality of features related to the target entity, a proposal for changing the feature value is created based on statistics of a plurality of feature values ​​in related case data, which is data including entity data similar to the target entity data, to reduce the predicted risk by inputting the target entity data into the prediction model; providing a UI (User Interface) on the input / output console for displaying the proposals made regarding the target entity; Suggestion system.

2. For each controllable characteristic associated with the target entity, the processor: classifying a plurality of feature values ​​in the related case data into a first distribution and a second distribution having a statistically greater risk value than the first distribution; When a relationship between a current feature value, which is a feature value in the target entity data, and the first distribution satisfies a first condition and a relationship between the first distribution and the second distribution satisfies a second condition, a proposal is made to bring the current feature value closer to the first distribution, the proposal being to decrease or increase the current feature value. The recommendation system of claim 1 .

3. the processor converts the created proposal into a quantitative proposal that represents a time constraint and an increase or decrease amount of a feature value for each controllable feature related to the target entity based on a time boundary that is a boundary that separates a feasible pair of pairs of risk and time into an unfeasible pair and a risk reduction target that is a target for how much and by when to reduce the risk; the UI displays quantitative suggestions for each controllable characteristic of the target entity; The recommendation system of claim 1 .

4. When the processor receives a designation of one of a risk constraint that is a risk target and a time constraint that is a time target for the target entity, it determines the other of the risk constraint and the time constraint to be a constraint on the time boundary or a constraint in the feasible set; The pair of the one constraint and the other constraint is the risk reduction goal. The proposal system of claim 3 .

5. When the processor receives designation of both a risk constraint, which is a risk target, and a time constraint, which is a time target, for the target entity, it determines whether a pair of the risk constraint and the time constraint falls on the time boundary or is one of the feasible pairs; If the result of the determination is true, the pair of the risk constraint and the time constraint is the risk reduction goal. The proposal system of claim 3 .

6. If the result of the determination is false, the processor: Develop one or more alternative goals; providing a UI displaying the one or more alternative goals to the input / output console; accepting a designation of an alternative goal, which may be a selection of one or more of the alternative goals or a manual input of an alternative goal; The alternative goal proposal is a goal proposal in which one and / or both of the pair of the risk constraint and the time constraint are changed so as to fall on either the time boundary or the feasible pair; the designated alternative goal is the risk reduction goal; The proposal system of claim 5 .

7. the storage device stores domain data; the domain data includes proposal data including data representing a domain proposal, which is a proposal of a specific method for realizing an action for each pair of a feature and an action, which is either a decrease or an increase of the feature value, for the feature; If the proposal data contains data representing a feature-action pair that matches a feature-action pair in the created proposal, the processor identifies a domain proposal from the proposal data that corresponds to the pair; If there is a domain proposal identified among the created proposals, the UI displays the identified domain proposal. The recommendation system of claim 1 .

8. The domain data includes, for each domain proposal, proposal conflict data that represents domain proposals that conflict with the domain proposal; For each of the identified domain proposals, if a domain proposal that conflicts with the identified domain proposal is identified from the identified domain proposals based on the proposal conflict data, filtering the conflicting domain proposal; The UI displays the domain suggestions that remain unfiltered. The proposal system of claim 7.

9. The domain data includes entity conflict data, which is data representing, for each entity, domain proposals that conflict with the entity; The processor, based on the entity conflict data, if a domain proposal that conflicts with the target entity is identified from the identified domain proposals, filters the conflicting domain proposal; The UI displays the domain suggestions that remain unfiltered. The proposal system of claim 7.

10. The computer acquires entity data similar to the target entity data, which is data including each feature value of a plurality of features related to the target entity, from the history data; the historical data includes entity data for each of a plurality of entities at each past point in time; For each entity, the entity data at the past time point includes feature values ​​at the past time point for each feature of the entity; a computer, for each controllable feature among a plurality of features related to the target entity, based on statistics of a plurality of feature values ​​in related case data, which is data including entity data similar to the target entity data, to input the target entity data into a prediction model, and creating a proposal for changing the feature values ​​to reduce the predicted risk; The prediction model is a model that receives data including feature values ​​of a plurality of features related to an entity as input and outputs a risk, The computer provides a UI (User Interface) that displays the created proposals related to the target entity. Proposal method.

11. Acquire entity data similar to the target entity data, which is data including each feature value of a plurality of features related to the target entity, from the history data; the historical data includes entity data for each of a plurality of entities at each past point in time; For each entity, the entity data at the past time point includes feature values ​​at the past time point for each feature of the entity; For each controllable feature among the plurality of features related to the target entity, a proposal for changing the feature value is created based on statistics of a plurality of feature values ​​in related case data, which is data including entity data similar to the target entity data, to reduce the predicted risk by inputting the target entity data into a predictive model; The prediction model is a model that receives data including feature values ​​of a plurality of features related to an entity as input and outputs a risk, providing a user interface (UI) for displaying the created proposals relating to the target entity; A computer program that causes a computer to do something.

Citation Information

Patent Citations

  • Health assistance device and health assistance program

    JP2022064113A

  • Healthcare Information Technology System for Predicting or Preventing Readmissions

    US20140207492A1

  • Patient data management systems and conversational interaction methods

    US20210259641A1

  • Machine learning techniques for generating hybrid risk scores

    US20220122736A1