Clinical decision support algorithm for fluid removal

Abstract

In one embodiment, a method is provided for a processor running a machine learning model, which includes receiving an input set including a measured urine volume and a time value indicating the remaining time from when a first measurement is performed until a target time to reach the target urine volume; using at least the measured value and the time value, the machine learning model predicts an estimated urine volume at the target time; compares the estimated urine volume at the target time with the target urine volume; and generates an alert regarding whether the target urine volume will be reached by the target time, based on a comparison of the target urine volume with the estimated urine volume predicted by the machine learning model. Related systems and computer program products are also provided.

Description

Technical Field

[0001] The subject matter described herein generally relates to machine learning for supporting clinical decisions regarding fluid removal from a patient.

Background Art

[0002] It is often necessary to collect fluids such as urine from a patient. For example, to collect urine from a patient, a urine collection bag may be coupled to a urinary catheter, such as a Foley catheter, that is inserted into the patient's bladder. The patient's urine output may be monitored along with other patient parameters. As a further example, a patient may be given a drug such as a diuretic. In this example, a caregiver can administer a diuretic to enable the patient to excrete a certain amount of urine. The patient can then be monitored, among other things, to evaluate the volume of urine excreted by the patient. During monitoring, if the patient is not excreting the expected amount of urine, the caregiver can reevaluate whether to administer an increased (or decreased) dose of the diuretic to the patient.

Summary of the Invention

[0003] A manufactured product is provided that includes a system, a method, and a computer program product for predicting urine output. In one aspect, a method is provided that includes receiving, in a processor executing a machine learning model, an input set that includes a measured value of urine output and a time value indicating the remaining time from when a first measurement was performed until a target time by which a target urine output should be reached; predicting, by the machine learning model, an estimated urine output at the target time using at least the measured value and the time value; comparing the estimated urine output at the target time with the target urine output; and generating an alert regarding whether the target urine output will be reached by the target time based on a comparison between the target urine output and the estimated urine output predicted by the machine learning model.

[0004] In some variations, one or more of the features disclosed herein, including the following, may be included in any feasible combination: Receiving further includes receiving multiple input sets corresponding to multiple voiding volumes and multiple time values ​​until a target time to reach a target voiding volume. Predicting the estimated voiding volume is performed after a set of threshold volume inputs has been received by the machine learning model. The voiding volume measurements indicate urine volume or urine weight. Urine is collected via a Foley catheter over a time interval. The input sets include the total voiding volume at the measurement time, the average voiding volume per hour at the measurement time, the standard deviation of the voiding volume per hour at the measurement time, the average voiding volume per hour during the second half of the urine monitoring session, the voiding volume per hour, the elapsed time from the start of the urine monitoring session, and / or the time remaining until the target time. The target time and target voiding volume are set via a user interface and provided to the processor. The machine learning model includes a gradient boosting regression tree machine learning model. The machine learning model is trained, and / or the training is based at least on nonparametric statistical learning. The machine learning models include linear regression machine learning models, random forest machine learning models, neural network machine learning models, gradient boosting regressor machine learning models, and / or Kalman filters. Alerts are provided on the display to indicate whether the target voiding volume will be reached by the target time. Alerts are used to evaluate whether to change the dosage of medications that affect voiding volume. Comparisons are performed by comparison logic and / or machine learning models. The machine learning models include an ensemble of machine learning models. The ensemble of machine learning models includes a first machine learning model that predicts the first quantile of the first estimated voiding volume at the target time, a second machine learning model that predicts the second quantile of the second estimated voiding volume at the target time, and a third machine learning model that predicts the third quantile of the third estimated voiding volume at the target time, where the first estimated voiding volume, the second estimated voiding volume, and the third estimated voiding volume provide confidence intervals for the estimated voiding volume at the target time.The comparison involves comparing the first estimated urine volume, the second estimated urine volume, and the third estimated urine volume with the target urine volume. The machine learning model is incorporated into the urine collection system, coupled to the urine collection system via a wired or wireless connection, and provided as a service to one or more urine collection systems.

[0005] Implementations of this subject matter may include systems and methods consistent with the descriptions provided herein, as well as articles comprising a tangibly embodied machine-readable medium capable of operating in one or more machines (e.g., a computer) to produce an operation that implements one or more of the features described herein. Similarly, computer systems may include one or more processors and one or more memories coupled to one or more processors. Memories, which may include non-temporary computer-readable or machine-readable storage media, may contain, encode, store, or similarly contain one or more programs causing one or more processors to perform one or more of the operations described herein. Computer implementations consistent with one or more implementations of this subject matter may be implemented by one or more data processors residing in a single computing system or multiple computing systems. Such multiple computing systems may be connected to one or more by one or more connections, including, for example, connections via a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, etc.), direct connections between one or more of the multiple computing systems, and may exchange data and / or commands or other instructions, etc.

[0006] Details of one or more modifications of the subject matter described herein are given in the accompanying drawings and in the following description. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, as well as from the claims. Certain features of the subject matter of this disclosure are given for illustrative purposes in relation to the stratification of sepsis patients, but it should be readily understood that such features are not intended to be limiting. The claims following this disclosure are intended to define the scope of the subject matter protected. [Brief explanation of the drawing]

[0007] The accompanying drawings incorporated herein and constituting part thereof illustrate specific aspects of the subject matter disclosed herein and, together with the description, help to illustrate some of the principles relating to the disclosed implementations. In the drawings,

[0008] [Figure 1] Figure 1 shows examples of plots of dose intensity administered to patients over time, according to several embodiments.

[0009] [Figure 2A] Figure 2A shows examples of urine collection systems according to several embodiments;

[0010] [Figure 2B] Figure 2B shows examples of user interfaces that may be presented to set the total urination volume at a target time, according to several embodiments.

[0011] [Figure 3A] Figure 3A is a block diagram showing an example of a machine learning processor according to several embodiments.

[0012] [Figure 3B] Figure 3B shows examples of user interfaces in several embodiments that include alerts regarding whether the patient's urine output reaches the target total urine output within a given time. [Figure 3C]FIG. 3C shows an example of a user interface including an alert regarding whether a patient's urine output reaches the total urine output at a target time according to some embodiments. [Figure 3D] FIG. 3D shows an example of a user interface including an alert regarding whether a patient's urine output reaches the total urine output at a target time according to some embodiments.

[0013] [Figure 4] FIG. 4 is a block diagram showing an example of an input feature set provided to a machine learning model according to some embodiments.

[0014] [Figure 5] FIG. 5 depicts a plot of predicted urine output over time according to some embodiments.

[0015] [Figure 6A] FIG. 6A is a block diagram showing an example of training a machine learning model according to some embodiments.

[0016] [Figure 6B] FIG. 6B is a block diagram showing an example of an ensemble of machine learning models according to some embodiments.

[0017] [Figure 7] FIG. 7 depicts a flowchart illustrating an example of a process for machine learning-based prediction of urine output according to some embodiments.

