EFFICIENTLY GENERATING MACHINE LEARNING MODELS CONFIGURED TO FORECAST INFORMATION REGARDING TIME UNTIL OCCURRENCE OF CLINICAL EVENTS

TECHNICAL FIELD

This application relates to computer-implemented techniques for efficiently generating machine learning models configured to forecast information regarding time until occurrence of clinical events.

BACKGROUND

Care providers face multiple challenges in identifying complex patients, managing care plans and forecasting patient outcomes to plan post discharge care. Discharge planning for complex patients is a process that seeks to safely transfer patients and prevent future readmissions by ensuring they receive the proper continuity of care after leaving the hospital. Inpatient discharge planning for complex patients is a critical decision point in patient care, with implications for the intake capacity of the inpatient unit as well as other units of the hospital. Effective discharge planning informed by the prospective outcomes of complex patients can ensure a patient's continued care needs are met, decrease the chances of readmission, aid recovery, ensure medications are prescribed and given correctly, and adequately prepare the patient and the patient's family for the next phase of the patient's care. Early planning and coordination by the healthcare team, including physicians, social workers, rehabilitation specialists, and post-acute care services, improves inpatient care quality and access while reducing costs. Care providers need help identifying complex patients, learning more about their prospective outcomes and planning their care both before and after their discharge.

SUMMARY

The following presents a summary to provide a basic understanding of one or more embodiments of the invention. This summary is not intended to identify key or critical elements or delineate any scope of the different embodiments or any scope of the claims. Its sole purpose is to present concepts in a simplified form as a prelude to the more detailed description that is presented later.

In one or more embodiments described herein, systems, computer-implemented methods, apparatus and/or computer program products are described that facilitate efficiently generating machine learning models configured to forecast information regarding time until occurrence of clinical events. The clinical events can include clinical events associated with patients wherein the the timing of occurrence of the clinical events vary from patient to patient based on a wide range of clinical and non-clinical variables aggregated over time. In one or more exemplary embodiments, the clinical events can include discharge from an inpatient medical facility and the machine learning models comprise one or more models trained to predict information regarding estimated remaining length of stay (LOS) at the inpatient medical facility. In other embodiments, the clinical events can include development of a particular medical condition (e.g., sepsis, a respiratory disease requiring a ventilator, and other medical conditions).

According to an embodiment, a system is provided that comprises a memory that stores computer executable components, and a processor that executes the computer executable components stored in the memory. The computer executable components can comprise a clustering component that clusters training data samples corresponding to different patients that experienced a clinical event into different patient groups as a function of different defined timeframes within which the clinical event occurred. The computer executable component can further comprise a classification modeling component that employs a first machine learning process to train a classification model using the training data samples to predict the different patient groups to which the training data samples respectively belong, and an event modeling component that employs a second machine learning process to train a clinical time to event model using the training data samples to predict an expected duration of time until occurrence of the clinical event as a function of the different patient groups. In some embodiments, the computer executable components further comprise an event window modeling component that employs a third machine learning process to train an event window model using the training data samples to predict an expected time window within which the clinical event will occur as a function of the different patient groups.

Once the model training has been completed, the system can apply the models to new patient data for a new patient to predict the patient group to which the patient belongs, the expected timing of occurrence of the clinical event for the new patient, and the expected time window in which the clinical event will occur. For example, in embodiments in which the clinical event comprises discharge from an inpatient medical facility, the system can apply the trained models to the new patient data as collected and aggregated on daily basis to forecast the remaining LOS of the patient (i.e., the discharge date of the patient relative to the current day/point of forecast) and the discharge date window.

In some embodiments, elements described in the disclosed systems can be embodied in different forms such as a computer-implemented method, a computer program product, or another form.

DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates a block diagram of an example, non-limiting system for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter.

FIG. 1B presents an example care outcomes forecasting component in accordance with one or more embodiments of the disclosed subject matter.

FIG. 2 provides example types of clinical and non-clinical patient data that can be used as input to forecast patient discharge events and needs in accordance with one or more embodiments of the disclosed subject matter.

FIG. 3 presents example clinical data points that can be collected for a patient over an inpatient stay in accordance with one or more embodiments of the disclosed subject matter.

FIG. 4 illustrates a block diagram of another example, non-limiting system for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter.

FIG. 5 presents an example visualization reporting identified complex patients and their forecasted discharge dispositions in accordance with one or more embodiments of the disclosed subject matter.

FIG. 6 illustrates a block diagram of another example, non-limiting system for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter.

FIG. 7 presents a flow diagram illustrating an ensemble-based machine learning approach for forecasting patient discharge destinations in accordance with one or more embodiments of the disclosed subject matter

FIG. 8 presents a flow diagram illustrating an ensemble-based machine learning approach for forecasting patient discharge times in accordance with one or more embodiments of the disclosed subject matter.

FIG. 9 illustrates a block diagram of another example, non-limiting system for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter.

FIG. 10 presents an example graphical user interface (GUI) that facilitates planning and coordinating patient discharge events in accordance with one or more embodiments of the disclosed subject matter.

FIG. 11 presents an example GUI that facilitates receiving user feedback regarding patient discharge barriers and milestones in accordance with one or more embodiments of the disclosed subject matter.

FIG. 12 presents an example visualization reporting identified patient discharge barriers and associated alerts in accordance with one or more embodiments of the disclosed subject matter.

FIG. 13 illustrates a block diagram of another example, non-limiting system for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter.

FIG. 14 illustrates an example, high-level flow diagram of a computer-implemented process for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter.

FIG. 15 illustrates another example, high-level flow diagram of another computer-implemented process for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter.

FIG. 16 illustrates another example, high-level flow diagram of another computer-implemented process for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter.

FIG. 17 presents another example care outcomes forecasting component in accordance with one or more embodiments of the disclosed subject matter.

FIG. 18 presents a high-level flow diagram of an example process for forecasting information regarding time until occurrence of clinical events in accordance with one or more embodiments of the disclosed subject matter.

FIG. 19 presents a high-level flow diagram of an example process for generating one or more classification models that classify patients into different patient groups as a function of defined timeframes in which a defined clinical event is expected to occur.

FIG. 20 presents a high-level flow diagram of an example process for generating one or more clinical time-to-event models in accordance with one or more embodiments of the disclosed subject matter.

FIG. 21 presents a high-level flow diagram of an example process for generating remaining LOS forecasting models with reduced training time and complexity in accordance with one or more embodiments of the disclosed subject matter.

FIG. 22 presents a graph illustrating the LOS distribution for a patient population pool in accordance with one or more embodiments of the disclosed subject matter.

FIG. 23 presents tables illustrating aspects of a training data sampling protocol that facilitates generating remaining LOS forecasting models with reduced training time and complexity in accordance with one or more embodiments of the disclosed subject matter.

FIG. 24 presents a graph illustrating the distribution of the current LOS with the sampled patients in accordance with one or more embodiments of the disclosed subject matter.

FIG. 25 presents a high-level flow diagram of an example process for generating a training dataset using a sampling process that facilitates efficient model development in accordance with one or more embodiments of the disclosed subject matter.

FIG. 26 presents a flow diagram of an example process for sampling patient data in association with generating the training dataset in accordance with one or more embodiments of the disclosed subject matter.

FIG. 27 presents a high-level flow diagram of an example process for predicting the time-to-event and event window using machine learning in accordance with one or more embodiments of the disclosed subject matter.

FIGS. 28A and 28B present a high-level flow diagram of an example ensemble model process for predicting the time-to-event and event window using in accordance with one or more embodiments of the disclosed subject matter.

FIG. 29 presents a high-level flow diagram of an example machine learning process for estimating time windows in which a defined clinical event is expected to occur in accordance with one or more embodiments of the disclosed subject matter.

FIG. 30 presents a high-level flow diagram of another example machine learning process for estimating time windows in which a defined clinical event is expected to occur in accordance with one or more embodiments of the disclosed subject matter.

FIG. 31 illustrates an example, high-level flow diagram of a computer-implemented process for training machine learning models to forecast information regarding time until occurrence of clinical events in accordance with one or more embodiments of the disclosed subject matter.

FIG. 32 illustrates an example, high-level flow diagram of another computer-implemented process for training machine learning models to forecast information regarding time until occurrence of clinical events in accordance with one or more embodiments of the disclosed subject matter.

FIG. 33 illustrates a block diagram of an example, non-limiting operating environment in which one or more embodiments described herein can be facilitated.

DETAILED DESCRIPTION

The following detailed description is merely illustrative and is not intended to limit embodiments and/or application or uses of embodiments. Furthermore, there is no intention to be bound by any expressed or implied information presented in the preceding Summary section or in the Detailed Description section.

The disclosed subject matter is directed to systems, computer-implemented methods, apparatus and/or computer program products for forecasting patient discharge events and needs using machine learning analytics to facilitate managing and coordinating inpatient and post-discharge care. Discharge planning and patient transitions are among the most complex and challenging moments in the healthcare system. At some point before the patient is discharged, the discharge disposition must be identified in order to initiate the corresponding preparation. The discharge disposition refers to the destination where a patient is being discharged. For example, a patient can be discharged home, discharged home with home professional care assistance, or discharged to a variety of post-acute care facilities, such as long-term hospitals, skilled nursing facilities (SNFs), rehabilitation facilities, and the like. The terms discharge “disposition” and discharge “destination” are used herein synonymously to indicate a type of care destination where a patient is discharged.

Hospital discharge to a post-acute setting (e.g., a non-home setting) is often among the most daunting challenges that patients and their families face. An estimated one in five hospitalized patients are discharged to post-acute care settings. There are many challenges for hospitals when planning a patient's discharge to a post-acute setting as they typically require more resources and planning than home discharges due to the increased clinical and logistical complexity of such cases. This includes insurance paperwork, coordination with any destination facilities, transportation arrangement, post discharge care planning, and patient and family instruction. Such preparation can take days, and failure to initiate in a timely manner can result in significant discharge delays. Unnecessary discharge delays not only negatively impact the patients and their families but cause increased costs to the hospital (increased costs, extra days of stay), create blockages in patient flow, increase care team and physician workload, and hinder care of potential patients not yet admitted to the hospital.

One or more embodiments of the disclosed subject matter provides systems, computer-implemented methods, apparatus and/or computer program products for predicting care outcomes of patients currently admitted to a hospital (or another type of inpatient facility) based on a variety of information collected for the patients, including medical information as well as as socioeconomic, insurance, mental health, behavioral and other types of non-clinical information. This information can be collected from various sources at various times over the course of their inpatient care. For example, a variety of clinical and non-clinical factors used to predict the patient are outcomes can be extracted from static and dynamics data sources, including patient medical records, patient admission records, insurance records, social services records, demographics records, family support information, case worker impression files, clinician reports/notes, medical monitoring devices, patient tracking systems, clinical ordering systems, procedure scheduling systems, laboratory reports, imaging study reports, and the like. In various embodiments, the care outcomes can include expected discharge destinations, expected discharge times or length of stay (LOS), expected readmission risk, forecasted safety risks and the like. The disclosed techniques can also provide for determining a probability indicating the likelihood that a patient will be discharged to a particular discharge destination, referred to herein as a “placement probability”. Forecasted care outcomes (e.g., discharge destinations and associated probabilities, LOS, readmission risk, safety risk, etc.) can be regularly/dynamically updated over the course of a patient's stay to reflect changes in the patient's status and medical care needs.

The disclosed techniques for predicting patient care outcomes employ one or more machine learning models respectively trained to predict the patient care outcome based on learned correlations between a variety of unique combinations of clinical and non-clinical factors. For example, the clinical factors can include information regarding the patient's medical history prior to admission, as well as admission data regarding the reason for admission, patient status and diagnosis upon admission, initial clinical orders for the patient, an initial care plan for the patient, and the like. The clinical data can also include tracked clinical information collected for the patient over their inpatient stay, including information regarding medical procedures performed and scheduled, clinicians involved in the patient's care (e.g., physicians, nurses, technicians, etc.), laboratory tests conducted, imaging studies performed, medications administered, and the like. The tracked clinical information can also include information regarding monitored vital signs (e.g., captured and reported in real-time), monitored patient status (e.g., including changes in patient's status over time), tracked patient location, and the like.

The non-clinical factors can include various additional factors that can influence the type of post discharge care a patient will need and/or can obtain from a personal, social, logical, economic and family support perspective. For example, the non-clinical factors can include demographic factors, such patient age, gender, ethnicity, religion, language, marital status, occupation, etc. The non-clinical factors can also include factors related to the patient's socioeconomic status, such as income level, net worth, credit score, standard of living, home location, assets, education level, and the like. The non-clinical factors can also include factors related to the patient's family, including information regarding whether the patient has family members that will be responsible for the patient post discharge, their respective roles in the patient's post discharge care, their respective locations, their abilities relevant to ensuring the patient's post discharge medical needs are met, and the like. The non-clinical factors can also include information regarding any other individuals (non-family members) that will be responsible for the patient post discharge and/or involved in the patient's post discharge care. In some implementations, the non-clinical factors can also include information regarding the patient's home environment, including whether the patient lives alone or with other individuals (e.g., and who these individuals are), as well as other factors that indicate whether the patient's home environment is conducive to their post discharge needs and state (e.g., structural factors, whether the home has stairs/elevators, location relative to stores, appointments, emergency services, etc.). The non-clinical factors can also include information regarding the patient's insurance provider and plan, patient preferences related to their post-discharge care, known discharge barriers, and the like. In some implementations, the non-clinical factors can also include information regarding patient behavior, patient mental health, and medication taken.

In various embodiments, the disclosed patient care outcome forecasting techniques employ and an ensemble machine learning approach that involves chaining and/or stacking of a plurality of different predictive models that respectively predict the patient care outcomes based on different combinations of clinical and/or non-clinical factors and/or using different weighting schemes for one or more of the input parameters. For example, with respect to forecasting discharge destinations and associate placement probabilities, the different predictive models can include a first model that forecasts discharge destinations based on a first set of clinical and/or non-clinical factors, a second model that forecast discharge destinations based on a second set of clinical and/or non-clinical factors, a third model that forecast discharge destinations based on a third set of clinical and/or non-clinical factors, and so on. In some implementations, the different discharge forecasting models can also include models that employ different types of machine learning algorithms/models (e.g., neural network models, decision tree models, random forest models, k-means models, etc.).

In addition to forecasting where a patient will be discharged, the disclosed systems can also employ ensemble based machine learning techniques (e.g., model stacking and chaining) to forecast when (e.g., time and date) a patient will be discharged based on the unique combinations of clinical and non-clinical data factors collected for the patient over their inpatient stay. In some implementations, the timing of discharge can be expressed as an expected length of stay (LOS). Patient care services and operations can then be aligned around this date, with the goal of minimizing delays and inefficiencies during the patient's stay, reducing their length of stay (LOS), and helping to alleviate overcrowding through improved patient flow. The forecasted discharge times can also be regularly updated over the course of their inpatient stay to reflect changes in their status, care needs, identified barriers to discharge, and other contextual factors related to their discharge (e.g., availability of beds at transition and/or discharge dispositions, coordination of transportation, etc.).

With these embodiments, the outputs of the respective models can be aggregated and evaluated using one or more optimization techniques to converge on a final discharge trajectory forecast that provides greater confidence relative to the individual models. For example, the one or more optimization techniques can determine a final discharge forecast (e.g., including one or more possible discharge destinations and associated probabilities) based on the aggregated predictions of the different models, defined discharge constraints (e.g., care needs, financial constraints, regulatory requirements, known barriers to discharge, etc.), and/or defined optimization criteria (e.g., minimize LOS, minimize discharge delay times, minimize costs, optimize patient flow, etc.). The one or more optimization techniques can also employ tailored weighting schemes for the different model outputs based on learned relevance and accuracy of the respective models for different patient groups (e.g., grouped by diagnosis, demographic factors, insurance factors, socioeconomic factors, etc.). The usage of different models respectively configured to make care outcome predictions using different sets of input parameters further enables a stacked machine learning approach, wherein different models can respectively be called and applied based on the available data for a particular patient at current point in time (e.g., when a discharge prediction is being made). In this regard, the disclosed techniques can stack and chain the appropriate models together based on the current data collected for each patient over their stay to provide predictions tailored to their individual cases and needs.

Based on predicted discharge destinations, the disclosed systems can predict well before discharge, which patients will likely require post-acute care (e.g., as opposed to home discharge), including specific types of post-acute care dispositions they will need. This allows care providers to coordinate and provide relevant care to the patients before and after hospital discharge in a timely manner. For example, patients discharged to a post-acute setting often have medically complex needs and require coordinated consultations from a variety of providers and specialists. In another example, a patient might need dialysis before and after discharge along with nursing support, or patient may need oxygen before and after discharge along with equipment support etc.

In some embodiments, patients that require post-acute care (e.g., discharge to a post-acute care destination) can be classified as complex needs patients. In one or more additional embodiments, the disclosed systems can also evaluate the various clinical and non-clinical data collected for a patient to determine or predict whether a patient is a complex needs patient and/or will be a complex needs patient upon discharge, and to determine or predict the particular care needs of the patient that make the patient a complex needs patient. With these embodiments, the disclosed systems can include a complex patient identification component that uses machine learning, qualitative and hybrid methods to identify such patients based the various clinical and non-clinical factors described herein. In this regard, identifying whether a patient needs complex care is quite different from just predicting medical events for the patient. Existing techniques for identifying complex needs patients generally involve performing risk analysis to identify patients associated with medically high risk. However, identifying complex needs patients based on medical risk alone does not provide for determining the feasible resources and the required level of care post discharge. The disclosed techniques go beyond evaluating medically complex conditions and looks at a combination of factors ranging from medical conditions, social vulnerability, mental health, behavior characteristics, insurance, medications, and other non-traditional factors, to determine whether a patient is or is likely to be a complex needs patient. Thus, the disclosed techniques provide a more accurate picture of what type of post-discharge care a complex needs patient will require and the feasible resources for providing such post-discharge care well before discharge by evaluating a variety of clinical and non-clinical factors in real-time.

In various embodiments, the disclosed systems can further provide information regarding the predicted patient care outcomes and the identified complex needs patients to care providers in real-time via a suitable rendering application to support the care delivery process. For example, in some implementations, the solution can be integrated as a visualization tile of a care delivery optimization application accessible via a network-based platform (e.g., a web-application, a website, a thin client application), a centralized command center, or another suitable operating environment. The visualization can allow a care provider to view the predicted discharge destinations and discharge times of the currently admitted patients to facilitate discharge planning. In some implementations, the visualization can specifically identify and/or otherwise call-out patients determined to be complex needs patients, such as patients expected to be discharged to post-acute care facilities. The real-time display can also include additional information that is relevant to discharge planning, such as pending consults, barriers to discharge, insurance details, current unit location, nurse notes, care team activities, disposition trajectory, discharge barriers, and the like. In this regard, the discharge planning tile can provide a concerted view of all the information pertinent to the discharge of the patient. In some embodiments, the discharge planning application can also provide for receiving user feedback regarding discharge barriers, patient needs, scheduled consults, and other relevant information that can affect where and when a patient is discharged. This user feedback can be fed back into the discharge destination and LOS forecasting models to further update and improve the accuracy of these models over time.

One or more embodiments are now described with reference to the drawings, wherein like referenced numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a more thorough understanding of the one or more embodiments. It is evident, however, in various cases, that the one or more embodiments can be practiced without these specific details.

Turning now to the drawings, FIG. 1A illustrates a block diagram of an example, non-limiting system 100 for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter. Embodiments of systems described herein can include one or more machine-executable components embodied within one or more machines (e.g., embodied in one or more computer-readable storage media associated with one or more machines). Such components, when executed by the one or more machines (e.g., processors, computers, computing devices, virtual machines, etc.) can cause the one or more machines to perform the operations described.

For example, system 100 includes a patient discharge planning module 110, one or more patient input data systems/sources 102, and one or more user devices 122. The patient discharge planning module 110 can be and include various computer/machine executable components, including data collection component 112, care outcomes forecasting component 114 and reporting component 116. These computer/machine executable components (and other described herein) can be stored in memory (not shown) associated with the one or more machines (not shown). The memory can further be operatively coupled to at least one processor (not shown), such that the components (e.g., the discharge planning module 108 itself, the data collection component 112, the care outcomes forecasting component 114, the reporting component 116, and other components described herein), can be executed by the at least one processor to perform the operations described. Examples of said and memory and processor as well as other suitable computer or computing-based elements, can be found with reference to FIG. 33, and can be used in connection with implementing one or more of the systems or components shown and described in connection with FIG. 1 or other figures disclosed herein.

In one or more embodiments, the data collection component 112 can be configured to collect, extract or otherwise receive input data 104 from various patient input data systems/sources 102 for processing by the patient discharge planning module 110 to generate output data 120. For example, the data collection component 112 can collect, from one or more patient input data systems/sources 102, clinical patient data 106 and non-clinical patient data 108 for respective patients admitted to a healthcare facility (e.g., a hospital or the like) at the time of admission and at various points in time over the course of the patients' stay. The care outcomes forecasting component 114 can further processes the input data 104 using one or more machine learning models to forecast patient care outcomes, including but not limited to, expected patient discharge destinations (and placement likelihood), expected patient discharge times (which can include time and data, total forecasted LOS and/or remaining LOS), forecasted readmission risk, and forecasted safety risk.

In particular, FIG. 1B provides an example care outcomes forecasting component 114 in accordance with one or more embodiments described herein. In the embodiment shown, the care outcomes forecasting component 114 includes discharge destination forecasting component 128, LOS forecasting component 134, readmission risk forecasting component 140, and safety risk forecasting component 146.

With reference to FIGS. 1A and 1B, in various embodiments, the data collection component 112 can collect, extract or otherwise receive input data 104 including a variety of defined clinal and non-clinical data points associated with an admitted for input to the respective forecasting models (e.g., the one or more discharge destination forecasting models 126, the one or more LOS forecasting models 132, the one or more readmission risk forecasting models 138, the one or more safety risk forecasting models 144, and the like). The data collection component 112 can collect this input data 104 from various different patient input data systems/sources 102 at the time of admission and continue to collect relevant input data from one or more of these patient input data systems/sources 102 over the course of the patient's inpatient stay (e.g., up until discharge or another defined point in the patient's care). For example, the patient input data systems/sources 102 can include various static and dynamics data sources, including electronic databases, systems or devices that provide patient medical records (e.g., EHRs), patient admission information, patient insurance information, patient demographic information, patient family support information, case worker impression information, clinician reports/notes, imaging study information, laboratory information, tracked patient status information, tracked patient vital signs information, tracked clinical event information (e.g., procedures performed, medications administered, etc.), tracked patient location information, and the like. In some embodiments, the data collection component 112 can extract defined clinical and/or non-clinical parameters (and corresponding values) from the input data 104 using natural language processing (NLP). For example, the data collection component 112 can evaluate medical orders, clinical notes, laboratory reports, imaging study reports, dictations, case worker files, etc., using NLP to identify and extract defined input parameters (and values) for input to the respective care outcome forecasting models.