[0018] [Figure 8] FIG. 8 is a block diagram showing an example of a computing system according to some embodiments.

[0019] In practical cases, like reference numerals indicate like structures, features, or elements.

DETAILED DESCRIPTION OF THE INVENTION

[0020] Patients administered diuretics may be monitored, in particular, to assess the amount of urine excreted by the patient. Urine volume may be used by caregivers when assessing whether to increase (or decrease) the diuretic dosage for the patient.

[0021] Figure 1 shows an example of a time-course plot of dose intensity administered to a patient. In this example, the patient receives a diuretic dose at time T1102. The patient is monitored over time 104, such that monitoring includes measuring urine volume and / or symptoms of dyspnea. During monitoring, the caregiver predicts that the patient is not excreting an adequate amount of urine and, as a result, increases the diuretic dose at 106A-C. At 106D-E, the caregiver predicts that the patient is excreting an adequate amount of urine and, therefore, there is no change in the diuretic dose for the fourth and fifth doses. At 106F, the caregiver predicts that the patient has excreted an excess of urine and, as a result, the diuretic dose is reduced for the sixth dose at 106F. Figure 1 illustrates an example of how difficult it can be for a caregiver to predict whether a patient is excreting an adequate amount of urine during a treatment session.

[0022] In some embodiments, a machine learning (ML) model is provided that is configured to predict whether a patient will reach a target volume of urine output at a target time. For example, the prediction may be used by a caregiver to determine whether to change the dosage of diuretics (e.g., whether to increase, decrease, or keep it the same).

[0023] Figure 2A shows examples of urine collection systems 200 according to several embodiments. A caregiver may use the urine collection system to collect, measure, and / or monitor urine collected from a patient over time. For example, the urine collection system may include a urine collection bag 202 which can be connected to the patient's bladder via a catheter such as a Foley catheter. The urine collection bag may be physically connected to the urine collection system (e.g., via a ring 204) to allow the volume of collected urine to be determined over time. Once the bag 202 is suspended from the ring 204, the weight of the urine in the bag may be measured by the urine collection system from time to time, such as at 15-minute time intervals (or other time intervals including 1 minute, 5 minutes, 10 minutes, 30 minutes, 45 minutes, etc.). The measured weight can then be converted to volume (e.g., the volume of urine is equal to the urine weight divided by the urine density). The amount of urine a patient may be stored in at least the urine collection system's database as part of the patient's electronic medical record (EMR) information, and / or transmitted (via wireless and / or wired links) to a database where the patient's EMR information is stored.

[0024] Some examples refer to the amount of collected urine evaluated in terms of urine volume, but the amount of collected urine can also be evaluated in terms of other aspects, such as weight.

[0025] Figure 2A further illustrates the processor 210, including a display 212 (e.g., a touchscreen display, or other type of display that presents one or more user interfaces to enable interaction with the user). The display may present a user interface that depicts the current urine volume (e.g., 47 ml for the current time), past urine volumes (e.g., 55 ml for the previous time, 50 ml for 2 hours ago, and 65 ml for 3 hours ago), the bag's fill percentage (e.g., 50%), and / or other parameters associated with the urine collection monitoring and / or monitored patient. For example, diuretic dosage, dosage administration time, urine temperature, patient's body temperature, total amount of urine excreted by the patient by a certain time, and / or other information, alerts, and / or similar.

[0026] During operation, the processor 210 may present a user interface 230 as shown in Figure 2B. The user interface 230 may include user interface elements that can be selected to set the total amount of urine to be excreted by the patient by a certain target time (GT) ("Target Excretion Volume", TUV). For example, the user interface 230 may include user interface elements 232A corresponding to predetermined target excretion volumes such as 500 ml, 750 ml, 1000 ml, 1250 ml, 1250 ml, 1500 ml, 1750 ml, 2000 ml, 2500 ml, and / or other values. For example, if a caregiver selects one of the user interface elements corresponding to a predetermined excretion volume, such as 1000 ml, the selected excretion volume indicates to the processor 210 that the Target Excretion Volume (TUV) of the monitored patient is 1000 ml. Alternatively or additionally, the user interface 230 may include a user interface element 232B having a customizable TUV. For example, when user interface element 232B is selected via the touchscreen display 212, the selection allows for the input of a “custom” TUV not listed under a predetermined urination volume value 232A.

[0027] Furthermore, the user interface 230 may include user interface elements 234A-C that allow setting a target time (GT). In the example in Figure 2B, the target time is set to, for example, 6 hours 234C, but other times can be set similarly (e.g., 12 hours, 24 hours, or other times). Furthermore, the set 6-hour monitoring period can be scheduled to a given time, such as "start now" 234B (e.g., when "today" 234A and "now" 234B are selected), or to other scheduled times (e.g., when scheduled via start dates and times set in user interface elements 234F and 234G, respectively). Thus, the TUV of the patient being monitored in this example is 600 mL with a 6-hour GT.

[0028] The previous example describes a monitoring session configured to monitor the patient's total urine output 231A at a target end time of, for example, 6 hours 234C. Alternatively, or additionally, the caregiver may select a target type every hour (for example, for each hour) by selecting a user interface element 231B. In other words, the target urine output (TUV) is relative to the target time (GT) of one hour, which can be repeated for at least one hour. For example, if 100 mL is selected for the target type per hour 234B and the target end time of 6 hours 231C (for example, as a custom selection in 232B), the target urine output after 6 hours would be 600 mL. In this example, an alert may be generated if the patient's TUV at each hour falls below the target of 100 mL.

[0029] Furthermore, the user interface 230 may include user interface elements 240 where alerts can be configured. For example, an alert configuration may include the conditions under which an alert should be sent (e.g., the patient does not reach the TUV by the GT), the type of alert (e.g., email, voice, haptic, visual, SMS, etc.), and / or the recipient of the alert (e.g., primary caregiver, nurse on duty, etc.).

[0030] Referring again to Figure 2A, according to some embodiments, the urine collection system 200 may be coupled via a link 252 (e.g., a wired link, a wireless link, a network, the Internet, and / or a bus) to a machine learning (ML) processor 250 including a machine learning model 310. The ML processor including the ML model may be configured to predict whether the patient will reach TUV by GT (e.g., selected in the user interface 230 and provided to the ML processor 250 via link 252) and to output indications such as alerts regarding whether the patient will reach TUV by GT.

[0031] The ML processor 250 may be contained in a separate device, such as a processing device, which includes at least one high-speed processor configured to run an ML model. Examples of high-speed processors include graphics processing unit (GPU) chips, ML (or artificial intelligence) chips, etc. Alternatively or additionally, the ML processor may be provided as a service to one or more urine collection systems (e.g., a cloud service, a web service, etc.). For example, one or more urine collection systems may access (e.g., share) a single ML processor (e.g., via a wired link, a wireless link, a network, the internet, and / or a bus). Alternatively or additionally, the ML processor may be contained in the processor 210 of the urine collection system 200 (e.g., as a separate chip (or chipset) that shares processing resources with other functions provided by the urine collection system and / or provides ML resources to the urine collection system).