The discharge destination forecasting component 128 can further apply the one or more discharge destination forecasting models 126 to the input data 104 as the input data is received over the course of a patient's stay to generate one or more discharge destination forecasts 130 for the patient over the course of the patient' stay. Likewise, the LOS forecasting component 104 can apply the one or more LOS forecasting models 132 to the input data 104 as the input data is received over the course of the patient's stay to generate one or more discharge time/LOS forecasts 136 for the patient over the course of the patient's inpatient stay. The readmission risk forecasting component 140 can similarly apply the one or more readmission risk models 138 to the input data 104 to generate one or more readmission risk forecasts 142 for the patient, and the safety risk forecasting component 146 can apply the one or more safety risk forecasting models 144 to the input data 140 to generate one or more safety risk forecasts 148 for the patient.

In this regard, the discharge forecasting component 128 can be configured to processes the input data 104 using one or more discharge destination forecasting models 126 to determine or predict one or more discharge destinations where the patients will be discharged. In some implementations, the one or more discharge destination forecasting models 126 can also predict probabilities indicating the predicted probabilities that the patients will be discharged to the respective discharge destinations. For example, for each (or in some implementations one or more) patient evaluated, the discharge destination forecasting component 128 can apply the one or more discharge destination forecasting models 126 to the input data 104 to predict one or more discharge destinations where the patient may possibly or likely be discharged. The one or more discharged forecasting models 120 can also predict the probability that the patient will be discharged to each forecasted discharge destination (e.g., a 90% chance of discharge to a SNF and a 10% chance of discharge home with home assisted care). In this regard, in some implementations, the discharge destination forecasting component 128 can be configured to identify more than one discharge destination where a patient may be discharged. The discharge destination forecasting component 128 can further generate a discharge destination forecast 130 for each (or in some implementations one or more) patient evaluated identifying the discharge destination or destinations where the patient may be discharged and the placement probabilities indicating the expected likelihood that the patient will be discharged to the respective discharge destinations.

The discharge destination forecasting models 126 can thus include one or more machine learning models trained to predict patient discharge destinations and associated probabilities based on learned correlations between defined discharge dispositions/destination and different combinations of clinical and non-clinical features (and/or their feature values). For example, the one or more discharge destination forecasting models 126 can include a model configured to predict an admitted patient's likely and/or possible discharge destination (or destinations) based on a plurality of clinical factors regarding their medical history, their current diagnosis, their scheduled procedures, their tracked vital signs, imaging studies performed (e.g., including modality, timing and results), laboratory studies performed (e.g., including modality, timing and results), as well as a plurality of non-clinical factors, including demographic factors (e.g., age, gender, ethnicity, religion, language, occupation, etc.), socioeconomic factors (e.g., income level, standard of living, tax bracket, current home location, assets, net worth), insurance factors (e.g., whether the patient has insurance and what type of insurance the patient has, whether a detectable has been met, whether reimbursement cap has be met, etc.), post-discharge support factors (e.g., whether the patient lives alone, who the patient lives with if not alone, whether the patient has friends and/or family members responsible for the patient's post discharge care, capabilities of these friends/family members, locations of these friends/family members, etc.), and factors regarding patient post discharge care preferences.

The defined discharge dispositions/destinations can include (but are not limited to): home, home with skilled care (e.g., including different defined types of skilled care), a nursing home, an assisted living facility, a rehabilitation facility, a SNF, a long-term acute care (LTAC) facility, a transitional care unit, a sub-acute hospital, a continuing care retirement community, a Hospice care facility, a palliative care facility, an inpatient acute rehabilitation care facility, a psychiatric care facility, an ambulatory care facility, a respite care facility, and the like, as well as any of these types of facilities or destinations (e.g., home or home with skilled care) that are further subdivided into sub-types based on different specialty services they provide. In this regard, based on learned correlations between discharge of patients to the respective discharge dispositions and different combinations of clinical and non-clinical features, the one or more discharge destination forecasting models 126 can be configured to predict whether, and with what likelihood, a currently admitted patient (e.g., admitted to a hospital or another type of inpatient facility) will be discharged to one or more of the respective discharge dispositions. The discharge destination forecasting component 128 (or the data collection component 112) can thus identify and extract these different clinical and non-clinical features (and/or feature values) as included in the input data 104 for input to the one or more discharge destination forecasting models 126 to determine the predicted discharge destinations (and associated probabilities) for the currently admitted patients. The different clinical and non-clinical patient data features that the one or more discharge destination forecasting models 126, the one or more LOS forecasting models 132, the one or more readmission risk forecasting models 138 and the one or more safety risk forecasting models 144 can be configured to process are discussed in greater detail with reference to FIG. 2.

Thus, in various embodiments, the one or more discharge destination forecasting models 126 can include previously trained/developed models. For example, the one or more discharge destination forecasting models 126 can include one or more models trained on training data including same or similar clinical and non-clinical features included in the input data 104 and recorded discharge information (e.g., discharge document files) identifying actual discharge dispositions where the patients represented in the training data were discharged. It should be appreciated that the model training process can vary based on the type machine learning algorithms employed by the respective discharge destination forecasting models 126, which can vary. For example, some suitable machine learning algorithms/models that can be used for the one or more discharge destination forecasting models 126 can include but are not limited to: a nearest neighbor algorithm, a naïve Bayes algorithm, a decision tree algorithm, a boosting algorithm, a gradient boosting algorithm, a linear regression algorithm, a neural network algorithm, a k-means clustering algorithm, an association rules algorithm, a q-learning algorithm, a temporal difference algorithm, a deep adversarial network algorithm, or a combination thereof. As described in greater detail infra with reference to FIGS. 6-8, in some embodiments, the one or more discharge forecasting models 126 can include a plurality of different models respectively configured to process different types of input parameters, employ different machine learning algorithms, and/or provide different biases toward certain patient groups. In some embodiments, (discussed in greater detail infra with refence to FIG. 13), the one or more discharge destination forecasting models 126 can also be regularly updated/optimized over time based on the input data 104 and discharge information indicating the actual destinations where the patients were actually discharged, as well as user feedback regarding identified discharge barriers for certain patients (e.g., using one or more supervised and/or unsupervised machine learning mechanisms).

The LOS forecasting component 134 can also process the input data 104 using one or more LOS forecasting models 132 to determine or predict one or more discharge times when the respective patients evaluated are expected to be discharged. As used herein, the term “discharge time” can refer to both a calendar date (e.g., day of the week, year, etc.) as well as a specific time of day. In various embodiments, the LOS forecasting component 134 can express the expected discharge time (or times) in terms of LOS, which can include remaining LOS (e.g., remaining number of days until discharge from a current date), and/or expected total LOS (e.g. expected total number of days the patient will be admitted). In some implementations, the one or more LOS forecasting models 122 can also be configured to generate probability information indicating the predicted probability that a patient will be discharged at a forecasted discharge time (e.g., a 70% chance of discharge with a LOS of 3 days and a 30% chance of discharge with a LOS of 4 days). The discharge destination forecasting component 134 can further generate a discharge time/LOS forecast 136 for each (or in some implementations one or more) patient evaluated providing the expected discharge time (or times), remaining LOS, and/or expected total LOS.

In this regard, the LOS forecasting models 132 can include one or more machine learning models that have been trained to predict patient discharge times (and optionally associated probabilities) based on learned correlations between when patients are discharged and a variety of unique combinations of clinical and non-clinical features (and feature values) associated with the patients. The LOS forecasting component 134 (or the data collection component 112) can thus identify and extract these clinical and non-clinical features (and/or feature values) as included in the input data 104 for input to the one or more discharge LOS forecasting models 132 to determine the predicted discharge times (and associated probabilities) for the currently admitted patients. It should be appreciated that the specific input features extracted from the input data 104 by the discharge destination forecasting component 128 and fed into the discharged forecasting models 126 and extracted by the LOS forecasting component 134 and fed into the LOS forecasting models 132 can vary (e.g., the respective models can be configured to process different input sets).

The readmission risk forecasting component 140 can also process the input data 104 using one or more readmission risk forecasting models 138 to determine or predict a readmission risk score for each (or in some implementations one or more) currently admitted patient. The readmission risk score can represent a forecasted probability/likelihood that patient will be readmitted post-discharge. The readmission risk forecasting component 140 can further generate a readmission risk forecast 142 for each (or in some implementations one or more) patient evaluated providing the readmission risk score. In this regard, the readmission risk forecasting models 138 can include one or more machine learning models that have been trained to predict a probability (or another measurable indicator) representing the likelihood a patient will be readmitted based on learned correlations between readmission rates and a variety of unique combinations of clinical and non-clinical features (and feature values) associated with the patients. The readmission risk forecasting component 140 (or the data collection component 112) can further identify and extract these clinical and non-clinical features (and/or feature values) as included in the input data 104 for input to the one or more discharge readmission risk models 138 to determine the readmission risk measures for the currently admitted patients. It should be appreciated that the specific input features extracted from the input data 104 by the readmission risk forecasting component 140 and fed into the readmission risk forecasting models 138 can be the same or vary from those extracted and applied to the discharged forecasting models 126 and the LOS forecasting models 132.

Similarly, the safety risk forecasting component 146 can also process the input data 104 using one or more safety risk forecasting models 144 to forecast information regarding safety risks associated with each (or in some implementations one or more) currently admitted patient. In this regard, although hospitals, clinics, and doctor's offices take many steps to keep their patients safe, medical errors, also referred to as adverse events, can happen. In some embodiments, the one or more safety risk forecasting models 144 can forecast safety risks identifying specific adverse events that may occur for the patient and/or be caused by the patient and likelihood of occurrence (e.g., this patient has an X % probability of acquiring an infection). In some embodiments, the one or more safety risk forecasting models 144 can forecast a safety risk score representative of a collective safety degree of risk representative of the likelihood of occurrence of adverse events attributed to the patient and/or severity of the adverse events. The safety risk forecasting component 146 can further generate a safety risk forecast 148 for each (or in some implementations one or more) patient evaluated providing the forecasted adverse events, likelihood of occurrence of the adverse events and/or the safety risk score.

In this regard, the safety risk forecasting models 144 can include one or more machine learning models that have been trained to predict adverse events or safety risks that may occur and/or the probability (or another measurable indicator) representing the likelihood of occurrence based on correlations between the adverse events/safety risks and a variety of unique combinations of clinical and non-clinical features (and feature values) associated with the patients. The safety risk forecasting component 146 (or the data collection component 112) can further identify and extract these clinical and non-clinical features (and/or feature values) as included in the input data 104 for input to the one or more safety risk models 144 to determine the safety risks (and associated probabilities of occurrence) for the currently admitted patients. The safety risk forecasting component 146 can also generate a safety risk score representative of the cumulative degree of safety risk (e.g., as a function of the collective safety risks identified, the likelihood of occurrence, and/or risk severity associated with the types of the safety risks). It should be appreciated that the specific input features extracted from the input data 104 by the safety risk forecasting component 146 and fed into the safety risk forecasting models 144 can be the same or vary from those extracted and applied to the discharged forecasting models 126, the LOS forecasting models 132, and/or the readmission risk forecasting models 138.

The type of machine learning algorithms/models used for the LOS forecasting models 132, the readmission risk forecasting models 138 and the safety risk forecasting models 144 can also vary. For example, some suitable machine learning algorithms/models that can be used for the one or more LOS forecasting models 132, the readmission risk forecasting models 138, and the safety risk forecasting models 144 can include but are not limited to: a nearest neighbor algorithm, a naïve Bayes algorithm, a decision tree algorithm, a boosting algorithm, a gradient boosting algorithm, a linear regression algorithm, a neural network algorithm, a k-means clustering algorithm, an association rules algorithm, a q-learning algorithm, a temporal difference algorithm, a deep adversarial network algorithm, or a combination thereof. As described in greater detail infra with reference to FIGS. 6-8, in some embodiments, the LOS models 132, the readmission risk forecasting models 138 and the safety risk forecasting models 144 can also include a plurality of different models respectively configured to process different types of input parameters, employ different machine learning algorithms, and/or provide different biases toward certain patient groups. The LOS forecasting models 132, the readmission risk forecasting models 138 and the safety risk forecasting models 144 can also be regularly updated/optimized over time based on the input data 104 and discharge information indicating the actual discharge times (e.g., expressed in terms of LOS) when the patients were actually discharged, as well as user feedback regarding identified discharge barriers for certain patients (e.g., using one or more supervised and/or unsupervised machine learning mechanisms).