[0032] Figure 3A shows examples of implementations of the ML processor 250 according to several embodiments. The ML processor 250 may include an ML model 310 and comparison logic 312. The ML model can be trained (and configured) to predict the amount of urine a patient will produce at one or more time points, such as GT.

[0033] During operation, the ML model 310 may receive patient voiding volume information 315A (e.g., measured voiding volume) and time information 315B (e.g., time remaining until GT) as inputs. For example, the urine collection system 200 may provide a set of inputs 315A-315B to the ML processor 250 via link 252. In response to the received inputs 315A-315B, the ML model may provide an output 317 indicating the predicted voiding volume (e.g., urine volume or weight) at a specific time, such as the target time (GT). To illustrate further, the urine collection system 200 may provide inputs 315A-315B including one or more measured (e.g., observed) voiding volume values ​​and one or more corresponding time remaining until the target time. For example, inputs 315A to 315B may include the first measurement of total urination volume of 100 mL and the remaining 5 hours from the first measurement until the target time, the second measurement of total urination volume of 150 mL and the remaining 4 hours from the second measurement until the target time, the third measurement of total urination volume of 250 mL and the remaining 3 hours from the third measurement until the target time, and so on.

[0034] As a further example, the ML model 310 may receive from the urine collection system 200 a urine volume value for the current period (e.g., the second hour of a 6-hour monitoring session) as input 315A, and receive an indication that 4 hours remain until the target time GT from the time the urine volume measurement was performed. In this example, the ML model 310 may generate output 317 containing the predicted urine volume at GT. The ML processor 250 (e.g., comparison logic 312) may then compare the output 317 of the predicted urine volume at GT with a threshold such as TUV set for GT (e.g., set via the user interface 230 in 232A). Referring to the previous example of a TUV of 600 mL at 6 hours GT, the ML model may predict a TUV of 111 mL at 6 hours GT, which is below the threshold of 600 mL at 6 hours. In this example, the ML processor (or, for example, the comparison logic 312) outputs an indication that the predicted urination volume (111 mL in this example) will be less than the set TUV (600 mL in this example) at GT (6 hours in this example) (320).

[0035] Figure 3A shows the comparison logic 312 within the ML processor 250, but the comparison logic may be contained in other processors, such as the processor 210 of the urine collection system 200.

[0036] Figure 3B shows another example of the user interface 330, including a subtarget user interface element 332 indicating that the patient's predicted urination volume falls below the TUV at GT. Referring to the previous example where the predicted urination volume falls below the set TUV at GT, the output 320 of the ML processor 250 may trigger or cause the subtarget user interface element 332. Furthermore, the subtarget user interface element 332 may trigger other alerts (e.g., haptic, audio, email, SMS message) to re-evaluate whether the dosage to the patient should be adjusted, for example, by signaling a caregiver (in this example, it may suggest increasing the diuretic). The user interface 330 may be presented on a display such as the touchscreen display 212 on the processor 210. Alternatively or additionally, the user interface 330 (and / or the subtarget user interface element 332) may also be presented (or provided) on other devices.

[0037] Figure 3C shows another example of the user interface 340, including a goal-following user interface element 342 that indicates the patient's predicted voiding volume is likely to reach TUV at GT. For example, the output 320 of the ML processor 250 may indicate that the patient is being tracked, and therefore the patient's predicted voiding volume is likely to reach TUV at GT. In this case, the output 320 of the ML processor 250 may trigger or cause the goal-following user interface element 342. In this example, the caregiver may consider not changing the current dosage of the diuretic. The goal-following user interface element 342 may trigger other alerts (e.g., haptic, audio, email, SMS message) to notify the caregiver. The user interface 340 may be presented on a display, such as a touchscreen display 212 on the processor 210. Alternatively or additionally, the user interface 340 (and / or the goal-following user interface element 342) may also be presented (or provided) on other devices.

[0038] Figure 3D shows another example of the user interface 350, including a target user interface element 352 indicating that the patient's predicted voiding volume exceeds the TUV at GT. For example, if the patient's predicted voiding volume exceeds the TUV at GT by only a threshold voiding volume, the output 320 of the ML processor 250 may indicate that the patient is above target or significantly above TUV. In this case, the output 320 of the ML processor 250 may trigger or cause the target user interface element 352 described above. The target user interface element 352 may also trigger other alerts (e.g., haptic, audio, email, SMS message) to prompt the caregiver to reassess whether the patient's dosage should be adjusted (in this example, it may suggest reducing the diuretic). The user interface 350 may be presented on a display such as the touchscreen display 212 on the processor 210. Alternatively or additionally, the user interface 330 (and / or the target user interface element 352 described above) may also be presented on (or provided to) other devices.

[0039] The previous example illustrated the use of only two inputs 315A-B to the ML model 310 to enable predicted voiding volume 317, but other types and / or quantities of inputs may also be used. In some embodiments, the inputs may include one or more of the following: total voiding volume during the measurement (or observation) time, average voiding volume per hour during the observation time, standard deviation of voiding volume per hour during the observation time, voiding volume during the last (or previous) time, elapsed time since the start of monitoring by the urine collection system, and time remaining until GT. These inputs may also be called features, input sets, or input feature sets. Furthermore, the inputs may be calculated from voiding volume measurements collected over time for the patient (e.g., average hourly voiding volume, standard deviation, etc.).

[0040] Figure 4 shows an exemplary implementation configuration that includes input 410, such as the total amount of urine voided during the observation period (total_uo_at_obs_time), the average amount of urine voided per hour during the observation period (avg_hourly_uo_at_obs_time), the average amount of urine voided per hour during the second half of the patient's session (avg_hourly_uo_second_half), the standard deviation of the amount of urine voided per hour during the observation period (sd_hourly_uo_at_obs_time), the amount of urine voided in the last (or previous) hour (last_hour_uo), the elapsed time since the start of monitoring by the urine collection system (elapsed_time), and the time remaining until GT (time_remaining). During operation, input 410 may be provided to the ML processor 250 by the urine collection system 200. Alternatively, or additionally, the urine collection system 200 may provide so-called raw data including a urine observation (or measurement) of a given patient and corresponding time information (e.g., a timestamp when the weight or volume of the urine measurement was performed), in which case a processor such as the ML processor 250 or another processor may preprocess the raw data to determine and / or provide the input 410. In response to the input 410, the ML model 310 (to be trained) generates an output 320 indicating whether the void volume is below, equal to, or above a set TUV in GT.

[0041] In the example in Figure 4, input 410 contains information about urination volume, such as the current urination volume (e.g., the total amount of urination during the measurement or observation time, such as total_uo_at_obs_time) and past urination volume information (e.g., the amount of urination during the previous or last time, such as last_hour_UO). Input 410 may also include time information, such as elapsed time and time remaining until GT. Furthermore, the rows of inputs shown in the diagram are sometimes called an input set or feature set because all of these inputs 410 are associated with the same measurement or observation. For example, if another measurement is taken, another (or second) input row may be provided in 410 as an input or feature set.

[0042] In some embodiments, a processor such as the ML processor 250, the urine collection system 200, and / or other processors may determine a range or confidence interval for the predicted urine volume. The confidence level may be set via a user interface, such as through the selection of a user interface element 230 in Figure 2B. Alternatively or additionally, the range or confidence interval may be provided as a default value (which may or may not be modified by the caregiver). Furthermore, in some embodiments, comparison logic may be incorporated into the ML model 310, in which case the ML model infers an indication 320.

[0043] Figure 5 shows plots of observed urination volume 510 (e.g., solid lines representing actual measurements from the urine collection system 200) and predicted urination volume 512 (e.g., dashed lines representing predictions from the ML model 310) over time. In this example, the ML model may predict the total urination volume at target time 504 at time 502. The prediction may include a confidence interval (or range) 506. In some embodiments, the confidence interval may be set via the user interface, such as via a user interface element in the user interface 230. Alternatively, or additionally, the confidence interval may be set as a default. As a further example, the confidence interval 506 may indicate that there is a 70% probability that the predicted urination volume at 512A falls within the range 506 defined by a high value 512B and a low value 512C. In some embodiments, the ML model 310 may provide a predicted total void volume (TUV) output 512A at a target time (GT), as well as predictions for high void volume 512B and low void volume 512C, in which case the comparison logic 312 may be used to process 512A-C and determine an indication 320 that the patient has reached TUV by GT. In the example in Figure 5, the range 506 (or confidence interval) also indicates that there is a 15% probability that the predicted void volume will be below the low void volume value 512C and a 15% probability that the predicted void volume will be above the high value 512B. In the example in Figure 5, the predicted void volume 512A (and even the high void volume 512B) is below TUV 520 at GT in 504. In this example, an alert (or output in 320) may be set to trigger when the patient's void volume falls below TUV 520 when the predicted high void volume 512B falls below TUV 520. Alternatively, or additionally, an alert (or output in 320) may be configured to trigger when the patient's urination volume falls below TUV520, where the predicted urination volume 512A falls below TUV520, but the predicted high urination volume 512B does not fall below TUV520. In some embodiments, a confidence interval may be used to determine whether to trigger an alert that the patient will not reach TUV.

[0044] Referring again to Figure 3A, the ML model 310 may include at least one ML model that is trained to predict for a patient whether the patient's urine volume will reach TUV at GT, and is therefore configured in that manner. In some embodiments, the ML model may include a gradient boosting regression tree. In the case of a gradient boosting regression tree (also called gradient boosting), the ML model uses a nonparametric statistical learning technique for classification and regression. A nonparametric learning model (e.g., k-nearest neighbors) does not depend on a specific parameter setting to make predictions. Alternatively, or additionally, the ML model 310 may include one or more of the following: linear regression, random forest, neural network, gradient boosting regressor, and Kalman filter.

[0045] In some implementations, raw patient data may be preprocessed before use in ML model training (and ML model inference). For example, void volume (UO) observations measured by the urine collection system 200 (or from other sources or databases of UO observations) may be formatted and / or stored in a database in tabular form, as shown in Table 1 below. In this example, Table 1 shows void volume (UO) observations in units defined by "charttime" (representing a timestamp when the UO observation was made), "storetime" indicating the encounter or monitoring session with the subject, "itemid" indicating the corresponding subject, and "valueuom" which in this example is milliliters (mL).

[0046] [Table 1]

[0047] For ML model training, the so-called raw data in Table 1 may be preprocessed as described above. For example, preprocessing may filter the raw data for (1) patients from, for example, the intensive care unit, (2) patients who received at least one diuretic administration during hospitalization, (3) patients with a Foley catheter, (4) patients with at least 24 hours of voiding volume measurements, and / or (5) patients who had at least one voiding volume measurement per hour during the first 24 hours of hospitalization. This preprocessing is performed on the ML training data to facilitate the training process and remove patient data for patients who do not have a consistent documentation of voiding readings. In other words, preprocessed filtered data should not be used for training. For example, in one embodiment, the training set included a training dataset of 4155 unique patient stays, but training datasets of other sizes may also be used.

[0048] Alternatively, or additionally, the process may also include generating inputs to the ML model 310, such as inputs 315A-B or 410. As mentioned above, these inputs are also called features. For example, a feature set (or input to the ML model) may include one or more of the following inputs (or features): • Total urination volume at observation time: Total urination volume is the total volume in milliliters of urine urinated by the patient from the start of diuretic therapy until the time of prediction. • Average hourly urination volume (avg_hourly_uo_at_obs_time): Average hourly urination volume is the average amount of urine urinated per hour from the start of diuretic therapy. • Average hourly urination during the second half of the stay: This represents the average hourly urination during the second half of the diuretic session (for example, in a 4-hour session, the average hourly urination during the last 2 hours). • Standard deviation of hourly urination volume sd_hourly_uo_at_obs_time: This is the standard deviation of the patient's hourly urination volume. • Last hour's urine output: This is the amount of urine the patient urinated in the most recent hour. • Elapsed_time: This is the number of hours since the start of diuretic therapy. • Remaining time: This is the time until the finish time.

[0049] To illustrate further, features can be determined from urine observation and time information (for example, the mean and standard deviation of hourly voiding volume can be calculated from so-called raw data of the patient's urine observation and time information). The use of one or more (but not all) of the mentioned features may provide a better prediction of whether the patient's voiding volume will reach the target voiding volume by the target time, compared with other types of feature sets. In the case of the average voiding volume per hour in the latter half of the stay, this feature can provide a useful indicator of the patient's urinary trajectory when compared with initial measurements when the patient first starts a diuretic session and is being monitored by the urine collection system 200. Furthermore, in some embodiments, the ML processor 250 may prohibit prediction until after a threshold time or voiding volume measurement to help ensure accurate prediction. For example, the ML processor may consist of threshold volume measurements (e.g., four voiding volume measurements over one hour) before enabling the prediction 317 and output indication 320 regarding TUV in GT.

[0050] After the features have been determined and / or computed, training data 610, as shown in Figure 6A, may be provided to ML model 310 to train the ML model. In this example, each row of the training data represents a patient's stay (e.g., an ICU patient's stay) with the corresponding column of the features described above. For supervised or semi-supervised learning of the ML model, the training data may include labels for each row that indicate a predicted outcome (e.g., an indication of whether the predicted voiding volume at the target time and / or whether the total voiding volume is reached at GT). For supervised or semi-supervised learning of the ML model, the ML model adjusts its configuration (e.g., weights) until it learns to produce predicted outcomes given input features (e.g., converges). After training ML model 310 in Figure 6A, the ML model may be used to perform inference (e.g., perform predictions 317 about TUV at GT and output indications 320) using new input data from patient urine observation information (e.g., 315A-B / 410).