With reference again to FIG. 1A in view of FIG. 1B, the reporting component 116 can further facilitate providing output data 120 regarding the predicted care outcomes 122, (e.g., including the discharge destination forecasts 130, the discharge time/LOS forecasts 136, the readmission risk forecasts 142, and the safety risk forecasts 148) to one or more relevant entities (e.g., systems, devices, applications, etc.) as the predicated care outcome information is generated in real-time. The output data 120 can be reported using various suitable data structures (e.g., as machine readable text, as human readable text, as a graphical visualization, etc.) and/or electronic rendering applications. For example, in some embodiments, the reporting component 116 (and/or the discharge planning module 108) can be integrated with or be coupled to one or more applications that provide various features and/or functionalities associated with optimizing care delivery and/or discharge planning. For instance, in one implementation, the application can include care delivery optimization application accessible via a network-based platform (e.g., a web-application, a website, a thin client application), a centralized command center, or another suitable operating environment. The display component 118 can further provide one or more tiles reporting the output data 120 in real-time.

For example, in the embodiment shown, the reporting component 116 can include a display component 118 configured to facilitate generating a graphical visualization and/or graphical user interface (GUI) for displaying at one or more user devices 122 that includes information regarding forecasted patient outcomes for one or more currently admitted patients. The forecasted predicted care outcomes 122 information can include for example, for each (or in some implementations one or more) of the currently admitted patients, information identifying the predicted discharge destinations and likelihoods, the predicted discharge time (or remaining LOS), the predicted readmission risk, the predicted safety risk, and the like. The one or more user devices 122 can include for example, display monitors and/or computing devices associated with entities involved in the patients' inpatient and/or post-discharge care (e.g., clinicians at the inpatient facility, administrative workers at the inpatient facility, case workers, discharge planners, the patients themselves, friends and family of the patients, etc.). In this regard, the visualization can allow a care provider, case worker, or the like, to view the predicted discharge destinations and discharge times of the currently admitted patients to facilitate discharge planning. In accordance with this example, displayed information regarding the forecasted patient outcomes can be dynamically updated in real-time to reflect updated predictions determined over the course of the patients' inpatient stay.

In this regard, the deployment architecture of system 100 and other systems described herein can vary. For example, various features and functionalities of system 100 (and additional systems described herein) can be deployed using a distributed computing environment, wherein the one or more devices, sources, modules and/or components of system 100 (and other systems described herein) can be provided in a distributed manner across various interconnected (via one or more networks) systems and devices (e.g., internal systems, the cloud, two or more dedicated servers, etc.). For example, system 100 can be deployed in a cloud architecture, a virtualized enterprise architecture, or an enterprise architecture wherein one the front-end components and the back-end components are distributed in a client/server relationship. With these embodiments, one or more features and functionalities of the system 100 can be deployed as a web-application, a cloud-application, a thin client application, a thick client application, a native client application, a hybrid client application, or the like, wherein one or more of the front-end components (e.g., reporting component 116) are provided at client device (e.g., the one or more user devices 122) and one or more of the back-end components (e.g., the data collection component 112, care outcomes forecasting component 114, etc.) are provided in the cloud, on a virtualized server, a virtualized data store, a remote server, a remote data store, a local data center, etc., and accessed via a network (e.g., the Internet). In this regard, the patient input data systems/sources 102, the patient discharge planning module 110, one or more components of the patient discharge planning module 110, and/or the one or more user devices 122 can be physically separated yet communicatively coupled via one or more networks. However, it should be appreciated however that system 100 is not limited to this architectural configuration. For example, in another embodiment, the entirety of the patient discharge planning module 110 can be deployed on a single local device (e.g., a desktop computer) as a local web-based application.

Turning now to FIG. 2, presented are some example types of clinical patient data 106 and non-clinical patient data 108 that can be used as input to forecast patient discharge events and needs in accordance with one or more embodiments of the disclosed subject matter. In this regard, the one or more discharge destination forecasting models 126 and/or the one or more LOS forecasting models 132, the one or more readmission risk forecasting models 138, and the one or more safety risk forecasting models 144 can respectively be configured to predict their corresponding care outcomes based on a plurality of defined clinical features included in the clinical patient data 106 and defined non-clinical features included in non-clinical patient data 108.

With reference to FIG. 2 in view of FIGS. 1A and 1B, in one or more embodiments, the clinical patient data 106 can be grouped into medical history data 202 and current visit data 204. The medical history data 202 can include medical history information for currently admitted patients and past patients, such as that provided in by one or more EHR databases and systems. For example, the patient medical history information can include internal medical history information for patients associated with a single healthcare organization, as well as medical history information aggregated for patients across various disparate healthcare organizations/vendors (e.g., internal and third-party organizations/vendors) and accessed via a healthcare information exchange system (HIE). Some clinical features included in the medical history data 202 that can be used as input to one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 132 and/or the one or more safety risk forecasting models 144 can include but are not limited to: comorbidities, ongoing illnesses (including mental illnesses), past diagnoses, past hospital stays and associated LOS, past intensive care unit (ICU) stays, past surgeries, regular and acute medications taken, and whether the patient has any implanted medical devices (IMDs) and if so, the type and location of the IMDs.

The current visit data 204 can include clinical information regarding a patient's current inpatient stay from the time of admission to the time of discharge. The current visit data 204 is divided into initial admissions data 206, care progression data 208 and case worker data 210. The initial admissions data 206 can include known clinical information about a patient collected at or near the time of admission of the patient, including information regarding the context of admission (e.g., where, when, and why the patient was admitted), the state of the patient at or near the time of admission, and the initial clinical care ordered and/or provided to the patient at or near the time of admission. Some clinical features included in the initial admissions data 206 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 132 and/or the one or more safety risk forecasting models 144, can include but are not limited to: admission time, admission entry point (e.g., emergency room, elective, transfer, scheduled surgery, etc.), primary diagnosis, initial treatment provided (e.g., surgical procedures, diagnostic tests, medications administered, etc.), initial clinical orders, patient status and reported symptoms upon admission, initial care plan or care pathway prescribed, and the like. In some implementations, the initial admissions data can also include a measure of medical complexity, severity or risk determined for the patient which can be used as input to the respective care outcome forecasting models. The initial admission data can be received from various sources or systems. For example, the initial admissions data 206 can be provided by and/or extracted from (e.g., via the collection component 110) admission forms (e.g., filled out by the patient or another person accompanying the patient), from clinical data entry systems, from clinical notes (e.g., written, spoken and recorded, etc.), from electronic scheduling systems (e.g., providing information regarding scheduled procedures and clinical events), and the like.

The care progression data 210 can include clinical information regarding a patient's status, location, and treatment over the course of the patient's stay. In this regard, the care progression data 208 can provide a timeline of the patient's stay that tracks relevant information regarding the clinical treatment received and scheduled, the patient's status, and the patient's location (e.g., care unit) as a function of time. Some clinical features included in the care progression data 208 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 132 and/or the one or more safety risk forecasting models 144, can include but are not limited to: current diagnosis, current patient status, current patient location and duration at that location, medical treatment received (e.g., procedures performed, medications administered, etc.,), clinicians involved in provision of the treatment (e.g., ordering physician, attending physician, nurses, etc.), laboratory tests conducted (e.g., including type, timing and results reported), imaging studies performed (e.g., including type, timing and results reported), other diagnostic tests performed, unit transfers, and occurrence of other defined medical events. In various embodiments, this care progression data 208 can be reported and received in real-time over the course of the patient's stay. For example, this care progression data can be provided by and/or extracted from (e.g., via the collection component 110), from clinical data entry systems, from clinical notes (e.g., written, spoken and recorded, etc.), from electronic scheduling systems (e.g., providing information regarding scheduled procedures and clinical events), from clinical ordering systems, from medical imaging systems, from laboratory reporting systems, and the like.

The care progression data 208 can also include tracked physiological parameters regarding a patient's physiological state (e.g., vital signs and other measurable physiological parameters) captured at one or more timepoints over the course of the patient's stay. In various embodiments, these physiological parameters can be received in real-time (or substantially real-time) from one or more medical monitoring devices, biofeedback devices and/or audio/visual monitoring devices.

For example, FIG. 3 presents a chart 300 that provides some example clinical data points that can be collected as care progression data 208 for a patient over an inpatient stay in accordance with one or more embodiments of the disclosed subject matter. In accordance with the example shown in chart 300, the clinical data points tracked include treatment unit, diagnosis, imaging studies performed (e.g., including type/modality), surgeries performed, laboratory tests performed and the results (e.g., hematocrit, creatinine, etc.), and patient vitals. These parameters are tracked as a function of time (e.g., which can be in hours, days, or another suitable sampling frequency). For example, each square along the treatment unit timeline can represent a specific unit where the patient was located at the corresponding time. The respective squares along the diagnosis timeline can represent a specific diagnosis code that corresponds the patient's diagnosis (or diagnoses) at the corresponding time. The respective square along the imaging timeline can represent a specific type of imaging study (including modality) that was performed at the corresponding time. For example, certain types of imaging studies are more costly, more invasive, and/or more disruptive (e.g., with respect to radiation exposure) than others, and are only performed if warranted given the context of the patient's medical needs and state. Thus, the specific types of imaging studies performed and the respective times at which they are performed can correlate to the patient's medical needs and state which can further correlate to the patient's discharge disposition, LOS, readmission risk, and/or safety risks.

The respective squares along the surgeries timeline can further represent a particular type of surgical procedure (or another non type of procedure if not surgical) performed at the corresponding time. Each square along the labs timeline can represent a specific type of laboratory reading that was conducted and values of the measured parameter(s). Similarly, each square along the vitals timeline can represent a different measured physiological parameter and the corresponding parameter value captured at the respective times.

In various embodiments, the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 132 and/or the one or more safety risk forecasting models 144, can be configured to process these data points as input (e.g., and other parameters described herein, including medical history data 204 parameters, initial admission data 206 parameters, case worker data 210 parameters, and various non-clinical patient data 108 parameters) to predict the monitored patient's care outcomes (e.g., the discharge trajectory including one more discharge destinations and corresponding likelihood of placement there, expected discharge time/date or total LOS, readmission risk and/or safety risks). For example, in some implementations, the data collection component 112 can collect receive, or otherwise extract these data points over the course of a patient's care. The discharge destination forecasting component 128, the LOS forecasting component 134, the readmission risk forecasting component 140 and/or the safety risk forecasting component 146 can further establish defined sets or groups of the data points for input to their respective models, wherein each defined set or group of the data points reflects a period of time up to the current point in time at which the models are applied.

For example, the discharge destination forecasting component 128 can be configured to apply the one or more discharge destination forecasting models to a first set of input parameters reflective of the data points collected from time (t0) to time (t1) to generate a first discharge destination forecast. After some time passes and additional data points are received, the discharge destination forecasting component 128 can be configured to apply the one or more discharge destination forecasting models to a second set of input parameters reflective of the data points collected from time (t0) to time (t2) to generate a second (updated) discharge destination forecast that reflects all the data points collected thus far, and so on. The LOS forecasting component 134 can apply the one or more LOS forecasting models to data sets collected in a same or similar fashion. The reporting component 116 can further report the most up to date discharge trajectory forecast and/or LOS forecast.

In some implementations, the frequency at which the models are applied can be fixed (e.g., every 30 minutes, every hour, every 24 hours, every 48 hours, etc.). In other implementations, the discharge destination forecasting component 128, the LOS forecasting component 134, the readmission risk forecasting component 140 and/or the safety risk forecasting component 146 can be configured to apply their respective models in response to reception of a new data point reflective of the occurrence of a new clinical event for a monitored patient (e.g., a unit transfer, a surgery performed, an imaging study conducted, etc.) and/or a significant change (e.g., relative to a defined degree of change) in a previously monitored parameter (e.g., a spike in temperature, a decrease in heart rate (HR), etc.).

In some embodiments, the discharge destination forecasting component 128, the LOS forecasting component 134, the readmission risk forecasting component 140 and/or the safety risk forecasting component 146, can calculate certain input parameter values that involve a time component based on the data points collected up to a current point in time (e.g., at which the models are applied) as appropriate. For example, in some implementations, the model input parameter values can include a duration of time associated with a monitored parameter (e.g., duration of time in the ICU unit, duration of time between surgeries, etc.,), a frequency associated with a monitored parameter (e.g., frequency of procure X, number of imaging studies performed, etc.), and/or a degree of change/variance in a monitored parameter. With these embodiments, the discharge destination forecasting component 128, the LOS forecasting component 134, the readmission risk forecasting component 140 and/or the safety risk forecasting component 146, can calculate the parameter input values based on the received data points prior to input into their respective models.

With reference again to FIG. 2, the case worker data 210 can include information provided by a case worker (or the like) that is involved with a patient's care. The case worker data can be received and extracted from notes, files, reports and the like provided by the case worker over the course of the patient's inpatient stay. For example, some patients, particularly complex needs patients, can be assigned a case worker to serve as a liaison for the patient and the different services they receive in and out of the hospital. Case workers can perform tasks including determining initial discharge plans and tracking and coordinating care activities, such as arranging dialysis for a patient post discharge. The case worker often works with the patient and the service provides in the community to coordinate and arrange these care activities. Case workers can also provide feedback regarding a patient's care needs, behaviors, capabilities (e.g., capabilities to care for oneself), and mental status. For example, a case worker can report information regarding specialty care requirements of a patient, such as whether a patient requires ventilator care, hemodialysis, chemotherapy, radiation therapy, wound vacuums, and/or has mental health care needs. In another example, a case worker can report information regarding a specialty diet of a patient, whether a patient requires medical shots to be administered, whether a patient has bandage change needs, and the like. Case workers further provide documentation regarding their involvement in the patient's care (e.g., as notes, activity logs, formalized reports, or the like). For example, case workers can provide documentation regarding their discharge plans, coordinated care activities, and observed patient care needs, behavior, capabilities, mental status, etc. In this regard, some clinical features included in the case worker data 210 that can be extracted from the case worker documentation and used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: patient care needs, medical equipment needs, care activities scheduled, care activities performed, recommended discharge disposition, discharge activities scheduled, transportation arrangements, patient capabilities, patient mental status, patient behaviors, and the like.

The non-clinical patient data 108 can include various additional features that can influence or indicate the type of post discharge care a patient will need and/or can obtain from a personal, social, logical, economic and family support perspective. For example, in the embodiment shown, the non-clinical patient data 108 can include demographics data 212, socioeconomic data 214, insurance data 216, personal patient support data 218, patient preferences data 220 and patient lifestyle data 222.

The demographics data 212 can include several demographic features about a patient, such as those provided in admit, discharge and transfer (ADT) feeds, EHR databases and systems, admission forms, and the like. Some non-clinical features included in the demographics data 212 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: patient age, gender, height, weight, body mass index (BMI), ethnicity/race, religion, language, marital status, nationality, birth location (e.g., country, state and/or city), and current residence location (e.g., country, state and/or city).

The socioeconomic data 214 can include social and economic factors about a patient. For example, some non-clinical features included in the socioeconomic data 214 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: education level, occupation, income level per capita, median household income, debt, net worth, credit score, assets, home zip code, rural-urban community area (RUCA) code associated with the patient's current home location, criminal background (e.g., arrests, convictions, etc.), living family members (e.g., spouse, parents, grandparents, siblings, children, grandchildren), family member ethnicities, number of siblings, number of children, number of grandchildren, next of kin, emergency contact type, emergency contact person, and the like.

The insurance data 216 can include information regarding a patient's medical insurance, (including whether the patient has medical insurance), that can control if a patient can receive certain services, where they can receive them, costs of services, and the like. In this regard, some non-clinical features included in the insurance data 216 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: whether the patient is insured or uninsured, insurance provider, insurance plan type, and parameters regarding plan coverage benefits and restrictions.

The personal patient support data 218 can include information regarding who (if anyone besides that patient), will be responsible for caring for the patient from the point of discharge. This can include family, friends, case workers, or another individual (or group of individuals) that is hired or volunteered help. In some implementations, the personal patient support data 218 can also include information regarding the patient's home environment or living arrangements (e.g., including type, structural features such as stairs/elevators, location, and other individuals that live there). The personal patient support data 218 can also include factors regarding capabilities of the patient to care for oneself post-discharge. In this regard, some non-clinical features included in the personal patient support data 218 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: whether the patient has anyone that will be responsible for the patient post-discharge, relationship of the person or persons responsible for the patient to the patient (e.g., friend, family member, type of family member), age of person or persons responsible for the patient, whether the patient has transportation, whether the patient lives alone, who lives with the patient (e.g., friends, family members, live in nurse, etc.), type of home environment (e.g., house, apartment), location of home environment, whether the home environment requires the patient to use stairs or an elevator, whether the patient is capable of performing daily life activities (e.g., feeding oneself, bathing oneself, clothing oneself, etc.), and mobility of the patient (e.g., ability to walk, requires a walker, requires crutches, requires a wheelchair, etc.).

The patient preferences data 220 can include patient preferences regarding where, when, how and by whom the patient would prefer to receive various medical services. For example, some non-clinical features included in the patient preferences data 220 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: preferred discharge destination, preferred providers, preferred scheduling times for appointments, and preferred characteristics of the caregivers involved in the patient's care.

The patient lifestyle data 222 can include information regarding patient lifestyle activities and behaviors that can have an impact on the patient's medical condition or state during and after discharge. For example, some non-clinical features included in the patient preferences data 220 that can be used as input to the one or more discharge destination forecasting models 126, the one or more of LOS forecasting models 132, the one or more readmission risk forecasting models 138 and/or the safety risk forecasting models 144, can include but are not limited to: frequency/amount of tobacco smoking, frequency/amount of alcohol use, frequency/amount and type of other recreational drug use, frequency/amount and type of exercise, recent foreign travel, and exposure to environmental pathogens through recreational activities or pets.

FIG. 4 illustrates a block diagram of another example, non-limiting system 400 for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter. System 400 includes same or similar features as system 100 with the addition of complex patient identification component 402 to the patient discharge planning module 110 and information regarding complex patients 404 to the output data 120. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

In one or more embodiments, the complex patient identification component 402 can identify currently admitted patients that are considered to be complex needs patients and/or expected to become complex needs patients (also generally referred to herein as “complex patients”). In this regard, a portion of the patients currently admitted to a hospital (or another inpatient facility) can be considered complex needs patients. These patients require more care and resources during their hospital stay and after their discharge from the hospital. Identifying such type of patients early and managing their care during their hospital stay and after their discharge can significantly improve the care delivery for these patients. This will lead to reduced readmissions and hospital stays. However, identifying such patients early faces multiple challenges.

The complex patient identification component 402 can employ various techniques to identify complex needs patients early into their admission based on the unique array of clinical and non-clinical input parameters discussed herein (with reference to FIG. 2). In some embodiments, the complex patient identification component 402 can employ machine learning methods, qualitative methods or combination thereof (e.g., a hybrid of machine learning and qualitative methods), to identify complex patients based on the forecasts generated by the care outcomes forecasting component 114 (e.g., the discharge destination forecasts 130, the discharge time/LOS forecasts 136, the readmission risk forecasts 142 and the safety risk forecasts 148). With these embodiments, the complex patient identification component 402 can employ the output of the care outcomes forecasting component 114 to identify patients that are or are likely to become complex needs patients. In other embodiments, the complex patient identification component 402 can employ machine learning methods, qualitative methods or combination thereof (e.g., a hybrid of machine learning and qualitative methods), to identify complex patients based on defined clinical and non-clinical parameters extracted from the input data 104 (e.g., parameters regarding medical complexity, socio-economic conditions, insurance, medications, behavioral characteristics, mental health characteristics, etc.).

In this regard, in some implementations, the complex patient identification component 402 can determine whether a currently admitted patient is a complex needs patient (or not) based on their forecasted discharge destination(s) and placement probability. For example, certain defined discharge destinations can be associated with complex needs patients. In one implementation of this embodiment, the complex needs patient identification component 402 can classify all patients that receive a predicted discharge destination to one that is associated with complex needs patients, as complex needs patients. For example, the complex patient identification component 402 can classify all patients that receive a forecasted discharge destination to a LTAC disposition as complex needs patients based on previously defined information associating the LTAC disposition with complex needs patients. In another implementation, the complex patient identification component 402 can also determine whether a patient is a complex needs patient based on whether the predicted probability of the patient being discharged to a disposition included in the complex needs group is above a defined probability threshold. For example, the complex patient identification component 402 can classify all patients that receive a forecasted discharge destination to a LTAC disposition with a probability of 70% or higher as complex needs patients based on previously defined information associating the LTAC.

In another embodiment, in addition to, (or alternative to), determining whether a currently admitted patient is or is likely to become a complex needs patient based on their discharge destination forecast 130, the complex patient identification component 402 can determine whether a patient is considered a complex needs patient or likely to become a complex needs patient based on a variety of other criteria. For example, in some implementations, the other criteria can include the patient's discharge time forecast 136, patient readmission risk forecast 142 and/or the patients safety risk forecast 148. In another implementation, the other criteria can include one or more of the clinical and non-clinical factors discussed herein with reference to FIG. 2, including but not limited to: one or more medical history factors discussed herein, one or more initial admissions data factors discussed herein, one or more care progression data factors discussed herein, one or more case worker data factors discussed herein, one or more demographic factors discussed herein, one or more socioeconomic factors discussed herein, one or more insurance factors discussed herein, one or more personal patient support factors discussed herein, one or more patient preferences factors discussed herein and/or one or more patient lifestyle factors discussed herein. In this regard, as the data collection component 112 collects, extracts or otherwise receives input data 104 about a currently admitted patient over the course of the patient's stay and/or the care outcomes forecasting component 114 generates predicated care outcomes data (e.g., discharge destination forecasts 130), discharge time forecasts 136, patient readmission risk forecasts 142 and/or the patients safety risk forecast 148), the complex patient identification component 402 can evaluate and reevaluate the aggregated data to determine whether the patient is or is likely to be considered a complex needs patient.

In some implementations of these embodiments, the complex patient identification component 402 can employ one or more machine learning techniques to learn correlations between the various discharge care outcomes (e.g., discharge destinations and associated probabilities, LOS, readmission risk, safety risks, etc.), clinical factors, and non-clinical factors described herein and patients historically considered complex needs patients to facilitate determining whether a currently admitted patient should be classified as a complex needs patient. For example, the complex patient identification component 402 can learn correlations between discharge destinations, LOS, readmission risk, and/or safety risks, to a patient being classified as complex needs. In another example, the complex patient identification component 402 can learn what specific combinations of the clinical and non-clinical parameters (and the parameter values) included in the input data 104 correlate to a patient considered to be complex needs. The complex patient identification component 402 can further develop one or more complex patient classification models configured to classify a patient as complex needs or not based on the learned correlations. The complex patient identification component 402 can further apply the one or more classification models to the input data 104 collected for an admitted patient (and in some implementations the predicted discharge dispositions/probabilities and LOS values determined for the patient) to classify the patient complex needs or not.

In another embodiment, the complex patient identification component 402 can filter the currently admitted patients based on their forecasted discharge destination, LOS, readmission risk and/or safety risks, or another defined criterion (e.g., medical complexity, diagnosis, comorbidity, etc.) to generate a smaller more refined subgroup of patients to evaluate for classification as complex needs or not. For example, the complex needs classification component 402 can filter out all patients predicted to be discharged home or select only those patients predicted to be discharged to one or more defined post-acute care dispositions that generally receive complex needs patients. The complex needs classification component 402 can also filter and select the currently admitted patients based on the LOS exceeding a defined number of days. With these embodiments, the complex needs classification component 402 can then evaluate only the filtered subgroup of patients based on one or more additional defined criteria (e.g., clinical and/or non-clinical factors) and/or using the one or more classification models to determine which patients included in the subgroup to classify as complex needs.

In another embodiment, the complex patient identification component 402 can be configured to identify complex needs patients using machine learning, qualitative and/or hybrid techniques based on defined clinical and non-clinical factors extracted from the input data 104 (e.g., including parameters regarding medical complexity, socio-economic conditions, insurance, medications, behavioral characteristics, mental health characteristics, etc.). The care outcomes forecasting component 114 can further be configured to only evaluate those patients classified as complex needs patients to determine predicted care outcomes 122 for those patients. With these embodiments, the respective care outcomes forecasting models (e.g., the one or more discharge destination forecasting models 126, the one or more LOS forecasting models 132, the one or more readmission risk forecasting model 138, and/or the one or more safety risk forecasting models 144), can be specifically trained/configured to evaluate input parameters (and associated values) for the target patient population of complex needs patients.

In some embodiments, the complex patient identification component 402 can also employ machine learning methods, qualitative methods, or hybrid techniques to identify relevant clinical factors collected for a currently admitted patient (e.g., via the data collection component 112) that strongly influence the patient being classified as complex needs and/or that require clinical attention (e.g., during the patient stay and/or post-discharge). For example, the complex patient identification component 402 can identify specific care needs of the complex patient that significantly contribute (e.g., relative to other factors) to them being classified as complex (e.g., needing hemodialysis, chemotherapy, radiation therapy, wound vacuums, and mental health care needs, having a physical disability, etc.). In another example, the complex patient identification component 402 can identify clinical factors that require coordination and scheduling for the complex needs patient during and/or post-discharge (e.g., the patient needs dialysis before and after discharge along with nursing support, the patient needs oxygen before and after discharge along with equipment support etc.). These relevant factors can be predefined and/or learned using one or more machine learning techniques. In some implementations, these strong contributing factors can be given higher weight in the complex needs classification model.

The reporting component 116 can further include information regarding those currently admitted patients classified as complex in the output data 120. For example, in the embodiment shown, this information is depicted as complex patients 404 information. In some implementations, if determined, the complex patient 404 information can also include information describing the relevant clinical factors that strongly influence the patient being classified as complex and/or require clinical attention. In some embodiments in which the output data 120 is presented in a display tile (e.g., as a visualization or GUI) at one or more user devices 122 to entities involved in the patients care, the display component 118 can visually distinguish or otherwise call attention to those patients classified as complex. In this regard, complex patients can be flagged or otherwise called to attention to facilitate better managing and coordinating their care needs during and after their inpatient stay.

For example, FIG. 5 presents an example visualization 500 reporting identified complex patients and their forecasted discharge dispositions in accordance with one or more embodiments of the disclosed subject matter. Visualization 500 provides an example display that can be generated by the display component 118 based on the output data 120 as generated/determined using the techniques described herein. In the embodiment shown, the visualization 500 identifies three currently admitted patients (names abbreviated) that have been classified as complex patients and forecasted to need post-acute placement. The left side of the visualization 500 provides some high-relevant information for each patient, including their medical record number (MRN), current department and unit number (e.g., medical (MED), neurological (NEURO), and insurance (INS) provider. As shown in FIG. 5, in some implementations, uninsured patients can be flagged. The visualization also includes information identifying the respective patients' admission (ADM) date, current LOS, and estimated departure date (EDD). As shown in FIG. 5, in some implementations, uninsured patients without an EDD can be flagged. The visualization also includes symbols that respectively represent medical reasons contributing to their classification as a complex needs patient. In other implementations, text descriptions can be used instead and/or in addition to the symbols. The left side of the visualization 500 further provides information regarding the forecasted discharge dispositions of the respective patients and probabilities indicating the expected likelihood of discharge to the respective dispositions. The far-right side of the visualization further includes the discharge dispositions predicted for the respective patients and associated placement probabilities indicating the likely of placement. The predicted discharge dispositions include a skilled nursing facility (SNF), long-term acute care (LTAC), and rehabilitation (REHAB). In this regard, with this example, two different discharge dispositions are predicted for each patient. However, in practice, the number of discharge dispositions predicted for each patient can vary from one or more.

FIG. 6 illustrates a block diagram of another example, non-limiting system 600 for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter. System 600 includes same or similar features as system 400 with the addition of optimization component 602 and optimization information 604 to the patient discharge planning module 110. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

In one or more embodiments, the disclosed care outcomes forecasting techniques can employ an ensemble machine learning approach that involves chaining and/or stacking of a plurality of different predictive models and employing the aggregated outputs of all the different models to converge on a final optimized prediction. With these embodiments, the respective forecasting models (e.g., the discharge destination foresting models 126, the LOS forecasting models 132, the readmission risk forecasting models 138 and/or the safety risk forecasting models 144) can include a plurality of different models respectively configured to forecast their corresponding patient care outcomes based on different combinations of clinical and/or non-clinical factors (e.g., different input parameters), using different weighting schemes for one or more of the input parameters, and/or using different types of machine learning algorithms/models. With these embodiments, the optimization component 602 can combine/aggregate and evaluate the outputs of the individual models to generate an optimized care outcome forecast. In accordance with these embodiments, the predicted care outcomes 122 can comprise optimized discharge destination forecasts, optimized discharge time/LOS forecasts 136, optimized readmission risk forecasts 142 and/or optimized safety risk forecasts 148). predictions. Information that controls how the optimization component 602 combines the aggregated care outcome predictions to generate the optimized care outcome forecasts can be defined in an optimization information 604 data store.

In this regard, FIG. 7 presents a flow diagram 700 illustrating an ensemble-based machine learning approach for forecasting patient discharge destinations in accordance with one or more embodiments of the disclosed subject matter. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

With reference to FIG. 7 and FIG. 1B, in the embodiment shown, a plurality of different discharge destination forecasting machine learning models are used to generate intermediate discharge destination forecasts for currently admitted patients based on the input data 104. These different models are respectively identified as discharge destination forecasting model 126₁, discharge destination forecasting model 126₂, discharge destination forecasting model 126₃, and discharge destination forecasting model 126_N, (wherein N can represent any integer). The number of different discharge destination models can vary. The intermediate discharge destination forecasts determined/output by the respective models are identified as intermediate discharge destination forecast 702₁, intermediate discharge destination forecast 702₂, intermediate discharge destination forecast 702₃, and so on up to intermediate discharge destination forecast 702_N. Each (or in some implementations one or more) of the intermediate discharge destination forecasts 702_1-N, can include one or more predicted discharged destinations/dispositions where a currently admitted patient may be discharged to, and in some implementations, placement probabilities indicating the predicted likelihood of the patient being admitted to the one or more discharge destinations/dispositions.

In some embodiments, the different discharge destination forecasting models can be trained/configured to process different sets of input parameters included in the input data 104. For example, the first discharge destination forecasting model 126₁can be trained/configured determine a first intermediate discharge destination forecast 702₁based on a first set of clinical and/or non-clinical factors, the second discharge destination forecasting model 126₂can be trained/configured determine a second intermediate discharge destination forecast 702₂based on a second set of clinical and/or non-clinical factors, the third discharge destination forecasting model 126₃can be trained/configured determine a third intermediate discharge destination forecast 702₃based on a third set of clinical and/or non-clinical factors, and so on. With these embodiments, the discharge destination forecasting component 128 (or the data collection component 112) can identify and extract the different sets of input parameters from the input data 104. The discharge destination forecasting component 128 can then apply the respective models to the specific input parameter sets they are respectively configured to process to generate the respective intermediate discharge destination forecasts.

The usage of different models respectively configured to make discharge predictions using different sets of input parameters enables a stacked machine learning approach, wherein the discharge destination forecasting component 128 can call and apply certain models based on the available data for a particular patient at current point in time when a discharge prediction is being made. For example, over the course of a patients' inpatient stay, new input data 104 can be received (e.g., care progression data 2018, case worker data 210, etc.) at different times. In addition, some input parameters values required by a particular model may not be received/provided for a patient (e.g., because the input parameter does not apply to the patient and/or is not included in the input data 104 collected for that patient). In this regard, in one or more embodiments, the discharge destination forecasting component 128 can evaluate all the input data 104 received for a patient up to a current point in time when a discharge disposition forecast is being made (e.g., by request, as scheduled, in response to a trigger event, etc.) to determine which discharge destination forecasting models can be applied based on whether the collective input data 104 includes all (or most) of the respective models' required input parameter values. Accordingly, the specific discharge destination models that are used for a particular patient at a given point in time will depend on the collective input data received, which can vary from patient to patient and vary as a function of time progression over the course of their inpatient stay. This approach can result in generating highly personalized discharge disposition forecasts that are tailored to a patient's individual case and needs at a current point in the inpatient stay.

In other implementations, the different discharge destination forecasting models 702_1-N, can also (or alternatively) include two or more models respectively configured to process the same input parameter set, yet apply a different weighting scheme for the parameters. For example, one model can apply a weighting scheme that is biased (e.g., gives more weight to) toward clinical factors as opposed to non-clinical factors, while another model can apply a different weighting scheme that is biased toward non-clinical factors as opposed to clinical factors.

In another implementation, the different discharge destination forecasting models 702_1-N, can also (or alternatively) include different types of machine learning models. For example, the different types of machine learning models can include but are not limited to: a nearest neighbor model, a naïve Bayes model, a decision tree model, a boosting model, a gradient boosting model, a linear regression model, a neural network model, a k-means clustering model, an association rules model, a q-learning model, a temporal difference model, a deep adversarial network model, or a combination thereof. The optimization component 602 can further combine/fuse the different output predictions in accordance with a defined weighting scheme to generate a final output prediction that balances the strengths and weaknesses of the different types of machine learning models.