[0051] In some embodiments, the ML model 310 may include an ensemble of multiple ML models. For example, the ML model 310 may include three ML models. For example, a first ML model is trained to provide a lower voiding volume prediction, such as 512C. A second ML model is trained to provide a middle voiding volume prediction (e.g., 512A), and a third ML model is trained to provide a high voiding volume prediction, such as 512B. In this way, the ensemble can provide a range 506 (e.g., a confidence interval) of predicted voiding volumes, rather than a single-point prediction of voiding volume. For example, instead of predicting a single voiding volume (e.g., voiding volume 512A), the ensemble of ML models provides a predicted confidence interval or range 506. In some embodiments, the three ML models include three gradient-boosted regression tree models or three random forest models, but other types of ML models may also be used.

[0052] In some embodiments, the first ML model may be trained to provide predictions for lower percentile marks of expected voiding volume. For example, the first model may provide a lower voiding volume prediction 512C, which may correspond to lower percentiles in the range such as lower 10%, 15%, 20%, 25%, or other values ​​in the lower interval. At the 20% lower percentile, approximately 80% of the predictions made by the ML model will be higher than the lower interval predictions. Similarly, the third ML model may provide a higher voiding volume prediction 512B, which may correspond to higher percentiles in the range such as lower 90%, 85%, 80%, 75%, or other values ​​in the higher interval. At the 80% higher percentile, 80% of the voiding volume predictions will be lower than the upper interval mark. In this configuration of confidence intervals, if the ML processor predicts that the patient will not meet the total voiding volume by the target time, in this example, there is an 80% chance that the time will be correct. Figure 6B shows an exemplary implementation of ensemble ML models 625A–C, each providing a low-prediction 640A, a medium-prediction 640B, and a high-prediction 640C. Outputs 640A–640C may be coupled to comparison logic (e.g., comparison logic 312) that compares outputs 640A–C to TUV and outputs an indication (e.g., output 320) about whether the TUV output is reached in GT. Figure 6B shows an ensemble of three ML models, but other quantities of ML models may be used in the ensemble.

[0053] As described above, the ML model 310 (or ensemble) can be trained (e.g., in the training phase) using raw data filtered as described above from a large set of patients. For example, the ML model 310 may be initially trained using data from a large general database of patient data and filtered as described above with respect to (1) to (5). Alternatively or additionally, the ML model training data may include data obtained from observations provided by one or more urine collection systems 200.

[0054] During the training phase of ML model 310, the ML model may consume training data, which may be a relatively large amount of data. The training data may be characterized as labeled data that indicates "known" information about the training data. During training, the ML model learns (constructs itself) to predict an output (which is known or labeled) based on the input. Specifically, the ML model learns how to predict void volume levels by taking in the training data. This training data may be similar to the training data 610 shown in Figure 6A from multiple patients whose void volume (UO) in milliliters is known. In the case of the ensemble ML model described above, the lower, middle, and upper models use the alpha-quantile regression function:

number

[0055] Once the ML model is trained, it can then be used (in the inference phase) to predict the void volume at a target time (GT) for at least one patient, as described above. For example, the trained ML model can predict the void volume at GT for at least one patient (whose void volume measurement data is so-called "new" data and therefore not part of the training data), as described above with respect to Figures 2A, 3A, and 4.

[0056] Figure 7 shows a flowchart illustrating an example of Process 700 for using ML to predict whether a patient's urine output will reach the target urine output (TUV) in the target time (GT).

[0057] In 702, the process may include receiving an input set in a processor running a machine learning model, which includes a measured urine volume and a time value indicating the remaining time from when the first measurement was taken until the target time to reach the target urine volume. For example, an ML processor 250 containing an ML model 310 (trained on training data to predict urine volume at a target time) may receive a first measured urine volume over at least a first time interval. For example, the input set may correspond to the total urine volume at the observation time (see, e.g., total_uo_at_obs_time above), or some other value indicating the patient's observation / measurement of urine collected via a Foley catheter and measured by the urine collection system 200. Furthermore, the time value indicating the remaining time until the target time (GT) to reach the target urine volume may correspond to the remaining time until the target time is reached (see, e.g., time_remaining). Referring to the example in Figure 4, the measured value may correspond to 1255.0 ML and the time value may correspond to 4 hours. While this example refers to two inputs, the ML model may also receive other values ​​as part of its input feature set, such as the average hourly urination volume during the measurement period, the standard deviation of hourly urination volume during the measurement period, the average hourly urination volume during the second half of the urination volume monitoring session, the urination volume in the previous hour, and the elapsed time since the start of the urination volume monitoring session.

[0058] In 704, the process may, according to several embodiments, include predicting the estimated urination volume at a target time using a machine learning model and at least measured and time values. For example, the ML model 310 may generate a prediction of the estimated urination volume as described above with respect to 317 in Figures 3A and 4.

[0059] In 706, the process may include comparing the estimated urination volume at the target time with the target urination volume. For example, the estimated urination volume 317 (predicted by the ML model 310) may be compared with the target urination volume. This comparison may be performed by comparison logic 312. Alternatively, or additionally, the comparison may be performed by the ML model.

[0060] In 708, the process may include generating alerts regarding whether the target urination volume will be reached by the target time, based on a comparison of the target urination volume with an estimated urination volume predicted by a trained machine learning model. For example, the estimated urination volume 317 predicted by the ML model 310 may be compared to a target urination volume (which may be set for the patient via a user interface such as the user interface 230). In the examples in Figures 3A and 4, the comparison logic 312 performs this comparison. If the comparison indicates, for example, that the estimated urination volume value is smaller than the target urination volume value at the target time, an alert is generated (indicating that the target urination volume at the target time will not be reached). An example of a below-target alert is shown in 332 in Figure 3B. If the comparison indicates, for example, that the estimated urination volume estimate is greater than the estimated target urination volume at the target time, an alert is generated (indicating that the target urination volume at the target time will be exceeded). An example of an over-target alert is shown in 352 in Figure 3D. Then, if the comparison indicates that the estimated urination volume value will reach the target urination volume value at the target time, an alert is generated, for example, indicating that the target urination volume is on track. An example of a target on track alert is shown in Figure 3C, 342. Alternatively, or additionally, alert generation can be performed by an ML model.

[0061] In some embodiments, the ML processor 250 may generate an indication 320 after threshold quantity input information 315A~B (and / or 410) has been received and processed by the ML model 310. For example, the ML processor 250 may require a minimum amount of patient urination volume measurement before making predictions in 317 and / or 320.

[0062] In some embodiments, receiving in 702 further includes receiving multiple input sets corresponding to multiple voiding volumes, each of which includes a corresponding time value to a target time to reach a target voiding volume. As shown in the example in Figure 4, an input row (410 or part thereof) may include a first input set, while another measurement / observation may provide a second input set. For example, the first input set may include the total voiding volume at the measurement time, the average voiding volume per hour at the measurement time, the standard deviation of the voiding volume per hour at the measurement time, the average voiding volume per hour during the second half of the urine monitoring session, the voiding volume in the previous hour, the elapsed time since the start of the urine monitoring session, and / or the time remaining to the target time, while the second input set may correspond to these values ​​for another measurement / observation of the patient.