In accordance with flow diagram 700, at 704 the optimization component 602 can aggregate the intermediate discharge destination forecasts. At 706, the optimization component 602 can further determine an optimized discharge destination forecast 708 for the patient based on the aggregated intermediate discharge destination forecasts, defined discharge constraints, and/or defined optimization criteria. In this regard, the defined optimization criteria can include information that controls how the optimization component 602 should combine the aggregated outputs to generate the generate the optimized discharge disposition forecast 708. For example, in some embodiments, the optimization criteria can define a weighting scheme for applying to the different model predications (e.g., give model 1 predictions X % weight, give model 2 predication Y % weight, etc.). With these embodiments, the optimization component 602 can combine the intermediate discharge destination forecasts based on the defined weighting scheme. In some implementations, the defined weighting scheme applied can be based on learned relevance and accuracy of the respective models for different patient groups (e.g., grouped by diagnosis, demographic factors, insurance factors, socioeconomic factors, etc.). In this regard, different weighting schemes for applying to the respective models can be defined for different patient groups (e.g., for patients included in subgroup A, give model 1 predictions X % weight, give model 2 predication Y % weight, for patients included in subgroup B, give model 1 predictions Y % weight, give model 2 predication Z % weight etc.). The criteria used to group the different patients into subgroups can vary (e.g., grouped by diagnosis, demographic factors, insurance factors, socioeconomic factors, etc.). With these implementations, the optimization component 602 can further apply the appropriate weighting scheme to the respective model outputs based on the specific patient group to which the patient being evaluated belongs. The optimization component 602 can also be configured to determine a discharge destination for a patient based on the number of models that converged on the same or a similar (e.g., with respect to the placement probabilities) result. For example, the optimization component 602 can select the top N (e.g., one, two, etc.) discharge destinations that were most frequently predicted by the collective. The optimization component 602 can also adjust the placement probability for a selected discharge destination based on the different probabilities determined for the same discharge destination by the different models (e.g., use the average of the different probabilities, or the like), as well as the different placement probabilities determined for other discharge destinations.

In some embodiments, the optimization component 602 can also employ defined constraints regarding where and when a patient can be discharged to facilitate determining the optimized discharge destination forecast 708 for a currently admitted patient. For example, the defined discharge constraints can include constraints regarding required care needs of the patient, financial constraints, insurance constraints, regulatory requirement constraints (e.g., defined service level agreements (SLAs)), family support constraints, resource constraints, known barriers to discharge, and the like. For example, in implementations in which the intermediate discharge destination forecasts 702_1-Ninclude different forecasted destinations (e.g., one predicted discharge home, another predicted discharge to SNF, another predicted discharge to LTAC, etc.), the optimization component 602 can eliminate (e.g., rule out) a particular discharge destination based on a defined constraint associated with the patient that prevents the patient from going to that particular discharge destination. (e.g., patient cannot be discharged to disposition “ABC” because it is not covered by the patient's insurance and the patient cannot pay out of pocket). It should be appreciated the defined constraints can include criteria that was not accounted for in the discharge destination forecasting models applied. In various embodiments, the defined constraints can include constraints that are unique/personalized for the particular patient being evaluated.

In one or more additional embodiments in which the intermediate discharge destination forecasts 702_1-Ninclude different forecasted discharge destination options and/or in which the optimization component 602 identifies several discharge destination options where the patient can be discharged (e.g., after applying the defined constraints and any known barriers to discharge), the optimization component 602 can further employ one or more optimization functions to select one or more of the discharge destination options to recommend for placing the patient. For example, the optimization component 602 can determine the most economically feasible option, the most convenient option (e.g., based on location factors, based on timing factors, etc.), the option that provides the highest level/quality of care, the option that best satisfies the patient's preferences (e.g., as included in the patient preference data 220), and the like. In this regard, the optimization component 602 can apply one or more defined optimization functions to facilitate selecting one or more discharge destinations from a group of possible discharge destination options to recommend. The one or more defined optimization function can be configured to satisfy and/or balance one or more defined optimization criterion, including but not limited to: minimize LOS, minimize discharge delay times, minimize costs, optimize patient flow, satisfy patient preferences, minimize recovery time, and minimize travel between required medical appointments.

The disclosed ensemble-based machine learning approach can also be used by the LOS forecasting component 134, the readmission risk forecasting component 140 and/or the safety risk forecasting component 146.

For example, FIG. 8 presents a flow diagram 800 illustrating an ensemble-based machine learning approach for forecasting patient discharge times in accordance with one or more embodiments of the disclosed subject matter.

With reference to FIG. 8 and FIG. 1B, in the embodiment shown, a plurality of different LOS forecasting models are used to generate intermediate discharge time forecasts for currently admitted patients based on the input data 104. These different models are respectively identified as discharge time forecasting model 132₁, discharge time forecasting model 132₂, discharge time forecasting model 132₃, and discharge time forecasting model 132_N, (wherein N can represent any integer). The number of different LOS forecasting models can vary. The intermediate discharge time forecasts determined/output by the respective models are identified as intermediate discharge time forecast 802₁, intermediate discharge time forecast 802₂, intermediate discharge time forecast 802₃, and so on up to intermediate discharge time forecast 802_N. Each (or in some implementations one or more) of the intermediate discharge time forecasts 8021_1-Ncan include one or more predicted discharged times at which the patient is expected to be discharged and/or a predicted LOS. In some implementations in which a discharge time forecast includes two or more possible discharge times, the respective discharge times can also be associated with probabilities indicating the expected likelihood of the patient being discharged at the respective times.

In some embodiments, the different LOS forecasting models 132_1-Ncan be trained/configured to process different sets of input parameters included in the input data 104. For example, the first discharge time forecasting model 132₁can be trained/configured determine a first intermediate discharge time forecast 802₁based on a first set of clinical and/or non-clinical factors, the second discharge time forecasting model 132₂can be trained/configured determine a second intermediate discharge time forecast 802₂based on a second set of clinical and/or non-clinical factors, the third discharge time forecasting model 132₃can be trained/configured determine a third intermediate discharge time forecast 802₃based on a third set of clinical and/or non-clinical factors, and so on. With these embodiments, the LOS forecasting component 134 (or the data collection component 112) can identify and extract the different sets of input parameters from the input data 104 for feeding into the respective LOS forecasting models 132_1-Nto generate the respective intermediate discharge destination forecasts. In this regard, as discussed with respect to the discharge destination forecasting models 126_1-N, as new input parameters are collected for a patient over the course of the patient's stay, the LOS forecasting component 134 can selectively call and apply the appropriate models configured to account for the new input parameters at that time.

In other implementations, the different LOS forecasting models 802_1-N, can also (or alternatively) include two or more models respectively configured to process the same input parameter set, yet apply a different weighting scheme for the parameters. In another implementation, the different discharge destination forecasting models 802_1-N, can also (or alternatively) include different types of machine learning models. For example, the different types of machine learning models can include but are not limited to: a nearest neighbor model, a naïve Bayes model, a decision tree model, a boosting model, a gradient boosting model, a linear regression model, a neural network model, a k-means clustering model, an association rules model, a q-learning model, a temporal difference model, a deep adversarial network model, or a combination thereof. The optimization component 602 further combine/fuse the different output predictions in accordance with a defined weighting scheme to generate a final output prediction that balances the strengths and weaknesses of the different types of machine learning models.

In accordance with flow diagram 800, at 804 the optimization component 602 can aggregate the intermediate discharge time forecasts. At 806, the optimization component 602 can further determine an optimized discharge destination forecast 808 for the patient based on the aggregated intermediate discharge time forecasts, defined discharge constraints, and/or defined optimization criteria. In this regard, the defined optimization criteria can include information that controls how the optimization component 602 should combine the aggregated outputs to generate the generate the optimized discharge time forecast 808. For example, in some embodiments, the optimization criteria can define a weighting scheme for applying to the different model predications (e.g., give model 1 predictions X % weight, give model 2 predication Y % weight, etc.). With these embodiments, the optimization component 602 can combine the intermediate discharge time forecasts based on the defined weighting scheme. In some implementations, the defined weighting scheme applied can be based on learned relevance and accuracy of the respective models for different patient groups. The criteria used to group the different patients into subgroups can vary (e.g., grouped by diagnosis, demographic factors, insurance factors, socioeconomic factors, etc.). With these implementations, the optimization component 602 can further apply the appropriate weighting scheme to the respective model outputs based on the specific patient group to which the patient being evaluated belongs. The optimization component 602 can also be configured to determine an optimal discharge time forecast for a patient based on the number of models that converged on the same or a similar result. In another embodiment, the optimization component 602 can determine an optimal discharge time forecast by taking the mean or median of the different discharge times and/or LOS values generated by the respective models.

In some embodiments, the optimization component 602 can also employ defined constraints regarding where and when a patient can be discharged to facilitate determining the optimized discharge time forecast 808 for a currently admitted patient. For example, the defined discharge constraints can include constraints regarding required care needs of the patient, financial constraints, insurance constraints, regulatory requirement constraints (e.g., defined service level agreements (SLAs)), family support constraints, resource constraints, known barriers to discharge, and the like. For example, a patient's insurance policy can require a patient stay a minimum of N days before discharge to a SNF to be covered. According to this example, the optimization component 602 can eliminate any LOS predictions that are less than N days if the patient has a predicted discharge destination to a SNF with a high probability (e.g., relative to a defined threshold, such as 90% or greater) and the patient is unable or unwilling to pay for the SNF services out of pocket. In various embodiments, the defined constraints can include constraints that are unique/personalized for the particular patient being evaluated.

FIG. 9 illustrates a block diagram of another example, non-limiting system 900 for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter. System 900 includes same or similar features and functionalities as system 600 with the addition of regulation component 902, and feedback component 908 to the patient discharge planning module 110. System 900 also includes the addition of alerts 906 to the output data 120 and input data 910. Although not shown, it should be appreciated that system 900 can also include one or more user devices 122 for receiving and/or rendering the output data 120 and/or facilitating user interaction with the patient discharge planning module 110. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

In some embodiments, the optimization component 602 can receive additional input data 910 including user feedback data 912 and/or system state data 914 to facilitate determining optimized discharge destination forecasts and/or optimized discharge time forecasts. The user feedback data 912 can include information relevant to a patient's discharge provided by one or more individuals involved in the patient's care (e.g., a care provider, a case worker, a family member, a friend, the patient, etc.). For example, the user feedback data 912 can include user reported information identifying barriers to discharge including clinical and non-clinical tasks to be performed and/or scheduled prior to discharge, during discharged and/or following discharge (e.g., arranging dialysis, scheduling a consult, arranging/scheduling transportation, managing dietary requirements, setting up medication delivery, etc.). The user feedback data 912 can also include information regarding completed tasks and/or discharge milestones. The user feedback data 912 can include contextual information regarding arranging and performing check out of the patient from the hospital, including information regarding who will be accompanying the patient away from the hospital, when they will be arriving, how they will be transporting the patient, and the like.

In various embodiments, the feedback component 908 can facilitate receiving user feedback data 912 regarding barriers to discharge (e.g., tasks to be performed), tasks completed (e.g., milestones), tasks scheduled and the like. For example, in some embodiments, the feedback component 908 can include and/or be associated with a patient discharge planning application that facilitates planning a patient's discharge, including managing and coordinating relevant tasks and activities associated a patient's discharge. With these embodiments, the user feedback data 912 can include information received via the patient discharge planning application.

For example, FIG. 10 presents an example GUI 1000 that facilitates receiving user feedback data 912 regarding patient discharge barriers and milestones in accordance with one or more embodiments of the disclosed subject matter. In various embodiments, GUI 1000 is an example GUI that can be generated and/or provided by the feedback component 908 and/or the display component 118 to facilitate coordinating patient care and capturing user feedback (e.g., user feedback data 912) regarding patient care needs, barriers to discharge, and the like.

In accordance with this example implementation, the GUI 1000 can include a pending tasks element management element 1004 that allows a user (e.g., a case worker, a care provider or the like) to select and add tasks that need to be (or are preferred to be) completed for the patient to facilitate smooth discharge and/or to record information regarding completed tasks and/or milestones. These can include tasks to be completed before discharge, as well as tasks to be completed after discharge and/or in association with placing the patient at a particular discharge destination. For example, in the embodiment shown, the tasks and/or milestones are organized into different categories in selectable tabs, including care management, care navigation, imaging, nursing, nutrition, pharmacy, and PTO/OT/SLP. In this example, the care management tab is selected and a list of know tasks that fall into this category are displayed. In some implementations, the specific task options available for selection can be pre-populated based on the patient's forecasted discharge disposition and/or other criteria (e.g., diagnosis, medical history, clinical orders, etc.). The user can further select tasks to add, provide notes and/or comments regarding the selected tasks and the like. All selected and pending tasks for the patient are shown on the left side of the GUI in the pending tasks window 1002. The pending tasks window 1002 can also allow the user to add custom tasks and add notes regarding the pending tasks, mark tasks as completed, remove tasks and the like.

FIG. 11 presents another example GUI 1100 that facilitates planning and coordinating patient discharge events in accordance with one or more embodiments of the disclosed subject matter. In various embodiments, GUI 1100 is another example GUI that can be generated and/or provided by the feedback component 908 and/or the display component 118 to facilitate coordinating patient care and capturing user feedback (e.g., user feedback data 912) regarding patient care needs, barriers to discharge, and the like.

In accordance with this example implementation, the top portion of the GUI 1100 can display information relevant to a selected patient and their forecasted disposition trajectory. For example, top portion of the GUI 1100 includes general patient demographic information, insurance information, physician information, diagnosis in formation, and the like. The top portion of the GUI 1100 also includes information regarding relevant dates, including the admission date, the required discharge data (RDD), the predicted LOS, the expected discharge date (EDD), and pending order dates. The top portion of the GUI 1100 also includes predicted discharge destination options, percent expectancy of discharge to the predicted discharge options, and predicted readmission risk associated with discharge to the respective discharge destinations. In this example, the primary predicted discharge destination is a behavior facility (BH). Other discharge destinations options are not explicitly identified and are grouped together generally. In some implementations, selection of the “other” GUI element can result in presenting information regarding other possible discharge destination options.

The bottom portion of the GUI 1100 includes information regarding known discharge barriers and milestones for a selected discharge disposition. In this example, the behavior facility discharge disposition is selected, and discharge barriers and milestones associated with discharge of the patient to the behavior facility are shown on the right. In various embodiments, information identifying the discharge barriers and milestones displayed in GUI 1100 can be received as user feedback data 912 (e.g., via GUI 1000).

With reference again to FIG. 9, the system state data 914 can include dynamic, real-time information regarding variable conditions associated with the state of the inpatient facility (e.g., hospital) where patients are being discharged from, as well as the state of the discharge destinations where patients are being discharged too, that can influence when and where the patients are discharged. For example, the system state data 914 can include real-time information regarding the operating conditions/contexts of the hospital that vary and can influence when and where a patient is discharged, including information regarding patient flow, bed availability, wait times for beds, and availability of resources (e.g., availability of care providers to assist patients, availability of medical supplies/equipment, availability of transportation services, etc.) and the like. The system state data 914 can also include information regarding the operating conditions/contexts of the respective discharge facilities where patients may be discharged, including information regarding bed availability and demand (e.g., wait times), availability of resources at the respective discharge facilities (e.g., patient needs “xyz” resources at the discharge facility upon arrival but these aren't available, aren't working, have long wait times, etc.) and the like. The system state data 914 can also include real-time information regarding insurance authorization processing, including whether an authorization request is pending, expected time to approval, and the like.

In this regard, in some embodiments, the optimization component 602 can further facilitate determining optimized discharge destinations forecasts, recommending preferred discharged destinations (e.g., when more than one discharge destination can provide the level and type of care a patient requires) and/or determining optimized discharge time forecasts based on the user feedback data 912 and/or the system state data 914. For example, the optimization component 602 can employ information regarding barriers to discharge reported in the user feedback data 912 to identify and select one or more discharge dispositions that account for the barriers (e.g., discharge dispositions that are possible in view of the barriers and/or that minimize or eliminate barriers), and/or to adjust the placement probabilities associated with one or more possible discharge dispositions based on the barriers. The optimization component 602 can also employ information regarding bed availability, wait times, availability of resources, discharge check out arrangements, insurance authorization processing and the like, included in received system state data 914 to identify and select one or more discharge dispositions that account for the factors and/or to adjust the placement probabilities associated with one or more possible discharge dispositions based on the barriers. For example, even once a patient is ready for discharge, it could take days for an insurance provider to review a patient's medical record to authorize discharged to a post-acute care facility. By the time the process is finished, a bed may not be available in the facility of the patient's choice the discharge. In accordance with this example, the optimization component 602 can employ real-time information included in the system state data 914 regarding bed availability at discharge destination options and expected time to receiving insurance authorization for placement to better predict where a patient will be discharged.

The optimization component 602 can similarly adjust the predicted discharge time forecast based on the received user feedback data 912 regarding barriers to discharge and/or completed milestones (e.g., removed barriers), and system state data 914 regarding bed availability, availability of resources, insurance authorization processes, and the like. For example, if there is something preventing a patient from being discharged at a certain time or getting to a forecasted discharge destination (e.g., a reported barrier, unavailability of beds/resources, an insurance processing delay, etc.,), the LOS optimization can increase the predicted discharge time accordingly. In some embodiments, the optimization component 602 can facilitate determining patient discharge times based on the discharge destinations predicted for the respective patients and constraints reported in the user feedback data 912 and the system state data 914 associated with placing the respective patients at the discharge destinations. For example, assume the discharge destination forecasting component 128 and/or the optimization component 602 determines a discharge destination where a patient is likely to be discharged too (e.g., with a placement probability exceeding a threshold probability). Based on this expected discharge destination, the optimization component 602 can identify information included in the user feedback data 912 and/or the system state data 914 that influences when the patient can be discharged to the discharge destination and determine the expected discharge time based in part on these constraints.

In the embodiment shown, the patient discharge planning module 110 can further include a regulation component 902 to facilitate regulating the patient discharge process in accordance with defined rules, requirements and/or expectations. For example, in some implementations, the optimization information 604 can define various rules and requirements that control or influence when and where a patient is discharged. For instance, these rules and requirements can relate to patient care requirements (e.g., regarding where a patient can be discharged, regarding tasks to be completed before discharge, etc.), discharge protocol requirements, insurance policy requirements (e.g., regarding authorizations, regarding minimum and maximum LOS, etc.), SLA requirements (e.g., regarding minimum and maximum LOS, regarding discharge delays, regarding level/type of care provided, etc.), and the like.

In some embodiments, the regulation component 902 can identify violations and/or potential violations to the defined rules and requirements (as defined in the optimization information 604) based on the predicted discharge destinations and/or predicted discharge times, and in some implementations the user feedback data 912 and the system state data 914. The alert component 904 can further generate and provide alerts 906 regarding identified violations and/or potential violations. For example, the regulation component 902 can determine whether placing a patient at a predicted discharge destination violates a level of care requirement, an SLA requirement, an insurance policy, or the like. In another example, the regulation component 902 can determine whether a forecasted discharge time violates one or more rules or requirements defined in the optimization information 604. For example, the regulation component 902 can determine whether a predicted discharge time violates a minimum or maximum LOS requirement for the patient (e.g., defined by SLAs, defined by an insurance policy of the patient, etc.). In another example, the regulation component 902 can determine whether a barrier exists (e.g., reported in the user feedback data 912, and/or included in the system stat data 914 or the input data 104) that inhibits or prevents placing a patient at a forecasted discharge destination and/or that inhibits or prevents placing the patient at the forecasted discharge destination at the forecasted discharge time.

In some implementations, the regulation component 902 can also determine required tasks and/or events that need to occur before a patient can be discharged based on the predicted discharge destination (or destinations) determined for the patient. For example, based on forecasting that a patient will likely (e.g., relative to a threshold placement probability) be discharged to a specific discharge destination, the regulation component 902 can determine one or more uncompleted tasks that need to be performed before the patient can be discharged to that particular discharge destination (e.g., ordering consultations, receiving insurance authorization, arranging oxygen transport, etc.). The alert component 904 can further generate and provide alerts 906 regarding the identified required tasks.

For example, FIG. 12 presents an example visualization 1200 reporting identified patient discharge barriers and associated alerts in accordance with one or more embodiments of the disclosed subject matter. Visualization 1200 provides another example display that can be generated by the display component 118 based on the output data 120 as generated/determined using the techniques described herein. In the embodiment shown, the visualization 1200 identifies three currently admitted patients and general information about the respective patients, including their MRN number, current medical department and unit, and insurance provider. The visualization also includes information regarding the patients' respective admission dates, expected or current LOS, and EDD. Tasks relevant to the patients' discharge are further identified via symbols. In some implementations, these tasks can include required tasks determined by the regulation component 902. The far-right side of the visualization further includes information regarding the patients' discharge status, transfer date and transfer time. In the embodiment shown, if a patients' discharge status is confirmed but barriers exist that prevent discharge (e.g., determined by the regulation component 902), a notification symbol can be displayed (e.g., generated by the alert component 906), as exemplified with the first patient, L.MCA.

FIG. 13 illustrates a block diagram of another example, non-limiting system 1220 for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter. System 1220 includes same or similar features and functionalities as system 900 with the addition of model optimization component 1222. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

In various embodiments, the one or more discharge destination forecasting models 126 and/or the one or more LOS forecasting models 132 can continuously learn and update over time based on new correlations observed between patient discharge destinations and time and the various parameters included in the input data 104 and the input data 910. With these embodiments, the model optimization component 1222 can facilitate training and updating the one or more discharge destination forecasting models 126 and/or the one or more LOS forecasting models 132 over time. For example, in some implementations, the model optimization component 1222 can feed user feedback data 912 regarding identified barriers (e.g., with status tracking), milestones, and associated comments, back into the discharge destination forecasting models 126 and the LOS forecasting models 132 to improve their accuracy. In this regard, the model optimization component 1222 can essentially facilitate a closed loop system where the feedback application also produces data used to improve the accuracy of the discharge destination forecasts and discharge time forecasts.

FIG. 14 illustrates another example, high-level flow diagram of a computer-implemented process 1400 for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

At 1402, a system operatively coupled to a processor (e.g., system 100, system 400, system 600, system 900, system 1200 or the like), employs qualitative and hybrid methods to identify complex patients (e.g., using complex patient identification component 402) included amongst patients currently admitted to a hospital based on a variety of patient information about the patients (e.g., included in input data 104), including information regarding medical complexity, socioeconomic conditions, insurance, medications, behavioral factors and mental health factors. At 1404, the system employs one or more forecasting machine learning models to predict care outcomes for the complex patients based on the patient information (e.g., using care outcomes forecasting component 1414), including remaining length of stay in the hospital, discharge destinations and their likelihoods, readmission risks and safety risks. At 1406, the system provides patient care outcomes information (e.g., predicted care outcomes 122) to one or more care providers to facilitate managing and coordinating inpatient and post-discharge care for the respective patients, wherein patient care outcomes (e.g., via reporting component 116).

FIG. 15 illustrates another example, high-level flow diagram of another computer-implemented process 1500 for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

At 1502, a system operatively coupled to a processor (e.g., system 100, system 400, system 600, system 900, system 1200 or the like), employs one or more discharge forecasting machine learning models (e.g., discharge forecasting models 126) to predict discharge destinations where respective patients that are currently admitted to a hospital will be placed after discharge from the hospital (e.g., using discharge destination forecasting component 128), wherein the one or more discharge forecasting machine learning models predict the discharge destinations based on clinical data points (e.g., clinical patient data 106) and non-clinical data points (e.g., non-clinical patient data 108) collected for the respective patients. At 1504, the system employs one or more LOS forecasting machine learning models (e.g., LOS forecasting model 122) to predict discharge times when the respective patients will be discharged from the hospital based on the clinical data points and the non-clinical data points (e.g., using LOS forecasting component 134). At 1506, the system provides discharge information identifying the discharge destinations predicted for the respective patients to one or more care providers to facilitate managing and coordinating inpatient and post-discharge care for the respective patients (e.g., via reporting component 116).

FIG. 16 illustrates another example, high-level flow diagram of another computer-implemented process 1600 for forecasting patient discharge events and needs using machine learning analytics in accordance with one or more embodiments of the disclosed subject matter. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

At 1602, a system operatively coupled to a processor (e.g., system 400, system 600, system 900, system 1200 or the like), employs one or more discharge forecasting machine learning models (e.g., discharge forecasting models 126) to predict discharge destinations where respective patients that are currently admitted to a hospital will be placed after discharge from the hospital (e.g., using discharge destination forecasting component 128), wherein the one or more discharge forecasting machine learning models predict the discharge destinations based on clinical data points (e.g., clinical patient data 106) and non-clinical data points (e.g., non-clinical patient data 108) collected for the respective patients. At 1604, the system identifies one or more patients of the respective patients that are classified as complex patients based in part on the discharge destinations predicted for the respective patients (e.g., using complex patient identification component 402). At 1606, the system provides discharge information identifying the one or more complex patients (e.g., complex patients data 404) and the discharge destinations predicted for the respective patients to one or more care providers to facilitate managing and coordinating inpatient and post-discharge care for the respective patients (e.g., via reporting component 116).

FIG. 17 presents another example care outcomes forecasting component 1700 in accordance with one or more embodiments of the disclosed subject matter. With reference to FIG. 1A and FIG. 17, in various embodiments the care outcomes forecasting component 114 of the patient discharge planning module 110 of system 100 (and other systems described herein) may include or be replaced with care outcomes forecasting component 1700. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

Similar to care outcomes forecasting component 114, care outcomes forecasting component 1700 can facilitate generating predicted patient care outcomes 122 information for patients represented in the input data 104 as collected by the data collection component 112. However, with these embodiments, the information forecasted by the care outcomes forecasting component 1700 can specifically relate to expected timing of occurrence of defined clinical events. The clinical events can include clinical events for which the timing of occurrence (or non-occurrence thereof) not only varies from patient to patient but can also vary for the same patient over their course of care as conditions change. For example, one type of clinical event satisfying this criterion includes discharge from an inpatient medical facility. Another type of clinical event satisfying this criterion includes development of a particular medical condition (e.g., sepsis, a respiratory disease requiring a ventilator, and other medical conditions).

To facilitate this end, the care outcomes forecasting component 1700 includes a modeling component 1706 that provides for training and generating machine learning models that forecast information regarding expected timing of occurrence (or non-occurrence) of one or more defined clinical events for patients. Trained and initial (e.g., pre-trained) versions of these models as well as information defining the features and parameters of these models can be stored as model data 1724 accessible to the care outcomes forecasting component 1700. The care outcomes forecasting component 1700 can further include or be operatively coupled to a datastore comprising the training data 1722 used by the modeling component 1706 to train and update the respective models over time. In one or more embodiments, the clustering component 1702 and the sampling component 1704 can perform one or more novel training data sampling and curation protocols to generate the training data samples used to train the respective models. Once the models have been trained, the model application component 1714 can apply the respective models to new patient data (e.g., included in the input data) to generate the corresponding inference forecasts the respective models have been trained to generate. The inference forecasts generated by the care outcomes forecasting component 1700 can be reported (e.g., displayed) and processed by the patient discharge planning module in a same or similar manner as described with reference to the predicted care outcomes data 122. Additional details regarding the machine learning models, the training data 1722, the clustering component 1702, the sampling component 1704, the modeling component 1706, the training processes for the respective models, and the model application component 1714 are described further with reference to FIGS. 18-26.

In this regard, FIG. 18 presents a high-level flow diagram of an example process 1800 for forecasting information regarding time until occurrence of clinical events in accordance with one or more embodiments of the disclosed subject matter. With reference to FIGS. 17 and 18, process 1800 corresponds to an example post-model training process that can be performed by the model application component 1714 using one or more machine learning models that have been trained (e.g., via the modeling component 1706) to forecast information regarding expected timing of occurrence (or non-occurrence) of one or more defined clinical events for patients. These models can be stored in the model data 1724 and include one or more classification models 1806, one or more time-to-event models 1812 and one or more event window models 1818.

In accordance with process 1800, at 1802, longitudinal data is collected (e.g., via the data collection component 112) for patients represented in the input data 104 up to a current point in time. For example, the patients can include all currently admitted patients in a hospital or a select subgroup of patients (e.g., selected based on any desired criterion, such as being associated with a specific medical condition, being associated with a particular hospital department/location, etc.). In various embodiments, the longitudinal data provides a timeline of various clinical and non-clinical data points associated with the respective patients over their patient's course of care at an inpatient medical facility. For example, the longitudinal data can comprise clinical patient data 106 and non-clinical patient data 108 gathered for the respective patients from the point of admittance until the current point in time and recorded with timestamp information (where applicable) indicating timing associated with occurrence of corresponding data points. The longitudinal patient data can also include relevant static clinical and non-clinical data for the patient, such as patient demographic data, medical history information, comorbidities, reason for admittance, and so on.

At 1804, the system (e.g., system 100 or the like) can apply (e.g., via classification component 1716) one or more of the classification models 1806 to first selected feature sets included in the collected longitudinal patient data to predict the respective patients patient group classifications 1808 corresponding to an expected timeframe within which a defined clinical event is expected to occur for the patient. The specific feature set to be processed by the one or more classification models 1806 is determined and defined during the model training and development process (as described infra) and will vary depending on the type of the clinical event. The expected timeframe can be based on a number of minutes, hours, days or another defined duration of time, which can also vary depending on the type of the clinical event. For example, in some embodiments in which the defined clinical event comprises discharge of the patient from an inpatient medical facility, the one or more classification models 1806 can be configured to classify patients according to expected LOS timeframes. In various implementations, the expected LOS timeframes can be defined based on the expected number of days the patient will remain inpatient at the facility until discharge. For example, the LOS timeframes may include a first grouping corresponding to 1-3 days, a second grouping corresponding to 3-5 days, a third grouping corresponding to 5-7 days, a fourth grouping corresponding to 7-10 days, and so on. The level of granularity of the respective timeframes can vary.

At 1810, the system (e.g., system 100 or the like) can apply (e.g., via event time predication component 1718) one or more of the time-to-event models 1812 to second selected feature sets included in the collected longitudinal patient data to predict the expected duration of time until occurrence of the clinical event from the current point in time for the respective patients, referred to herein as the expected times to event 1814 forecast. In this regard, as applied to patient discharge from an inpatient facility, the expected time to event 1814 for each patient can correspond to the expected remaining LOS of the patient at the inpatient facility from the current day/point in time of forecast. In this regard, as defined herein, a patient's total LOS at an inpatient facility is defined as the duration of time between the time the patient is admitted to the time the patient is discharged. A patient's remaining LOS is defined as the duration of time from a current point in time (i.e., the prediction time) until the expected discharge time. The remaining LOS prediction can thus identify an expected discharge time (e.g., day and/or time of the day) for the patient and identify or indicate a remaining duration of time the patient is expected to remain at the facility from the current point in time. In various embodiments, the time-to-event prediction generated at 1810 can be based at least in part on the patient group classification predicated at 1804. For example, in some implementations, the specific patient group classification predicated at 1804 can be applied as an input feature to the one or more time-to-event models 1812. Additionally, or alternatively, the one or more time-to-event models 1812 can comprise separate models tailored to the different defined patient group classifications for which the one or more classification models are adapted. For example, as applied to expected LOS groupings, the time-to-event models 1812 can include a first model tailored to forecast expected remaining LOS for patients classified as having an expected LOS between 1-3 days, a second model tailored to forecast expected remaining LOS for patients classified as having an expected LOS between 5-7 days, a third model tailored to forecast expected remaining LOS for patients classified as having an expected LOS between 8-10 days, and so on. With these implementations, the event time predication component 1718 can select and apply the corresponding time-to-event model depending on the patient group classification predicted at 1804.

At 1816, the system (e.g., system 100 or the like) can further predict (e.g., using event window prediction component 1720) the expected time windows 1820 within which the clinical event is expected to occur for each patient (e.g., using the event window predication component 1720). For example, as applied to patient discharge, the expected event windows 1820 can provide a predicted time window range in hours and/or day around the expected discharge time predicted at 1810. As described in greater detail with reference to FIG. 29, in some embodiments, this can involve using one or more event window models 1818. With these embodiments, the one or more event window models 1818 can comprise separate machine learning models trained by the event window modeling component 1712 to forecast the expected event window as a function of prediction intervals using a confidence level associated with the expected time to event 1814 forecast as input. In various embodiments, the expected event windows 1820 predicted at 1816 can also be based at least in part on the patient group classification predicated at 1804. For example, in some implementations, the specific patient group classification predicated at 1804 can be applied as an input feature to the one or more event window models 1818. Additionally, or alternatively, the one or more event window models 1818 can comprise separate models tailored to the different defined patient group classifications for which the one or more classification models are adapted.

Still in other embodiments, during the prediction phase, for every patient in which the system is predicting the remaining LOS (i.e., the time-to-event using the one or more time-to-event models 1812), the system can dynamically pick similar patients based on the sampling and clustering techniques described herein to prepare the prediction dataset for similar patients and run it through corresponding time-to-event models 1812 to estimate their remaining LOS. These estimates from similar patients provide the data distribution that can be used by the event window predication component 1720 to estimate the prediction intervals for a given predicted patient which in turn provides the estimate for the event window.

In various embodiments, process 1800 corresponds to a continuous process that can be repeatedly performed for each of the respective patients over time to generate updated forecasts as conditions change for over time that impact or control the timing of the defined clinical event being forecasted. For example, as applied to expected discharge time, many conditions related to the patient's health condition/status may change over their course of care that can influence when the patient will get discharged, as well as conditions related to the state of operations of the inpatient facility (e.g., availability of resources such as beds, staff and medical equipment/supplies, early/late discharge of other patients, admission of new higher priority patients, etc.), and availability of beds at post-discharge facilities, changes in barriers to discharge, etc. In this regard, as applied to predicting patient discharge timing and other clinical events, the care outcomes forecasting component 1700 can be configured to perform process 1800 for the respective patients once a day (i.e., once every 24 hours) or multiple times a day (e.g., a defined time points throughout the day) to generate updated forecasts for the respective patients as new longitudinal data is collected and aggregated for the respective patients over their course of stay at the inpatient facility.

FIG. 19 presents a high-level flow diagram of an example process 1900 for generating one or more classification models that classify patients into different patient groups as a function of defined timeframes in which a defined clinical event is expected to occur. With reference to FIGS. 17 and 19, process 1900 corresponds to an example process that can be performed by clustering component 1702, the sampling component 1704 and the classification modeling component 1708 to facilitate generating and updating the one or more classification models 1806. As noted above, the one or more classification models 1806 can be trained to classify patients according to defined patient groups corresponding to different defined timeframes within which a defined clinical event is expected to occur for the respective patients. Process 1900 is exemplified wherein the defined clinical event comprises discharge from an inpatient medical facility and wherein the defined timeframes correspond to different defined discharge timeframes (e.g., 1-3 days, 5-7 days, 8-10 days, etc.). However, it should be appreciated that the defined clinical event can vary and include any type of clinical event for which the timing of occurrence (or non-occurrence) varies for a patient as conditions changes over a time. For example, in other embodiments, the defined clinical event may include development of a particular medical condition/disease (e.g., sepsis, a respiratory condition requiring need for a ventilator device, etc.).

Classification is defined as the process of recognition, understanding, and grouping of objects and ideas into preset categories a.k.a “sub-populations.” Classification models (or algorithms) used in machine learning utilize input training data for the purpose of predicting the likelihood or probability that the data that follows will fall into one of the predetermined categories. With the help of these pre-categorized training datasets, classification in machine learning programs leverage a wide range of algorithms to classify future datasets into respective and relevant categories using a supervised machine learning process.

To this end, the classification modeling component 1708 can perform a supervised machine learning process to train the one or more classification models 1806 to classify a patient based on set of data points for that patient into one of the defined timeframe categories in which the clinical event is expected to occur. The set of data points can include clinical and non-clinical attributes or features and included in a data sample for that patient that influence or control timing of occurrence of the clinical event. The data sample can correspond to a longitudinal dataset that tracks at least some of the clinical and non-clinical attributes over time for that patient. For example, the set of data points can include static attributes related to the patient's medical history, demographic profile, reason for admittance, etc., as well as tracked information regarding the timeline of clinical events and conditions that occur over the course of the patient's care.

The training dataset 1906 used to train the one or more classification models 1806 can include historical, longitudinal data samples for past patients that have experienced the defined clinical event. For example, as applied to discharge timing, the training data can include historical data samples for past patients at the specific inpatient medical facility being modeled that have been discharged. The patients represented in the training data should provide a representative distribution of the different classification categories (e.g., patients belonging to different discharge timeframe categories) and the different types of patient profiles and care path conditions associated with each category (e.g., different patient profiles with respect to reason for admittance, demographic profile, disease state/status, care-pathway, timeline of events, etc.).

Process 1900 incorporates a novel training data sampling protocol performed by the clustering component 1702 and the sampling component 1704 to generate this training dataset 1906 from a training data sample pool 1901. In various embodiments, the training data 1722 can include both the training data sample pool 1901 and the training dataset 1906 (and other training datasets described herein). The training data sample pool 1901 can include data samples for all or a large (e.g., tens of thousands, hundreds of thousands, etc.) distribution of historical patients that have experienced the clinical event. The sampling protocol provides for significantly decreasing the size of the training dataset 1906 relative to the size of the training data sample pool 1901, thereby significantly reducing the training time required to train and generate the classification models 1806 (e.g., from months to days). As applied to forecasting discharge timing (i.e., remaining LOS), the sampling protocol further reduces bias that patients with longer LOS introduce and also increases the variance of the training data so that the model can generalize well.

In this regard, at 1902 the clustering component 1702 can cluster (e.g., using k-means clustering or another clustering algorithm) the data samples included in the training data sample pool 1902 into different patient groups a function of different defined timeframes within which the clinical event occurred. For example, as applied to discharge timeframe, the clustering component 1702 can cluster the data samples according to defined discharge timeframe groups (e.g., a first group corresponding to discharge occurring withing 1-3 days, a second group corresponding to discharge occurring within 4-7 days, a third group corresponding to discharge occurring withing 8-10 days, and so on). The number of different defined groups can vary and the level of granularity of the timeframes can vary). At 1904, the sampling component 1704 can select training data samples of the different groups. In this regard, the sampling component 1704 can select representative data samples for each of the groups from the training data sample pool 1901 as clustered at 1902. The number of data samples selected for each group can be restricted to a maximum sample size so as to restrict the size of the training dataset 1906 (e.g., to about 1000 samples total). In some embodiments, at 1904, the clustering component 1702 can further cluster the data samples included in each groups based on related attributes to generate sub-groups of patients with similar attributes and care pathways. The sampling component 1704 can further select representative data samples from each sub-groups to ensure the distribution of patient profiles and care-pathways associated with each discharge timeframe group is diverse. The sampling component 1704 can also employ the sub-groups to select similar patient data samples for training and validation (e.g., to ensure the validation patients are similar to the training patients).