[0063] In some embodiments, predicting the estimated urination volume is performed after a threshold amount of the input set has been received by the machine learning model. As described above, the ML model may be prohibited from making its prediction until a threshold amount of input is provided.

[0064] Figure 8 is a block diagram showing an example of a computing system 800 according to several embodiments. The computing system 800 may be used (at least in part) to provide one or more of the following embodiments: including a processor 210, an ML processor 250, an ML model 310, and a comparison logic 312.

[0065] As shown in Figure 8, the computing system 800 may include a processor 810, memory 820, storage device 830, and input / output device 840. The processor 810, memory 820, storage device 830, and input / output device 840 can be interconnected via a system bus 850. The processor 810 can process instructions for execution within the computing system 800. Such executed instructions may implement, for example, one or more components of the patient stratification system 100 and / or equivalent. In some implementations of the subject matter of the present invention, the processor 810 may be a single-threaded processor. Alternatively, the processor 810 may be a multi-threaded processor. The process may be a multi-core processor or a single-core processor having multiple processors. The processor 810 can process instructions stored in memory 820 and / or storage device 830 to display graphic information for a user interface provided via the input / output device 840. Memory 820 is a computer-readable medium, such as volatile or non-volatile, for storing information within the computing system 800. Memory 820 can store, for example, a data structure representing a configuration object database. Storage device 830 can provide persistent storage for the computing system 800. Storage device 830 may be a floppy disk drive, a hard disk drive, an optical disk drive, a tape drive, or other suitable persistent storage means. Input / output device 840 provides input / output operation for the computing system 800. In some implementations of the subject matter of the present invention, the input / output device 840 includes a keyboard and / or a pointing device. In various embodiments, the input / output device 840 includes a display unit for displaying a graphical user interface. According to some implementations of the subject matter of the present invention, the input / output device 840 can provide input / output operation for a network device.For example, the input / output device 840 may include an Ethernet® port or other networking port for communicating with one or more wired and / or wireless networks (e.g., a local area network (LAN), a wide area network (WAN), or the Internet).

[0066] Taking into consideration the above-mentioned implementation forms of the subject matter, the application discloses the following list of examples, where any further examples that fall within the disclosure of the application include one feature of a single example, or two or more features of such examples taken in combination, and optionally in combination with one or more features of one or more further examples.

[0067] Example 1. A method comprising: a processor running a machine learning model receiving an input set including a measured urine volume and a time value indicating the remaining time from when a first measurement is performed until a target time to reach the target urine volume; a machine learning model predicting an estimated urine volume at the target time using at least the measured value and the time value; comparing the estimated urine volume at the target time with the target urine volume; and generating an alert regarding whether the target urine volume will be reached by the target time based on a comparison of the target urine volume with the estimated urine volume predicted by the machine learning model.

[0068] Example 2. The method according to Example 1, further comprising receiving a set of inputs corresponding to a set of urine volumes and a set of time values ​​to reach a target time.

[0069] Example 3. The method according to any one of Examples 1-2, wherein the prediction of estimated urination volume is performed after a set of threshold quantity inputs has been received by the machine learning model.

[0070] Example 4. Any method of Examples 1-3, wherein the measurement of urine volume indicates the volume or weight of urine, and the urine is collected via a Foley catheter over a certain time interval.

[0071] Example 5. The method according to any one of Examples 1 to 4, wherein the input set includes the total amount of urine excreted during the measurement time, the average amount of urine excreted per hour during the measurement time, the standard deviation of the amount of urine excreted per hour during the measurement time, the average amount of urine excreted per hour during the second half of the urine monitoring session, the amount of urine excreted in the previous hour, the elapsed time since the start of the urine monitoring session, and / or the remaining time until the target time.

[0072] Example 6. The method according to any one of Examples 1-5, wherein the target time and target urination volume are set via a user interface and provided to the processor.

[0073] Example 7. The machine learning model is a method according to any of Examples 1-6, including a gradient boosting regression tree machine learning model.

[0074] Example 8. A machine learning model is trained and / or the training is based on at least non-parametric statistical learning, as described in any of Examples 1-7.

[0075] Example 9. The machine learning model is a method according to any one of Examples 1 to 8, including a linear regression machine learning model, a random forest machine learning model, a neural network machine learning model, a gradient boosting regressor machine learning model, and / or a Kalman filter.

[0076] Example 10. The method according to any one of Examples 1 to 9, further comprising providing an alert on the display to indicate whether the target urination volume will be reached by the target time.

[0077] Example 11. The method according to any of Examples 1-10, wherein an alert is used to evaluate whether to change the dosage of a drug that affects urine volume.

[0078] Example 12. The method according to any of Examples 1-11, wherein the comparison is performed by comparison logic and / or a machine learning model.

[0079] Example 13. The machine learning model is the method according to any of Examples 1-12, comprising an ensemble of machine learning models.

[0080] Example 14. The method according to any one of Examples 1 to 13, wherein the ensemble of machine learning models includes a first machine learning model that predicts a first quantile of a first estimated void volume at a target time, a second machine learning model that predicts a second quantile of a second estimated void volume at a target time, and a third machine learning model that predicts a third quantile of a third estimated void volume at a target time, wherein the first estimated void volume, the second estimated void volume, and the third estimated void volume provide confidence intervals for the estimated void volume at a target time.

[0081] Example 15. The method according to any one of Examples 1 to 14, wherein the first estimated urine volume, the second estimated urine volume, and the third estimated urine volume are compared with the target urine volume.

[0082] Example 16. The method according to any one of Examples 1 to 5, wherein the machine learning model is included in the urine collection system, coupled to the urine collection system via a wired or wireless connection, and provided as a service to one or more urine collection systems.

[0083] Example 17. Apparatus comprising at least one processor,

[0084] A device comprising at least one memory containing code, wherein the code, when executed by the at least one processor, causes a machine learning model to perform the following actions: predict an input set including a measured amount of urination and a time value indicating the remaining time from when a first measurement is performed until a target time to reach the target amount of urination; have the machine learning model use at least the measured amount and the time value to predict an estimated amount of urination at the target time; compare the estimated amount of urination at the target time with the target amount of urination; and generate an alert on whether the target amount of urination will be reached by the target time, based on a comparison of the target amount of urination with the estimated amount of urination predicted by the machine learning model.

[0085] Example 18. The apparatus according to Example 17, further comprising receiving a set of inputs corresponding to a set of urine volumes and a set of time values ​​to reach a target time.

[0086] Example 19. The apparatus according to Example 17 or 18, wherein predicting the estimated urination volume is performed after a set of threshold quantity inputs has been received by a machine learning model.

[0087] Example 20. The apparatus according to any of Examples 17-19, wherein the measurement of urine output indicates the volume or weight of urine, and the urine is collected via a Foley catheter over a certain time interval.

[0088] Example 21. The apparatus according to any one of Examples 17 to 20, wherein the input set includes the total amount of urine excreted during the measurement time, the average amount of urine excreted per hour during the measurement time, the standard deviation of the amount of urine excreted per hour during the measurement time, the average amount of urine excreted per hour during the second half of the urine monitoring session, the amount of urine excreted in the previous hour, the elapsed time since the start of the urine monitoring session, and / or the remaining time until the target time.

[0089] Example 22. The apparatus according to any of Examples 17-21, wherein the target time and target urination volume are set via a user interface and provided to the apparatus.

[0090] Example 23. The apparatus according to any one of Examples 17 to 22, comprising a gradient boosting regression tree machine learning model.

[0091] Example 24. The apparatus described in any of Examples 17-23, wherein a machine learning model is trained and / or the training is based on at least non-parametric statistical learning.

[0092] Example 25. The apparatus according to any one of Examples 17 to 24, wherein the machine learning model comprises a linear regression machine learning model, a random forest machine learning model, a neural network machine learning model, a gradient boosting regressor machine learning model, and / or a Kalman filter.

[0093] Example 26. The apparatus according to any one of Examples 17-25, further comprising providing an alert on the display to indicate whether the target urination volume will be reached by the target time.

[0094] Example 27. An alert device as described in any of Examples 17-26, used to evaluate whether to change the dosage of a drug that affects urine volume.

[0095] Example 28. The apparatus described in any of Examples 17-27, wherein the comparison is performed by comparison logic and / or a machine learning model.

[0096] Example 29. The apparatus according to any one of Examples 17 to 28, comprising an ensemble of machine learning models.

[0097] Example 30. An apparatus according to any one of Examples 17 to 29, wherein the ensemble of machine learning models includes a first machine learning model that predicts a first quantile of a first estimated urination volume at a target time, a second machine learning model that predicts a second quantile of a second estimated urination volume at a target time, and a third machine learning model that predicts a third quantile of a third estimated urination volume at a target time, wherein the first estimated urination volume, the second estimated urination volume, and the third estimated urination volume provide confidence intervals for the estimated urination volume at a target time.

[0098] Example 31. The apparatus according to any one of Examples 17 to 30, wherein the first estimated urination volume, the second estimated urination volume, and the third estimated urination volume are compared with a target urination volume.

[0099] Example 32. The apparatus according to any one of Examples 17-31, wherein the machine learning model is included in the urine collection system, coupled to the urine collection system via a wired or wireless connection, and provided as a service to one or more urine collection systems.

[0100] Without limiting the scope, interpretation, or application of the claims described below, one or more technical effects of the exemplary embodiments disclosed herein may include an improvement in predicting whether a target volume of urine will be reached by a target time.

[0101] One or more aspects or features of the subject matter described herein can be realized in digital electronic circuits, integrated circuits, specially designed ASICs, field-programmable gate arrays (FPGAs), computer hardware, firmware, software, and / or combinations thereof. These various aspects or features may include implementations in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which may be dedicated or general-purpose, coupled to receive data and instructions from a storage system, at least one input device, and at least one output device, and to transmit data and instructions to them. The programmable system or computing system may include clients and servers. Clients and servers are generally remote from each other and usually interact over a communication network. The client-server relationship is created by computer programs running on each computer that have a client-server relationship with each other.

[0102] These computer programs, also called programs, software, software applications, applications, components, or code, contain machine instructions for a programmable processor and may be implemented in high-level procedural programming languages ​​and / or object-oriented programming languages, as well as in assembly language / machine language. As used herein, the term “machine-readable medium” means any computer program product, apparatus, and / or device used to provide machine instructions and / or data to a programmable processor, including machine-readable medium that receives machine instructions as machine-readable signals, such as magnetic disks, optical disks, memory, and programmable logic devices (PLDs). The term “machine-readable signal” means any signal used to provide machine instructions and / or data to a programmable processor. A machine-readable medium can store such machine instructions non-temporarily, for example, non-temporarily, such as a solid-state memory or magnetic hard drive or any equivalent storage medium. Alternatively or additionally, a machine-readable medium can store such machine instructions temporarily, for example, such as a processor cache or other random-access memory associated with one or more physical processor cores.

[0103] To provide user interaction, one or more aspects or features of the subject matter described herein may be implemented on a computer having a display device for displaying information to the user, such as a cathode ray tube (CRT), liquid crystal display (LCD), or light-emitting diode (LED) monitor, and a keyboard and a pointing device, such as a mouse or trackball, to which the user can provide input to the computer. Other types of devices may also be used to provide user interaction. For example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic, verbal, or tactile input. Other possible input devices include touchscreens, or single or multi-point resistive or capacitive trackpads, speech recognition hardware and software, optical scanners, optical pointers, digital image capture devices, and other touch-sensitive devices such as associated interpretation software.

[0104] In the above description and claims, phrases such as “at least one of” or “one or more of” may appear following a connecting list of elements or features. The term “and / or” may also appear in a list of two or more elements or features. Depending on the context in which it is used, unless otherwise implicitly or explicitly negated, such phrases are intended to mean any of the enumerated elements or features individually, or any of the enumerated elements or features in combination with any of the other enumerated elements or features. For example, the phrases “at least one of A and B,” “one or more of A and B,” and “A and / or B” are intended to mean “A only, B only, or A and B together,” respectively. For example, the phrases “at least one of A, B, and C,” “one or more of A, B, and C,” and “A, B, and / or C” are intended to mean “A only, B only, C only, A and B together, A and C together, B and C together, or A, B and C together,” respectively.

[0105] The subject matter described herein can be embodied in systems, apparatus, methods, and / or articles, depending on the desired configuration. The embodiments described above do not represent all embodiments that correspond to the subject matter described herein. Rather, they are merely some examples that correspond to aspects related to the subject matter described herein. While some variations have been described in detail above, other modifications or additions are possible. In particular, further features and / or variations can be provided in addition to those described herein. For example, the embodiments described above may cover various combinations and subcombinations of the disclosed features, and / or combinations and subcombinations of some of the further features described above. Furthermore, the logical flows shown in the accompanying drawings and / or described herein do not necessarily require a specific order or sequence shown to achieve the desired result. For example, the logical flows may include different and / or additional operations without departing from the scope of this disclosure. One or more operations of the logical flows may be repeated and / or omitted without departing from the scope of this disclosure. Other embodiments may be within the scope of the following claims.

Claims

1. In a processor that runs a machine learning model, an input set is received that includes a measured urine volume and a time value indicating the remaining time from when the first measurement was performed until the target time to reach the target urine volume. The machine learning model predicts the estimated amount of urine excreted at the target time, using at least the measured value and the time value. Comparing the estimated amount of urine excreted at the target time with the target amount of urine excreted, A method comprising: generating an alert regarding whether the target urination volume will be reached by the target time, based on a comparison between the target urination volume and the estimated urination volume predicted by the machine learning model.

2. The method according to claim 1, further comprising receiving a plurality of input sets corresponding to a plurality of urination volumes and a plurality of time values ​​until a target time to reach the target urination volume.