Once the training dataset 1906 has been selected, at 1908, the classification modeling component 1708 can perform feature engineering and feature selection of the feature set (or sets) to be modeled and evaluated (e.g., as input) by the one or more classification models 1806. At 1910, the classification modeling component 1708 can perform the classification model training phase, and at 1912 the classification modeling component 1708 can perform the classification model validation phase. In this regard, in some embodiments, the classification modeling component 1708 can train a single classification model to classify all the patient training data samples, regardless of their discharge timeframe group, into one of the defined discharged timeframes. In other embodiments, the classification modeling component 1708 can train separate classification models for each discharge timeframe group. The type of classification algorithm employed by the one or more classification models can vary. Some suitable classification algorithms can include (but are not limited to), Naïve Bayes, decision trees, K-nearest neighbors. At 1914, the classification modeling component can further calculate the probability threshold for each patient group classification.

FIG. 20 presents a high-level flow diagram of an example process 2000 for generating one or more clinical time-to-event models in accordance with one or more embodiments of the disclosed subject matter. With reference to FIGS. 17 and 20, process 2000 corresponds to an example process that can be performed by the event time modeling component 1710 to generate (e.g., train and/or update) the one or more time-to-event models 1812 for a defined clinical event. Process 2000 can employ the training dataset 1906 sampled from the training data sample pool 1901 using the techniques described above with reference to process 1900. In this regard, as applied to patient discharge forecasting, the training dataset 1906 will comprise representative, longitudinal training data samples for past patients grouped by discharge timeframe classification.

At 2002, the classification modeling component 1708 can perform feature engineering and feature selection of the feature set (or sets) to be modeled and evaluated (e.g., as input) by the one or more time-to-event models 1812. The specific feature set or sets selected at 2002 for processing by the time-to-event models 1812 can be different relative to those selected for the classification models for the same clinical event, as the classification task and relevant features involved is different from the time-to-event prediction task. In this regard, as applied to discharge time prediction, the one or more time-to-event models are being trained to predict the specific discharge time (e.g., as a specific day or specific time/date) that a patient will be discharged. This prediction can be based on a multitude of different clinical and non-clinical attributes associated with each patient and their course of care. As noted above, the training data samples comprise historical data samples for which the actual discharge time of each patient is known and thus provides for training the one or more time to event models 1812 using a supervised machine learning process. In some embodiments, the time-to-event models can include separate models tailored to each patient group classification (e.g., a separate model for each discharge timeframe grouping as applied to predicting discharge time). With these embodiments, the event time modeling component 1710 can perform feature engineering and selection separately for each patient grouping. For example, the features that are most influential in predicting the discharge time for a patient falling into the discharge timeframe grouping of 1-3 days may be different from the features that are most influential in predicting the discharge time for another patient falling into the discharge timeframe grouping of 8-10 days. The feature engineering process at 2002 involves learning, identifying and selecting these relevant feature sets. Additionally, or alternatively, the time-to-event models 1812 can comprise a single model trained to predict the discharge time for any patient regardless of the patient group. With these embodiments, the patient group classification can be integrated into the model as an input feature to further reduce the complexity of the model, the training time and the inferencing speed processing time and processing power. Still in other embodiments, the time-to-event models 1812 can comprise a plurality of sub-models tailored to different points in time within a single 24-hour period (e.g., an 8:00 am model, a noon model, a 5:00 pm model, etc.) to account for different data features received over the course of a single day.

At 2004, the event time modeling component 1710 can perform the time-to-event model training phase using a supervised machine learning process, and at 2006, the event modeling component 1708 can perform the perform the time-to-event model validation phase. In various embodiments, the one or more time-to-event models 1812 can comprise a regression model. In other embodiments, the one or more time-to-event models 1812 can comprise an ensemble model combining a random forest model with a regression tree model. At 2008, the event time modeling component 1710 can further estimate the error threshold for accepting the time-to-event model result.

As applied to forecasting discharge time, the input to the time-to-event model can comprise the defined feature set (as determined at 2002) as extracted from the respective training data samples representing patients at some point in time prior to their discharge, and the output of the model comprises the forecasted discharge times of the patients. In various embodiments, the model training at 2004 can incorporate different feature sets for a same patient representative of different points in time throughout their inpatient stay. Accordingly, the model can be trained to predict the correct remaining time until discharge for the historical patients (which is known at training) regardless of the time at which the forecast is made (e.g., at admission, after passage of 1 day, after passage of 2 days, after passage of 3 days, etc.) and the different data points and attributes known about the patient at the different times of forecast.

Additionally, or alternatively, as applied to forecasting remaining time until discharge, the event time modeling component 1710 can employ a specially curated training dataset that accounts for different “current” days of prediction. With these embodiments, the prediction task of the time-to-event models lies in predicting a patient's remaining LOS from a current point in time of the inpatient stay, which often varies from an initial LOS forecast determined upon admission due to various changes in conditions related to the patient, the operating context of the inpatient medical facility, changes in barriers/obstacles to discharge, and so on. In order to mirror the real machine learning prediction setting, it is imperative to construct a training dataset that incorporates the current dates as an input feature and build the patients' profiles based on it. For a patient's timeline staying in the hospital, each day can be considered as the “current” date for prediction. The sampling protocol used to generate this remaining LOS training dataset described below with reference to FIG. 21 not only decreases the entire training data size while reducing the bias that patients with longer LOS introduce, but also increase the variances of the training data so that the model can generalize well.

In this regard, FIG. 21 presents a high-level flow diagram of an example process 2100 for generating remaining LOS forecasting models with reduced training time and complexity in accordance with one or more embodiments of the disclosed subject matter. With these embodiments, the one or more time-to-event models 1812 correspond to machine learning models trained to estimate the remaining LOS for patients. The training dataset 2108 comprise a specially curated/sampled training dataset that accounts for the “current day” of forecasting as an input feature. Process 2100 assumes all the patients' LOS represented in the training data sample pool 1901 are independent and identically distributed.

With reference to FIGS. 17 and 21, in accordance with process 2100, at 2102, the clustering component 1702 can group the patients represented in the training data sample pool 1901 as a function of their total LOS. The level of granularity of the grouping can vary. In various embodiments, can group the patients based on increments of individual days. For example, FIG. 22 presents a graph 2200 illustrating the LOS distribution for a patient population pool in accordance with one or more embodiments of the disclosed subject matter. With reference to FIGS. 21 and 22, in one or more example implementations, the training data sample pool 1901 can correspond to the patient population plotted in graph 2200. Graph 2200 plots the number of patients with a corresponding total LOS in days. For example, as illustrated in graph 2200, 3207 patients had a total LOS of 1 day, 465 patients had a total LOS of 5 days, and so on.

In accordance with process 2100, at 2104 the sampling component 1704 can further randomly select a number of patients for each LOS day (i.e., each 24 hour period) from the available pool that is proportional to the distribution of the total LOS. At 2106, for each LOS day (i.e., each 24-hour period) and the corresponding selected patients, the sampling component 1704 further generates patient data samples comprising longitudinal data up to the LOS day. The resulting training dataset 2108 comprises representative longitudinal patient data sets for each LOS day. In this regard, the total available data samples for each training patient in the pool includes longitudinal data tracked for the respective patients over their total length of stay at the inpatient medical facility. The training dataset 2108 however is sampled and curated in a manner to generate different subsets of the longitudinal data tracked up to different time points over their total LOS. For example, assuming a patient had a total LOS of three days, they can be associated with three data samples, one with longitudinal data up to day 1, another up to day 2 and another up to day 3. The remainder of process 2100 (i.e., the model training and validation) corresponds to process 2000 yet with the usage of training dataset 2108 instead of training dataset 1906. In some embodiments, the LOS group classification information can also be applied to each training data sample and used as an input feature in association with training the time-to-event (remaining LOS) models 1812.

In this regard, for each current LOS day, the sampling component 1704 can select a random sample of any of the patients in the pool that have a total LOS that includes the current LOS day yet restricts the total sample size for that current LOS based on the density of the LOS distribution for that day. The training data samples for each LOS include clinical and non-clinical data points for the corresponding patients tracked/received only up to the current LOS day. For example, FIG. 22 presents a first table (Table 1) identifying five patients with their respective total LOS days and a second table (Table 2) exemplifying how these five patients can be sampled with respect to 7 LOS days. As illustrated with respect to Table 1 and Table 2, those current days with fewer patients in the available pool (e.g., days 5-7) have fewer samples. In addition, looking at Day 1 for example, the patients sampled include patient 2 (with a total LOS of 1 day), patient 1 (with a total LOS of 3 day) and patient 3 (with a total LOS of 4 days). Day 1 could have included any of the patients 1-5 as all patients have data profiles up to at least Day 1. Those patients selected for Day 1 in this example were randomly selected. Reference to “building the patient's profile up to the current day,” means that the historical longitudinal data for each patient data sample associated with each day only includes those relevant clinical and non-clinical data points that were available at the current day.

In this regard, based on all the patients in the sampling pool, the number of patients drawn for each LOS day is proportional to the distribution of total LOS. When the pool size is larger than the desired sample size for a LOS day, a random sample of the patients is drawn without replacement. When the pool size is smaller than the desired sample size, the entire patient pool for that LOS day is used and a random sample of the patients is drawn without replacement for the remaining sample size. The samples are drawn starting from LOS day 1, and we stop sampling until the total sample with the given size is obtained.

FIG. 24 presents a graph 2400 illustrating the distribution of the current LOS with the sampled patients in accordance with one or more embodiments of the disclosed subject matter. In this regard, graph 2400 gives example of the distribution of the LOS days (current LOS) using sampled data of size 1000 from the patient population pool represented in graph 2100.

FIG. 25 presents a high-level flow diagram of an example process 2500 for generating a training dataset 2506 using a sampling process that facilitates efficient model development in accordance with one or more embodiments of the disclosed subject matter. In various embodiments, training dataset 2506 can correspond to training dataset 1906 and/or training dataset 2108. In this regard, in some embodiments, training dataset 2506 (and the techniques for generating this training dataset 2506 described below) can replace training dataset 1906 of process 1900 and/or training dataset 2108 of process 2100. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

Process 2500 employs a novel sampling process for sampling patient data from the input data 104 in a manner that reduces the size of the training dataset 2506 given a large pool of patients represented in the input data 104 while also minimizing bias attributed to the LOS distribution patient sample pools. In accordance with process 2500, the training dataset 2506 can comprise different subgroups of training datasets comprising patient data samples sampled from different time periods over which the input data 104 is generated. For example, in one or more embodiments, the input data 104 can correspond to a stream of patient data received and aggregated over a course of operation of the inpatient medical facility and the different time periods can correspond to different periods of time or segments of time over the course of operation of the inpatient medical facility (e.g., different 24-hour periods, or another time period segmentation). In other implementations, the different time periods can correspond to different time-periods within a single 24 hour period. For example, time period 1 can correspond to all patient data revied between midnight and 6 am, time period 2 can correspond to all patient data received between 6 am and noon, time period 3 can correspond to all patient data received between noon and 6 pm and time period 4 can correspond to all patient data received between 6 pm and midnight. The break down of the different time-periods can vary and thus the number of different time periods can include essentially any number N of different time periods. The time periods can be predefined.

In this regard, in accordance with process 2500, the input data 104 can be split into different training data sample pools corresponding to the different predefined time periods 1-N, (e.g., training data sample pool 2502₁for time period 1, training data sample pool 2502₂for time period 2, and so on up to training data sample pool 2502_Nfor time period N). Process 2500 further comprises generating different subgroups of training datasets from the respective training data sample pools, including sample patient data for time period 1 (e.g., training data subgroup 2504₁), sample patient data for time period 2 (e.g., training data subgroup 2504₂), and so on up to sample patient data for time period N (e.g., training data subgroup 2504_N). The number of patients sampled in the respective training data subgroups can comprise a portion of the patients represented in the corresponding training data sample pools. These include randomly selected/sampled patients from the corresponding pools. The sample size (e.g., sample size 1, sample size 2, sample size N) of the respective training data subgroups can be the same or different and proportional to the distribution of the total LOS. In some embodiments, each of the different training data subgroups represented in the training dataset 2506 can be used to train and generate different time-to-event models 1812 (e.g., remaining LOS models) associated with the different time periods.

FIG. 26 presents a flow diagram of an example process 2600 for sampling patient data relative to each of the training data subgroups illustrated in FIG. 25 in accordance with one or more embodiments of the disclosed subject matter. Process 2600 is illustrated relative to training data subgroup 2504₁for training data sample pool 2502₁, however it should be appreciated that the same process can be applied for each of the different training data subgroups and sampling pool periods. In accordance with process 2600, at 2602 the sampling component 1704 can estimate the density of the total LOS represented by all the patients in the training data sample pool sample pool 2502₁. At 2604, the sampling component can further randomly sample a number of patients proportional to the distribution of the total LOS. At 2608, for each LOS day and the corresponding selected/sampled patients, the sampling component 1704 can further generate patient data samples comprising longitudinal data up to the LOS day to generate the training data subgroup 2504₁.

FIG. 27 presents a high-level flow diagram of an example process 2700 for predicting the time-to-event and event window using machine learning in accordance with one or more embodiments of the disclosed subject matter. Process 2700 comprises an end-to-end process incorporating the time-to-event model training and development phase (e.g., including training and validation) and the predication phase in which the trained time-to-event models are used to predict the expected time-to-event and event window. Process 2700 is described in association with predicting remaining LOS and the corresponding discharge window. However, it should be appreciated that one or more aspects of process 2700 can be applied to predicting other types of clinical time-to-events and associated timing of occurrence windows.