3. The method according to claim 2, wherein predicting the estimated urination volume is performed after the machine learning model has received a set of threshold values ​​as inputs.

4. The method according to claim 1, wherein the measurement of the amount of urine excreted indicates urine volume or urine weight, and the urine is collected via a Foley catheter over a period of time.

5. The method according to claim 1, wherein the input set includes the total amount of urine excreted during the measurement time, the average amount of urine excreted per hour during the measurement time, the standard deviation of the amount of urine excreted per hour during the measurement time, the average amount of urine excreted per hour during the second half of the urine monitoring session, the amount of urine excreted in the previous hour, the elapsed time since the start of the urine monitoring session, and / or the remaining time until the target time.

6. The method according to claim 1, wherein the target time and the target amount of urine are set via a user interface and provided to the processor.

7. The method according to claim 1, wherein the machine learning model includes a gradient boosting regression tree machine learning model.

8. The method according to claim 1, wherein the machine learning model is trained and / or the training is based at least on nonparametric statistical learning.

9. The method according to claim 1, wherein the machine learning model includes a linear regression machine learning model, a random forest machine learning model, a neural network machine learning model, a gradient boosting regressor machine learning model, and / or a Kalman filter.

10. The method according to claim 1, further comprising providing the alert on a display to indicate whether the target amount of urine will be reached by the target time.

11. The method according to claim 1, wherein the alert is used to evaluate whether to change the dosage of a drug that affects the amount of urine excreted.

12. The method according to claim 1, wherein the comparison is performed by the comparison logic and / or the machine learning model.

13. The method according to claim 1, wherein the machine learning model includes an ensemble of machine learning models.

14. The method according to claim 13, wherein the ensemble of machine learning models includes a first machine learning model that predicts a first quantile of a first estimated urination volume at the target time, a second machine learning model that predicts a second quantile of a second estimated urination volume at the target time, and a third machine learning model that predicts a third quantile of a third estimated urination volume at the target time, and the first estimated urination volume, the second estimated urination volume, and the third estimated urination volume provide a confidence interval for the estimated urination volume at the target time.

15. The method according to claim 14, wherein the comparison involves comparing the first estimated urination volume, the second estimated urination volume, and the third estimated urination volume with the target urination volume.

16. The method according to claim 1, wherein the machine learning model is included in a urine collection system, coupled to the urine collection system via a wired or wireless connection, and provided as a service to one or more urine collection systems.

17. It is a device, At least one processor, The system comprises at least one memory containing code, and when the code is executed by the at least one processor, the at least one processor, In a machine learning model, an input set is received that includes a measured urine volume and a time value indicating the remaining time from when the first measurement was performed until the target time to reach the target urine volume. The machine learning model predicts the estimated amount of urine excreted at the target time, using at least the measured value and the time value. Comparing the estimated amount of urine excreted at the target time with the target amount of urine excreted, A device that performs the following actions: generating an alert regarding whether the target amount of urine will be reached by the target time, based on a comparison between the target amount of urine and the estimated amount of urine predicted by the machine learning model.

18. The apparatus according to claim 17, wherein the receiving further includes receiving a plurality of input sets corresponding to a plurality of urination volumes and a plurality of time values ​​until a target time to reach the target urination volume.

19. The apparatus according to claim 18, wherein predicting the estimated urination volume is performed after a set of threshold values ​​has been received by the machine learning model.

20. The apparatus according to claim 17, wherein the measured value of the amount of urine excreted indicates urine volume or urine weight, and the urine is collected via a Foley catheter over a period of time.

21. The apparatus according to claim 17, wherein the input set includes the total amount of urine excreted during the measurement time, the average amount of urine excreted per hour during the measurement time, the standard deviation of the amount of urine excreted per hour during the measurement time, the average amount of urine excreted per hour during the second half of the urine monitoring session, the amount of urine excreted in the previous hour, the elapsed time since the start of the urine monitoring session, and / or the remaining time until the target time.

22. The apparatus according to claim 17, wherein the target time and the target amount of urine are set via a user interface and provided to the apparatus.

23. The apparatus according to claim 17, wherein the machine learning model comprises a gradient boosting regression tree machine learning model.

24. The apparatus according to claim 17, wherein the machine learning model is trained and / or the training is based on at least nonparametric statistical learning.

25. The apparatus according to claim 17, wherein the machine learning model comprises a linear regression machine learning model, a random forest machine learning model, a neural network machine learning model, a gradient boosting regressor machine learning model, and / or a Kalman filter.

26. The apparatus according to claim 17, further comprising providing the alert on the display to indicate whether the target amount of urine will be reached by the target time.

27. The apparatus according to claim 17, wherein the alert is used to evaluate whether to change the dosage of a drug that affects the amount of urine excreted.

28. The apparatus according to claim 17, wherein the comparison is performed by the comparison logic and / or the machine learning model.

29. The apparatus according to claim 17, comprising an ensemble of machine learning models.

30. The apparatus according to claim 17, wherein the ensemble of machine learning models includes a first machine learning model that predicts a first quantile of a first estimated urination volume at the target time, a second machine learning model that predicts a second quantile of a second estimated urination volume at the target time, and a third machine learning model that predicts a third quantile of a third estimated urination volume at the target time, and the first estimated urination volume, the second estimated urination volume, and the third estimated urination volume provide a confidence interval for the estimated urination volume at the target time.

31. The apparatus according to claim 30, wherein the comparison involves comparing the first estimated urination volume, the second estimated urination volume, and the third estimated urination volume with the target urination volume.

32. The apparatus according to claim 17, wherein the machine learning model is included in the urine collection system, coupled to the urine collection system via a wired or wireless connection, and provided as a service to one or more urine collection systems.

33. A non-temporary computer-readable storage medium containing code, wherein the code, when executed by at least one processor, is sent to the at least one processor. In a machine learning model, an input set is received that includes a measured urine volume and a time value indicating the remaining time from when the first measurement was performed until the target time to reach the target urine volume. The machine learning model predicts the estimated amount of urine excreted at the target time, using at least the measured value and the time value. Comparing the estimated amount of urine excreted at the target time with the target amount of urine excreted, A non-temporary computer-readable storage medium that performs an operation including generating an alert regarding whether the target urination volume will be reached by the target time, based on a comparison between the target urination volume and the estimated urination volume predicted by the machine learning model.

34. It is a device, A means for receiving an input set in a machine learning model that includes a measured urine volume and a time value indicating the remaining time from when the first measurement is performed until the target time to reach the target urine volume, The machine learning model provides means for predicting the estimated amount of urine excreted at the target time, using at least the measured value and the time value. Means for comparing the estimated amount of urine excreted at the target time with the target amount of urine excreted, An apparatus comprising means for generating an alert regarding whether the target amount of urine will be reached by the target time, based on a comparison between the target amount of urine and the estimated amount of urine predicted by the machine learning model.

35. The apparatus according to claim 34, further comprising means for performing any of the functions described in any of claims 2 to 17.

Images