Process 2700 starts with the training dataset 2506 curated/sampled using the techniques described with reference to FIGS. 25 and 26. In some embodiments, process 2700 can be applied separately to each training data subgroup represented in the training dataset 2506. In accordance with process 2700, at 2702 the event time modeling component 1710 can process the training dataset 2506 (and/or respective training data subgroups) by performing feature engineering, feature selection and dimension reduction for the time-to-event prediction. At 2704, the clustering component 1702 can cluster the training dataset (and/or respective training data subgroups) into different clusters for different defined LOS timeframes, resulting in clustered training dataset 2706 comprising different clusters (e.g., cluster 1, cluster 2, and so on up to cluster N) of patient data samples corresponding to patients with the respective defined LOS timeframes. At 2708, the event time modeling component 1710 can perform the time-to-event model training phase for each cluster. In this regard, the event time modeling component 1710 can generate separate remaining LOS models for each cluster. In some implementations, as described in below with reference to FIG. 28, the remaining LOS model for each cluster can comprise an ensemble model (e.g., as described with reference to FIGS. 7 and 8) comprising a group of different remaining LOS models respectively having different parameters, weights and/or machine learning model types with different strengths and weaknesses. In some implementations of these embodiments, at 2710, the event time modeling component 1710 can estimate the ensemble weights for the respective models.

At 2710 the event time modeling component 1710 can further estimate the quantile thresholds for the event window prediction in association with performing the time-to-event model validation phase based on the level of accuracy in the respective outputs of the models. These quantile thresholds reflect bounds of a confidence level in the model output, which correlates to the estimated time window for occurrence of the event. At 2712, the system (e.g., system 100 or the like) can further perform the predication phase including the time-to-event model predication phase and the event window prediction phase. In various embodiments, the prediction phase involves applying the trained time-to-event models to new patient data samples sampled and clustered in the same manner as the training dataset 2506. In particular, in some embodiments, during the prediction phase, for every patient in the hospital that the system is predicting the remaining LOS, the sampling comment 1702 can dynamically pick similar patients (e.g., patients having clinical and/or non-clinical features) and prepare a prediction dataset for similar patients, run it through the corresponding reaming LOS model (or models) for the LOS cluster to which the similar patient belong and estimate their remaining LOS. In some implementations, the similar patients can include similar patients included in the training dataset 2506 and/or include new patients represented in the input data 104. The remaining LOS estimates from similar patients provide the data distribution to estimate the prediction intervals for the predicted patient which in turn provides estimates for the event window.

FIGS. 28A and 28B present a high-level flow diagram of an example ensemble model process 2800 for predicting the time-to-event and event window using in accordance with one or more embodiments of the disclosed subject matter. Process 2800 provides additional details regarding aspects of the time-to-event model training phase of step 2708 in process 2700 and the prediction phase of step 2712 in process 2700 in embodiments in which the time-to-event (i.e., remaining LOS) for each cluster in the clustered training dataset 2706 comprise an ensemble model. Process 2800 is described relative to a single cluster (e.g., corresponding to patient data samples classified as having a specific defined LOS timeframe, such as 1-3 days, 4-5 days, etc.). It should be appreciated however that process 2800 can separately be applied for each of the different clusters 1-N.

With reference to FIG. 28A, in accordance with process 2800, separate time-to event models 1812_1-N(e.g., remaining LOS models) are trained using random sets of subsamples (e.g., subsamples 1, subsamples 2, and so on up to subsamples N) samples from cluster 1. For example, at 2802₁the time-to-event modeling component can perform remaining LOS model training of time-to-event model 1812₁with random samples 1, at 2802₂the time-to-event modeling component can perform remaining LOS model training of time-to-event model 1812₂with random samples 2, and at 2802_Nthe time-to-event modeling component can perform remaining LOS model training of time-to-event model 1812_Nwith random samples N. Each of the separate models, referred to as time-to event model 1812₁, time-to event model 1812₂, and so on up to time-to event model 1812_N, can differ with respect to model type, input features processes, model architecture, model weights, or another factor.

With reference to FIG. 28B, once the respective time-to-event models have been trained, at 2712, the event prediction component 1718 can perform the time-to-event prediction phase (e.g., step 2712). At 2902₁, the event time prediction component 1718 can apply the LOS model 1812₁to new input data for a patient classified in cluster 1 (e.g., as determined via the classification component 1716 using the one or more classification models 1806) to generate a first intermediate remaining LOS forecast 2904₁for the patient. At 2902₂, the event time prediction component 1718 can apply the LOS model 1812₂to the same new input data for the patient to generate a second intermediate remaining LOS forecast 2904₂for the patient. At 2902_N, the event time prediction component 1718 can apply the LOS model 1812_Nto the same new input data for the patient to generate a final intermediate remaining LOS forecast 2904_Nfor the patient. At 2906, the event time prediction component 1718 can further aggregate the intermediate LOS forecasts for the patient generated from the different models and applied predetermined model weights for the respective forecasts to generate a converged final (e.g., weighted/averaged) aggregated LOS forecast for the patient. At 2910, the event time prediction component 1718 can optionally optimize the ensemble model based on variances between the respective model outputs.

FIG. 29 presents a high-level flow diagram of an example machine learning process 2900 for estimating time windows in which a defined clinical event is expected to occur in accordance with one or more embodiments of the disclosed subject matter. With reference to FIGS. 17 and 29, process 2900 corresponds to an example process that can be performed by the event window modeling component 1712 to generate one or more event window models 1818 configured to estimate a time window around an expected discharge time.

In accordance with process 2900, at 2902, an input confidence level is received to indicate the desired confidence level in the event window model prediction result. The input confidence level is used to define the upper and lower bounds of the input quantiles for the confidence level. For example, if an input confidence level of 70% is selected, the input quantiles include the 90% quantile and the 20% quantile. At 2904, quantile regression tree machine learning training is performed (e.g., via the event window modeling component 1712) for the input quantiles to train and generate the one or more event window models 1818. In one or more embodiments, this can involve a two quantiles regression tree using variance homogeneity as a metric. At 2906, the quantiles are predicted using the one or more event window models 1818. At 2908, the prediction interval is estimated using the predicted quantiles in a manner to ensure that the LOS regression estimate is between the predicted quantiles. At 2910, the discharge time window is estimated based on the prediction intervals.

FIG. 30 presents a high-level flow diagram of another example machine learning process 2600 for estimating time windows in which a defined clinical event is expected to occur in accordance with one or more embodiments of the disclosed subject matter. With reference to FIGS. 17 and 26, process 2600 corresponds to a second example process that can be performed by the event window modeling component 1712 to estimate a time window around an expected discharge time.

Process 3000 is similar to process 2900 with the usage of a sampling approach as opposed to a quantile approach. In accordance with process 3000, at 3602, an input confidence level is received to indicate the desired confidence level in the event window model prediction result. The input confidence level is used to define the upper and lower bounds of the desired prediction interval. At 3004, a time-to-event regression model (e.g., time-to-event models 1812 applied to remaining LOS) for each patient group classification is trained to forecast the remaining time until discharge in accordance with the techniques described above (e.g., using a gaussian process regression based on the predication interval). At 3006, the LOS prediction is performed for all current patients using the corresponding time-to-event models for the respective patient group LOS clusters to which the current patients belong (e.g., as determined using the one or more classification models 1806). At 3008, the prediction interval is estimated using the predicted quantiles in a manner to ensure that the LOS regression estimate is between the predicted quantiles. At 3010, the discharge time window is estimated based on the prediction intervals for patients with a same/similar LOS prediction. In this regard, during the prediction phase at 3006, for every patient in the hospital that the system is predicting the remaining LOS, the system dynamically picks similar patients using the sampling and clustering techniques described above to prepare the prediction dataset for similar patients. The system further runs the predication dataset through the corresponding LOS models and estimate their remaining LOS. The estimates from similar patients provide the data distribution to estimate the prediction intervals for the predicted patients which in turn provides estimates for the event window.

FIG. 31 illustrates an example, high-level flow diagram of a computer-implemented process 3100 for training machine learning models to forecast information regarding time until occurrence of clinical events in accordance with one or more embodiments of the disclosed subject matter. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

At 3102, a system operatively coupled to a processor (e.g., system 100, system 400, system 600, system 900, system 1200 or the like), clusters (e.g., using clustering component 1702) training data samples corresponding to different patients that experienced a clinical event into different patient groups as a function of different defined timeframes within which the clinical event occurred. At 3104, the system employs a first machine learning process (e.g., process 1900) to train a classification model using the training data samples to predict the different patient groups to which the training data samples respectively belong. At 3106, the system employs a second machine learning process (e.g., process 2000 and/or process 2100) to train a clinical time to event model using the training data samples to predict an expected duration of time until occurrence of the clinical event as a function of the different patient groups.

FIG. 32 illustrates an example, high-level flow diagram of another computer-implemented process 3200 for training machine learning models to forecast information regarding time until occurrence of clinical events in accordance with one or more embodiments of the disclosed subject matter. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

At 3202, a system operatively coupled to a processor (e.g., system 100, system 400, system 600, system 900, system 1200 or the like), clusters (e.g., using clustering component 3202) training data samples corresponding to different patients that experienced a clinical event into different patient groups as a function of different defined timeframes within which the clinical event occurred. At 3204, the system employs a first machine learning process (e.g., process 1900) to train a classification model using the training data samples to predict the different patient groups to which the training data samples respectively belong. At 3206, the system employs a second machine learning process (e.g., process 2000 and/or process 2100) to train a clinical time to event model using the training data samples to predict an expected duration of time until occurrence of the clinical event as a function of the different patient groups. At 3208, the system employs a third machine learning process (e.g., process 2900) to train an event window model using the training data samples to predict an expected time window within which the clinical event will occur as a function of the different patient groups.

Example Operating Environment

One or more embodiments can be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of the present invention can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It can be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

In connection with FIG. 29, the systems and processes described below can be embodied within hardware, such as a single integrated circuit (IC) chip, multiple ICs, an application specific integrated circuit (ASIC), or the like. Further, the order in which some or all of the process blocks appear in each process should not be deemed limiting. Rather, it should be understood that some of the process blocks can be executed in a variety of orders, not all of which can be explicitly illustrated herein.

With reference to FIG. 29, an example environment 2900 for implementing various aspects of the claimed subject matter includes a computer 2902. The computer 2902 includes a processing unit 2904, a system memory 2906, a codec 2935, and a system bus 2908. The system bus 2908 couples system components including, but not limited to, the system memory 2906 to the processing unit 2904. The processing unit 2904 can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit 3304.

The system bus 3308 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, or a local bus using any variety of available bus architectures including, but not limited to, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), Firewire (IEEE 1394), and Small Computer Systems Interface (SCSI).

The system memory 3306 includes volatile memory 3310 and non-volatile memory 3312, which can employ one or more of the disclosed memory architectures, in various embodiments. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 3302, such as during start-up, is stored in non-volatile memory 3312. In addition, according to present innovations, codec 3335 can include at least one of an encoder or decoder, wherein the at least one of an encoder or decoder can consist of hardware, software, or a combination of hardware and software. Although, codec 3335 is depicted as a separate component, codec 3335 can be contained within non-volatile memory 3312. By way of illustration, and not limitation, non-volatile memory 3312 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), Flash memory, 3D Flash memory, or resistive memory such as resistive random access memory (RRAM). Non-volatile memory 3312 can employ one or more of the disclosed memory devices, in at least some embodiments. Moreover, non-volatile memory 3312 can be computer memory (e.g., physically integrated with computer 3302 or a mainboard thereof), or removable memory. Examples of suitable removable memory with which disclosed embodiments can be implemented can include a secure digital (SD) card, a compact Flash (CF) card, a universal serial bus (USB) memory stick, or the like. Volatile memory 3310 includes random access memory (RAM), which acts as external cache memory, and can also employ one or more disclosed memory devices in various embodiments. By way of illustration and not limitation, RAM is available in many forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), and enhanced SDRAM (ESDRAM) and so forth.

Computer 3302 can also include removable/non-removable, volatile/non-volatile computer storage medium. FIG. 33 illustrates, for example, disk storage 3314. Disk storage 3314 includes, but is not limited to, devices like a magnetic disk drive, solid state disk (SSD), flash memory card, or memory stick. In addition, disk storage 3314 can include storage medium separately or in combination with other storage medium including, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage 3314 to the system bus 3308, a removable or non-removable interface is typically used, such as interface 3316. It is appreciated that disk storage 3314 can store information related to a user. Such information might be stored at or provided to a server or to an application running on a user device. In one embodiment, the user can be notified (e.g., by way of output device(s) 3336) of the types of information that are stored to disk storage 3314 or transmitted to the server or application. The user can be provided the opportunity to opt-in or opt-out of having such information collected or shared with the server or application (e.g., by way of input from input device(s) 3328).

It is to be appreciated that FIG. 33 describes software that acts as an intermediary between users and the basic computer resources described in the suitable operating environment 3300. Such software includes an operating system 3318. Operating system 3318, which can be stored on disk storage 3314, acts to control and allocate resources of the computer 3302. Applications 3320 take advantage of the management of resources by operating system 3318 through program modules 3324, and program data 3326, such as the boot/shutdown transaction table and the like, stored either in system memory 3306 or on disk storage 3314. It is to be appreciated that the claimed subject matter can be implemented with various operating systems or combinations of operating systems.

A user enters commands or information into the computer 3302 through input device(s) 3328. Input devices 3328 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 3304 through the system bus 3308 via interface port(s) 3330. Interface port(s) 3330 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 3336 use some of the same type of ports as input device(s) 3328. Thus, for example, a USB port can be used to provide input to computer 3302 and to output information from computer 3302 to an output device 3336. Output adapter 3334 is provided to illustrate that there are some output devices 3336 like monitors, speakers, and printers, among other output devices 3336, which require special adapters. The output adapters 3334 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 3336 and the system bus 3308. It should be noted that other devices or systems of devices provide both input and output capabilities such as remote computer(s) 3338.

Computer 3302 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 3338. The remote computer(s) 3338 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device, a smart phone, a tablet, or other network node, and typically includes many of the elements described relative to computer 3302. For purposes of brevity, only a memory storage device 3340 is illustrated with remote computer(s) 3338. Remote computer(s) 3338 is logically connected to computer 3302 through a network interface 3342 and then connected via communication connection(s) 3344. Network interface 3342 encompasses wire or wireless communication networks such as local-area networks (LAN) and wide-area networks (WAN) and cellular networks. LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).

Communication connection(s) 3344 refers to the hardware/software employed to connect the network interface 3342 to the bus 3308. While communication connection 3344 is shown for illustrative clarity inside computer 3302, it can also be external to computer 3302. The hardware/software necessary for connection to the network interface 3342 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and wired and wireless Ethernet cards, hubs, and routers.

While the subject matter has been described above in the general context of computer-executable instructions of a computer program product that runs on a computer and/or computers, those skilled in the art will recognize that this disclosure also can or can be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks and/or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive computer-implemented methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, mini-computing devices, mainframe computers, as well as computers, hand-held computing devices (e.g., PDA, phone), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated aspects can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects of this disclosure can be practiced on stand-alone computers. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

As used in this application, the terms “component,” “system,” “platform,” “interface,” and the like, can refer to and/or can include a computer-related entity or an entity related to an operational machine with one or more specific functionalities. The entities disclosed herein can be either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers. In another example, respective components can execute from various computer readable media having various data structures stored thereon. The components can communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry, which is operated by a software or firmware application executed by a processor. In such a case, the processor can be internal or external to the apparatus and can execute at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts, wherein the electronic components can include a processor or other means to execute software or firmware that confers at least in part the functionality of the electronic components. In an aspect, a component can emulate an electronic component via a virtual machine, e.g., within a cloud computing system.

In addition, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. Moreover, articles “a” and “an” as used in the subject specification and annexed drawings should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. As used herein, the terms “example” and/or “exemplary” are utilized to mean serving as an example, instance, or illustration and are intended to be non-limiting. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as an “example” and/or “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art.

As it is employed in the subject specification, the term “processor” can refer to substantially any computing processing unit or device comprising, but not limited to, single-core processors; single-processors with software multithread execution capability; multi-core processors; multi-core processors with software multithread execution capability; multi-core processors with hardware multithread technology; parallel platforms; and parallel platforms with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application specific integrated circuit (ASIC), a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), a discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Further, processors can exploit nano-scale architectures such as, but not limited to, molecular and quantum-dot based transistors, switches and gates, in order to optimize space usage or enhance performance of user equipment. A processor can also be implemented as a combination of computing processing units. In this disclosure, terms such as “store,” “storage,” “data store,” data storage,” “database,” and substantially any other information storage component relevant to operation and functionality of a component are utilized to refer to “memory components,” entities embodied in a “memory,” or components comprising a memory. It is to be appreciated that memory and/or memory components described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of illustration, and not limitation, nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or nonvolatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM). Volatile memory can include RAM, which can act as external cache memory, for example. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). Additionally, the disclosed memory components of systems or computer-implemented methods herein are intended to include, without being limited to including, these and any other suitable types of memory.

What has been described above include mere examples of systems and computer-implemented methods. It is, of course, not possible to describe every conceivable combination of components or computer-implemented methods for purposes of describing this disclosure, but one of ordinary skill in the art can recognize that many further combinations and permutations of this disclosure are possible. Furthermore, to the extent that the terms “includes,” “has,” “possesses,” and the like are used in the detailed description, claims, appendices and drawings such terms are intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim. The descriptions of the various embodiments have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations can be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

	Number	Date	Country
Parent	16588250	Sep 2019	US
Child	17810217		US

EFFICIENTLY GENERATING MACHINE LEARNING MODELS CONFIGURED TO FORECAST INFORMATION REGARDING TIME UNTIL OCCURRENCE OF CLINICAL EVENTS

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

RELATED APPLICATIONS

Continuation in Parts (1)