Methods and systems for optimal care setting for patients using machine learning

Abstract

A method includes: receiving patient information including information about a current hospitalization of a patient; receiving hospital-unit-volume information corresponding to a rolling window of time, indicating a patient number admitted to, transferred into, or discharged from a hospital unit housing the patient; converting the patient information and the hospital-unit- volume information into a machine-interpretable format for at least one binary output machine learning algorithm; executing the at least one algorithm to generate binary models that predict the likelihood of discharging the patient within each of multiple timeframes; combining the binary models into a single combined model, including optimizing weightings of discharge predictions for each binary model; determining, using the single combined model, at least one weighted discharge readiness quantization; transforming the at least one weighted discharge readiness quantization into at least one discharge prediction; and controlling a user interface to provide the at least one discharge prediction to a user.

Description

[0001]Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) METHODS AND SYSTEMS FOR OPTIMAL CARE SETTING FOR PATIENTS USING MACHINE LEARNING BACKGROUND Patients may be encountered at hospitals for various reasons. While at a hospital, patients may be moved among various units where appropriate care may be provided. Patients may ultimately be discharged from the hospital when it is no longer necessary for them to receive hospital care. SUMMARY Examples of the methods and systems discussed herein are not limited in application to the details of construction and the arrangement of components set forth in the following description or illustrated in the accompanying drawings. The methods and systems may be capable of implementation in other embodiments and of being practiced or of being carried out in various ways. Examples of specific implementations are provided herein for illustrative purposes and are not intended to be limiting. Acts, components, elements, and features discussed in connection with any one or more examples may be configured to operate and / or be implemented in a similar role in any other examples. The phraseology and terminology used herein is for the purpose of description. References to examples, embodiments, components, elements, or acts of the systems and methods herein referred to in the singular may also embrace embodiments including a plurality. Similarly, references in plural to embodiments, components, elements, or acts may be implemented as a singularity. References in the singular or plural form may therefore not be intended to limit the presently disclosed systems or methods, their components, acts, or elements. The use herein of “including,” “comprising,” “having,” “containing,” “involving,” and variations so forth, may encompass the items listed thereafter and equivalents thereof as well as additional items. References to “or” may be construed as inclusive so that any terms described using “or” may indicate any of a single, more than one, and all of the described terms. For example, the phrase “at least one of A or B” may refer A and / or B—that is, A only, B only, or A and B together. In addition, in the event of inconsistent usages of terms between this document and documents incorporated herein by reference, the term usage in the incorporated documents is Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) supplementary to this document. For irreconcilable differences, the term usage in this document controls. According to at least one aspect of the present disclosure, in one example, at least one non-transitory computer-readable medium storing thereon sequences of computer-executable instructions for quantizing a likelihood of discharging a patient from a hospital is disclosed. The sequences of computer-executable instructions include instructions that instruct at least one processor to: receive patient information about the patient, the patient information including information about a current hospitalization of the patient; receive hospital-unit-volume information corresponding to a rolling window of time, the hospital-unit-volume information indicating a number of patients admitted to, transferred into, or discharged from a hospital unit in which the patient currently resides; convert the patient information and the hospital-unit-volume information into a machine-interpretable format tailored to at least one binary output machine learning algorithm; execute the binary output machine learning algorithm to generate a plurality of binary models that predict the likelihood of discharging the patient within each timeframe of a plurality of timeframes; combine the plurality of binary models into a single combined discharge model, wherein combining the plurality of binary models includes optimizing weightings of discharge predictions for each binary model of the plurality of binary models; determine, using the single combined discharge model, at least one weighted discharge readiness quantization for the patient; transform the at least one weighted discharge readiness quantization into at least one discharge prediction for the patient; and control a user interface to provide the at least one discharge prediction to a user. In one example of the at least one non-transitory computer-readable medium, receiving the patient information includes accessing an electronic medical record (EMR) of the patient in real-time. In another example of the at least one non-transitory computer-readable medium, the rolling window of time corresponds to a most recent 12-hour span of time. In one example of the at least one non-transitory computer-readable medium, the plurality of binary models predict the likelihood of discharging the patient within one or more of a 12-hour timeframe, a 24-hour timeframe, a 36-hour timeframe, a 48-hour timeframe, a 60-hour timeframe, and a 72-hour timeframe. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In another example of the at least one non-transitory computer-readable medium, the instructions further instruct the at least one processor to optimize the plurality of binary models for each timeframe according to one or more optimization metrics. In one example of the at least one non-transitory computer-readable medium, the optimization metrics include accuracy, precision, recall, and F1-score. In another example of the at least one non-transitory computer- readable medium, the instructions further instruct the at least one processor to execute a Bayesian optimization algorithm to fine-tune one or more hyperparameters of the at least one binary output machine learning algorithm. In another example of the at least one non-transitory computer-readable medium, fine-tuning the one or more hyperparameters of the at least one binary output machine learning algorithm includes selecting values for the one or more hyperparameters that maximize an area-under-the-precision-recall curve (AUC-PR) for imbalanced datasets. In one example of the at least one non-transitory computer-readable medium, optimizing the weightings of discharge predictions for each binary model of the plurality of binary models includes: assigning a weight to a discharge prediction of each timeframe of the plurality of timeframes to produce a plurality of weighted discharge predictions; and identifying an optimal value of each weight. In one example of the at least one non-transitory computer-readable medium, identifying the optimal value of each weight includes determining a value of each weight that maximizes a median of a sum of the plurality of weighted discharge predictions. In another example of the at least one non-transitory computer-readable medium, identifying the optimal value of each weight includes imposing: a first restriction on the sum of the plurality of weighted discharge predictions to maximize a distribution of discharge predictions for patients likely to be discharged; and a second restriction on the sum of the plurality of weighted discharge predictions to minimize a distribution of discharge predictions for patients not likely to be discharged. In another example of the at least one non-transitory computer-readable medium, the first restriction includes imposing a minimum-value threshold on a first quartile of the sum of the plurality of weighted discharge predictions. In one example of the at least one non-transitory computer-readable medium, the second restriction includes imposing a maximum-value threshold on a third quartile of the sum of the plurality of weighted discharge predictions. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In another example of the at least one non-transitory computer-readable medium, the sum of the plurality of weighted discharge predictions is the at least one weighted discharge readiness quantization. In one example of the at least one non-transitory computer-readable medium, transforming the at least one weighted discharge readiness quantization into the at least one discharge prediction for the patient includes converting a likelihood of patient discharge into a value on a standardized scale of a plurality of standardized values. In another example of the at least one non-transitory computer-readable medium, the at least one discharge prediction is the value on the standardized scale of the plurality of standardized values. In one example of the at least one non-transitory computer-readable medium, the instructions further instruct the at least one processor to train each binary model of the plurality of binary models using at least one of Random Forest, Gradient Boosting, Support Vector Machines, or Neural Networks. In one example of the at least one non-transitory computer-readable medium, the binary output machine learning algorithm includes one or more gradient-boosted decision trees, transformer-based models, at least one custom deep learning architecture, Random Forest, support vector machine (SVM), k-nearest neighbors (KNN), or Lasso / Ridge regression. In one example of the at least one non-transitory computer-readable medium, the at least one custom deep learning architecture includes at least one of a convolutional neural network, a recurrent neural network, or a hybrid model. In one example of the at least one non-transitory computer-readable medium, the instructions further instruct the at least one processor to: receive at least one of new patient information or new hospital-unit-volume information; and re-train the binary output machine learning algorithm using the at least one of the new patient information or the new hospital-unit- volume information. In one example of the at least one non-transitory computer-readable medium, the instructions further instruct the at least one processor to: execute the re-trained binary output machine learning algorithm to determine at least one updated weighted discharge readiness quantization for the patient; transform the at least one updated weighted discharge readiness quantization into at least one updated discharge prediction for the patient; and control the user interface to provide the at least one updated discharge prediction to the user. In one example of the at least one non-transitory computer-readable medium, the instructions further instruct the at least one processor to: receive at least one of new patient information or new hospital-unit-volume information; execute the binary output machine Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) learning algorithm with respect to the at least one of new patient information or the new hospital- unit-volume information to determine at least one updated weighted discharge readiness quantization for the patient; transform the at least one updated weighted discharge readiness quantization into at least one updated discharge prediction for the patient; and control the user interface to provide the at least one updated discharge prediction to the user. According to at least another aspect of the present disclosure, in one example, a method of quantizing a likelihood of discharging a patient from a hospital is disclosed. The method including: receiving patient information about the patient, the patient information including information about a current hospitalization of the patient; receiving hospital-unit-volume information corresponding to a rolling window of time, the hospital-unit-volume information indicating a number of patients admitted to, transferred into, or discharged from a hospital unit in which the patient currently resides; converting the patient information and the hospital-unit- volume information into a machine-interpretable format tailored to at least one binary output machine learning algorithm; executing the at least one binary output machine learning algorithm to generate a plurality of binary models that predict the likelihood of discharging the patient within each timeframe of a plurality of timeframes; combining the plurality of binary models into a single combined discharge model, wherein combining the plurality of binary models includes optimizing weightings of discharge predictions for each binary model of the plurality of binary models; determining, using the single combined discharge model, at least one weighted discharge readiness quantization for the patient; transforming the at least one weighted discharge readiness quantization into at least one discharge prediction for the patient; and controlling a user interface to provide the at least one discharge prediction to a user. BRIEF DESCRIPTION OF THE DRAWINGS Various aspects of at least one embodiment are discussed below with reference to the accompanying figures, which may not be drawn to scale. The figures are included to provide an illustration and a further understanding of the various aspects and embodiments, and are incorporated in and constitute a part of this specification, but are not intended as a definition of the limits of any particular embodiment. The drawings, together with the remainder of the specification, serve to explain the principles and operations of the described and claimed aspects and embodiments. In the figures, each identical or substantially similar component that is Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) illustrated in various figures may be represented by a like numeral. For purposes of clarity, not every component may be labeled in every figure. In the figures: FIG.1 illustrates a process depicting an inpatient’s potential journey through various care settings in a hospital according to an example; FIG.2 illustrates a block diagram of an anticipatory system according to an example; FIG.3 illustrates a machine-learning process to predict the length of stay of a patient admitted into the hospital according to an example; FIG.4 illustrates a machine-learning process to predict the deterioration risk of a patient admitted into the hospital according to an example; FIG.5 illustrates a graphical user interface associated with predicting deterioration risks of patients in a hospital according to an example; FIG.6 illustrates a machine-learning process to predict a patient’s readiness for a care downgrade at a future time according to an example; FIG.7 illustrates a machine-learning process to predict a patient’s clinical readiness for discharge at a future time according to an example; FIG.8 illustrates a graphical user interface associated with predicting clinical readiness for discharging patients in a hospital in the next 24 hours according to an example; FIG.9 illustrates a machine-learning process to predict the operational readiness of the hospital for discharging a patient according to an example; FIG.10 illustrates a machine-learning process to predict the discharge disposition of a patient at a future time according to an example; FIG.11 illustrates a graphical user interface associated with predicting discharge dispositions of patients in a hospital according to an example; FIG.12 illustrates a machine-learning process to predict a patient’s readmission risk according to an example; and FIG.13 illustrates a graphical user interface associated with predicting readmission risks of patients at a hospital-system level according to an example. DETAILED DESCRIPTION Hospitals may treat hundreds to thousands of patients every month. Many hospitals include several different units specializing in various types of procedures. For example, a Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) hospital may include an organ-transplant unit, a general medicine unit, a trauma unit, a pediatrics unit, and so forth. Large hospitals may have dozens of discrete units. Controlling patient flow throughout a hospital from patient arrival to departure (and all movements in between) may involve vigilant monitoring of patients’ conditions and anticipating future clinical events to optimally manage patients and ensure they get the proper care at the right time and location. Currently, such control mostly relies on the clinical intuition and experience of healthcare professionals and is more reactive than anticipatory. FIG.1 illustrates a process 100 depicting an inpatient’s potential journey through various care settings in a hospital according to an example. Certain acts of the process 100 are described as occurring in sequence solely for purposes of explanation rather than limitation. However, in many implementations, acts of the process 100 may be executed in different orders and / or in parallel with one another. As one non-limiting example, one or more of acts 110, 114, 118, 124, 126, and / or 128 may be executed in parallel and / or in a different order than that depicted in FIG. 1. In various examples, many of the acts of the process 100 (including, for example, acts 110, 114, 118, 124, 126, and / or 128) may be executed repeatedly and / or continuously throughout execution of the process 100. Accordingly, no limitation is implied by the order of acts in the process 100. At act 102, the process 100 starts with admitting a patient to a hospital. In one example, at act 110, the patient is admitted to an acute care bed. In other examples, the process 100 may proceed to a different act, such as act 116 or act 120 depending on the patient’s medical condition. As discussed in greater detail below, acts 110, 116, and 120 may include moving a patient to an acute-care bed, an intensive care unit (ICU) bed, or an intermediate care unit (IMC) bed, respectively. In various examples, the act 102 may include determining which hospital unit is most likely to meet the patient’s needs (for example, between the units at the acts 110, 116, or 120) and proceeding to the corresponding act. At the act 112, in one example, the length of stay (LOS) of the patient in the hospital may be estimated. A first machine-learning process may be employed to evaluate the patient’s LOS, which will be described in more detail below with respect to FIG.3. The process 100 may then proceed to act 114, in one example, to predict the patient’s risk of in-hospital deterioration to assist in the decision-making of upgrading the patient’s care setting. A second machine-learning process may be employed to predict the deterioration Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) likelihood of the patient, which will be described in more detail below with respect to FIGS.4 and 5. If the deterioration likelihood is predicted to be low (“Low Risk”), the process 100 may proceed to act 124 to evaluate the patient’s clinical readiness for discharge. On the other hand, if the predicted deterioration likelihood is not low (“Otherwise”), the process 100 may proceed to act 116 to transfer or move the patient to, for example, an ICU bed. In one example, act 118 may follow the act 116 or act 120 to predict the patient’s readiness for care downgrade to assist in the decision-making of potentially downgrading the patient’s care setting in the hospital. A third machine-learning process may be employed to predict the downgrade readiness of the patient, which will be described in more detail below with respect to FIG.6. If the patient’s predicted readiness for care downgrade is low (“Not Ready”), the process 100 returns to the act 116 or 120 to maintain the patient in the ICU or IMC bed. On the other hand, if the patient’s predicted readiness for care downgrade is not low (“Otherwise”), the process 100 proceeds to act 120 or 122 to downgrade the patient’s care setting to an IMC bed or an acute care bed, respectively. At act 124, in one example, the patient’s clinical readiness for discharge at a future time is predicted to assist in the decision-making of when to discharge the patient from the hospital. A fourth machine-learning process may be employed to predict the clinical discharge readiness of the patient, which will be described in more detail below with respect to FIGS.7 and 8. If the predicted clinical discharge readiness is low (“Not Ready”), the process 100 returns to the act 122 to maintain the patient in the acute care bed. On the other hand, if the predicted clinical discharge readiness is not low (“Otherwise”), the process 100 proceeds to act 126. At the act 126, in one example, the operational readiness for discharging the patient is predicted to assist the decision-making of when to discharge the patient from the hospital. A fifth machine-learning process may be employed to predict the operational readiness for discharging the patient, which will be described in more detail below with respect to FIG.9. If the predicted operational readiness is low (“Not Ready”), the process 100 returns to the act 122 to maintain the patient in the acute care bed. On the other hand, if the predicted operational readiness is not low (“Otherwise”), the process 100 proceeds to act 128. At the act 128, in one example, the patient’s discharge disposition is predicted to assist the decision-making of where to discharge the patient from the hospital. A sixth machine- learning process may be employed to predict the discharge disposition of the patient, which will Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) be described in more detail below with respect to FIGS.10 and 11. If the predicted discharge disposition destination is not available (“Not Ready”), the process 100 returns to the act 122 to maintain the patient in the acute care bed. On the other hand, if the predicted discharge disposition destination is available (“Otherwise”), the process 100 proceeds to act 130. At the act 130, in one example, the patient’s readmission risk is predicted to assess how likely a patient is to be readmitted to a hospital after discharge. In some examples, the readmission risk may be evaluated over a certain length of time after discharge, such as within one day, one week, one month, 30 days, 60 days, and so forth. A seventh machine-learning process may be employed to predict the readmission likelihood of the patient, which will be described in more detail below with respect to FIGS.12 and 13. If the predicted readmission risk is not high (“Otherwise”), the process 100 proceeds to act 132 to discharge the patient. If the predicted readmission risk is high (“Risk too high”), the process 100 may return to the act 122 if the patient agrees to stay in the hospital, or still proceed to act 132 to discharge the patient if the patient insists on leaving the hospital. However, if the patient is still discharged, care personnel may intervene to address the risk and employ mitigation measures to reduce the risk of readmission for that patient. In some examples, the act 130 may be performed after the patient has been discharged from the hospital. At act 134, in one example, after a patient is discharged at the act 132, the patient may need to be readmitted to the hospital because, for example, the patient’s medical condition has deteriorated. For example, the patient may then be readmitted at the act 102 to re-experience at least a portion of the process 100. In various examples, one or more acts in the process 100 may be reordered or may extend over a period when multiple other acts are performed. For example, some or all of the acts 112, 114, 118, 124, 126, 128, and / or 130 may be performed in parallel. In other examples, acts 112, 114, 118, 124, 126, 128, and / or 130 may be repeatedly and / or continuously performed throughout a patient’s stay in the hospital. In various examples, an anticipatory system for assisting in clinical decision-making for optimal care settings (or “anticipatory system”) may include one or more computing devices. FIG.2 illustrates a block diagram 200 of an anticipatory system 201 according to an example. The anticipatory system 201 includes at least one controller 202 (“controller 202”), at least one user interface 204 (“user interface 204”), memory and / or storage 206 (“memory 206”), and at Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) least one network interface 208 (“network interface 208”). The anticipatory system 201 may be coupled to one or more external devices 210 (“external devices 210”) via the network interface 208. Medical personnel, such as the personnel tasked with changing care settings for patients, may use the anticipatory system 201 to aid in the decision-making of care setting changes. As discussed in greater detail below with respect to FIGS.3-13, the anticipatory system 201 may aid medical personnel by generating clinical predictions (for example, a patient’s admission likelihood, LOS, deterioration likelihood, downgrade readiness, discharge likelihood, operational readiness for discharge, discharge disposition, and readmission risk) for the medical personnel to consider as part of their medical evaluation and interventions. For example, the controller 202 may construct, optimize, and / or execute one or more machine-learning models to generate the clinical predictions based on information stored in the memory 206, and / or based on information received from the external devices 210, and display the clinical predictions on the user interface 204. For example, the user interface 204 may include a display device 212 (for example, a computer monitor, laptop display, smartphone display, or other such displays) to display the clinical predictions. Accordingly, references to the user interface 204 displaying information may include the display device 212 displaying information. Medical personnel may also input information via the user interface 204, such as (near) real-time information indicative of the patients’ status updates. The controller 202 may recognize the (near) real-time information and automatically re-execute the one or more models to update the clinical predictions in real-time based at least in part on the (near) real-time information. Referring to FIG.1, in one example, after the patient is admitted to an acute care bed at the act 110, the process 100 proceeds to act 112 to predict the patient’s estimated LOS in the hospital. In other examples, the act 112 may be performed at any time throughout a patient’s inpatient stay to predict and update the LOS before discharge. LOS is defined as the number of days an inpatient occupies a hospital bed from admission through discharge. Having the ability to accurately estimate LOS prior to patient discharge can assist with tactical and short-term decision-making, such as discharge planning, staffing shortfalls, and a variety of other flow and throughput issues. However, LOS is not easy to estimate or predict. For example, there may be considerable LOS variability with the LOS for a single diagnosis often ranging from 2 to 60+ days and the overall LOS distribution often Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) exhibits multiple peaks and troughs. LOS variation can be caused by a myriad of factors, including chronic and other health-related conditions not directly related to the current encounter, social and demographic circumstances, complications, and treatment complexities. In addition, data from which to produce estimates tends to be very sparse at the beginning of an encounter while longer encounters have considerably more inherent variability. FIG.3 illustrates a machine-learning process 400 to execute the act 112 to predict the LOS of a patient admitted into the hospital according to an example. At sub-act 402, in one example, the process 400 starts by extracting and compiling various types of data. In various examples, the sub-act 402 may include sub-acts 402a and 402b to extract several years (for example, five years) of clinical, operational, and financial data, primarily focused on patients and patient encounters, via various acquisition methods or standards. For example, the sub-act 402a extracts data via the health level seven (HL7) standards including the fast healthcare interoperability resources (FHIR) standard and the sub-act 402b extracts data via various web services. Other methods may be included in the sub-act 402, such as the KB_SQL queries, application programming interface (API) / web service calls, and event-driven real-time interfaces. An electronic medical record (EMR) is an application and database that acquires and stores clinical, operational, and financial data related to healthcare and health system operations. In one example, most data extracted at the sub-act 402 is extracted from the EMR. Categories of data acquired from the EMR include patient demographics, patient history, encounter details, medications, lab tests, vital signs, radiology results, nursing documentation, social determinants of health (SDOH), and financial details. At the sub-act 402a, in one example, data are extracted using the inpatient (or expected to be inpatient) or observation encounter en, where n ∈ {1,…,N} during the past five years, where each data sample represents a flat longitudinal patient. More recent data, especially physiologic measurements, are considered most relevant while older data are treated as less relevant and often summarized. At sub-act 404, in one example, the extracted and compiled data are preprocessed. In various examples, the sub-act 404 may include sub-acts 404a and 404b. At sub-act 404a, in one example, the response variables for the ground truth of a LOS model are estimated based on after-the-fact LOS data. In some examples, an objective of the act 112 is to provide not only point LOS estimates but also likely LOS ranges. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) For example, a series of predictive LOS models may be used, each trained only on data available at a specific time point for each encounter. Each LOS model estimates the remaining encounter LOS and also produces a likely upper / lower bound. For example, a 48-hour LOS model may be trained using only data available between admission and the 48th hour of encounter and outputs LOS-48 and likely upper and lower bounds. A total of 20 models may be created using a set of time cut-offs, for example, 12 hours, 24 hours, 36 hours, 48 hours, 60 hours, 72 hours, 84 hours, 96 hours, 108 hours, 120 hours, 144 hours, 168 hours, 192 hours, 216 hours, 240 hours, 264 hours, 288 hours, 312 hours, 336 hours, and 360 hours of encounter. In one example, given that the average LOS of the training population is about 5 days, each model beyond 120 hours may contain fewer and fewer encounters. After all variables for the LOS models have been analyzed individually and in concert to discover patterns, ranges, fluctuations over time, absences, distributions, correlations with other variables, and so forth, the most likely encoding techniques are chosen, and a data set created. Variables for which multiple encoding techniques are needed or wanted (for specific algorithms or discovery) are included multiple times in the data set, once for each encoding type. At sub-act 404b, in one example, the extracted and compiled data are feature-encoded and feature-engineered. The goal of both feature-encoding and feature-engineering is to maximize the predictive power of the extracted data. Many techniques for both encoding and engineering may be used. The efficacy of each technique may be analyzed iteratively along with model and feature selection (as discussed in greater detail below) to identify one or more optimal techniques based on the chosen metric(s). In one example, for constructing LOS models, various types of variables are encoded from the data features and evaluated based on performance. For example, encoded variables may include single variables such as numeric, boolean, ordinal, and categorical data features. Numerical data features include extracted data in the raw form such as height, weight, and BMI. Boolean data features may be encoded by uniformly converting extracted data to 1 (yes) and 0 (no) for information of, for example, whether a patient is on IV therapy, is in the ICU, or has previous encounters with a hospital or hospital system. Ordinal data features may be converted from the extracted data into a series of sequential integers while preserving their original rankings (for example, pain score, admission level of care, and Branden score). Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) For categorical data features, when the number of categories is reasonable, the data features may be encoded by either one-hot encoding (dummy encoding) or frequency encoding. For example, data features relating to admission source, mode of arrival, and primary insurance type may use one-hot encoding, and data relating to ZIP code, financial class, and type of breathing assistance may use frequency encoding. When the number of categories is large enough to cause dimensionality problems, the data features may be encoded by either hash encoding or grouping (especially when an appropriate industry standard “grouper” is available). For example, some EMRs may define tens of thousands of order codes, some with industry- standard coding (ICD or CPT), and some without. Because not all of them can be grouped in useful or meaningful ways, hash encoding is used to reduce the dimensionality while attempting to preserve enough detail to facilitate predictive modeling. On the other hand, medication data is generally stored as national drug code (NDC) codes, of which there are tens of thousands. To group these into manageable categories, anatomical therapeutic chemical (ATC) pharmacological and therapeutic groupings are used, as provided by the World Health Organization (WHO). Diagnoses are generally represented as international classification of diseases (ICD) codes. Again, there are tens of thousands of ICD codes. To group these into manageable categories, clinical classifications software refined (CCSR) body systems and clinical categories are used. In one example, for constructing the LOS models, variables that change over time are also encoded from the data features and evaluated based on performance. Although many healthcare data variables change over time, vital signs, for example, and the resulting chronological vectors are often irregular and / or sparse. Nevertheless, these types of data are still treated as time series variables. All data recorded beyond each time point is excluded. In addition, data are not limited to the current encounter, but anything recorded more than one year before the exclusion date is excluded. For each time series variable regardless of the type, the features created (after encoding the extracted data appropriately) include first value, most recent value, time since the most recent value is recorded, total number of values recorded, and average number of values recorded per day. Additional features are created for each numeric time series variable, which include median value, minimum value, maximum value, variance, difference between the median value and the most recent value, difference between the median value and the fist value, difference between the first value and the most recent value, first quartile Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) boundary, third quartile boundary, time spent in each quartile, time spent in each quartile as a percentage of total encounter time, current quartile, and the slope of a regression model fit to the values (for example, heart rate, pain score, and white blood count). Additional features may be created for each boolean time series variable, including time spent in positive and negative states (in fractional days) and time spent in positive and negative states as a percentage of total encounter time (for example, time on a ventilator, in ICU, and for receiving antibiotic). Additional features may be created for each ordinal variable (after being transformed or encoded), including time spent in each ordinal level (in fractional days) and time spent in each ordinal level as a percentage of total encounter time (for example, pain score, Richmond agitation-sedation scale [RASS] level, and patient mobility). Additional features may be created for each categorical variable, including time spent in each category (in fractional days) and time spent in each category as a percentage of total encounter time (for example, affect and behavior, respiratory within defined limits [WDL], and central line status). In various examples, at the sub-act 404, a series of summarized variables are produced from less recent data. For example, the summarized variables may include encounter history, diagnostic history, and medication history. Encounter history may include previous encounter data, number of inpatient encounters, average number of inpatient encounters per year, days since most recent inpatient encounter, number of emergency department (ED) / observation encounters, average number of ED / observation encounters per year, days since most recent ED / observation encounter, number of scheduled outpatient encounters, days since most recent outpatient encounter, number of inpatient days over the past five years (or other periods of time), number of surgical procedures performed over the past five years (or other periods of time), days since most recent surgical procedure, discharge disposition and location for the most recent encounter, number of different home addresses recorded, and / or other information. Diagnostic history may include CCSR categories for all diagnoses recorded prior to the current encounter (one Boolean feature per category) and CCSR body systems for all diagnoses recorded prior to the current encounter (one Boolean feature per body system). Medication history may include ATC pharmacological groups for all medications recorded prior to the current encounter (one boolean per group) and ATC therapeutic groups for all medications recorded prior to the current encounter (one boolean per group). Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) At sub-act 406, in one example, the type of machine-learning algorithm for the LOS model is selected from various types of algorithms. In various examples, the sub-act 406 includes sub-acts 406a and 406b. At the sub-act 406a, in one example, various binary models are trained, each using a different type of algorithm. For example, for training each LOS model, data folds and splits are constructed for an augmented version of k-fold cross-validation. The data set resulting from feature encoding and engineering is first split into two sets, one containing the oldest 85% of encounters (train-0), and the other containing the most recent 15% of encounters (test-0). Train-0 is further split into five “folds” of relatively equal size. Two constraints are imposed on the train-0 splitting process: to avoid cross-encounter data leakage, each fold is limited to a unique set of patients, including all encounters for those patients; each sub-set contains at least one sample of each category for all categorical variables. Each type of algorithm is trained using only split 1, with folds 2-5 used for training and fold 1 used for measuring performance. In one example, only four representative time points were used, which are, for example, 24 hours, 48 hours, 72 hours, and 96 hours. Hyperparameters for each model are chosen based on a coarse-grained grid search. If more than one variable / feature encoding was relevant, each may be tried sequentially. Features are culled separately for each model using algorithm-specific methods, requirements, and constraints. In some examples, further transformation and / or augmentation of the data may be required. For example, some algorithms cannot handle missing values so various imputation methods are used to address them. Some algorithms perform best when numeric data have been normalized so appropriate normalization techniques may be applied to those features. Some algorithms perform poorly if highly correlated features are used so a cross-correlation matrix is generated, and over- correlated features are dropped. Some algorithms perform better when continuous numeric features are split into binary “buckets.” In one example, at the sub-act 406a, the evaluated types of algorithms include Quantile Random Forest, Quantile Gradient Boosting, and Deep Learning (minimizing Pinball Loss). At the sub-act 406b, in one example, the performance of each tuned model is evaluated using a set of metrics. Although the target variable is binary, the desired model outputs are LOS point estimates and a likely LOS range. Since quantile regression is chosen as the modeling technique, quantile loss may be chosen as the primary metric with mean average error (MAE) as Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) a secondary metric. In addition, error distributions may be analyzed to understand the conditions under which each model performs best and worst. In one example, at the sub-act 406b, Quantile Gradient Boosting using the XGBoost “extreme gradient boosting” library with a pinball loss objective function may be chosen as the final algorithm type for constructing the LOS binary models. In other examples, one or more other machine-learning algorithms may be chosen alone or in various combinations at the sub-act 406b. At sub-act 408, in one example, the hyperparameters of the selected type of algorithm are optimized and feature culling is performed, both by training, to construct, optimize, validate, and update the final LOS models. In various examples, the sub-act 408 may include sub-acts 408a, 408b, 408c, 408d, and 408e. At the sub-act 408a, in one example, the final models may be constructed. While a single 80 / 20 split for only four time points (for example, 24 hours, 48 hours, 72 hours, and 96 hours) may be used to evaluate modeling algorithms at the sub-act 406, five separate models using different 4+1 combinations are first constructed at the sub-act 408a for the hyperparameter optimization of each final LOS model. Hyperparameters for each of the five separate models may be tuned using coarse grid search at the sub-act 408b. In one example, the hyperparameters defined below are optimized to improve the performance of the five LOS models. Number of trees may be limited to a particular threshold amount; for example, the number of trees may be capped at 2,000. Maximum tree depth is the maximum depth of the trees which controls the model complexity and may be specified. Its range is uniformly set between any of various numbers, such as between 3 and 8. Learning rate determines the step size during model training (for example, sampled from a logarithmic scale between 0.001 and 0.3) to allow for both small and large step sizes. Subsample ratio represents the fraction of training samples used for building each tree, uniformly sampled between, for example, 0.5 and 1 with a step size of 0.1. Column sample by tree specifies the fraction of features to be randomly sampled for each tree, sampled uniformly between, for example, 0.5 and 1 with a step size of 0.1. Other hyperparameters may also be specified. In certain examples, feature culling may also be performed for each of the five LOS models at the sub-act 408b. The importance of each feature for each LOS model may be determined using Shapley additive explanations (SHAP) analysis. SHAP is a model-agnostic Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) approach that uses coalitional game theory to evaluate each model feature representing how much that feature contributes to the model’s output. Features with zero contribution, based on the SHAP analysis, are dropped, and models are retrained without them to rule out anomalous behavior. Moreover, in various examples, the sub-act 408a may include investigating and, when necessary, mitigating biases of various types. Subsets of results from all fine-tuned models are used to check for biases by comparing them against the performance of the overall model. For example, the performance on a subset of results including only female patients may be compared to the performance of the entire model and the performance of the non-female population. For example, a bias check may be performed for various categories including race, ethnicity, and sex. If an unacceptable level of bias is discovered, attempts to mitigate that bias may be made. Mitigation may be done by over-sampling the biased population or re-weighting training samples to put more emphasis on the biased population. At the sub-act 408a, in one example, the final LOS models may be built using train-0 (a combination of all folds) and subsequently tested against test-0, a chronologically “most recent encounters” hold-out set, at the sub-act 408b. Hyperparameters for the final LOS models may be derived by averaging hyperparameters across all five corresponding split-based LOS models. The feature set for each final LOS model is a union of feature sets from all five corresponding split-based LOS models. The final LOS models may be built using the corresponding time point’s complete data set. At the sub-act 408c, the final LOS models may be validated. If the behavior of a final LOS model, including performance and levels of bias, is consistent with the split-based LOS models obtained at the sub-act 408a or sub-act 408b (“YES”), the process 400 proceeds to a sub- act 408d. Otherwise (“NO”), the process 400 returns to the sub-act 408a to find and fix the causes and reconstruct the final LOS model. In one example, testing at the sub-act 408c reveals a time bias which is affecting model performance. Investigation of this unwanted behavior at the sub-act 408a reveals that LOS distributions are different during part of the COVID-19 pandemic (specifically March 2020 through January 2023). To mitigate this skew, at the sub-act 408a, a binary feature (1=in the time range, 0=not in the time range) may be added and all investigative LOS models may be retrained and retested. After mitigation, the final LOS model behavior including performance and levels of bias must be consistent with individual split-based LOS Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) models (“YES”) at the sub-act 408a or sub-act 408b. If not (“NO”), further investigation and remediation at the sub-act 408a would be necessary. At the sub-act 408d, in one example, it is determined whether new real-time data of a first type are available for updating the dataset for training. For example, the new data of the first type may include relevant information such as whether certain care units become opened or closed which will affect the workflow through the hospital, or whether a new initiative is introduced at the hospital that affects the workflow of the nurses or doctors and changes where and when data are documented. In some examples, the sub-act 408d may be configured to be performed periodically, for example, daily, weekly, monthly, or quarterly, to search for new data of the first type. If new data are available (“YES”), the process 400 proceeds to the sub-act 408e to extract, process, and insert the new first-type data to update the dataset. After the dataset is updated, the process 400 returns to the sub-act 408b to retrain the final model with the updated dataset. If no new first-type data are available (“NO”) at the sub-act 408d, the process 400 proceeds to a sub-act 410 to execute the final model closest to the encounter time to output the LOS predictions. For example, if the patient has already been in the hospital for 42 hours, the closest model is the 48-hour model; accordingly, the 48-hour model may be used to estimate the patient’s total LOS. In another example, if the patient has already been in the hospital for 52 hours, the closest model is the 48-hour model; accordingly, the 48-hour model may be used to estimate the patient’s total LOS. Hourly LOS estimations and likely ranges may be provided to a discharge planning application. While the creation of the predictive LOS models may include only static historical data and the new first-type data, LOS predictions may change over time (sometimes quickly) as new EMR data of a second type becomes available. For example, the new second-type data may include new information associated with the patient or the care unit where the patient is currently bedded. The LOS predictions may be produced and sent to the EMR in as timely a fashion as possible, which requires near real-time data acquisition. Industry-standard mechanisms, such as HL7 and FHIR, are the primary near-real-time acquisition methods. Several additional data acquisition methods may also be used, such as data analytics reporting tools, API web services, and KB_SQL queries. This allows an automatic near-real-time two-way data pipeline. After the sub-act 410, in one example, the process 400 proceeds through sub-act 318 depending on whether new second-type data becomes available. In practice, for example, Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) estimated LOS may be generated at the sub-act 410 once per hour, using the most up-to-date data possible for all active inpatient encounters with an elapsed time ≥12 hours. At sub-act 314, in one example, if there is new second-type data available from, for example, a near-real-time data pipeline via HL7, FHIR, or other means, the process 400 proceeds to sub-act 316 to extract, process, and insert the new data to update the training dataset. The process 400 then returns to the sub-act 410 to re-execute the final LOS model. If there is no new second-type data available at the sub-act 314, the process 400 stays at the sub-act 314 to keep searching for new second- type data. In other examples, the sub-act 408d and the sub-act 318 may search for new data of the same type to be updated but may be performed at different periodicities. For example, the sub- act 318 may be performed more frequently than the sub-act 408d. In one example, after the LOS estimation is performed at the act 112, the process 100 proceeds to act 114 to predict the patient’s risk of in-hospital deterioration, such as serious negative health outcomes including organ failure, respiratory instability, sepsis, and even death, which may require an upgrade of the patient’s level of care. For example, the risk of patient deterioration over the next four hours may need to be gauged for patients throughout the hospital (including inpatients, observation patients, and ED boarders). The goal of identifying patients at high risk of deterioration is to forewarn providers. Knowing that a patient is at high risk for care upgrade, a provider may choose to take definitive action (such as transferring a patient to ICU), re-evaluate a patient’s condition, or simply become more watchful. Any of these actions can help prevent or reduce the severity of deterioration. FIG.4 illustrates a machine-learning process 500 to execute the act 114 to predict the deterioration risk of a patient admitted into the hospital according to an example. At sub-act 502, in one example, the process 500 starts by extracting and compiling various types of data. In various examples, the sub-act 502 may include sub-acts 502a, 502b, and 502c to extract several years (for example, five years) of clinical, operational, and financial data, primarily focused on patients and patient encounters, via various acquisition methods or standards. For example, the sub-act 502a extracts data via the HL7 standards including the FHIR standard, the sub-act 502b extracts data via interconnect web services such as the EMR web services, and the sub-act 502c extracts data via the KB_SQL queries. Other methods may be included in the sub-act 502, such as API / web service calls and event-driven real-time interfaces. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) An EMR is an application and database that acquires and stores clinical, operational, and financial data related to healthcare and health system operations. In one example, most data extracted at the sub-act 502 is extracted from the EMR. Categories of data acquired from the EMR include patient demographics, patient history, health and medical encounter details, medications, lab tests, vital signs, radiology results, nursing documentation, social determinants of health (SDOH), and financial details. At the sub-act 502a, in one example, data are extracted using the inpatient (or expected to be inpatient) or observation encounter en, where n ∈ {1,…,N} during the past five years, where each data sample represents a flat longitudinal single patient. More recent data, especially physiologic measurements, are considered while older data are treated as less relevant and often summarized. At sub-act 504, in one example, the extracted and compiled data are preprocessed. In various examples, the sub-act 504 may include sub-acts 504a and 504b. At sub-act 504a, the response variables for the ground truth of a deterioration risk model are estimated based on certain related clinical events. For example, these events may include an unplanned level of care elevation (acute to IMC or ICU, or IMC to ICU), a call to the rapid response team, a cardiac arrest, and death. In some examples, an objective of the act 114 is to identify patients up to a certain threshold time in advance of deterioration, such as four hours in advance of deterioration. Accordingly, patient data of deterioration events beyond the threshold time may be excluded. For patients who did not deteriorate, the median event time of all patients who did deteriorate may be used as the time threshold. After all variables have been analyzed individually and in concert to discover patterns, ranges, fluctuations over time, absences, distributions, correlations with other variables, and so forth, the most appropriate encoding techniques are chosen, and a data set created. Variables for which multiple encoding techniques are needed or wanted (for specific algorithms or discovery) are included multiple times in the data set, once for each encoding type. At sub-act 504b, in one example, the extracted and compiled data are feature-encoded and feature-engineered. The goal of both feature-encoding and feature-engineering is to maximize the predictive power of the extracted data. Many techniques for both encoding and engineering may be used. The efficacy of each technique may be analyzed iteratively along with model and feature selection (as discussed in greater detail below) to identify one or more optimal techniques based on the chosen metric(s). Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In one example, for constructing the deterioration risk model, various types of variables are encoded from the data features and evaluated based on performance. For example, encoded variables may include numeric, boolean, ordinal, and categorical data features. Numerical data features include extracted data in the raw form such as height, weight, and BMI. Boolean data features may be encoded by uniformly converting extracted data to 1 (yes) and 0 (no) for information of, for example, whether a patient is on IV therapy, is in the ICU, or has previous encounters with a hospital or hospital system. Ordinal data features may be converted from the extracted data into a series of sequential integers while preserving their original rankings (for example, pain score and admission level of care). For categorical data features, when the number of categories is reasonable, the data features may be encoded by either one-hot encoding (dummy encoding) or frequency encoding. For example, data features relating to admission source, mode of arrival, and primary insurance type may use one-hot encoding, and data relating to ZIP code, financial class, and type of breathing assistance may use frequency encoding. When the number of categories is large enough to cause dimensionality problems, the data features may be encoded by either hash encoding or grouping (especially when an appropriate industry standard “grouper” is available). For example, some EMRs may define tens of thousands of order codes, some with industry- standard coding, and some without. Because not all of them can be grouped in useful or meaningful ways, hash encoding is used to reduce the dimensionality while attempting to preserve enough detail to facilitate predictive modeling. On the other hand, medication data is generally stored as NDC codes, of which there are tens of thousands. To group these into manageable categories, ATC pharmacological and therapeutic groupings are used, as provided by the WHO. Diagnoses are generally represented as ICD codes. Again, there are tens of thousands of ICD codes. To group these into manageable categories, CCSR body systems and clinical categories are used. In one example, for constructing the deterioration risk model, variables that change over time are also encoded from the data features and evaluated based on performance. Although many healthcare data variables change over time, vital signs, for example, and the resulting chronological vectors are often irregular and / or sparse. Nevertheless, these types of data are still treated as time series variables. For each time series variable regardless of the type, the features created (after encoding the extracted data appropriately) include first value, most recent value, Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) time since the most recent value is recorded, total number of values recorded, and average number of values recorded per day. Additional features are created for each numeric time series variable, which include median value, minimum value, maximum value, variance, difference between the median value and the most recent value, difference between the median value and the fist value, difference between the first value and the most recent value, first quartile boundary, third quartile boundary, time spent in each quartile, time spent in each quartile as a percentage of total encounter time, current quartile, and the slope of a regression model fit to the values (for example, heart rate, pain score, and white blood count). Additional features may be created for each boolean time series variable, including time spent in positive and negative states (in fractional days) and time spent in positive and negative states as a percentage of total encounter time (for example, time on a ventilator, in ICU, and for receiving antibiotic). Additional features may be created for each ordinal variable (after being transformed or encoded), including time spent in each ordinal level (in fractional days) and time spent in each ordinal level as a percentage of total encounter time (for example, pain score, RASS level, and patient mobility). Additional features may be created for each categorical variable, including time spent in each category (in fractional days) and time spent in each category as a percentage of total encounter time (for example, affect and behavior, WDL, and central line status). In various examples, at the sub-act 504, a series of summarized variables are produced from less recent data (that is, patient data of deterioration events beyond the threshold period, such as four hours). For example, the summarized variables may include encounter history, diagnostic history, and medication history. Encounter history may include previous encounter data, number of inpatient encounters, average number of inpatient encounters per year, days since most recent inpatient encounter, number of ED / observation encounters, average number of ED / observation encounters per year, days since most recent ED / observation encounter, number of scheduled outpatient encounters, days since most recent outpatient encounter, number of inpatient days over the past five years (or other periods of time), number of surgical procedures performed over the past five years (or other periods of time), days since most recent surgical procedure, discharge disposition and location for the most recent encounter, number of different home addresses recorded, count of all deterioration events prior to the most recent encounter, days since the most recent deterioration event, and / or other information. Diagnostic history may Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) include CCSR categories for all diagnoses recorded prior to the current encounter (one boolean feature per category) and CCSR body systems for all diagnoses recorded prior to the current encounter (one boolean feature per body system). Medication history may include ATC pharmacological groups for all medications recorded prior to the current encounter (one boolean per group) and ATC therapeutic groups for all medications recorded prior to the current encounter (one boolean per group). At sub-act 506, in one example, the type of machine-learning algorithm for the deterioration risk model is selected from various types of algorithms. In various examples, the sub-act 506 includes sub-acts 506a and 506b. At the sub-act 506a, in one example, various binary models are trained, each using a different type of algorithm. For the training, folds and splits are constructed for an augmented version of k-fold cross-validation. The data set resulting from feature encoding and engineering is first split into two sets, one containing the oldest 85% of encounters (train-0), and the other containing the most recent 15% of encounters (test-0). Train-0 is further split into five “folds” of relatively equal size. Two constraints are imposed on the train-0 splitting process: to avoid cross-encounter data leakage, each fold is limited to a unique set of patients, including all encounters for those patients; each sub-set contains at least one sample of each category for all categorical variables. Each type of algorithm is trained using only split 1, with folds 2-5 used for training and fold 1 used for measuring performance. Hyperparameters for each model are chosen based on a coarse-grained grid search. Features are culled separately for each model using algorithm- specific methods, requirements, and constraints. In some examples, further transformation and / or augmentation of the data may be required. For example, some algorithms cannot handle missing values so various imputation methods are used to address them. Some algorithms perform best when numeric data have been normalized so appropriate normalization techniques may be applied to those features. Some algorithms perform poorly if highly correlated features are used so a cross-correlation matrix is generated, and over-correlated features are dropped. Some algorithms perform better when continuous numeric features are split into binary “buckets.” Some algorithms cannot handle the number of features in the training data so feature culling techniques (for example, follow-the-regularized-leader [FTRL]) are applied. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In one example, at the sub-act 506a, the evaluated types of algorithms include Ridge Regression with greedy FTRL feature selection, Support Vector Regression (linear, RBF, and polynomial), Random Forest, and / or Gradient Boosting (CatBoost and XGBoost). At the sub-act 506b, in one example, the performance of each tuned model is evaluated using a set of metrics. Although the target variable is binary, the desired model output is a probability expressed as a number between 0.0 (risk is 0%) and 1.0 (risk is 100%). In addition, the data are unbalanced, with the prevalence of deterioration risk generally ranging between 8% and 12%. AUC-ROC may be chosen as the primary measure of “goodness” partly because of its resistance to unbalanced data. In some examples, AUC-PR may be added as a secondary metric to provide a sanity check. In addition, error distributions are analyzed to understand the conditions under which each model performs best and worst. In one example, at the sub-act 506b, Gradient Boosting, specifically Extreme Gradient Boosting (XGBoost), may be chosen as the final algorithm type for constructing the deterioration risk binary model. In other examples, one or more other machine-learning algorithms may be chosen alone or in various combinations at the sub-act 506b. At sub-act 508, in one example, the hyperparameters of the selected type of algorithm are optimized and feature culling is performed, both by training, to construct, optimize, validate, and update the final admission likelihood model. In various examples, the sub-act 508 may include sub-acts 508a, 508b, 508c, 508d, and 508e. At the sub-act 508a, in one example, the final model is constructed. While a single 80 / 20 split may be used to evaluate modeling algorithms at the sub-act 506, five separate models using different 4+1 combinations are first constructed at the sub-act 508a for the hyperparameter optimization of the final model. In one example, the hyperparameters defined below are optimized to improve the performance of the XGBoost model. Number of trees may be limited to a particular threshold amount; for example, the number of trees may be capped at 2,500. Maximum tree depth is the maximum depth of the trees which controls the model complexity. Its range is uniformly set between any of various numbers, such as between 3 and 8. Learning rate determines the step size during model training (for example, sampled from a logarithmic scale between 0.001 and 0.3) to allow for both small and large step sizes. Minimum child weight specifies the minimum sum of instance weights required for a child node to split, helping control overfitting. Its range and step Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) size may be selected according to various design concerns; in one example, the range is set between 1 and 25 with a step size of 5. Minimum split loss (Gamma) defines the minimum loss reduction required for partitioning a leaf node and controls regularization. Its value and step size may be selected according to various design concerns; in one example, the range minimum split loss is sampled between 0.5 and 1 with a step size of 0.05. Subsample ratio represents the fraction of training samples used for building each tree, uniformly sampled between, for example, 0.5 and 1 with a step size of 0.1. Column sample by tree specifies the fraction of features to be randomly sampled for each tree, sampled uniformly between, for example, 0.5 and 1 with a step size of 0.1. Scale positive class weight is a parameter that may be particularly beneficial for handling imbalanced classes in a binary setup. It adjusts the balance of positive and negative weights to handle imbalanced data, sampled uniformly between, for example, 1 and 5 to give more weight to the positive class. Lambda (regularization rate in L2 regularization) may also be specified. In one example, at the sub-act 508b, the hyperparameters for each of the five models are fine-tuned using a differential evolution (DE) optimization procedure. DE is an extremely parallelizable technique so the workload may be spread across several servers to reduce run time. The goal of the optimization is to identify the optimal hyperparameter set λ∗that maximizes the AUC-ROC score, expressed as an objective function ^^λ^. Let ^^^^represent the AUC-ROC score of the XGBoost model with hyperparameters ^. The optimization problem is defined as: λ∗ = arg m^∈a^x ^ ^λ^,where ^ represents the hyperparameters to be optimized (for example, learning rate, maximum depth, regularization terms, and so forth), and Λ is the space of possible hyperparameters. For surrogate model fitting, a tree-structured Parzen estimator (TPE) may be used as the surrogate model to approximate the objective function ^^^^. TPE models the likelihood of good and bad hyperparameter configurations based on previous observations. Let ^^^^ be the likelihood of high-performing hyperparameters (those improving AUC-ROC) and ^^^^be the likelihood of low-performing hyperparameters (those reducing AUC-ROC). These distributions are updated based on observed evaluations, and the surrogate model is used to predict the performance of new hyperparameter configurations. In various examples, the surrogate model is iteratively refined as more real-time data is collected. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) For acquisition maximization, an acquisition function is used to guide the selection of the next hyperparameters for evaluation. This function maximizes the expected improvement by selecting configurations that optimize the ratio λ^ = arg m ^^^^^∈a^x ^^^^. This ratio directs the optimization process, balancing exploration (trying hyperparameters where the model is uncertain) and exploitation (choosing hyperparameters that are likely to perform well based on the surrogate model). In certain examples, feature culling may also be performed at the sub-act 508b. The importance of each feature for each model is determined using SHAP analysis. SHAP is a model-agnostic approach that uses coalitional game theory to evaluate each model feature representing how much that feature contributes to the model’s output. Features with zero contribution, based on the SHAP analysis, are dropped, and models are retrained without them to rule out anomalous behavior. Moreover, in various examples, the sub-act 508a may include investigating and, when necessary, mitigating biases of various types. Subsets of results from all fine-tuned models are used to check for biases by comparing them against the performance of the overall model. For example, the performance on a subset of results including only female patients may be compared to the performance of the entire model. For example, a bias check may be performed for the various categories including race, ethnicity, sex, language, and religion. If an unacceptable level of bias is discovered, attempts to mitigate that bias may be made. Mitigation may be done by over-sampling the biased population or re-weighting training samples to put more emphasis on the biased population. At the sub-act 508a, in one example, the final model is built using train-0 (a combination of all folds) and subsequently tested against test-0, a chronologically “most recent encounters” hold-out set, at the sub-act 508b. Hyperparameters for this final model are derived by averaging hyperparameters across all five split-based models. The feature set for the final model is a union of feature sets from all split-based models. The final model is built using the complete data set. Hyperparameters and the feature set are the same as for the train-0 model. Isotonic regression coefficients are calculated specifically for the final model. At the sub-act 508c, the final model is validated. If the behavior of the final model, including performance and levels of bias, is consistent with the split-based models obtained at Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) the sub-act 508a or sub-act 508b (“YES”), the process 500 proceeds to a sub-act 508d. Otherwise (“NO”), the process 500 returns to the sub-act 508a to find and fix the causes and reconstruct the final model. At the sub-act 508d, in one example, it is determined whether new real-time data of a first type are available for updating the dataset for training. For example, the new data of the first type may include relevant information such as whether certain care units become opened or closed which will affect the workflow through the hospital, or whether a new initiative is introduced at the hospital that affects the workflow of the nurses or doctors and changes where and when data are documented. In some examples, the sub-act 508d may be configured to be performed periodically, for example, daily, weekly, monthly, or quarterly, to search for new data of the first type. If new data are available (“YES”), the process 500 proceeds to the sub-act 508e to extract, process, and insert the new first-type data to update the dataset. After the dataset is updated, the process 500 returns to the sub-act 508b to retrain the final model with the updated dataset. If no new first-type data are available (“NO”) at the sub-act 508d, the process 500 proceeds to a sub-act 510 to execute the final model to output the deterioration likelihood prediction. At the sub-act 510, in one example, the final deterioration risk model may output a report showing the changes in the deterioration risk prediction over time in the context of a variety of patient-specific clinical measures being implemented at different times. The report may be displayed via the user interface 204 and may be in textural and / or graphical forms. Discretization of the output prediction at the sub-act 514 may still be needed because machine-learning models, even those that produce continuous results in the range of 0 to 1, do not generally produce outputs that resemble probabilities. Probabilistic alignment may be desirable for two reasons. First, non-probabilistic results can cause end-user cognitive dissonance. For example, people not trained in machine learning, statistics, or similar disciplines may not understand numbers that have no inherent meaning beyond rank. Second, model retraining may be done regularly (for example, quarterly) to incorporate new data and discover new patterns. Retrained models are likely to produce outputs with different characteristics (ranges, distributions, etc.) than their predecessors. In one example, to alleviate these problems, at sub-act 512, the model outputs are transformed to more closely match probabilities while preserving overall rank. If the error distribution of the final model exhibits sigmoidal characteristics, isotonic regression may be Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) chosen as the transformation technique. Other transformation techniques such as Platt scaling may also be considered. In one example, the pseudo-probabilities are discretized by thresholds pyramidally into four categories, where category 4 (highest risk) contains the smallest number of patients, and category 1 (lowest risk) contains the largest number of patients. This facilitates color coding and at-a-glance interpretation for end-users. In other examples, other numbers of discrete categories may be used for the pseudo-probabilities of the final model. While the creation of the predictive model may include only static historical data, per- patient deterioration risk scores may change over time (sometimes quickly) as new EMR data of a second type becomes available. For example, the new second-type data may include new information associated with the patient or the care unit where the patient is currently bedded. The deterioration risk scores may be calculated and sent to the EMR in as timely a fashion as possible, which requires near-real-time data acquisition. Industry-standard mechanisms, such as HL7 and FHIR, are the primary near-real-time acquisition methods. Several other data interoperability and acquisition methods are also used, such as data analytics reporting tools, API web services, and KB_SQL queries. This allows an automatic near-real-time two-way data pipeline. At the sub-act 510, in one example, the process 500 proceeds through sub-act 318 depending on whether new second-type data becomes available. In practice, for example, each readmission risk score may be updated in the EMR system display every few minutes (for example, every 8 to 12 minutes), depending on the availability of new data, to reduce the amount of variability in the displayed score over time and enhance the usability of the deterioration risk scores for clinical users. If there is new second-type data available from, for example, a near- real-time data pipeline via HL7, FHIR, or other means, the sub-act 318 is executed to extract, process, and insert the new data to update the training dataset. The process 500 then returns to the sub-act 510 to re-execute the final model. If there is no new second-type data available at the sub-act 318, the process 500 stays at the sub-act 318 to keep searching for new second-type data. In other examples, the sub-act 508d and the sub-act 318 may search for new data of the same type to be updated but may be performed at different periodicities. For example, the sub- act 318 may be performed more frequently than the sub-act 508d. The machine-learning process 500 for executing the act 114 to predict the patient’s deterioration risk may be performed via the user interface 204. For example, the user interface Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) 204 may display a graphical user interface (GUI) associated with the act 114. FIG.5 illustrates a GUI 600 associated with predicting deterioration risks of patients in a hospital according to an example. In one example, at the sub-act 512, a column 602 displays the colored or textured icons representing the patient deterioration risk scores predicted by the final model in descending order (from top to bottom) to assist in the decision-making of moving patients to higher levels of care in the next four hours. For example, if the deterioration risk score of a patient is in category 3 or 4, the corresponding icon may be displayed in red or of a first texture. If the deterioration risk score is in category 2, the corresponding icon may be displayed in yellow or of a second texture. If the deterioration risk score is in category 1, the corresponding icon may be displayed in green or of a third texture. Referring to FIG.1, in one example, if the deterioration risk of a patient is predicted to be low at the act 114, the process 100 proceeds to an act 124 at which the patient’s clinical readiness for discharge may be evaluated (described in more detail below). However, if the deterioration risk of the patient is predicted to be not low (medium or high), the process 100 proceeds to an act 116 to upgrade the patient’s level of care. For example, the patient’s level of care may be upgraded to ICU (or IMC or other levels higher than acute care bed at the act 110). In one example, following the act 116, the process 100 proceeds to an act 118 to predict the patient’s readiness for a care downgrade. FIG.6 illustrates a machine-learning process 700 for executing the act 118 to predict the patient’s readiness for a care downgrade from a higher level of care (such as an ICU bed at the act 116 or IMC bed at the act 120) to a lower level of care (such as an IMC bed at act 120 or acute care bed at act 122) at a future time according to an example. At sub-act 702, in one example, the process 700 starts with extracting and compiling patient data of different types in various ways. In various examples, the sub-act 702 includes a sub-act 702a and a sub-act 702b. In one example, the sub-act 702a may include receiving or extracting patient information (for example, from an EMR), the patient information including both discrete and non-discrete data available in the EMR about patients for current inpatient encounters en, where n ∈ {1,…,N}, such as information about the patient for the current hospitalization, time- features, event frequency features, prescription medications, patient’s healthcare insurer, comorbidities, and so forth. In some examples, the patient information may be received in real-time. The sub-act 702b may include extracting non- Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) structured data. Because a significant amount of information related to downgrade readiness hurdles is documented by clinical users in free-text notes which are not structured, such related information may be extracted from a variety of types of notes, for example, consult note, hospitalist note, and case management note, for each inpatient encounter en. In one example, the sub-act 702 may include compiling, receiving, or extracting hospital- unit-volume data on hospital unit volume vn, where n ∈ {1,…,N} for each inpatient encounter en, which measures the number of patients admitted to, or discharged from the hospital unit where the patient currently resides within a rolling window of time (for example, the past 12 hours). In some examples, the hospital-unit-volume information may be received in real-time. Patient data extraction and compilation at sub-act 702 may be performed in various ways. In various examples, the sub-act 702 may include systematically extracting input data from a variety of sources following standard medical data protocols such as HL7, FHIR, web services, connections to databases, data reporting schemes, and so forth. These protocols ensure consistent and seamless integration of data from multiple healthcare settings and devices. In one example, the sub-act 702 may include automatic data collection. Many data points, such as vital signs (heart rate, blood pressure), lab results, and medication administration, are collected automatically from medical devices integrated with EMR systems (for example, bedside monitors, laboratory systems that process bloodwork samples, and drug dispensing systems). These automatic inputs minimize manual errors and enhance the efficiency of data gathering. The sub-act 702 may include extracting patient data from manual data entry. Some data, such as clinician's assessments including height, weight, blood pressure, care plans including medications, family history, allergies, and patient-reported outcomes including pain score and symptoms, may be manually entered by healthcare professionals. To maintain consistency and accuracy, standard templates and checklists are used across different healthcare providers. The sub-act 702 may include extracting patient data using wearables and remote devices. In certain examples, data from patient-worn devices (for example, glucose monitors and fitness trackers) or remote monitoring systems can also be integrated into the EMR to provide continuous, real-time data streams. To account for the broadest possible range of patient characteristics, at sub-act 602, data may be extracted from diverse patient populations across different demographic groups, medical Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) conditions, and care settings. For example, patient demographics such as age, gender, ethnicity, and socioeconomic status are commonly captured during hospital admission processes. Diagnosis codes (ICD-10), clinical procedure codes, and patient treatment plans are also included to capture the diversity of patient conditions and healthcare needs. The data compilation at the sub-act 702 may include integrating information from various healthcare settings, including hospitals, clinics, and specialized care facilities. This comprehensive approach provides a holistic view of patient clinical encounters and outcomes. The data extraction at the sub-act 702 may follow data quality assurance protocols. In addition to automated checks for missing values and outliers, manual validation may be employed by clinical experts to confirm the accuracy of key variables, especially those that are manually entered or highly complex (for example, diagnostic codes and treatment plans). Throughout the data extraction and compilation process at the sub-act 702, privacy regulations such as HIPAA may be maintained. All data may be encrypted in transit and at rest, and de-identification techniques may be used when sharing or analyzing data, protecting sensitive patient information while allowing for meaningful analytics. At sub-act 704, in one example, the extracted and compiled patient data are preprocessed. In one example, the sub-act 704 includes sub-acts 704a, 704b, and 704c. At sub-act 704a, the response variables for ground truth are defined. The compiled dataset is preprocessed partly to establish reliable response variables, which serve as the ground truth labels for each binary model predicting downgrade readiness at specific future time intervals. For example, twelve binary models may be employed, each predicting the downgrade readiness at 2, 4, 6, 8, 10, ... , 24 hours in the future, respectively. The primary objective of defining the response variables is to accurately label each instance as either “ready for downgrade” or “not ready” within these designated timeframes. To achieve this objective, actual transfer times recorded in the EMRs are used as direct indicators of readiness for transfer to a lower or downgraded level of care. In cases where transfer times are not available or applicable, clinically validated proxies are utilized to represent a patient’s readiness for downgrade. These proxies may include specific clinical events or status changes, such as completion of stabilization protocols, achievement of certain physiological thresholds, or documented physician assessments indicating readiness for transfer. Each proxy is carefully chosen in consultation with clinical experts to ensure accuracy and relevance. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) By defining these response variables in this manner, the models may be trained with labels rooted in real clinical outcomes, enhancing the predictive performance and practical utility of each binary model across all timeframes. This systematic approach provides a strong foundation for developing models that can reliably forecast patient downgrade readiness, allowing for more informed and timely clinical decision-making in ICU and IMC settings. At sub-act 704b, in one example, the extracted patient data are feature-engineered to be ready for the following data transformation. The feature-engineering process is carefully designed to extract maximum value from patient data and enhance the predictive power of machine-learning models. The selection of data features is driven by clinical relevance, ensuring that the most meaningful variables are included. The key data features are identified in close collaboration with physicians and domain experts. In various examples, the sub-act 704b includes selecting features of current encounter information including critical aspects of the patient’s current hospital stay. This information includes patient demographics and clinical vital signs, hospital services and diagnoses, admission details, procedures and scheduled surgeries, medications and treatment plans, therapist evaluations and mobility assessments, and lab orders and results. Patient demographics and clinical vital signs may include core data, such as age, weight, height, body surface area (BSA), BMI, blood pressure, pulse, and temperature, which establish a baseline clinical profile. Hospital service and diagnoses may include information about current hospital services, primary diagnosis, admission reason, and overall acuity level, which provide insight into the patient’s condition and care requirements. Admission details may include factors such as admission type, source, level of care, unit-room-bed location, and arrival means (for example, emergency or scheduled admission), which give context to initial patient needs and subsequent changes in care level. Procedures and scheduled surgeries may include any recent procedures, ongoing treatments, or upcoming surgeries (for example, scheduled transitions from invasive to non- invasive support), which are critical indicators of care trajectory. These planned interventions often impact the patient’s readiness for a lower level of care, and their inclusion enhances the models’ ability to anticipate transfer timelines. Medications and treatment plans may include key aspects of the patient’s medication regimen, including recent changes in dosages or additions of critical medications (for example, antibiotics, sedatives, or vasoactive agents), which reflect real- Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) time clinical management and signal improvements or deteriorations relevant to downgrade readiness. Therapist evaluations and mobility assessments may include mobility scores, such as AM-PAC “6 Clicks” scores alongside therapist notes on the patient’s ability to perform daily activities, which offer important insight into functional status and progress toward transfer readiness. Lab orders and results may include data on lab tests (for example, blood gas analyses and electrolyte panels) which provide snapshots of vital organ function and stability and support decisions related to downgrade readiness based on clinical stability. The sub-act 704b may include selecting features of the most recent encounter information. To capture a holistic view of the patient’s care trajectory, important data from the patient’s most recent hospitalization, if available, is included in the feature engineering. This data may include historical stay attributes including the total length of stays, the level of care provided, and the hospital services utilized during the previous encounter, which provides context to the current clinical scenario. The data may also include previous diagnoses and clinical events. Previous diagnoses and significant clinical events (for example, ICU admission history and major surgeries) help create a timeline of patient acuity and recovery patterns, which informs the likelihood of downgrade readiness in the current encounter. The sub-act 704b may include selecting derived features from time-related dynamics and event frequencies. Derived features are generated to provide insights into time-related dynamics and event frequencies. These time-related dynamics track key aspects of a patient's healthcare clinical events, such as the number of days between the current and previous visits, the total hours spent in the hospital, and the time since the last mobility evaluation. Moreover, day-of- week effects are accounted for to capture potential variations in care based on the day the visit occurred. Event frequency features measure the frequency and cumulative occurrences of specific clinical events. For instance, the recent event counts, which represent the number of lab orders, transfers, or patient updates within a recent timeframe (for example, the past 12 hours) may be tracked. Cumulative event counts may also be calculated to monitor the total occurrences of key events (for example, lab orders and transfers) since admission. The sub-act 704b may include selecting derived features for hospital unit volume and bed turnover. These derived features are considered by tracking the number of patients admitted to, transferred into, or discharged from the hospital unit where the patient currently resides during a Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) defined period (for example, the past 12 hours or 24 hours). In addition, data on bed turnover rates and capacity utilization trends provide additional context on hospital pressures, helping predict whether a downgrade transfer is both feasible and appropriate within the desired timeframe. At sub-act 704c, in one example, the engineered data are transformed for input to the machine-learning models. Sub-act 704c may include converting the patient information and / or hospital-unit-volume information into a machine-interpretable format tailored to a desired machine-learning model (for example, XGBoost). A variety of transformation techniques may be applied based on the nature of the selected features. For numerical features, such as clinical measurements, the normalization technique may be used. This technique centers the data by removing the median and scales it based on the interquartile range, making it particularly resistant to outliers which are common in clinical datasets. In one example, a patient’s BMI, which might range from very low (for example, 15) to high (for example, 40), is normalized by subtracting the median BMI and scaling it based on the interquartile range (IQR). This makes the data more robust against outliers, such as extreme BMI values for patients with rare conditions. In another example, blood pressure readings, such as systolic values, typically range between 90 and 180 mmHg but can exhibit extreme values due to acute conditions. By normalizing these values, they are centered around the median systolic blood pressure and scale based on the IQR. This helps mitigate the influence of unusually high or low readings, providing a more stable dataset for model training. In another example, blood glucose levels, measured in mg / dL, can range from normal fasting levels around 70–99 mg / dL to very high values (for example, 200+ mg / dL) in cases of diabetes or stress-induced hyperglycemia. By normalizing glucose values through median- centering and IQR scaling, the skew from extreme glucose readings is reduced, ensuring that rare, high glucose levels do not disproportionately impact the model. In yet another example, the length of hospital stay often varies widely, with some patients staying only a few days and others remaining for weeks. Normalizing the length of stay by removing the median and scaling by the IQR ensures that the model can handle this variation effectively, reducing the impact of exceptionally long stays that might otherwise distort the feature distribution. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) For boolean features that represent binary outcomes, they are converted into 0 and 1 values to enable seamless integration into machine learning models. This binary format allows the models to interpret the presence or absence of specific patient conditions or statuses effectively. In one example, a patient’s first visit status is transformed into a boolean feature to capture whether a patient is experiencing their first hospitalization.1 represents a first-time visit and 0 indicates a repeat visit. This information is useful because first-time admissions may differ in complexity and transfer likelihood compared to subsequent visits In another example, surgery requirement status informing whether a patient requires surgery during their stay is also recorded as a boolean feature, with 1 indicating that surgery is needed and 0 indicating that surgery is not needed. This feature helps the model account for patients with surgical needs, who may have longer or more complex stays. For categorical features, one-hot transformation may be employed. This transformation converts categorical variables into one-hot encoded vectors, ensuring that the models can effectively interpret and analyze them. In doing so, rare categories (those occurring fewer than 100 times) are grouped and any unknown categories are treated as infrequent to ensure that even lesser-seen data is accounted for. In one example, hospital service type categories like “cardiology,” “oncology,” and “neurology” are each converted into separate binary columns (one for each service). If a patient is in Cardiology, their entry will have a “1” in the cardiology column and a “0” elsewhere. In another example, means of arrival categories like “ambulance,” “walk-in,” or “transferred” are transformed similarly. To handle rare categories (occurring fewer than a threshold number of times, such as 100 times), rare categories may be grouped under “other” to avoid sparsity issues in the models. If an unexpected category appears (for example, new means of arrival), the unexpected category may be treated as “other” to prevent the models from breaking due to unknown data. In another example, the level of care such as “ICU,” “IMC,” or “nursery” are also one- hot encoded. Each level of care is assigned its own binary column, enabling the models to identify the intensity of care required. Patients in ICU, for example, will have a “1” in the ICU column and a “0” in others. Grouping rare levels under “other” ensures that less frequent levels do not affect model performance. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) For ordinal features, the inherent ranking of these categories is preserved by converting them into numeric values based on a predefined order. If the model encounters an unknown category, a default numeric value (for example, -1) is assigned to allow the transformation process to handle unexpected inputs without disrupting the model performance. In one example, if a patient’s mobility level is classified as “fully mobile,” “assisted,” or “bedridden,” numeric values are assigned, such as 2, 1, and 0, respectively. This preserves the ranking while allowing the models to understand the progression of mobility states. If an unknown mobility level is encountered, it is assigned a default numeric value, such as -1, ensuring that the models can still process the data without disruption. In another example, the AM-PAC (activity measure for post-acute care) G-code metrics are encoded based on functional ability, reflecting the likelihood of discharge disposition. Lower-functioning codes (for example, CN, CM, and CL) are assigned lower numeric values and indicate a higher likelihood of subacute rehab while higher-functioning codes (for example, CJ, CI, and CH) are assigned higher values to suggest that the patient may be ready for discharge home. This numeric scale preserves the ranking, with CN mapped to 0 and CH to 6, to capture the progressive scale of functional ability. Unknown codes are assigned a default value of -1. In another example, the acuity level reflects the urgency of medical attention required, with levels ordered as “less urgent,” “urgent,” “emergent,” and “immediate.” These are assigned numeric values to capture the hierarchy, with 0 for “less urgent,” 1 for “urgent,” 2 for “emergent,” and 3 for “immediate.” This encoding ensures the model accurately interprets increasing acuity. Any unknown acuity level is assigned -1 to maintain data consistency. For textual data, which often include rich but unstructured data like the reason for visits, textual transformation is used. Textual transformation converts the text into a matrix of term frequency-inverse document frequency (TF-IDF) scores. By lowering the text to lowercase, ignoring common stop words, and focusing on the top 20 most important words, the transformation captures the most significant terms that best represent the textual data, enabling the models to process and interpret these insights effectively. In one example, for the feature of the reason for visit, a text field describing the patient’s reason for visiting the hospital (for example, “chest pain” and “shortness of breath”) is transformed into a matrix of TF-IDF scores. By converting the text to lowercase and ignoring common stop words (for example, “the” and “is”), the most relevant terms (for example, the top Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) 20 most relevant words) are focused on. This allows the models to emphasize the key factors driving the visit, such as “pain” or “breath,” which could be critical for predicting downgrade readiness or other outcomes. In another example, text fields of clinical notes are transformed into a matrix of TF-IDF scores, describing a patient's health status, treatment plan, and medical history such as quality improvement measures on deep vein thrombosis (DVT) prophylaxis, urinary catheter existence, ambulation status, and nutrition. In another example, text fields of operative notes that describe a patient’s surgery, such as type of surgery, estimated blood loss, type of anesthesia, and urine output are transformed into a matrix of TF-IDF scores. At sub-act 706, in one example, a machine-learning algorithm is selected from multiple types of algorithms for each binary model. The sub-act 706 may include sub-acts 706a and 706b. In one example, the sub-act 706a includes training the twelve binary models described above to predict downgrade readiness in different future time frames using algorithms of different types. In another example, the algorithm selection at the sub-act 706 may include training and evaluating only one or more of the twelve binary models using algorithms of different types. This multi-model approach implemented in the process 700 allows for greater granularity, as different clinical indicators may signal downgrade readiness at various stages of a patient’s ICU or IMC stay. For example, indicators signaling readiness for downgrade within 2 hours may differ significantly from those relevant within 12 or 24 hours. Training separate models for each timeframe allows each model to focus on the clinical features most pertinent to that specific interval, enabling more precise and context-aware predictions. The rationale for using multiple models lies in the complexity and variability of ICU or IMC patient conditions. Attempting to capture downgrade readiness across all time intervals with a single model would risk oversimplification and could dilute prediction accuracy because the relevance of specific clinical signals may fluctuate depending on the patient’s stage of recovery. For instance, vital signs, medication adjustments, or laboratory values can vary greatly in significance depending on whether a downgrade prediction is for the short term (for example, 2- 4 hours) or slightly longer intervals (for example, 12-24 hours). Multiple models allow us to better capture these nuances and account for clinical variability across the ICU or IMC care spectrum. Additionally, using distinct models for each timeframe allows each one to be fine- tuned to account for the unique distributions of clinical data, as indicators like heart rate variability, respiratory support needs, or lab trends may evolve differently over time. For Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) example, a model predicting downgrade readiness within the next 2 hours may weigh rapid changes in respiratory support more heavily whereas a model for a 24-hour interval might prioritize stabilized lab values and consistent vital signs. To integrate these multiple predictive outputs, a combined optimization approach is employed, which synthesizes each model’s output into a single, actionable downgrade readiness score. This ensemble method leverages the strengths of each timeframe-specific model while minimizing reliance on any single set of features. By optimizing the weightings of each model's predictions, this combined score provides a balanced, robust assessment of readiness for downgrade that can adjust dynamically to individual patient needs and clinical trajectories. At sub-act 706a, in one example, a plurality of binary models, each corresponding to one of the time intervals (from 2 hours to 24 hours), is executed and trained using different types of algorithms with default parameter settings, such as Random Forest, XGBoost, Support Vector Machines (SVM), and Neural Networks. The models are trained based on the data with features obtained from sub-act 704. To evaluate the performance of these models, in one example, a 5- fold cross-validation is employed using a dataset where the ground truth of whether the actual care downgrade occurred within the specified time frames is known. The dataset is split into five parts, with each model trained on four folds and tested on the remaining fold. This is repeated five times to ensure that each part of the dataset is used as a test set exactly once, providing a robust assessment of model performance. At sub-act 706b, in one example, a comprehensive comparison based on a set of metrics is performed for the various machine-learning algorithms to predict the patient’s readiness for care downgrade within the next 2, 4, 6, ... , and 24 hours. The binary models are evaluated based on key metrics including accuracy, precision, recall, F1-score, and the receiver operating characteristic-area under the curve (ROC-AUC). Accuracy measures overall prediction correctness. Precision focuses on minimizing false positives by ensuring that patients predicted as dischargeable were indeed ready for downgrade. Recall prioritizes the capture of all truly dischargeable patients, minimizing false negatives. ROC-AUC measures a model’s ability to distinguish between two classes (ready for downgrade or not ready). In one example, upon comprehensively evaluating the training results across all models based on the metrics above, XGBoost may outperform other algorithms by being able to handle complex and imbalanced clinical datasets. Furthermore, XGBoost may be able to prevent Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) overfitting through regularization. As a result, XGBoost may be selected at sub-act 706b as the optimal algorithm for each of the binary models, ensuring reliable and high-performance predictions for patient downgrade readiness across all time intervals in ICU or IMC settings. In other examples, one or more other machine-learning algorithms may be chosen alone or in various combinations at the sub-act 706b. At sub-act 708, in one example, a Bayesian optimization procedure may be implemented to fine-tune the hyperparameters of each binary model. This optimization ensures that each model maximizes its predictive performance while minimizing overfitting, allowing good generalization to unseen data. This allows further refining of the models’ accuracy to ensure that each binary model is a reliable tool for predicting whether a patient will be ready for transfer to a lower level of care within the specific time intervals. In one example, the hyperparameters defined below are optimized to improve the performance of the XGBoost model. Maximum tree depth is the maximum depth of the trees which controls the model complexity. In various examples, maximum tree depth may be set to a range between, for example, 3 and 10. Learning rate determines the step size during model training, sampled from a logarithmic scale between a range of values (for example, 0.001 and 0.3) to allow for both small and large step sizes. Minimum child weight specifies the minimum sum of instance weights required for a child node to split, helping control overfitting. In at least one example, minimum child weight may be set within a range between 1 and 6. Gamma defines the minimum loss reduction required for partitioning a leaf node and controls regularization. In at least one example, the gamma value may be sampled between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.05). Subsample ratio represents the fraction of training samples used for building each tree, uniformly sampled between a range of values (for example, a range of 0.5 and 1) with a specified step size (for example, a step size of 0.05). Column sample by tree specifies the fraction of features to be randomly sampled for each tree, sampled uniformly between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.1). Scale positive class weight is a parameter particularly beneficial for handling imbalanced classes in a binary setup. Scale positive class weight adjusts the balance of positive and negative weights to handle imbalanced data, sampled uniformly between a range of values (for example, 1 and 9) to give more weight to the positive class. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In one example, given the unbalanced nature of the dataset, the evaluation metric for fine- tuning the hyperparameters is selected as the Area Under the Precision-Recall Curve (AUC-PR), which is more suitable for handling imbalanced classes. The goal of the sub-act 708 is to identify the optimal hyperparameter set λ∗that maximizes the AUC-PR score, expressed as an objective function ^^λ^. Let ^^^^represent the AUC-PR score of the XGBoost model with hyperparameters ^. The optimization problem is defined as: λ∗ = arg m^∈a^x ^ ^λ^,where ^ represents the hyperparameters to be optimized (for example, learning rate, maximum depth, and regularization terms), and Λ is the space of possible hyperparameters. For surrogate model fitting, a TPE is used as the surrogate model to approximate the objective function ^^^^. TPE models the likelihood of good and bad hyperparameter configurations based on previous observations. Let ^^^^ be the likelihood of high-performing hyperparameters (those improving AUC-PR) and ^^^^ be the likelihood of low-performing hyperparameters (those reducing AUC-PR). These distributions are updated based on observed evaluations, and the surrogate model is used to predict the performance of new hyperparameter configurations. In various examples, the surrogate model is iteratively refined as more real-time data is collected. For acquisition maximization, an acquisition function is used to guide the selection of the next hyperparameters for evaluation. This function maximizes the expected improvement by selecting configurations that optimize the ratio λ^ = arg m^∈a^x ^^^^^^^^. This ratio directs the optimization process, balancing exploration (trying hyperparameters where the model is uncertain) and exploitation (choosing hyperparameters that are likely to perform well based on the surrogate model). For example, the Bayesian optimization procedure start at step one of initialization, in which a few initial random hyperparameter configurations are evaluated to gather baseline data. These configurations are chosen randomly within the specified hyperparameter space Λ and provide the initial observations necessary to build a surrogate model. At step two of surrogate model fitting, the surrogate model is fitted based on the observed data, constructing the ^^^^and Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) ^^^^ distributions. The surrogate model serves as a probabilistic estimator that guides the search for optimal hyperparameters, predicting how different configurations will perform without needing to evaluate each one directly. At step three of acquisition maximization, the next hyperparameter configuration is selected by maximizing the acquisition function, which balances exploration (testing hyperparameters where uncertainty is high) and exploitation (testing configurations likely to yield high performance based on the surrogate model). This ensures that the search efficiently converges towards optimal hyperparameters, even in complex search spaces. At step four of evaluation, for each selected hyperparameter configuration, the model is fit using XGBoost with a maximum of 500 boosting rounds per trial. Additionally, if there is no improvement in model performance after 100 boosting rounds, early stopping is triggered to prevent further unnecessary iterations. Performance may be evaluated using the AUC-PR score, which is particularly relevant for an imbalanced healthcare dataset, focusing on precision and recall. At step five of iteration, the optimization continues by repeating steps two to four. In one example, the total number of trials may be limited to a maximum value (for example, 50) to ensure that the search process remains efficient without overfitting the hyperparameter space. If, within these trials, the model reaches a plateau where further boosting rounds yield no significant improvement in AUC-PR scores, the optimization may be stopped and the hyperparameter fine-tuning is completed. At sub-act 710, in one example, a formulation of a final downgrade readiness at a specific future time is constructed, optimized, validated, and updated. To integrate and optimize the outputs of the binary models to accurately predict the patient downgrade readiness from the ICU 116 or IMC 120 across incremental 2-hour intervals up to 24 hours, a formulation to predict downgrade readiness in, for example, the next 6 to 12 hours is constructed that combines the weighted predictions from each model trained for all time intervals. The combination of the weights of these binary model predictions is optimized to generate an accurate and calibrated final downgrade readiness prediction for each patient. In various examples, the sub-act 710 includes sub-acts 710a, 710b, 710c, 710d, 710e, and 710f. At sub-act 710a, in one example, the formulation of the final downgrade readiness in the next 6 or 12 hours is constructed. For example, the formulation may be constructed as the median of the weighted downgrade likelihood ^^^^, where ^^^^is calculated as Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) ^^^^ = ∑^ ^ ^ ," ,...,^" ^^^^^^^ ,where ^ refers to the observation timestamp during the patient’s stay in the hospital. At any given time ^, ^^^^ predicts the final likelihood (or readiness) of downgrade within the next $ hours from that specific time ^. Also, the terms ^^^^^ represents the output of one of the twelve models for the downgrade likelihood within a respective time frame (the next 2, 4, 6, 8, ... , or 24 hours), and ^^is the corresponding weight subject to the normalization constraint ∑^ ^ ^ ," ,...,^" ^^ = 1.The primary goal of the formulation optimization of the final downgrade likelihood ^^^^ is to maximize the median, &'(^^^^^^ across the training dataset. All ^^^^ values computed from various patients and at various times ^ in the training data are gathered and sorted into a distribution. The median &'(^^^^^^ is the middle value in the sorted distribution, representing the typical likelihood across the population of all ^^^^values. At sub-act 710b, in one example, two key constraints are imposed on the maximization of &'()^^^^* to optimize ^^^^. First, the distribution of the final downgrade readiness may be maximized for patients likely to be ready, particularly focusing on predictions updated during early morning hours before the anticipated transfer, to increase the accuracy of identifying patients ready for downgrade within a configurable target timeframe, for example, the next 6 or 12 hours. By ensuring that the first quartile +1 of the final downgrade likelihood ^^^^is above a configurable threshold τ- (for example, 0.3), that is +1)^^^^* > τ- for ^ = time before downgrade at early morning (such as 6 AM or 7 AM),the downgrade likelihood ^^^^ is maintained sufficiently high when predicting downgrade readiness within the configurable target timeframe, for example, the next 6 or 12 hours, for enhancing early identification accuracy. Second, the distribution of final downgrade likelihood ^^^^may be minimized for patients who are predicted to remain in the ICU 116 or IMC 120, reducing the risk of mistakenly categorizing patients as ready for downgrade when they should remain in the higher level of care. By ensuring that the third quartile +3 of the final downgrade likelihood ^^^^ is below a configurable threshold 0^(for example, 0.5), that is +3)^^^^* < τ^ for ^ = other times before downgrade, Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) this constraint ensures that the optimized final downgrade likelihood ^^^^ does not become overly optimistic at other times before the downgrade to improve reliability and reduce the likelihood of premature downgrades. Therefore, in this example, the optimization problem can be mathematically defined as: ^ 42 53&'( )^^^^*, subject to∑^ ^ ^ ," ,...,^" ^^ = 1,+1)^^^^* > τ- for ^ = time before downgrade at early morning, and^^^^* < τ^ for ^ = other times before downgrade. To solve the optimization problem of finding the best weights for combining the twelve binary models into the optimized final downgrade likelihood ^^^^, a significant amount of randomly generated weight sets (for example, 100,000) are generated and evaluated. A formulation optimization procedure will be followed that maximizes the median, &'(^^^^^^, while ensuring that the two key constraints on quartiles +1)^^^^* and +3)^^^^* are met. At sub-act 710c, in one example, the formulation optimization procedure starts at step one of initialization, in which a large number of sets of weights ^^are generated while ensuringthat each set satisfies the constraint of ∑^ ^ ^ ," ,...,^" ^^ = 1. For example, 100,000 sets may begenerated to explore a broad range of potential combinations. At step two of evaluating &'(^^^^^^ for each set of weights, the likelihood of care downgrade within the next $ hours (2, 4, 6, 8, ... , and 24 hours) is computed for each patient during their stays in hospital at any given time ^. Then, &'(^^^^^^ can be obtained from the entire training data sets. At step three of checking constraints, it is verified that the two quartile constraints are satisfied. If a set of weights meets the constraints and yields an improved &'(^^^^^^, it is retained as the best candidate set. The steps one to three may be repeated for each set and through the entire volume of generated weight sets. The formulation optimization procedure stops when all sets of weights have been evaluated. The best-performing set of weights is selected for the final downgrade likelihood ^^^^based on the highest &'(^^^^^^ that satisfies the constraints. At the sub-act 710d, the final model formulation is validated. If the behavior of the final model formulation is consistent with those obtained at the sub-act 710a or sub-act 710c (“YES”), Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) the process 700 proceeds to the sub-act 710e. Otherwise (“NO”), the process 700 returns to the sub-act 710a to find and fix the causes and reformulate the final model. At the sub-act 710e, in one example, it is determined whether new real-time data of a first type are available for updating the dataset for training. For example, the new data of the first type may include relevant information such as whether certain care units become opened or closed which will affect the workflow through the hospital, or whether a new initiative is introduced at the hospital that affects the workflow of the nurses or doctors and changes where and when data are documented. In some examples, the sub-act 710e may be configured to be performed periodically, for example, daily, weekly, monthly, or quarterly, to search for new data of the first type. If new data are available (“YES”), the process 700 proceeds to the sub-act 710f to extract, process, and insert the new first-type data to update the dataset. After the dataset is updated, the process 700 returns to the sub-act 710c to retrain the final model with the updated dataset. If no new first-type data are available (“NO”) at the sub-act 710e, the process 700 proceeds to a sub-act 712 to execute the final model to output the downgrade likelihood prediction and discretize the prediction into final scores. At sub-act 712, in one example, the output or value of the optimized final downgrade readiness ^^^^is discretized. In certain examples, to further enhance the interpretability of the final scores by users such as hospital personnel, a discretization process may be implemented to transform the continuous final downgrade readiness (ranging from 0 to 1) into a number of distinct categories (for example, five categories of 1, 2, 3, 4, and 5). This discretization may be achieved by selecting cutoff values at the 20%, 35%, 50%, and 65% percentiles to categorize the values of the optimized final downgrade likelihood ^^^^. For example, category 1 may correspond to a final downgrade likelihood value of 0~20%, category 2 may correspond to a final downgrade likelihood value of 20~35%, category 3 may correspond to a final downgrade likelihood value of 35~50%, category 4 may correspond to a final downgrade likelihood value of 50~65%, and category 5 may correspond to a final downgrade likelihood value of 65~100%. In other examples, different cutoff values between 0% and 100% may be used for the discrete categorization, and / or different numbers of categories may be implemented. The resulting discrete downgrade readiness categories provide an intuitive and straightforward representation of a patient’s likelihood of care downgrade at a particular time in the future. This allows for consistent tracking over time and ensures that the downgrade Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) readiness scores over customizable timeframes are both interpretable and actionable within clinical settings. While the creation of the downgrade likelihood model may include only static historical data, the final scores may change over time (sometimes quickly) as new EMR data of a second type becomes available. For example, the new second-type data may include new information associated with the patient or the care unit where the patient is currently bedded. The downgrade likelihood scores may be calculated and sent to the EMR in as timely a fashion as possible, which requires near-real-time data acquisition. Industry-standard mechanisms, such as HL7 and FHIR, are the primary near-real-time acquisition methods. Several other data acquisition methods are also used, such as data analytics reporting tools, API web services, and KB_SQL queries. This allows an automatic near-real-time two-way data pipeline. After the sub-act 712, in one example, the process 700 proceeds through sub-act 318 depending on whether new second-type data becomes available. In practice, for example, each downgrade likelihood score may be updated in the EMR system display every few minutes (for example, every 8 to 12 minutes), depending on the availability of new data, to reduce the amount of variability in the displayed score over time and enhance the usability of the scores for clinical users. If there is new second-type data available from, for example, a near-real-time data pipeline via HL7, FHIR, or other means, the sub-act 318 is executed to extract, process, and insert the new data to update the training dataset. The process 700 then returns to the sub-act 712 to re- execute the final model. If there is no new second-type data available at the sub-act 318, the process 700 stays at the sub-act 318 to keep searching for new second-type data. In other examples, the sub-act 710e and the sub-act 318 may search for new data of the same type to be updated but may be performed at different periodicities. For example, the sub- act 318 may be performed more frequently than the sub-act 710e. In the example in FIG.1, the process 700 for executing the act 118 to predict the readiness for care downgrade is performed after a patient is placed in either the ICU 116 or IMC 120. In other examples, the process 700 for executing the act 118 may be performed after a patient is placed in any care units of an elevated care level. Referring to FIG.1, after the patient is downgraded to the IMC 120 and then again to an acute care bed 122, the process 100 proceeds to an act 124 in which a machine-learning process is executed to predict the patient’s clinical readiness for future discharge. FIG.7 illustrates a Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) machine-learning process 800 for executing the act 124 to predict the patient’s clinical readiness for discharge at a future time according to an example. At sub-act 802, in one example, the process 800 starts by extracting and compiling patient data of different types in various ways, including patient information and hospital-unit-volume information. In various examples, the sub-act 802 includes a sub-act 802a and a sub-act 802b. In one example, the sub-act 802a may include receiving or extracting patient information including both discrete and non-discrete data available in the EMR about patients for current inpatient encounters en, where n ∈ {1,…,N}, including information about the patient for the current hospitalization, time- event frequency features, prescription medications, patient’s healthcare insurer, comorbidities, and so forth. Patient information may be received in real-time from an EMR. The sub-act 802b may include extracting non-structured data. Because a significant amount of information related to clinical discharge hurdles is documented by clinical users in free-text notes which are not structured, discharge related information may be extracted from a variety of types of notes, for example, consult note, hospitalist note, and case management note, for each inpatient encounter en, where n ∈ {1,…,N}. In one example, the sub-act 802 may include compiling or receiving hospital-unit-volume information including data on hospital unit volume vn, where n ∈ {1,…,N} for each inpatient encounter en, which measures the number of patients admitted to, into, or discharged from the hospital unit where the patient currently resides within a rolling window of time (for example, past 12 hours). In some examples, hospital-unit-volume information may be received and / or updated in real-time. Patient data extraction and compilation at sub-act 802 may be performed in various ways. In various examples, the sub-act 802 may include systematically extracting input data from a variety of sources following standard medical data protocols such as HL7, FHIR, web services, connections to databases, data reporting schemes. These protocols ensure consistent and seamless integration of data from multiple healthcare settings and devices. In one example, the sub-act 802 may include automatic data collection. Many data points, such as vital signs (heart rate, blood pressure, and so forth), lab results, and medication administration, are collected automatically from medical devices integrated with EMR systems (for example, bedside monitors, laboratory systems that process bloodwork samples, and drug dispensing systems). These automatic inputs minimize manual errors and enhance the efficiency of data gathering. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) The sub-act 802 may include extracting patient data from manual data entry. Some data, such as clinician's assessments including height, weight, blood pressure, care plans including medications, family history, allergies, and patient-reported outcomes including pain score and symptoms, may be manually entered by healthcare professionals. To maintain consistency and accuracy, standard templates and checklists are used across different healthcare providers. The sub-act 802 may include extracting patient data using wearables and remote devices. In certain examples, data from patient-worn devices (for example, glucose monitors, and fitness trackers) or remote monitoring systems can also be integrated into the EMR to provide continuous, real-time data streams. To account for the broadest possible range of patient characteristics, at sub-act 802, data may be extracted from diverse patient populations across different demographic groups, medical conditions, and care settings. For example, patient demographics such as age, gender, ethnicity, and socioeconomic status are commonly captured during hospital admission processes. Diagnosis codes (ICD-10), clinical procedure codes, and patient treatment plans are also included to capture the diversity of patient conditions and healthcare needs. The data compilation at the sub-act 802 may include integrating information from various healthcare settings, including hospitals, clinics, and specialized care facilities. This comprehensive approach provides a holistic view of patient clinical encounters and outcomes. The data extraction at the sub-act 802 may follow data quality assurance protocols. In addition to automated checks for missing values and outliers, manual validation may be employed by clinical experts to confirm the accuracy of key variables, especially those that are manually entered or highly complex (for example, diagnostic codes, and treatment plans). Throughout the data extraction and compilation process at the sub-act 802, data may be encrypted in transit and at rest, and de-identification techniques may be used when sharing or analyzing data, protecting sensitive patient information while allowing for meaningful analytics. At sub-act 804, in one example, the extracted and compiled patient data are preprocessed. In one example, the sub-act 804 includes sub-acts 804a, 804b, and 804c. At sub-act 804a, the response variables for ground truth are defined. The compiled dataset is preprocessed partly to establish reliable response variables, which serve as the ground truth labels for each binary model predicting discharge likelihood at specific future time intervals. For example, six binary models may be employed, each predicting the discharge likelihood at 12, 24, 36, 48, 60, or 72 Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) hours in the future, respectively. The primary objective of defining the response variables is to accurately label each instance as either “clinically ready for discharge” or “not ready” within these designated timeframes. To achieve this objective, actual discharge times recorded in the EMR are used as a direct indicator of discharge readiness. In cases where discharge time is not available or applicable, clinically accepted proxies are utilized to represent a patient’s readiness for discharge. These proxies may include specific clinical events or status changes, such as completion of treatment plans or physician-documented readiness for discharge, which are validated in consultation with clinical experts to ensure accuracy and relevance. By defining these response variables, the models may be trained with labels rooted in real clinical outcomes, enhancing the predictive performance and practical utility of each binary model across all timeframes. This systematic approach provides a strong foundation for developing models that can reliably forecast patient discharge readiness, allowing for more informed clinical decision-making. At sub-act 804b, in one example, the extracted patient data are feature-engineered to be ready for the following data transformation. The feature-engineering process is carefully designed to extract maximum value from patient data and enhance the predictive power of machine-learning models. The selection of data features is driven by clinical relevance, ensuring that the most meaningful variables are included. The key data features are identified in close collaboration with physicians and domain experts. In various examples, the sub-act 804b includes selecting features of current encounter information including critical aspects of the patient’s current hospital stay. This information includes hospital services provided, the patient's diagnosis, reason for visit, level of care, acuity level, means of arrival, admission type & source, and unit-room-bed location. Additionally, essential clinical measures may be included, such as age, weight, height, BSA, BMI, blood pressure, pulse, and temperature, as well as relevant lab orders and results. To further enrich the data, therapist evaluations and notes are included, such as mobility levels and AM-PAC “6 Clicks” scores, which measure a patient’s ability to perform daily activities. The sub-act 804b may include selecting features of the most recent encounter information. In addition to the current encounter, important historical data from the patient’s most recent hospital stay is considered. The historical data may include the total length of stays, Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) the level of care provided, the hospital services utilized, and the diagnoses from that encounter. By including this historical context, the model can understand the patient’s care trajectory and further refine predictions based on both recent and current clinical information. The sub-act 804b may include selecting derived features from time-related dynamics and event frequencies. Derived features are generated to provide insights into time-related dynamics and event frequencies. These time-related dynamics track key aspects of a patient's healthcare clinical events, such as the number of days between the current and previous visits, the total hours spent in the hospital, and the time since the last mobility evaluation. Moreover, day-of- week effects are accounted for to capture potential variations in care based on the day the visit occurred. Event frequency features measure the frequency and cumulative occurrences of specific clinical events. For instance, the recent event counts, which represent the number of lab orders, transfers, or patient updates within a recent timeframe (for example, the past 12 hours) may be tracked. Cumulative event counts may also be calculated to monitor the total occurrences of key events (for example, lab orders and transfers) since admission. The sub-act 804b may include selecting derived features for hospital unit volume. These derived features are considered by tracking the number of patients admitted to, transferred into, or discharged from the hospital unit where the patient currently resides during a defined period (for example, the past 12 hours or 24 hours). At sub-act 804c, in one example, the engineered data are transformed for input to the machine-learning models. Transforming the engineered data may include converting the patient information and / or the hospital-unit-volume information into a machine-interpretable format tailored to a selected machine-learning model (for example, XGBoost). A variety of transformation techniques may be applied based on the nature of the selected features. For numerical features, such as clinical measurements, the normalization technique may be used. This technique centers the data by removing the median and scales the data based on the interquartile range, making the technique particularly resistant to outliers which are common in clinical datasets. In one example, a patient’s BMI, which might range from very low (for example, 15) to high (for example, 40), is normalized by subtracting the median BMI and scaling it based on the IQR. This makes the data more robust against outliers, such as extreme BMI values for patients with rare conditions. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In another example, blood pressure readings, such as systolic values, typically range between 90 and 180 mmHg but can exhibit extreme values due to acute conditions. By normalizing these values, they are centered around the median systolic blood pressure and scale based on the IQR. This helps mitigate the influence of unusually high or low readings, providing a more stable dataset for model training. In another example, blood glucose levels, measured in mg / dL, can range from normal fasting levels around 70–99 mg / dL to very high values (for example, 200+ mg / dL) in cases of diabetes or stress-induced hyperglycemia. By normalizing glucose values through median- centering and IQR scaling, the skew from extreme glucose readings is reduced, ensuring that rare, high glucose levels do not disproportionately impact the model. In yet another example, the length of hospital stay often varies widely, with some patients staying only a few days and others remaining for weeks. Normalizing the length of stay by removing the median and scaling by the IQR ensures that the model can handle this variation effectively, reducing the impact of exceptionally long stays that might otherwise distort the feature distribution. For boolean features that represent binary outcomes, they are converted into 0 and 1 values to enable seamless integration into machine learning models. This binary format allows the models to interpret the presence or absence of specific patient conditions or statuses effectively. In one example, a patient’s current stay in the ICU is recorded as a boolean feature. A patient’s current stay may be transformed into a binary indicator (1 for ICU, 0 for not in ICU) to ensure that the models can understand the importance of ICU status in predicting clinical discharge readiness. In another example, the feature of whether a patient is experiencing their first hospitalization is encoded as a boolean variable.1 represents a first-time visit and 0 indicates a repeat visit. This information is useful as first-time admissions may differ in complexity and discharge likelihood compared to subsequent visits. In another example, whether a patient requires surgery during their stay is also recorded as a boolean feature, with 1 indicating that surgery is needed and 0 indicating that it is not. This feature helps the model account for patients with surgical needs, who may have longer or more complex stays. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) For categorical features, one-hot transformation may be employed. This transformation converts categorical variables into one-hot encoded vectors, ensuring that the models can effectively interpret and analyze them. In doing so, rare categories (for example, those occurring fewer than 100 times) are grouped and any unknown categories are treated as infrequent to ensure that even lesser-seen data is accounted for. In one example, hospital service type categories like “cardiology,” “oncology,” and “neurology” are each converted into separate binary columns (one for each service). If a patient is in Cardiology, their entry will have a “1” in the cardiology column and a “0” elsewhere. In another example, means of arrival categories like “ambulance,” “walk-in,” or “transferred” are transformed similarly. To handle rare categories (occurring fewer than a threshold number of times, such as 100 times), rare categories may be grouped under “other” to avoid sparsity issues in the models. If an unexpected category appears (for example, new means of arrival), the unexpected category may be treated as “other” to prevent the models from breaking due to unknown data. In another example, the level of care such as “ICU,” “IMC,” or “nursery” are also one- hot encoded. Each level of care is assigned its own binary column, enabling the models to identify the intensity of care required. Patients in ICU, for example, will have a “1” in the ICU column and a “0” in others. Grouping rare levels under “other” ensures that less frequent levels do not affect model performance. For ordinal features, the inherent ranking of these categories is preserved by converting them into numeric values based on a predefined order. If the model encounters an unknown category, a default numeric value (for example, -1) is assigned to allow the transformation process to handle unexpected inputs without disrupting the model performance. In one example, if a patient’s mobility level is classified as “fully mobile,” “assisted,” or “bedridden,” numeric values are assigned, such as 2, 1, and 0, respectively. This preserves the ranking while allowing the models to understand the progression of mobility states. If an unknown mobility level is encountered, it is assigned a default numeric value, such as -1, ensuring that the models can still process the data without disruption. In another example, the AM-PAC (activity measure for post-acute care) G-code metrics are encoded based on functional ability, reflecting the likelihood of discharge disposition. Lower-functioning codes (for example, CN, CM, and CL) are assigned lower numeric values and Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) indicate a higher likelihood of subacute rehab while higher-functioning codes (for example, CJ, CI, and CH) are assigned higher values to suggest that the patient may be ready for discharge home. This numeric scale preserves the ranking, with CN mapped to 0 and CH to 6, to capture the progressive scale of functional ability. Unknown codes are assigned a default value of -1. In another example, the acuity level reflects the urgency of medical attention required, with levels ordered as “less urgent,” “urgent,” “emergent,” and “immediate.” These are assigned numeric values to capture the hierarchy, with 0 for “less urgent,” 1 for “urgent,” 2 for “emergent,” and 3 for “immediate.” This encoding ensures the model accurately interprets increasing acuity. Any unknown acuity level is assigned -1 to maintain data consistency. For textual data, which often include rich but unstructured data like the reason for visits, textual transformation is used. Textual transformation converts the text into a matrix of TF-IDF scores. By lowering the text to lowercase, ignoring common stop words, and focusing on the top 20 most important words, the transformation captures the most significant terms that best represent the textual data, enabling the models to process and interpret these insights effectively. In one example, for the feature of the reason for visit, a text field describing the patient’s reason for visiting the hospital (for example, “chest pain” and “shortness of breath”) is transformed into a matrix of TF-IDF scores. By converting the text to lowercase and ignoring common stop words (for example, “the” and “is”), the most relevant terms (for example, the top 20 most relevant terms) are focused on. This allows the models to emphasize the key factors driving the visit, such as “pain” or “breath,” which could be critical for predicting discharge readiness or other outcomes. In another example, text fields of clinical notes are transformed into a matrix of TF-IDF scores, describing a patient's health status, treatment plan, and medical history such as quality improvement measures on DVT prophylaxis, urinary catheter existence, ambulation status, and nutrition. In another example, text fields of operative notes that describe a patient’s surgery, such as type of surgery, estimated blood loss, type of anesthesia, and urine output are transformed into a matrix of TF-IDF scores. At sub-act 806, in one example, a machine-learning algorithm is selected from multiple types of algorithms. In certain examples, one or more of the algorithm types may include a binary model by default and may sometimes be specified to include a multi-class model. The sub-act 806 may include sub-acts 806a and 806b. In one example, the sub-act 806a includes training a plurality of binary models to predict clinical discharge likelihoods using algorithms of Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) different types. For example, the binary models may include six individual binary models, each binary model predicting whether a patient will be ready for discharge from the hospital at a respective future time (for example, in the next 12, 24, 36, 48, 60, or 72 hours from now). This multi-model approach implemented in the process 800 allows for greater granularity, as different clinical factors become more or less relevant at varying stages of patient recovery. For example, a patient ready for discharge in the next 12 hours may present different clinical indicators than one ready in the next 72 hours, making specialized models essential for capturing these nuances. By training distinct models for each time frame, each model may focus on the specific clinical signals relevant to its discharge window. This specialization allows for more precise predictions, as each model can be fine-tuned to prioritize key indicators such as vital signs, lab results, or medication effectiveness that are most significant at a particular stage in the patient's recovery. In contrast, attempting to use a single model for all time intervals may introduce unnecessary complexity and potentially dilute the accuracy of predictions across different time frames. Moreover, different clinical features often display varying distributions depending on how far along the patient is in their recovery. For instance, blood pressure trends or lab results may behave differently for patients nearing discharge within 12 hours compared to those expected to be discharged within 72 hours. By using multiple models, these variations are accounted for and each model’s handling of the data may be tailored accordingly, making the process 800 more robust and adaptable. Finally, the use of multiple models allows the integration of their outputs into an ensemble, which combines their predictions into an optimized, final discharge score (as discussed in greater detail below). This ensemble approach leverages the strengths of each model, ensuring that the final prediction is not overly reliant on any single set of features or data peculiarities. As a result, the process 800 is better equipped to handle outliers and provides more reliable discharge planning, enhancing decision-making for clinicians. At sub-act 806a, in one example, each binary model corresponding to one of the time intervals is executed and / or trained using different types of algorithms with default parameter settings, including Random Forest, XGBoost, SVM, and Neural Networks. The models are trained based on the data with features obtained from sub-act 804. To evaluate the performance of these models, in one example, a 5-fold cross-validation is employed using a dataset where the ground truth of whether the actual discharge occurred within the specified time frames is known. The dataset is split into five parts, with each model trained on four folds and tested on the Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) remaining fold. This is repeated five times to ensure that each part of the dataset is used as a test set exactly once, providing a robust assessment of model performance. Sub-act 806a may include executing the XGBoost algorithm to generate a plurality of binary models that predict the likelihood of discharging the patient within each of a plurality of timeframes, such as within 12 hours, within 24 hours, and so forth. At sub-act 806b, in one example, a comprehensive comparison based on a set of metrics is performed for various machine-learning algorithms to predict the likelihood of patient discharge within the next 12, 24, 36, 48, 60, and 72 hours. The binary models are evaluated and / or optimized based on key metrics including accuracy, precision, recall, F1-score, and the ROC-AUC. Accuracy measures overall prediction correctness. Precision focuses on minimizing false positives by ensuring that patients predicted as dischargeable were indeed ready for discharge. Recall prioritizes the capture of all truly dischargeable patients, minimizing false negatives. ROC-AUC measures a model’s ability to distinguish between two classes (discharged or not). In one example, upon comprehensively evaluating the training results across all models based on the metrics above, XGBoost may be preferred for handling complex and imbalanced clinical datasets. XGBoost may be able to prevent overfitting through regularization. As a result, XGBoost may be selected at sub-act 806b as the optimal algorithm for each of the binary models, ensuring reliable predictions for patient discharge readiness across the 12, 24, 36, 48, 60, and 72-hour intervals. In other examples, one or more other machine-learning algorithms may be chosen alone or in various combinations at the sub-act 806b. At sub-act 808, in one example, a Bayesian optimization procedure may be implemented to fine-tune the hyperparameters of each binary model. This optimization ensures that each model maximizes its predictive performance while minimizing overfitting, allowing it to generalize well to unseen data. This allows further refining of the models’ accuracy to ensure that each binary model is a reliable tool for predicting whether a patient will be ready for discharge within the specific time interval. In one example, the hyperparameters defined below are optimized to improve the performance of the XGBoost model. Maximum tree depth is the maximum depth of the trees which controls the model complexity. In various examples, maximum tree depth may be set to a range between, for example, 3 and 10. Learning rate determines the step size during model Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) training, sampled from a logarithmic scale between a range of values (for example, 0.001 and 0.3) to allow for both small and large step sizes. Minimum child weight specifies the minimum sum of instance weights required for a child node to split, helping control overfitting. In at least one example, minimum child weight may be set within a range of between 1 and 6. Gamma defines the minimum loss reduction required for partitioning a leaf node and controls regularization. In at least one example, the gamma value may be sampled between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.05). Subsample ratio represents the fraction of training samples used for building each tree, uniformly sampled between a range of values (for example, a range of 0.5 and 1) with a specified step size (for example, a step size of 0.05). Column sample by tree specifies the fraction of features to be randomly sampled for each tree, sampled uniformly between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.1). Scale positive class weight is a parameter particularly beneficial for handling imbalanced classes in a binary setup. Scale positive class weight adjusts the balance of positive and negative weights to handle imbalanced data, sampled uniformly between a range of values (for example, 1 and 9) to give more weight to the positive class. In one example, given the unbalanced nature of the dataset, the evaluation metric for fine-tuning the hyperparameters is selected as the AUC-PR, which is more suitable for handling imbalanced classes. The goal of the sub-act 808 is to identify the optimal hyperparameter set λ∗that maximizes the AUC-PR score, expressed as an objective function ^^λ^. Let ^^^^ represent the AUC-PR score of the XGBoost model with hyperparameters ^. The optimization problem is defined as: λ∗ = arg m^∈a^x ^ ^λ^,where ^ represents the hyperparameters to be optimized (for example, learning rate, maximum depth, and regularization terms), and Λ is the space of possible hyperparameters. For surrogate model fitting, a TPE is used as the surrogate model to approximate the objective function ^^^^. TPE models the likelihood of good and bad hyperparameter configurations based on previous observations. Let ^^^^ be the likelihood of high-performing hyperparameters (those improving AUC-PR) and ^^^^ be the likelihood of low-performing Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) hyperparameters (those reducing AUC-PR). These distributions are updated based on observed evaluations, and the surrogate model is used to predict the performance of new hyperparameter configurations. In various examples, the surrogate model is iteratively refined as more real-time data is collected. For acquisition maximization, an acquisition function is used to guide the selection of the next hyperparameters for evaluation. This function maximizes the expected improvement by selecting configurations that optimize the ratio λ^ = arg m^∈a^x^^^^ ^^^^. This ratio directs the optimization process, balancing exploration (trying hyperparameters where the model is uncertain) and exploitation (choosing hyperparameters that are likely to perform well based on the surrogate model). For example, the Bayesian optimization procedure starts at step one of initialization, in which a few initial random hyperparameter configurations are evaluated to gather baseline data. These configurations are chosen randomly within the specified hyperparameter space Λ and provide the initial observations necessary to build a surrogate model. At step one of surrogate model fitting, the surrogate model is fitted based on the observed data, constructing the ^^^^and ^^^^distributions. The surrogate model serves as a probabilistic estimator that guides the search for optimal hyperparameters, predicting how different configurations will perform without needing to evaluate each one directly. At step three of acquisition maximization, the next hyperparameter configuration is selected by maximizing the acquisition function, which balances exploration (testing hyperparameters where uncertainty is high) and exploitation (testing configurations likely to yield high performance based on the surrogate model). This ensures that the search efficiently converges towards optimal hyperparameters, even in complex search spaces. At step four of evaluation, for each selected hyperparameter configuration, the model is fit using XGBoost with a maximum number of boosting rounds per trial (for example, 500 boosting rounds per trial). Additionally, if there is no improvement in model performance after a certain number of boosting rounds (for example, 100 boosting rounds), early stopping is triggered to prevent further unnecessary iterations. Performance is evaluated using the AUC-PR Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) score, which is particularly relevant for an imbalanced healthcare dataset, focusing on precision and recall. At step five of iteration, the optimization continues by repeating steps two to four. In one example, the total number of trials may be limited to a maximum (for example, 50) to ensure that the search process remains efficient without overfitting the hyperparameter space. If, within these trials, the model reaches a plateau where further boosting rounds yield no significant improvement in AUC-PR scores, the optimization is stopped and the hyperparameter fine-tuning is completed. At sub-act 810, in one example, a formulation of a final clinical discharge likelihood at a specific future time is constructed, optimized, validated, and updated. To integrate and optimize the outputs of the binary models to more accurately predict the patient discharge likelihood at a specific future time (such as 24 hours from a current time) than a single binary model, a formulation is constructed that combines the weighted predictions from each model trained for different time intervals (12, 24, 36, 48, 60, and 72 hours). The primary objective is to optimize the weights of these binary model predictions to generate an accurate and calibrated discharge likelihood for each patient. In various examples, the sub-act 810 includes sub-acts 810a, 810b, 810c, 810d, 810e, and 810f. At sub-act 810a, in one example, the formulation of the final clinical discharge likelihood in the next 24 hours is constructed. Constructing the final clinical discharge likelihood may include combining the plurality of binary models into a single combined discharge model which may, in turn, include optimizing weightings for each discharge prediction of each binary model. For example, the formulation may be constructed as the median of the weighted discharge likelihood ^^^^, where ^^^^ is calculated as a sum of a plurality of weighted discharge predictions, ^^^^ = ^-^-^^^ + ^^^^^^^ + ⋯ + ^8^8^^^,where ^ refers to the observation timestamp during the patient’s stay in the hospital. At any given time ^, ^^^^ predicts the final likelihood of discharge within the next $ hours from that specific time ^ and may be referred to as a weighted discharge readiness quantization for the patient.Also, the terms ^-^^^, ^^^^^, ... , ^8^^^ represent the outputs of the six models (for the next 12, Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) 24, 36, 48, 60, and 72 hours) for the discharge likelihood within those respective time frames,and ^-, ^^, ... , ^8 are the corresponding weights subject to the normalization constraint^- + ^^ + ⋯ + ^8 = 1.The primary goal of the formulation optimization of the final discharge likelihood ^^^^is to maximize the median, &'(^^^^^^ across the training dataset. All ^^^^values computed from various patients and at various times ^ in the training data are gathered and sorted into a distribution. The median &'(^^^^^^ is the middle value in the sorted distribution, representing the typical likelihood across the population of all ^^^^ values. At sub-act 810b, in one example, two key restrictions are imposed on the maximization of &'()^^^^* to optimize ^^^^. First, the distribution of the final discharge likelihood ^^^^ for patients likely to be discharged may be maximized, particularly focusing on predictions updated at a specific time, for example, at 6 AM the day before discharge, to increase the accuracy of identifying patients ready for discharge the following day. By ensuring that the first quartile +1 of the optimized final discharge likelihood ^^^^is above a configurable minimum-value threshold τ- (for example, 0.3), that is +1)^^^^* > τ-for ^ = the specific time before discharge, for example, at 6 AM the previous day,the optimized final likelihood is maintained sufficiently high when predicting discharge one day before the actual discharge happens. Second, the distribution of the optimized final discharge likelihood ^^^^ may be minimized for patients who are predicted to remain in the hospital, reducing the risk of mistakenly categorizing patients as ready for discharge when they should remain under care. By ensuring that the third quartile +3 of the final discharge likelihood ^^^^is below a configurable maximum-value threshold 0^(for example, 0.5), that is +3)^^^^* < τ^ for ^ = other times before discharge, Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) this constraint ensures that the optimized final discharge likelihood ^^^^ does not become overly optimistic at other times before discharge. Therefore, in this example, the optimization problem can be mathematically defined as: 49^,4:2,…3,4< &'( )^^^^*, subject to= 1, +1)^^^^* > τ- = one discharge at 6 AM, and+3)^^^^* < τ^ for ^ = other times before discharge.To solve the optimization problem of finding the best weights for combining the six binary models into the optimized final discharge likelihood ^^^^, a significant amount of randomly generated weight sets (for example, 100,000) are generated and evaluated. A formulation optimization procedure will be followed that maximizes the median, &'(^^^^^^, while ensuring that the two key constraints on quartiles +1)^^^^* and +3)^^^^* are met. At sub-act 810c, in one example, the formulation optimization procedure starts at stepone of initialization, in which a large number of sets of weights ^-, ^^, ... , ^8 are generatedwhile ensuring that each set satisfies the constraint of ^- + ^^ + ⋯ + ^8 = 1. For example,100,000 sets may be generated to explore a broad range of potential combinations. At step two of evaluating &'(^^^^^^, for each set of weights, the likelihood of discharge within the next $ hours (12, 24, 36, 48, 60, and 72 hours) is computed for each patient during their stays in hospital at any given time ^. Then, &'(^^^^^^ can be obtained from the entire training data sets. At step three of checking constraints, it is verified that the two quartile constraints are satisfied. If a set of weights meets the constraints and yields an improved &'(^^^^^^, it is retained as the best candidate set. The steps one to three are repeated for each set and through the entire volume of generated weight sets. The formulation optimization procedure stops when all sets of weights have been evaluated. The best-performing set of weights is selected for the final discharge likelihood ^^^^based on the highest &'(^^^^^^ that satisfies the constraints. At the sub-act 810d, the final model formulation is validated. If the behavior of the final model formulation is consistent with those obtained at the sub-act 810a or sub-act 810c (“YES”), Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) the process 800 proceeds to the sub-act 810e. Otherwise (“NO”), the process 800 returns to the sub-act 810a to find and fix the causes and reformulate the final model. At the sub-act 810e, in one example, it is determined whether new real-time data of a first type are available for updating the dataset for training. For example, the new data of the first type may include relevant information such as whether certain care units become opened or closed which will affect the workflow through the hospital, or whether a new initiative is introduced at the hospital that affects the workflow of the nurses or doctors and changes where and when data are documented. In some examples, the sub-act 810e may be configured to be performed periodically, for example, daily, weekly, monthly, or quarterly, to search for new data of the first type. If new data are available (“YES”), the process 800 proceeds to the sub-act 810f to extract, process, and insert the new first-type data to update the dataset. After the dataset is updated, the process 800 returns to the sub-act 810c to retrain the final model with the updated dataset. If no new first-type data are available (“NO”) at the sub-act 810e, the process 800 proceeds to a sub-act 812 to execute the final model to output the discharge likelihood prediction and discretize the prediction into final scores. At the sub-act 812, in one example, the score or value of the optimized final discharge likelihood ^^^^is discretized. In certain examples, to further enhance the interpretability of the final scores by users such as hospital personnel, a discretization process may be implemented to transform the continuous final discharge likelihood (ranging from 0 to 1) into a number of distinct categories (for example, five categories of 1, 2, 3, 4, and 5). This discretization may be achieved by selecting cutoff values at the 20%, 35%, 50%, and 65% percentiles to categorize the values of the optimized final discharge likelihood ^^^^. For example, category 1 may correspond to a final discharge likelihood value of 0~20%, category 2 may correspond to a final discharge likelihood value of 20~35%, category 3 may correspond to a final discharge likelihood value of 35~50%, category 4 may correspond to a final discharge likelihood value of 50~65%, and category 5 may correspond to a final discharge likelihood value of 65~100%. Accordingly, sub- act 712 may include transforming the weighted discharge readiness quantization ^^^^ into a discharge prediction, that is, a value (for example, 1, 2, 3, 4, or 5) on a standardized scale (for example, 1-5). In other examples, different cutoff values between 0% and 100% may be used for the discrete categorization, and / or a different number of discrete categories may be implemented. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) The resulting discrete discharge likelihood categories provide an intuitive and straightforward representation of a patient’s likelihood of discharge at a particular time in the future. This allows for consistent tracking over time and ensures that the discharge scores are both interpretable and actionable within clinical settings. While the creation of the discharge likelihood model may include only static historical data, the final scores may change over time (sometimes quickly) as new EMR data of a second type becomes available. For example, the new second-type data may include new information associated with the patient or the care unit where the patient is currently bedded. The discharge likelihood scores may be calculated and sent to the EMR in as timely a fashion as possible, which requires near-real-time data acquisition. Industry-standard mechanisms, such as HL7 and FHIR, are the primary near-real-time acquisition methods. Several other data acquisition methods are also used, such as data analytics reporting tools, API web services, and KB_SQL queries. This allows an automatic near-real-time two-way data pipeline. After the sub-act 812, in one example, the process 800 proceeds through sub-act 318 depending on whether new second-type data becomes available. In practice, for example, each discharge likelihood score may be updated in the EMR system display every few minutes (for example, every 8 to 12 minutes), depending on the availability of new data, to reduce the amount of variability in the displayed score over time and enhance the usability of the scores for clinical users. If there is new second-type data available from, for example, a near-real-time data pipeline via HL7, FHIR, or other means, the sub-act 318 is executed to extract, process, and insert the new data to update the training dataset. The process 800 then returns to the sub-act 812 to re- execute the final model. If there is no new second-type data available at the sub-act 318, the process 800 stays at the sub-act 318 to keep searching for new second-type data. In other examples, the sub-act 810e and the sub-act 318 may search for new data of the same type to be updated but may be performed at different periodicities. For example, the sub- act 318 may be performed more frequently than the sub-act 810e. The machine-learning process 800 for executing the act 124 to predict the patient’s clinical readiness for discharge at a future time may be performed via the user interface 204. The user interface 204 may display a GUI associated with the act 124. FIG.8 illustrates a GUI 900 for predicting clinical readiness for discharging patients in a hospital in the next 24 hours according to an example. A first column 902 displays the discretized final discharge likelihood Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) scores of patients currently in the hospital in a transparent and straightforward manner to assist in the decision-making of whether any of the patients are ready to or should be discharged in the next 24 hours. A second column 904 displays the unit and bed numbers of the patients to identify those patients. For example, the patient in bed 129-A of unit 1W has a discharge likelihood score of 4 to be discharged from the hospital in the next 24 hours and the patient in bed 131-A of unit 1W has a discharge likelihood score of only 2. In other examples, discharge-likelihood scores may span a range other than 1 to 5. In various examples, after obtaining the discharge likelihood score of a patient at the act 124, the process 100 proceeds to an act 126 to predict the operational readiness of the hospital for discharging the patient. In one example, the act 126 may only be executed for the patients having a high enough discharge likelihood score. Discharge planning may be relevant to patient flow since delays in discharge can lead to hospital-wide congestion. After patients are identified as clinically ready for discharge, there still could be operational delays before the patients physically leave the hospital unless a set of conditions or criteria is met to safely discharge the patients. FIG.9 illustrates a machine-learning process 1000 for executing the act 126 to predict the operational readiness of the hospital for discharging a patient according to an example. At sub-act 1002, in one example, the process 1000 starts by extracting and compiling patient data of different types in various ways. In various examples, the sub-act 1002 includes a sub-act 1002a and a sub-act 1002b. In one example, the sub-act 1002a may include extracting structured data from EMR. A wide array of structured patient data from EMR systems are systematically extracted, including medical condition and recovery status, laboratory results, and treatments. Input data are extracted from a variety of sources following standard medical data protocols such as HL7, FHIR, web services, connections to databases, and data acquisition schemes. These protocols ensure consistent and seamless compilation of data from multiple healthcare settings and devices. The sub-act 1002a may include automatic data collection. Many data points, such as lab results and medication administration, are collected automatically from medical devices integrated with EMR systems (for example, laboratory systems that process bloodwork samples, and drug dispensing systems). These automatic inputs minimize manual errors and enhance the efficiency of data gathering. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) The sub-act 1002a may include manual data entries. Some data such as acuity of illness, functional assessment, physician and nurse assessments, and patient feedback and self- assessments such as physical mobility, understanding of their care instructions, SDOH barriers, and confidence in managing post-hospital care are manually entered by healthcare professionals. To maintain consistency and accuracy, standard templates and checklists are used across different healthcare providers. The sub-act 1002a may employ wearables and remote devices. In certain examples, data from patient-worn devices (for example, glucose monitors and fitness trackers) or remote monitoring systems can also be integrated into the EMR to provide continuous, real-time data streams. To account for the broadest possible range of patient characteristics, at sub-act 1002a, data may be extracted from diverse patient populations across different demographic groups, medical conditions, and care settings. For example, patient demographics such as age, gender, ethnicity, and socioeconomic status are commonly captured during hospital admission processes. Diagnosis codes (ICD-10), clinical procedure codes, and patient treatment plans are also included to capture the diversity of patient conditions and healthcare needs. The data compilation at the sub-act 1002a may include integrating information from various healthcare settings, including hospitals, clinics, and specialized care facilities. This comprehensive approach provides a holistic view of patient clinical encounters and outcomes. The data extraction at the sub-act 1002a may follow data quality assurance protocols. Ensuring high-quality data is paramount. In addition to automated checks for missing values and outliers, manual validation may be employed by clinical experts to confirm the accuracy of key variables, especially those that are manually entered or highly complex (for example, diagnostic codes, and treatment plans). Throughout the data extraction and compilation process at the sub-act 1002a, data may be encrypted in transit and at rest, and de-identification techniques may be used when sharing or analyzing data, protecting sensitive patient information while allowing for meaningful analytics. Act sub-act 1002b, in one example, non-structured data, such as free text in clinical notes, are extracted. An information extraction process is developed using natural language processing (NLP) techniques to obtain data and features related to tasks that must be completed for patients to be discharged. Pending tasks that need to be completed for the patients to be discharged from Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) a hospital are usually documented as free text within clinical notes by a multidisciplinary team, including physicians, nurses, case managers, physical therapists, and social workers who help coordinate the discharge planning process. The non-structured data may include data relating to clinical recovery, medication management, rehabilitation status, social and home support, insurance authorization and payment, post-discharge arrangements, and SDOH factors. Clinical recovery data confirm that the patient meets recovery milestones based on treatment protocols. Medication management data are used to confirm that all medications are reconciled, and the patient is stable on their medication regimen. Rehabilitation status data are used to confirm that the patient can safely manage their activities of daily living. Social and home support data are used to confirm that the family members or caregivers are ready to provide support or home care has been arranged. Insurance authorization and payment data are used to ensure that insurance or other payment mechanisms are in place, which can sometimes delay discharge. Post-discharge arrangement data are used to confirm that home care, transportation, or the availability of rehabilitation facilities, as these are logistical factors that need to be addressed before discharge can happen. SDOH factors data are used to confirm that if a patient identifies SDOH barriers to a stable environment in terms of food security, housing security / stability, transportation issues (to home and / or to follow-up appointments), and so forth, these SDOH barriers have been adequately addressed prior to discharge. The non-structured data may include consult notes, hospitalist notes, and case management notes. Consult notes are medical documents created by a consulting healthcare provider, usually a specialist, who is asked to evaluate a patient by the referring provider. A consult note may include the specialist's assessment, findings, and recommendations for further management or treatment. From this record of the consultation, insights and guidance may be provided for continuing care, such as suggested next-step treatments, lab tests or imaging, and follow-ups. Hospitalist notes are typically part of the patient's daily medical record and include updates on the patient’s condition, treatment plan, and any changes in their status during the hospital stay. The extracted data may provide assessment and diagnosis of the patient’s current condition, outline of medications, therapies, tests, or procedures planned for the patient, as well as any discharge considerations. The NLP techniques may include text removal and combination, sentence segmentation, lowercasing and stope word removal, spelling correction and abbreviation expansion, handling Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) temporal information, and discharge keywords. Text removal and combination includes removing duplicate notes and combining long notes separated into different database entries for continuation and completeness. Sentence segmentation includes splitting text into sentences to make analysis easier. Lowercasing and stop word removal includes converting text to lowercase and removing irrelevant words. Spelling correction and abbreviation expansion includes correcting typos and expanding medical abbreviations using a medical lexicon. Handling temporal information includes creating a timeline for each patient for key events (for example, treatment date and recovery status), and then aligning and standardizing dates to enable extraction of trends over time, particularly for lab results and medication adherence tracking. Discharge keywords include detecting and extracting information specially designed to detect patient discharge hurdles, such as “safe discharge plan,” “physical therapy and / or occupational therapy discharge recommendations,” and “transportation needs at discharge.” At sub-act 1004, in one example, the extracted and compiled patient data are preprocessed. In one example, the sub-act 1004 includes sub-acts 1004a, 1004b, and 1004c. At sub-act 1004a, the response variables for ground truth are defined. The compiled dataset is preprocessed to establish reliable response variables, which serve as the ground truth labels for a binary model to predict operational discharge readiness within, for example, the next 24 hours. To define this variable effectively, the dataset undergoes a thorough preprocessing phase that leverages data elements within the EMR system. This preprocessing focuses on identifying both direct discharge indicators (such as actual discharge timestamps) and proxy indicators that reflect operational readiness when actual discharge times may not be available. The most straightforward proxy for operational readiness is the actual discharge timestamp. For patients whose discharge process is documented in the EMR, the actual time of discharge serves as an objective marker for readiness, allowing the model to learn from definitive discharge events. In many cases, operational readiness may not align perfectly with documented discharge times due to operational delays, such as waiting for transportation or care coordination. In these cases, proxy indicators are essential to capture operational readiness more accurately. Proxy indicators may include clinical notes and medical orders, disposition documentation, consult and procedure completion times, and nursing and case management notes. Clinical notes and medical orders include clinician notes that indicate a plan to discharge or notations within medical orders, Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) signaling the discontinuation of key treatments or medications and providing insights into when the patient was operationally ready for discharge. Disposition documentation includes entries within the EMR where discharge dispositions (for example, home and rehabilitation facility) have been established or updated, which may imply operational readiness even before the actual discharge. Consult and procedure completion times include the timing of key consults, procedures, or diagnostics relevant to discharge clearance, suggesting that all necessary steps for discharge are complete. Nursing and case management notes include observations or documentation from nursing or case management staff indicating readiness to transition the patient out of the current care setting. Notes such as “awaiting transport” or “discharge pending” are operational indicators that can help define readiness in the absence of exact timestamps. Proxy indicators are refined through close collaboration with physicians, discharge planners, and other domain experts to ensure their clinical relevance and operational alignment. This collaboration ensures that only meaningful variables are included as proxies for readiness, reducing noise in the data and focusing the model on high-quality training signals. Once proxies and direct indicators are selected, they are validated against historical cases to assess how closely they align with actual operational readiness. This validation step helps to ensure that the chosen proxies, such as clinical notes and disposition entries, consistently reflect true discharge readiness and allow the model to generalize effectively. At sub-act 1004b, in one example, the extracted patient data are feature-engineered to be ready for the following data transformation. The feature-engineering process is carefully designed to extract maximum value from the compiled data and enhance the predictive power of machine-learning models. The selection of data features is driven by clinical relevance, ensuring that the most meaningful variables are included. The key data features are identified in close collaboration with physicians and domain experts. In various examples, the sub-act 1004b includes selecting features of relevant aspects of the patient’s current hospital stay. These features may include, for example, hospital services provided, the patient's diagnosis, reason for visit, level of care, acuity level, means of arrival, admission type and source, unit-room-bed location, and so forth. Additionally, relevant orders may be included, such as imaging, lab, procedure, therapy and diet, and the corresponding results. To further enrich the data, therapist evaluations and notes may be included, such as Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) mobility levels and AM-PAC “6 Clicks” scores, which measure a patient’s ability to perform daily activities. The sub-act 1004b may include selecting derived features from time-related dynamics and event frequencies. Derived features are generated to provide insights into time-related dynamics and event frequencies. These time-related dynamics track key aspects of a patient's healthcare clinical events, such as the number of days between the current and previous visits, the total hours spent in the hospital, and the time since the last mobility evaluation. Moreover, day-of-week effects are accounted for to capture potential variations in care based on the day the visit occurred. Event frequency features measure the frequency and cumulative occurrences of specific clinical events. For instance, the recent event counts, which represent the number of lab orders, transfers, or patient updates within a recent timeframe (for example, the past 12 hours) may be tracked. Cumulative event counts may also be calculated to monitor the total occurrences of key events (for example, lab orders and transfers) since admission. The sub-act 1004b may include selecting derived features from notes. These derived features are considered to identify discharge barriers, including recovery status (for example, medically ready for discharge), pending laboratory results, trends of vital signs, surgical or procedural recovery milestones, functional assessment from physical therapy and occupational therapy, and physician and nurse assessments. At sub-act 1004c, in one example, the engineered data are transformed for input to the machine-learning models. A variety of transformation techniques may be applied based on the nature of the selected features. For numerical features, such as clinical measurements, the normalization technique may be used. This technique centers the data by removing the median and scales the data based on the interquartile range, making the technique particularly resistant to outliers which are common in clinical datasets. In one example, numerical features may include the number of pending items, such as the total number of imaging, lab, procedure, therapy, and diet orders that are not completed. This number directly indicates operational readiness for discharge. In another example, the length of hospital stay often varies widely, with some patients staying only a few days and others remaining for weeks. Normalizing the length of stay by removing the median and scaling by the IQR ensures that the model can handle this variation Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) effectively, reducing the impact of exceptionally long stays that might otherwise distort the feature distribution. Boolean features that represent binary outcomes are converted into 0 and 1 values to enable seamless integration into machine learning models. This binary format allows the models to interpret the presence or absence of specific patient conditions or statuses effectively. In one example, whether a patient is medically ready for discharge is selected as a feature encoded as a boolean variable.1 represents medically ready and 0 indicates otherwise. In another example, a patient’s current stay in the ICU is recorded as a boolean feature. The current stay information may be transformed into a binary indicator (1 for ICU, 0 for not in ICU) to ensure that the models can understand the importance of ICU status in predicting clinical discharge readiness. In another example, whether a patient requires surgery during their stay is also recorded as a boolean feature, with 1 indicating that surgery is needed and 0 indicating that it is not. This feature helps the model account for patients with surgical needs, who may have longer or more complex stays. For categorical features, one-hot transformation may be employed. This transformation converts categorical variables into one-hot encoded vectors, ensuring that the models can effectively interpret and analyze them. In doing so, rare categories (for example, those occurring fewer than 100 times) are grouped and any unknown categories are treated as infrequent to ensure that even lesser-seen data is accounted for. In one example, hospital service type categories like “cardiology,” “oncology,” and “neurology” are each converted into separate binary columns (one for each service). If a patient is in Cardiology, their entry will have a “1” in the cardiology column and a “0” elsewhere. In another example, means of arrival categories like “ambulance,” “walk-in,” or “transferred” are transformed similarly. To handle rare categories (for example, those occurring fewer than 100 times), rare categories are grouped under “other” to avoid sparsity issues in the models. If an unexpected category appears (for example, new means of arrival), the unexpected category is treated as “other” to prevent the models from breaking due to unknown data. In another example, the level of care such as “ICU,” “IMC,” or “nursery” are also one- hot encoded. Each level of care is assigned its own binary column, enabling the models to identify the intensity of care required. Patients in ICU, for example, will have a “1” in the ICU Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) column and a “0” in others. Grouping rare levels under “other” ensures that less frequent levels do not affect model performance. For ordinal features, the inherent ranking of these categories is preserved by converting them into numeric values based on a predefined order. If the model encounters an unknown category, a default numeric value (for example, -1) is assigned to allow the transformation process to handle unexpected inputs without disrupting the model performance. In one example, the readiness for hospital discharge scale (RHDS) may be administered close to the discharge on a range of values (for example, on a scale from 0 to 10), with higher scores indicating greater readiness. In another example, scales such as Barthel index, which ranges from 0 to 100, and Katz index, which ranges from 0 to 6, may be employed to access a patient’s ability to perform activities of daily living (ADLs) and evaluate the patient’s physical readiness for discharge. In another example, the AM-PAC (activity measure for post-acute care) G-code metrics are encoded based on functional ability, reflecting the likelihood of discharge disposition. Lower-functioning codes (for example, CN, CM, and CL) are assigned lower numeric values and indicate a higher likelihood of subacute rehab while higher-functioning codes (for example, CJ, CI, and CH) are assigned higher values to suggest that the patient may be ready for discharge home. This numeric scale preserves the ranking, with CN mapped to 0 and CH to 6, to capture the progressive scale of functional ability. In another example, the acuity level reflects the urgency of medical attention required, with levels ordered as “less urgent,” “urgent,” “emergent,” and “immediate.” These are assigned numeric values to capture the hierarchy, with 0 for “less urgent,” 1 for “urgent,” 2 for “emergent,” and 3 for “immediate.” This encoding ensures the model accurately interprets increasing acuity. Any unknown acuity level is assigned -1 to maintain data consistency. For textual data, which often include rich but unstructured data like the reason for visits, textual transformation is used. Textual transformation converts the text into a matrix of TF-IDF scores. By lowering the text to lowercase, ignoring common stop words, and focusing on the most important words (for example, the top 20 most important words), the transformation captures the most significant terms that best represent the textual data, enabling the models to process and interpret these insights effectively. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In one example, for the feature of the reason for visit, a text field describing the patient’s reason for visiting the hospital (for example, “chest pain” and “shortness of breath”) is transformed into a matrix of TF-IDF scores. By converting the text to lowercase and ignoring common stop words (for example, “the” and “is”), the most relevant terms are focused on. This allows the models to emphasize the key factors driving the visit, such as “pain” or “breath,” which could be important for predicting discharge readiness or other outcomes. In another example, text fields of consult notes are transformed into a matrix of TF-IDF scores, describing a specialist’s assessment, findings, and recommendations for further management or treatment, for example, “consult with cardiology,” “follow up required,” and “continue cardiac monitoring,” which can identify barriers for discharge. In another example, text fields that describe a patient’s medical, social, or financial needs, for example, “pending guardianship,” “insurance authorization pending,” and “awaiting facility / agency acceptance,” are transformed into a matrix of TF-IDF scores. At sub-act 1006, in one example, a machine-learning algorithm is selected from multiple algorithms. The sub-act 1006 may include sub-acts 1006a and 1006b. In one example, the sub- act 1006a includes training binary classification models to predict operational readiness for discharge using algorithms of different types. For example, a binary model (predicting high or low) of each type may be employed to predict whether a patient is operationally ready to be discharged within the next 24 hours. At sub-act 1006a, in one example, binary models of different types are trained using different types of algorithms with default parameter settings, including Random Forest, XGBoost, SVM, and Neural Networks. The models are trained based on the data with features obtained from sub-act 1004. To evaluate the performance of these models, in one example, a ten- fold cross-validation is employed using a dataset where the ground truth of whether the actual discharge occurred within 24 hours is known. The dataset is randomly split into ten parts, with each model trained on nine folds and tested on the remaining fold. This may be repeated ten times to ensure that each part of the dataset is used as a test set exactly once, providing a robust assessment of model performance. The random split was repeated fifty times to further ensure a more stable and reliable estimate of model performance. At sub-act 1006b, in one example, the binary models of different types are evaluated based on key metrics including accuracy, precision, recall, and F1-score. Accuracy measures Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) overall prediction correctness. Precision focuses on minimizing false positives by ensuring that patients predicted as dischargeable were indeed ready for discharge. Recall prioritizes the capture of all truly dischargeable patients, minimizing false negatives. F1-score balances precision and recall, crucial in handling class imbalances often present in patient discharge scenarios. In one example, upon comprehensively evaluating the training results across all model types based on the metrics above, XGBoost consistently outperforms the other algorithms. Its strength in handling complex and imbalanced clinical datasets, coupled with its ability to prevent overfitting through regularization, makes it the most suitable algorithm for this task. As a result, XGBoost may be selected at sub-act 1006b as the optimal algorithm for the binary model, ensuring reliable predictions for operational readiness for discharge in the next 24 hours. In other examples, one or more other machine-learning algorithms may be chosen alone or in various combinations at the sub-act 1006b. At sub-act 1008, in one example, the hyperparameters of the selected type of machine- learning algorithm may be optimized through training and periodically updated. In some examples, the sub-act 1008 may include sub-acts 1008a, 1008, and 1008c. At sub-act 1008a, in one example, a Bayesian optimization procedure may be implemented to fine-tune the hyperparameters of the selected binary model. This optimization enables the model to maximize its predictive performance while minimizing overfitting, allowing the model to generalize well to unseen data. This allows further refining of the model’s accuracy to ensure that the model is a reliable tool for predicting whether a patient will be operationally ready for discharge within the next 24 hours. In one example, the hyperparameters defined below are optimized to improve the performance of the XGBoost model. Maximum tree depth is the maximum depth of the trees which controls the model complexity. In various examples, maximum tree depth may be set to a range between, for example, 3 and 10. Learning rate determines the step size during model training, sampled from a logarithmic scale between a range of values (for example, 0.001 and 0.3) to allow for both small and large step sizes. Minimum child weight specifies the minimum sum of instance weights required for a child node to split, helping control overfitting. In at least one example, minimum child weight may be set within a range of between 1 and 6. Gamma defines the minimum loss reduction required for partitioning a leaf node and controls Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) regularization. In at least one example, the gamma value may be sampled between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.05). Subsample ratio represents the fraction of training samples used for building each tree, uniformly sampled between a range of values (for example, a range of 0.5 and 1) with a specified step size (for example, a step size of 0.05). Column sample by tree specifies the fraction of features to be randomly sampled for each tree, sampled uniformly between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.1). Scale positive class weight is a parameter particularly beneficial for handling imbalanced classes in a binary setup. Scale positive class weight adjusts the balance of positive and negative weights to handle imbalanced data, sampled uniformly between a range of values (for example, 1 and 9) to give more weight to the positive class. In one example, given the unbalanced nature of the dataset, the evaluation metric for fine-tuning the hyperparameters is selected as the AUC-PR, which is more suitable for handling imbalanced classes. In other examples, other metrics may be added or may replace AUC-PR. The goal of the sub-act 1008a is to identify the optimal hyperparameter set λ∗that maximizes the AUC-PR score, expressed as an objective function ^^λ^. Let ^^^^represent the AUC-PR score of the XGBoost model with hyperparameters ^. The optimization problem is defined as: λ∗ = arg m^∈a^x ^ ^λ^,where ^ represents the hyperparameters to be optimized (for example, learning rate, maximum depth, and regularization terms), and Λ is the space of possible hyperparameters. For surrogate model fitting, a TPE is used as the surrogate model to approximate the objective function ^^^^. TPE models the likelihood of good and bad hyperparameter configurations based on previous observations. Let ^^^^be the likelihood of high-performing hyperparameters (those improving AUC-PR) and ^^^^be the likelihood of low-performing hyperparameters (those reducing AUC-PR). These distributions are updated based on observed evaluations, and the surrogate model is used to predict the performance of new hyperparameter configurations. In various examples, the surrogate model is iteratively refined as more real-time data is collected. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) For acquisition maximization, an acquisition function is used to guide the selection of the next hyperparameters for evaluation. This function maximizes the expected improvement by selecting configurations that optimize the ratio λ^ = arg m^^^^ ^∈a^x^^^^. This ratio directs the optimization process, balancing exploration (trying hyperparameters where the model is uncertain) and exploitation (choosing hyperparameters that are likely to perform well based on the surrogate model). For example, the Bayesian optimization procedure may start at step one of initialization, in which a few initial random hyperparameter configurations are evaluated to gather baseline data. These configurations are chosen randomly within the specified hyperparameter space Λ and provide the initial observations necessary to build a surrogate model. At step two of surrogate model fitting, the surrogate model is fitted based on the observed data, constructing the ^^^^ and ^^^^ distributions. The surrogate model serves as a probabilistic estimator that guides the search for optimal hyperparameters, predicting how different configurations will perform without needing to evaluate each one directly. At step three of acquisition maximization, the next hyperparameter configuration is selected by maximizing the acquisition function, which balances exploration (testing hyperparameters where uncertainty is high) and exploitation (testing configurations likely to yield high performance based on the surrogate model). This ensures that the search efficiently converges towards optimal hyperparameters, even in complex search spaces. At step four of evaluation, for each selected hyperparameter configuration, the model is fit using XGBoost with a maximum number of boosting rounds per trial (for example, 500 boosting rounds per trial). Additionally, if there is no improvement in model performance after a certain number of boosting rounds (for example, 100 boosting rounds), early stopping is triggered to prevent further unnecessary iterations. Performance is evaluated using the AUC-PR score, which is particularly relevant for our imbalanced healthcare dataset, focusing on precision and recall. At step five of iteration, the optimization continues by repeating steps two to four. In one example, the total number of trials may be limited to a maximum number (for example, 50) to ensure that the search process remains efficient without overfitting the hyperparameter space. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) If, within these trials, the model reaches a plateau where further boosting rounds yield no significant improvement in AUC-PR scores, the optimization is stopped and the hyperparameter fine-tuning is completed. At the sub-act 1008b, in one example, it is determined whether new real-time data of a first type are available for updating the dataset for training. For example, the new data of the first type may include relevant information such as whether certain care units become opened or closed which will affect the workflow through the hospital, or whether a new initiative is introduced at the hospital that affects the workflow of the nurses or doctors and changes where and when data are documented. In some examples, the sub-act 1008b may be configured to be performed periodically, for example, daily, weekly, monthly, or quarterly, to search for new data of the first type. If new data are available (“YES”), the process 1000 proceeds to the sub-act 1008c to extract, process, and insert the new first-type data to update the dataset. After the dataset is updated, the process 1000 returns to the sub-act 1008a to retrain the final model with the updated dataset. If no new first-type data are available (“NO”) at the sub-act 1008b, the process 1000 proceeds to a sub-act 1010 to execute the final model to output the operational readiness prediction. At the sub-act 1010, the determination of an appropriate probability cutoff is critical for classifying whether a patient is operationally ready to be discharged within the next 24 hours. This cutoff ensures that the final model’s predictions are both clinically actionable and aligned with operational priorities. To determine an optimal cutoff, in one example, the receiver operating characteristic (ROC) curve of the final model may first be analyzed. The ROC curve plots sensitivity (true positive rate) against specificity (false positive rate) for various probability cutoffs. The ROC curve visualizes the trade-off between the final model’s ability to correctly identify patients operationally ready for discharge (sensitivity) and its ability to correctly exclude patients not operationally ready for discharge (specificity). Second, in one example, Youden’s index (J) of the ROC curve may be calculated to identify the optimal cutoff that best balances sensitivity and specificity. Youden’s Index (J) is calculated for each point on the ROC curve: == ^'>?@^@A@^B + ^C'D@^@D@^B − 1,where sensitivity reflects the proportion of actual positives (operationally ready patients) correctly identified by the final model and specificity reflects the proportion of actual negatives Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) (not operationally ready patients) correctly excluded. The cutoff that maximizes Youden’s Index (J) may be selected as the optimal cutoff, as it ensures the best balance between the two metrics. Third, in one example, the clinical and operational circumstances of the patient may be incorporated into the determination of the cutoff. While the mathematical cutoff obtained above may provide a strong baseline, adjustments may be considered based on certain clinical and operational goals. For example, if minimizing missed opportunities to discharge patients is a priority, a slightly lower cutoff may be preferred to increase sensitivity. Conversely, in another example, to reduce false positives (incorrectly labeling patients as operationally ready), the threshold may be adjusted upward to favor specificity. In various examples, clinical stakeholders and / or operational teams may be engaged to validate and refine the cutoff based on practical circumstances. Fourth, in one example, the selected cutoff may be validated and then implemented. For example, the selected cutoff may be tested on a hold-out dataset to ensure robust performance. Key evaluation metrics, such as precision, recall, and F1-score, may be computed to assess the final model’s reliability with the chosen cutoff. In one example, an ROC curve is analyzed to reveal that a cutoff of 0.65 maximizes Youden’s index (J). This cutoff implies that patients with a predicted operational readiness probability above 0.65 are classified as having a “High” likelihood of operational readiness for discharge while those below 0.65 are classified as having a “Low” likelihood. Adjustments may also be made to ensure alignment with clinical safety protocols. An example of the prediction output of the operational readiness for discharge in the next 24 hours and an associated list of pending items remaining to be completed prior to discharge is shown in Table 1. Patient Name Chief Complaint Operational Pending Items Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) -Require Ambulance with Stretcher Mouse, Minnie Influenza; Shortness of Breath High -Schedule PCP follow-up appointment . While the creation of the operational readiness model may include only static historical data, the final prediction may change over time (sometimes quickly) as new EMR data of a second type becomes available. For example, the new second-type data may include new information associated with the patient or the care unit where the patient is currently bedded. The operational readiness prediction may be calculated and sent to the EMR in as timely a fashion as possible, which requires near-real-time data acquisition. Industry-standard mechanisms, such as HL7 and FHIR, are the primary near-real-time acquisition methods. Several other data acquisition methods are also used, such as data analytics reporting tools, API web services, and KB_SQL queries. This allows an automatic near-real-time two-way data pipeline. After the sub-act 1010, in one example, the process 1000 proceeds through the sub-act 318 depending on whether new real-time data of a second type becomes available for updating the model hyperparameters. In practice, for example, each prediction may be updated in the EMR system display every few minutes (for example, every 8 to 12 minutes), depending on the availability of new data, to reduce the amount of variability in the displayed score over time and enhance the usability of the predictions for clinical users. If there is new second-type data available from, for example, a near-real-time data pipeline via HL7, FHIR, or other means, the sub-act 318 is executed to extract, process, and insert the new data to update the training dataset. If new second-type data are available, the sub-act 318 is performed to extract, process, and insert the new data to update the input dataset. Then the process 1000 returns to the sub-act 1010 to re- execute the final model. If no new second-type data are available at sub-act 1010, the process 1000 stays at the sub-act 318 to keep searching for new second-type data. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In other examples, the sub-act 1008c and the sub-act 318 may search for new data of the same type to be updated but may be performed at different periodicities. For example, the sub- act 318 may be performed more frequently than the sub-act 1008c. In various examples, after obtaining the predicted operational readiness for discharging the patient at the act 126, the process 100 proceeds to an act 128 to predict the discharge disposition of the patient. Discharge disposition may refer to the destination to which a patient may be discharged, such as a long-term care facility, skilled nursing facility, rehabilitation facility, home, and others. In certain examples, the act 128 may only be executed for the patients having a high enough discharge likelihood score and / or a high operational readiness. The act 128 leverages the EMR data and overcomes the issue of high cardinality when predicting many classes. A customizable re-grouping module is employed to consolidate a number of discharge dispositions (for example, over 100 nuanced discharge dispositions) into major groups, reducing complexity and improving prediction accuracy. FIG.10 illustrates a machine-learning process 1100 to execute the act 128 to predict the discharge disposition of a patient at a future time according to an example. At sub-act 1102, in one example, the process 1100 starts by extracting and compiling patient data of different types in various ways. In various examples, the sub-act 1102 includes a sub-act 1102a and a sub-act 1102b. In one example, the sub-act 1102a may include extracting both discrete and non-discrete data available in the EMR about patients for current inpatient encounters en, where n ∈ {1,…,N}, including information about the patient for the current hospitalization, time-related features, event frequency features, prescription medications, patient’s healthcare insurer, comorbidities, and so forth. The sub-act 1102b may include extracting non-structured data. Because a significant amount of information related to operational discharge hurdles may be documented by clinical users in free-text notes that are not structured, discharge related information may be extracted from a variety of types of notes, for example, consult notes, hospitalist notes, and case management note, for each inpatient encounter en, where n ∈ {1,…,N}. In 1102 may include compiling data on hospital unit volume vn, where n ∈ {1,…,N} for each inpatient encounter en, which measures the number of patients admitted into, or discharged from the hospital unit where the patient currently resides within a defined time period (for example, past 12 hours). Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) Patient data extraction and compilation at sub-act 1102 may be performed in various ways. In various examples, the sub-act 1102 may include systematically extracting input data from a variety of sources following standard medical data protocols such as HL7, FHIR, web services, connections to databases, data reporting schemes, and so forth. These protocols ensure consistent and seamless integration of data from multiple healthcare settings and devices. In one example, the sub-act 1102 may include automatic data collection. Many data points, such as vital signs (for example, heart rate and blood pressure), lab results, and medication administration, are collected automatically from medical devices integrated with EMR systems (for example, bedside monitors, laboratory systems that process bloodwork samples, and drug dispensing systems). These automatic inputs minimize manual errors and enhance the efficiency of data gathering. The sub-act 1102 may include extracting patient data from manual data entry. Some data, such as clinician's assessments including height, weight, blood pressure, care plans including medications, family history, allergies, and patient-reported outcomes including pain score and symptoms, may be manually entered by healthcare professionals. To maintain consistency and accuracy, standard templates and checklists may be used across different healthcare providers. The sub-act 1102 may include extracting patient data using wearables and remote devices. In certain examples, data from patient-worn devices (for example, glucose monitors and fitness trackers) or remote monitoring systems can also be integrated into the EMR to provide continuous, real-time data streams. To account for the broadest possible range of patient characteristics, at sub-act 1102, data may be extracted from diverse patient populations across different demographic groups, medical conditions, and care settings. For example, patient demographics such as age, gender, ethnicity, and socioeconomic status are commonly captured during hospital admission processes. Diagnosis codes (ICD-10), clinical procedure codes, and patient treatment plans are also included to capture the diversity of patient conditions and healthcare needs. The data compilation at the sub-act 1102 may include integrating information from various healthcare settings, including hospitals, clinics, and specialized care facilities. This comprehensive approach provides a holistic view of patient clinical encounters and outcomes. The data extraction at the sub-act 1102 may follow data quality assurance protocols. Ensuring high-quality data is paramount. In addition to automated checks for missing values and Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) outliers, manual validation may be employed by clinical experts to confirm the accuracy of key variables, especially those that are manually entered or highly complex (for example, diagnostic codes, and treatment plans). Throughout the data extraction and compilation process at the sub-act 1102, data may be encrypted in transit and at rest, and de-identification techniques may be used when sharing or analyzing data, protecting sensitive patient information while allowing for meaningful analytics. At sub-act 1104, in one example, the extracted and compiled patient data are preprocessed. In one example, the sub-act 1104 includes sub-acts 1104a, 1104b, and 1104c. At sub-act 1104a, the response variables for ground truth are defined for training multi-class (that is, not binary) prediction models that estimate patient discharge dispositions. Unlike binary classification, where a model determines a simple “ready” or “not ready” status, this multi-class approach predicts a range of possible discharge outcomes, such as “home,” “skilled nursing facility (SNF),” “rehabilitation,” or other broad disposition categories. The creation of accurate response variables may be important, as it provides the multi-class model with the ground truth needed to learn and predict these complex patient outcomes. Discharge data may contain many disposition categories (for example, over 100 nuanced disposition categories), which vary across healthcare institutions and patient populations. Managing this level of detail can add complexity, potentially leading to overfitting and reduced model interpretability. To address this, a customizable re-grouping module 1004a1 may be constructed to consolidate these highly specific discharge dispositions into broader, clinically meaningful categories. For example, a first category of rehabilitation facilities may include specific dispositions like “discharge to on-site distinct rehabilitation unit from chronic for inpatients” or “discharge to off-site rehabilitation center specializing in post-acute care.” A second category of psychiatric facilities may encompass dispositions like “discharge to a psychiatric facility or an off-site psychiatric unit of another acute care hospital” and “transfer to on-site behavioral health rehabilitation program.” A third category of long-term care (LTC) facilities may cover specific placements such as “discharge to a LTC facility” or “transfer to nursing home with SNF level of care.” A fourth category of home care and community-based services may include “discharge to home with basic home health assistance,” “home discharge with comprehensive home care services,” and “discharge to hospice care at home.” A fifth category of specialized care settings may consist of dispositions like “transfer to subacute Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) rehabilitation unit within a skilled nursing facility,” “discharge to long-term acute care hospital (LTACH),” and “discharge to transitional care unit (TCU).” By consolidating these nuanced categories into major groups based on the customizable re-grouping module 1104a1, the model’s classification task becomes streamlined, improving accuracy and reducing complexity. The re-grouping module 1104a1 is also designed to be adaptable across diverse healthcare settings. Each institution or provider can customize the grouping based on their operational needs and disposition categories, enhancing the model’s flexibility and relevance to different environments. To create the response variables, actual recorded discharge dispositions in the EMR are used and cross-validated with clinical notes and hospital standards to ensure each patient’s discharge disposition is accurately represented. This approach ensures that the multi-class model is trained on reliable, real-world data, establishing high-quality labels for the multi-class output. At sub-act 1104b, in one example, the extracted patient data are feature-engineered to be ready for the following data transformation. The feature-engineering process is carefully designed to extract maximum value from patient data and enhance the predictive power of machine-learning models. The selection of data features is driven by clinical relevance, ensuring that the most meaningful variables are included. The key data features are identified in close collaboration with physicians and domain experts. In various examples, the sub-act 1104b includes selecting features of current encounter information including critical aspects of the patient’s current hospital stay. This information may include hospital services provided, the patient's diagnosis, reason for visit, level of care, acuity level, means of arrival, admission type and source, and unit-room-bed location. Additionally, essential clinical measures may be included, such as age, weight, height, BSA, BMI, blood pressure, pulse, and temperature, as well as relevant lab orders and results. To further enrich the data, therapist evaluations and notes are included, such as mobility levels and AM-PAC “6 Clicks” scores, which measure a patient’s ability to perform daily activities. The sub-act 1104b may include selecting features of the most recent encounter information. In addition to the current encounter, important historical data from the patient’s most recent hospital stay is considered. The historical data may include the total length of stays, the level of care provided, the hospital services utilized, and the diagnoses from that encounter. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) By including this historical context, the model can understand the patient’s care trajectory and further refine predictions based on both recent and current clinical information. The sub-act 1104b may include selecting derived features from time-related dynamics and event frequencies. Derived features are generated to provide insights into time-related dynamics and event frequencies. These time-related dynamics track key aspects of a patient's healthcare clinical events, such as the number of days between the current and previous visits, the total hours spent in the hospital, and the time since the last mobility evaluation. Moreover, day-of-week effects are accounted for to capture potential variations in care based on the day the visit occurred. Event frequency features measure the frequency and cumulative occurrences of specific clinical events. For instance, the recent event counts, which represent the number of lab orders, transfers, or patient updates within a recent timeframe (for example, the past 12 hours) may be tracked. Cumulative event counts may also be calculated to monitor the total occurrences of key events (for example, lab orders and transfers) since admission. The sub-act 1104b may include selecting derived features for hospital unit volume. These derived features are considered by tracking the number of patients admitted to, transferred into, or discharged from the hospital unit where the patient currently resides during a defined period (for example, the past 12 hours or 24 hours). At sub-act 1104c, in one example, the engineered data are transformed for input to the machine-learning models. A variety of transformation techniques may be applied based on the nature of the selected features. For numerical features, such as clinical measurements, the normalization technique may be used. This technique centers the data by removing the median and scales it based on the interquartile range, making it particularly resistant to outliers which are common in clinical datasets. In one example, a patient’s BMI, which might range from very low (for example, 15) to high (for example, 40), is normalized by subtracting the median BMI and scaling it based on the IQR. This makes the data more robust against outliers, such as extreme BMI values for patients with rare conditions. In another example, blood pressure readings, such as systolic values, typically range between 90 and 180 mmHg but can exhibit extreme values due to acute conditions. By normalizing these values, they are centered around the median systolic blood pressure and scale Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) based on the IQR. This helps mitigate the influence of unusually high or low readings, providing a more stable dataset for model training. In another example, blood glucose levels, measured in mg / dL, can range from normal fasting levels around 70–99 mg / dL to very high values (for example, 200+ mg / dL) in cases of diabetes or stress-induced hyperglycemia. By normalizing glucose values through median- centering and IQR scaling, the skew from extreme glucose readings is reduced, ensuring that rare, high glucose levels don’t disproportionately impact the model. In yet another example, the length of hospital stay often varies widely, with some patients staying only a few days and others remaining for weeks. Normalizing the length of stay by removing the median and scaling by the IQR ensures that the model can handle this variation effectively, reducing the impact of exceptionally long stays that might otherwise distort the feature distribution. For boolean features that represent binary outcomes, they are converted into 0 and 1 values to enable seamless integration into machine learning models. This binary format allows the models to interpret the presence or absence of specific patient conditions or statuses effectively. In one example, a patient’s current stay in the ICU is recorded as a boolean feature. A patient’s stay may be transformed into a binary indicator (1 for ICU, 0 for not in ICU) to ensure that the models can understand the importance of ICU status in predicting clinical discharge readiness. In another example, the feature of whether a patient is experiencing their first hospitalization is encoded as a boolean variable.1 represents a first-time visit and 0 indicates a repeat visit. This information is useful as first-time admissions may differ in complexity and discharge likelihood compared to subsequent visits. In another example, whether a patient requires surgery during their stay is also recorded as a Boolean feature, with 1 indicating that surgery is needed and 0 indicating that it is not. This feature helps the model account for patients with surgical needs, who may have longer or more complex stays. For categorical features, one-hot transformation may be employed. This transformation converts categorical variables into one-hot encoded vectors, ensuring that the models can effectively interpret and analyze them. In doing so, rare categories (for example, those occurring Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) fewer than 100 times) are grouped and any unknown categories are treated as infrequent to ensure that even lesser-seen data is accounted for. In one example, hospital service type categories like “cardiology,” “oncology,” and “neurology” are each converted into separate binary columns (one for each service). If a patient is in Cardiology, their entry will have a “1” in the cardiology column and a “0” elsewhere. In another example, means of arrival categories like “ambulance,” “walk-in,” or “transferred” are transformed similarly. To handle rare categories (for example, categories occurring fewer than 100 times), rare categories may be grouped under “other” to avoid sparsity issues in the models. If an unexpected category appears (for example, new means of arrival), the unexpected category may be treated as “other” to prevent the models from breaking due to unknown data. In another example, the level of care such as “ICU,” “IMC,” or “nursery” are also one- hot encoded. Each level of care is assigned its own binary column, enabling the models to identify the intensity of care required. Patients in ICU, for example, will have a “1” in the ICU column and a “0” in others. Grouping rare levels under “other” ensures that less frequent levels do not affect model performance. For ordinal features, the inherent ranking of these categories is preserved by converting them into numeric values based on a predefined order. If the model encounters an unknown category, a default numeric value (for example, -1) is assigned to allow the transformation process to handle unexpected inputs without disrupting the model performance. In one example, if a patient’s mobility level is classified as “fully mobile,” “assisted,” or “bedridden,” numeric values are assigned, such as 2, 1, and 0, respectively. This preserves the ranking while allowing the models to understand the progression of mobility states. If an unknown mobility level is encountered, the unknown mobility level is assigned a default numeric value, such as -1, ensuring that the models can still process the data without disruption. In another example, the AM-PAC (activity measure for post-acute care) G-code metrics are encoded based on functional ability, reflecting the likelihood of discharge disposition. Lower-functioning codes (for example, CN, CM, and CL) are assigned lower numeric values and indicate a higher likelihood of subacute rehab while higher-functioning codes (for example, CJ, CI, and CH) are assigned higher values to suggest that the patient may be ready for discharge Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) home. This numeric scale preserves the ranking, with CN mapped to 0 and CH to 6, to capture the progressive scale of functional ability. Unknown codes are assigned a default value of -1. In another example, the acuity level reflects the urgency of medical attention required, with levels ordered as “less urgent,” “urgent,” “emergent,” and “immediate.” These are assigned numeric values to capture the hierarchy, with 0 for “less urgent,” 1 for “urgent,” 2 for “emergent,” and 3 for “immediate.” This encoding ensures the model accurately interprets increasing acuity. Any unknown acuity level is assigned -1 to maintain data consistency. For textual data, which often include rich but unstructured data like the reason for visits, textual transformation is used. Textual transformation converts the text into a matrix of TF-IDF scores. By lowering the text to lowercase, ignoring common stop words, and focusing on the most important words (for example, the top 20 most important words), the transformation captures the most significant terms that best represent the textual data, enabling the models to process and interpret these insights effectively. In one example, for the feature of the reason for visit, a text field describing the patient’s reason for visiting the hospital (for example, “chest pain” and “shortness of breath”) is transformed into a matrix of TF-IDF scores. By converting the text to lowercase and ignoring common stop words (for example, “the” and “is”), the top most relevant terms are focused on. This allows the models to emphasize the key factors driving the visit, such as “pain” or “breath,” which could be critical for predicting discharge readiness or other outcomes. In another example, text fields of clinical notes are transformed into a matrix of TF-IDF scores, describing a patient's health status, treatment plan, and medical history such as quality improvement measures on deep vein thrombosis (DVT) prophylaxis, urinary catheter existence, ambulation status, and nutrition. In another example, text fields of operative notes that describe a patient’s surgery, such as type of surgery, estimated blood loss, type of anesthesia, and urine output are transformed into a matrix of TF-IDF scores. At sub-act 1106, in one example, a machine-learning algorithm is selected from multiple algorithms of different types. The sub-act 1106 may include sub-acts 1106a and 1106b. In one example, the sub-act 1106a includes training multiple multi-class models to predict discharge disposition using algorithms of different types. At sub-act 1106a, in one example, each multi-class model is trained using different types of algorithms with default parameter settings, including Random Forest, XGBoost, SVM, and Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) Neural Networks. The models may be trained based on the data with features obtained from sub- act 1104. To evaluate the performance of these models, in one example, a 5-fold cross-validation is employed using a dataset where the ground truth of the discharge disposition is known. The dataset is split into five parts, with each model trained on four folds and tested on the remaining fold. This is repeated five times to ensure that each part of the dataset is used as a test set exactly once, providing a robust assessment of model performance and reducing the risk of overfitting to any specific subset of data. At sub-act 1106b, in one example, a comprehensive comparison based on a set of metrics is performed for various machine-learning algorithms of different types to predict the discharge disposition of a patient at the time of the discharge. The multi-class models are evaluated based on key metrics tailored to healthcare analytics, including accuracy, precision, recall, F1-score, and ROC-AUC. Accuracy measures overall prediction correctness. Precision focuses on minimizing false positives by ensuring that patients predicted for a specific disposition category (for example, “Home” or “Skilled Nursing Facility”) truly belong to that category. Recall ensures that the multi-class models capture all patients belonging to each disposition category, minimizing false negatives. F1-score balances precision and recall, crucial for handling class imbalances often encountered in patient discharge disposition prediction. ROC-AUC measures a model’s ability to distinguish between classes. In multi-class settings, ROC-AUC is calculated using the one-vs-rest approach for each class and then averaged. A higher ROC-AUC indicates better model performance in correctly ranking disposition categories and minimizing incorrect classifications. These metrics help ensure that the model is both precise in its predictions (minimizing false positives) and sensitive to capturing all relevant discharge dispositions (minimizing false negatives), which is particularly important in high-stakes healthcare environments. For each metric, two averaging methods are used, macro- and micro-averaging, to provide a comprehensive view of model performance. Macro-averaging calculates each metric for each class independently and then averages these scores equally across all classes. This approach treats each class with equal importance, giving insight into how well the model performs across less frequent disposition categories. Micro-averaging aggregates true positives, false positives, and false negatives across all classes before calculating each metric, emphasizing Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) the performance of the more common classes. Micro-averaging is particularly useful for understanding the model’s effectiveness in capturing the most frequently observed dispositions In one example, XGBoost may be strong in handling complex, multi-class, and imbalanced clinical datasets, and may be robust against overfitting through regularization. Furthermore, XGBoost’s efficiency in processing large, nuanced datasets may allow it to generalize well across diverse patient cases, capturing key patterns across a broad range of discharge dispositions. As a result, XGBoost may be selected at sub-act 1106b as the optimal algorithm for the multi-class model. In other examples, one or more other machine-learning algorithms may be chosen alone or in various combinations at the sub-act 1106b. At sub-act 1108, in one example, the hyperparameters of the selected type of machine- learning algorithm may be optimized by training and periodically updated. The sub-act 1108 may include sub-acts 1108a, 1108b, and 1108c. At the sub-act 1108a, in one example, a Bayesian optimization procedure may be implemented to fine-tune the hyperparameters of the selected multi-class model. This optimization ensures that the model maximizes its predictive performance while minimizing overfitting, allowing it to generalize well to unseen data. This allows further refining of the model’s accuracy to ensure that the model is a reliable tool for predicting the most likely discharge disposition for the patient. In one example, the hyperparameters defined below are optimized to improve the performance of the XGBoost model. Maximum tree depth is the maximum depth of the trees which controls the model complexity. In various examples, maximum tree depth may be set to a range between, for example, 3 and 10. Learning rate determines the step size during model training, sampled from a logarithmic scale between a range of values (for example, 0.001 and 0.3) to allow for both small and large step sizes. Minimum child weight specifies the minimum sum of instance weights required for a child node to split, helping control overfitting. In at least one example, minimum child weight may be set within a range of between 1 and 6. Gamma defines the minimum loss reduction required for partitioning a leaf node and controls regularization. In at least one example, the gamma value may be sampled between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.05). Subsample ratio represents the fraction of training samples used for building each tree, uniformly sampled between a range of values (for example, a range of 0.5 and 1) with a specified step size Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) (for example, a step size of 0.05). Column sample by tree specifies the fraction of features to be randomly sampled for each tree, sampled uniformly between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.1). Maximum delta step is particularly beneficial for handling imbalanced classes in a multi-class setup. Setting a limit on the maximum step size that each leaf node’s weight can take helps stabilize the model’s updates, preventing excessive shifts that could favor the majority class. Maximum delta step may be defined using a quantized uniform distribution to explore integer values between 0 and 10. In one example, given the unbalanced nature of the dataset, the evaluation metric for fine- tuning the hyperparameters is selected as the AUC-PR, which is more suitable for handling imbalanced classes. The goal of the sub-act 1108a is to identify the optimal hyperparameter set λ∗that maximizes the AUC-PR score, expressed as an objective function ^^λ^. Let ^^^^represent the AUC-PR score of the XGBoost model with hyperparameters ^. The optimization problem is defined as: λ∗ = arg m^∈a^x ^ ^λ^,where ^ represents the hyperparameters to be optimized (for example, learning rate, maximum depth, and regularization terms), and Λ is the space of possible hyperparameters. For surrogate model fitting, a TPE is used as the surrogate model to approximate the objective function ^^^^. TPE models the likelihood of good and bad hyperparameter configurations based on previous observations. Let ^^^^be the likelihood of high-performing hyperparameters (those improving AUC-PR) and ^^^^be the likelihood of low-performing hyperparameters (those reducing AUC-PR). These distributions are updated based on observed evaluations, and the surrogate model is used to predict the performance of new hyperparameter configurations. In various examples, the surrogate model is iteratively refined as more real-time data is collected. For acquisition maximization, an acquisition function is used to guide the selection of the next hyperparameters for evaluation. This function maximizes the expected improvement by selecting configurations that optimize the ratio Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) λ^ = arg m^∈a^x ^^^^^^^^. This ratio directs the optimization process, balancing exploration (trying hyperparameters where the model is uncertain) and exploitation (choosing hyperparameters that are likely to perform well based on the surrogate model). For example, the Bayesian optimization procedures start at step one of initialization, in which a few initial random hyperparameter configurations are evaluated to gather baseline data. These configurations are chosen randomly within the specified hyperparameter space Λ and provide the initial observations necessary to build a surrogate model. At step two of surrogate model fitting, the surrogate model is fitted based on the observed data, constructing the ^^^^ and ^^^^ distributions. The surrogate model serves as a probabilistic estimator that guides the search for optimal hyperparameters, predicting how different configurations will perform without needing to evaluate each one directly. At step three of acquisition maximization, the next hyperparameter configuration is selected by maximizing the acquisition function, which balances exploration (testing hyperparameters where uncertainty is high) and exploitation (testing configurations likely to yield high performance based on the surrogate model). This ensures that the search efficiently converges towards optimal hyperparameters, even in complex search spaces. At step four of evaluation, for each selected hyperparameter configuration, the model is fitted using XGBoost with a maximum number of rounds per trial (for example, 500 boosting rounds per trial). Additionally, if there is no improvement in model performance after a certain number of boosting rounds (for example, 100 boosting rounds), early stopping may be triggered to prevent further unnecessary iterations. Performance may be evaluated using the AUC-PR score, which is particularly relevant for an imbalanced healthcare dataset, focusing on precision and recall. At step five of iteration, the optimization continues by repeating steps two to four. In one example, the total number of trials may be limited to a maximum number (for example, 50) to ensure that the search process remains efficient without overfitting the hyperparameter space. If, within these trials, the model reaches a plateau where further boosting rounds yield no significant improvement in AUC-PR scores, the optimization may be stopped and the hyperparameter fine-tuning is completed. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) At the sub-act 1108b, in one example, it is determined whether new real-time data of a first type are available for updating the dataset for training. For example, the new data of the first type may include relevant information such as whether certain care units become opened or closed which will affect the workflow through the hospital, or whether a new initiative is introduced at the hospital that affects the workflow of the nurses or doctors and changes where and when data are documented. In some examples, the sub-act 1108b may be configured to be performed periodically, for example, daily, weekly, monthly, or quarterly, to search for new data of the first type. If new data are available (“YES”), the process 1100 proceeds to the sub-act 1108c to extract, process, and insert the new first-type data to update the dataset. After the dataset is updated, the process 1100 returns to the sub-act 1108a to retrain the final model with the updated dataset. If no new first-type data are available (“NO”) at the sub-act 1108b, the process 1100 proceeds to a sub-act 1110. At the sub-act 1110, in one example, the process 1100 proceeds based on whether the predicted disposition may be characterized as a sensitive scenario. If it is a sensitive scenario (“YES”), such as in cases where predicted dispositions are sensitive to mortality (for example, predictions relating to death), the process 1100 proceeds to the sub-act 1112 to post-process the discharge disposition prediction. In various examples, sub-act 1110 may include determining whether the predicted disposition is on a list of pre-defined sensitive dispositions. At sub-act 1112, in one example, the sensitive predictions are converted to “to be determined” to allow healthcare providers to reassess critical cases without relying solely on the model’s output. This safeguard ensures that sensitive cases receive the necessary caution and attention. The sub-act 1112 may include sub-acts 1112a and 1112b. At sub-act 1112a, in one example, if case managers or healthcare staff document discharge-related dispositions in the EMR system, these human-entered inputs automatically overwrite the model’s predictions. This priority on case managers’ inputs helps avoid miscommunications by ensuring the final output aligns with real-time human judgment. The sub-act 1112a may include detecting and integrating these human-entered data points to seamlessly override the model’s output as needed. At sub-act 1112b, in one example, the post-processing of the prediction results may be adaptable to accommodate additional rules for specific scenarios or guidelines, such as flagged cases for extended observation or special discharge handling based on institutional requirements. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) This customizable approach enhances the relevance of the model’s predictions by enabling adjustments and modifications aligned with unique healthcare policies or patient needs. After overrides or adjustments are completed at the sub-act 1112, the process 1100 proceeds to the sub-act 1114 to execute the optimized multi-class model and output prediction results of discharge disposition for the patient. Also, at the sub-act 1110, if the predicted disposition is not a sensitive scenario (“NO”), the process 1100 proceeds directly to the sub-act 1114 to execute the optimized multi-class model to output prediction results of discharge disposition for the patient. While the creation of the discharge disposition model may include only static historical data, the final prediction may change over time (sometimes quickly) as new EMR data of a second type becomes available. For example, the new second-type data may include new information associated with the patient or the care unit where the patient is currently bedded. The discharge disposition prediction may be produced and sent to the EMR in as timely a fashion as possible, which requires near-real-time data acquisition. Industry-standard mechanisms, such as HL7 and FHIR, are the primary near-real-time acquisition methods. Several other data acquisition methods are also used, such as data analytics reporting tools, API web services, and KB_SQL queries. This allows an automatic near-real-time two-way data pipeline. After the sub-act 1114, in one example, the process 1100 proceeds through the sub-act 318 depending on whether new real-time data of a second type becomes available for updating the model hyperparameters. In practice, for example, each prediction may be updated in the EMR system display every few minutes (for example, every 8 to 12 minutes), depending on the availability of new data, to reduce the amount of variability in the displayed score over time and enhance the usability of the predictions for clinical users. If there is new second-type data available from, for example, a near-real-time data pipeline via HL7, FHIR, or other means, the sub-act 318 is executed to extract, process, and insert the new data to update the training dataset. If new second-type data are available, the sub-act 318 is performed to extract, process, and insert the new data to update the input dataset. Then the process 1100 returns to the sub-act 1114 to re- execute the final model. If no new second-type data are available at sub-act 318, the process 1100 stays at the sub-act 318 to keep searching for new second-type data. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In other examples, the sub-act 1108c and the sub-act 318 may search for new data of the same type to be updated but may be performed at different periodicities. For example, the sub- act 318 may be performed more frequently than the sub-act 1108c. The machine-learning process 1100 for executing the act 126 to predict the patient’s discharge disposition may be performed via the user interface 204. The user interface 204 may display a GUI associated with the act 126. FIG.11 illustrates a GUI 1200 for predicting discharge dispositions of patients in a hospital according to an example. A first column 1202 displays the predicted discharge disposition results for patients currently in the hospital in a transparent and straightforward manner to assist in the decision-making of where the patients may be discharged at their respective discharge times. A second column 1204 displays the unit and bed numbers of the patients to identify those patients. For example, the patient in bed 534-B of unit 5W should be discharged home but the patient in bed 3-1 of unit 2C should be discharged to an SNF. Referring to FIG.1, in various examples, after the discharge disposition of a patient is predicted at the act 128, the process 100 proceeds to act 130 to predict the patient’s risk of readmission after the patient is discharged from the hospital for a certain period. In other examples, the act 130 may be executed shortly after the patient’s arrival at the hospital at the act 102 and continues throughout the patient’s inpatient stay and up until after the patient’s discharge at act 132 for a certain period. Sometimes, a patient may need to be readmitted to the hospital after departure or discharge. A readmission occurs when a patient is admitted, discharged, and then subsequently readmitted. The terms “admitted,” “discharged,” and “readmitted” are specific to inpatients, although they are frequently misused even by healthcare professionals. Certain types of readmissions are planned. For example, some orthopedic surgeries require a follow-up inpatient encounter to remove temporarily implanted hardware. Some readmissions are either unrelated to or undertaken long after the initial admission. In healthcare, unplanned readmissions that occur within a relatively short amount of time, that is, excluding special cases like those described above, are widely viewed as undesirable. It may be a sign of previous inadequate or incomplete care. There are relevant state and federal metrics based on readmission rates that are used to rank hospitals. Sometimes these metrics are used to impose monetary incentives / disincentives. In Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) addition, insurance companies will often not pay claims for unplanned readmissions under certain circumstances. An example type of readmission is an unplanned 30-day readmission, the likelihood of which needs to be predicted before patient discharge. A 30-day readmission refers to a readmission that occurs within 30 days after the discharge date. Traditional readmission risk scores are calculated at discharge time, which allows no opportunity to plan for preventive measures prior to discharge. By assessing a patient’s readmission risk throughout their hospital stay, transitional nurse navigators can identify high-risk patients several days before discharge to allow for patient education efforts and other medical or supportive interventions before discharge to prevent readmission. Also, transitional nurse navigators will no longer need to sift through all bedded inpatients to determine which ones have high-risk conditions, have currently been readmitted, and might be amenable to interventions to reduce readmission risk. FIG.12 illustrates a machine-learning process 1300 to execute the act 130 to predict the readmission risk of a patient if the patient is discharged from the hospital according to an example. At sub-act 1302, in one example, the process 1300 starts by extracting and compiling various types of data. In various examples, the sub-act 1302 may include sub-acts 1302a, 1302b, and 1302c to extract several years of clinical, operational, and financial data, primarily focusing on patients and patient encounters, from a hospital’s or hospital system’s EMR and / or other sources, including cross-organization data repositories such as a statewide health information exchange (HIE). For example, EMR and HIE data may be extracted at sub-act 1302a and 1302b, respectively, using a variety of standard extract-transform-load (ETL) techniques and data acquisition methods, including SQL queries, API / web service calls, and event-driven real-time interfaces. API calls and real-time interfaces may adhere to well-known international standards such as HL7, DICOM, and FHIR. An EMR is an application and database that acquires and stores clinical, operational, and financial data related to healthcare and health system operations. In one example, most data extracted at the sub-act 1302 is extracted from the EMR at the sub-act 1302a. Categories of data acquired from the EMR include patient demographics, patient history, encounter details, medications, lab tests, vital signs, radiology results, nursing documentation, SDOH, and financial details. Act the sub-act 1302a, data are extracted using the inpatient (or expected to be inpatient) encounter en, where n ∈ {1,…,N} as the cornerstone data point such that all other data are related Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) to that specific inpatient encounter. While the focus on the predicted risk score is inpatients (hospitalized patients), the readmission risk score is also calculated for currently in-house non- inpatients (in the ED and / or observation unit) who might become inpatients, and also previous inpatients within 30 days of discharge. HIE is a cross-organization data repository offering data that may not be generally available to a single healthcare organization because healthcare organizations often do not share data directly with each other. For readmissions, a typical healthcare organization only has access to readmission data for patients who are both admitted and subsequently readmitted to one of that organization’s facilities. In one example, cross-organization data repositories (for example, HIE) extracted at the sub-act 1302b fills the gap, providing admission and readmission data for patients whose index admission or subsequent readmission occurred outside the boundaries of the healthcare organization. At sub-act 1302c, in one example, publicly available data may be extracted from the U.S. Census Bureau (for example, the decennial census supplemented by ACS), CDC (social vulnerability index), and Neighborhood Atlas (social vulnerability index). Publicly available data are extracted in bulk via file transfer and then loaded into a relational database management system (RDBMS) with geographic information system (GIS) extensions. At sub-act 1304, in one example, the extracted and compiled data are preprocessed. In various examples, the sub-act 1304 may include sub-acts 1304a and 1304b. At sub-act 1304a, in one example, the response variables for the ground truth of a 30-day (unplanned) readmission risk model are defined based on data extracted from the HIE, along with readmission-specific diagnosis codes and hospital admission or readmission facilities. In other examples, readmission risk models for unplanned readmission after a different period (for example, 60 days or 90 days) from the discharge date may be employed. At sub-act 1304b, in one example, the extracted and compiled data are feature-encoded and feature-engineered. The goal of both feature-encoding and feature-engineering is to maximize the predictive power of “raw” data. Many techniques for both encoding and engineering may be used, so it may be advantageous to gauge the efficacy of each and retain only the best performing techniques for the model type and metric(s) chosen. This is done iteratively along with model and feature selection (as described in more detail below). Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) In one example, for constructing a 30-day readmission model, the following variables are encoded from the data features and evaluated based on performance. Single variables include numeric, boolean, ordinal, and categorical data features. Numerical data features include extracted data such as height, weight, and BMI. Boolean data features may be encoded by uniformly converting extracted data to 1 (yes) and 0 (no) for information of, for example, whether a patient is on IV therapy, in the ICU, or has previous encounters with a hospital or hospital system. Ordinal data features may be converted from the extracted data into a series of sequential integers while preserving their original rankings (for example, pain score and admission level of care). For categorical data features, when the number of categories is reasonable, the data features may be encoded by either one-hot encoding (dummy encoding) or frequency encoding. For example, data features relating to admission source, mode of arrival, and primary insurance type may use one-hot encoding, and data relating to ZIP code, financial class, and type of breathing assistance may use frequency encoding. When the number of categories is large enough to cause dimensionality problems, the data features may be encoded by either hash encoding or grouping (especially when an appropriate industry standard “grouper” is available). For example, an EMR may define tens of thousands of order codes, some with industry-standard coding, and some without. Because not all of them can be grouped in useful or meaningful ways, hash encoding is used to reduce the dimensionality while attempting to preserve enough detail to facilitate predictive modeling. On the other hand, medication data is generally stored as NDC codes, of which there are tens of thousands. To group these into manageable categories, ATC pharmacological and therapeutic groupings are used, as provided by the WHO. Diagnoses are generally represented as ICD codes. Again, there are tens of thousands of ICD codes. To group these into manageable categories, CCSR body systems and clinical categories are used. In one example, for constructing the 30-day readmission model, variables that change over time are also encoded from the data features and evaluated based on performance. Although many healthcare data variables change over time, vital signs, for example, the resulting chronological vectors, are often irregular and / or sparse. Nevertheless, these types of data are still treated as time series variables. For each time series variable regardless of the type, the features created (after encoding the extracted data appropriately) include first value, most recent value, Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) time since the most recent value is recorded, total number of values recorded, and average number of values recorded per day. Additional features are created for each numeric time series variable, which include median value, minimum value, maximum value, variance, difference between the median value and the most recent value, difference between the median value and the fist value, difference between the first value and the most recent value, first quartile boundary, third quartile boundary, time spent in each quartile (in minutes), time spent in each quartile as a percentage of total encounter time, current quartile, and the slope of a regression model fit to the values (for example, heart rate, pain score, and white blood count). Additional features are created for each boolean time series variable, including time spent in positive and negative states (in minutes) and time spent in positive and negative states as a percentage of total encounter time (for example, time on a ventilator, in ICU, and for receiving antibiotic). Additional features are created for each ordinal variable (after being transformed or encoded), including time spent in each ordinal level (in minutes) and time spent in each ordinal level as a percentage of total encounter time (for example, pain score, Richmond agitation-sedation scale (RASS) level, and patient mobility). Additional features are created for each categorical variable, including time spent in each category (in minutes) and time spent in each category as a percentage of total encounter time (for example, affect and behavior, respiratory WDL, and central line status). At sub-act 1306, in one example, the type of machine-learning algorithm for the 30-day readmission model is selected from various types of algorithms. In various examples, the sub-act 1306 includes sub-acts 1306a and 1306b. At the sub-act 1306a, in one example, various binary models are trained, each using a different type of algorithm. For the training, folds and splits are constructed for an augmented version of k-fold cross-validation. The data set resulting from feature encoding and engineering is first split into two sets, one containing the oldest set of encounters (train-0) (for example, the oldest 85% of encounters), and the other containing the most recent set of encounters (test-0) (for example, the most recent 15% of encounters). Train-0 is further split into five “folds” of relatively equal size. Two constraints are imposed on the train- 0 splitting process: to avoid cross-encounter data leakage, each fold is limited to a unique set of patients, including all encounters for those patients; each sub-set contains at least one sample of each category for all categorical variables. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) Hyperparameters for each model are chosen based on a coarse-grained grid search. Features are culled separately for each model using algorithm-specific methods, requirements, and constraints. In some examples, further transformation and / or augmentation of the data may be required. For example, some algorithms cannot handle missing values so various imputation methods are used to fill the gaps. Some algorithms perform best when numeric data have been normalized so appropriate normalization techniques are applied to those features. Some algorithms perform poorly if highly correlated features are used so a cross-correlation matrix is generated, and over-correlated features are dropped. Some algorithms perform better when continuous numeric features are split into binary “buckets.” Some algorithms may not be equipped to handle the number of features in the training data so feature culling techniques (for example, FTRL) may be applied. In one example, at the sub-act 1306b, the evaluated types of algorithms include Simple Regression (Ridge and Lasso), Gradient Boosted Trees (normal via CatBoost and “extreme” via XGBoost), Support Vector Machines (for example, linear only without “kernel trick” variations), Random Forest (classical and “extra trees” variant), and Neural Networks (for example, long short-term memory [LSTM] and recurrent neural network [RNN]). At the sub-act 1306b, in one example, the performance of each tuned model is evaluated using a set of metrics. Although the target variable is binary, the desired model output is a probability expressed as a number between 0.0 (risk is 0%) and 1.0 (risk is 100%). In addition, the data may be unbalanced, with the prevalence of 30-day unplanned readmission generally ranging between 5% and 20%. AUC-ROC may be chosen as the primary measure of quality partly because of its resistance to unbalanced data and because AUC-ROC is the metric widely accepted in assessing readmission risk. AUC-PR may be added as a secondary metric to provide a sanity check. In addition, error distributions are analyzed to understand the conditions under which each model performs best and worst. In one example, at the sub-act 1306b, the gradient-boosted-tree models turn out to be less brittle, require significantly fewer resources to train and maintain, and have less positive-case error. Therefore, gradient boosted trees (XGBoost variant) are chosen as the final algorithm type for constructing the 30-day readmission risk binary model. In other examples, one or more other machine-learning algorithms may be chosen alone or in various combinations at the sub-act 1306b. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) At sub-act 1308, in one example, the hyperparameters of the selected type of algorithm are optimized and updated, and feature culling is performed, both by training, for a final 30-day readmission model. In various examples, the sub-act 1308 may include sub-acts 1308a, 1308b, 1308c, 1308d, and 1308e. At the sub-act 1308a, in one example, the final model is constructed. While a single 80 / 20 split may be used to evaluate modeling algorithms at the sub-act 1306, five separate models using different 4+1 combinations are first constructed for the hyperparameter optimization of the final model at the sub-act 1308a. In one example, the hyperparameters defined below are optimized to improve the performance of the XGBoost model. Maximum tree depth is the maximum depth of the trees which controls the model complexity. In various examples, maximum tree depth may be set to a range between, for example, 3 and 8. Learning rate determines the step size during model training, sampled from a logarithmic scale between a range of values (for example, 0.001 and 0.3) to allow for both small and large step sizes. Minimum child weight specifies the minimum sum of instance weights required for a child node to split, helping control overfitting. In at least one example, minimum child weight may be set within a range of between 1 and 25 with a step size of 5. Gamma defines the minimum loss reduction required for partitioning a leaf node and controls regularization. In at least one example, the gamma value may be sampled between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.05). Subsample ratio represents the fraction of training samples used for building each tree, uniformly sampled between a range of values (for example, a range of 0.5 and 1) with a specified step size (for example, a step size of 0.1). Column sample by tree specifies the fraction of features to be randomly sampled for each tree, sampled uniformly between a range of values (for example, 0.5 and 1) with a specified step size (for example, a step size of 0.1). Scale positive class weight is a parameter particularly beneficial for handling imbalanced classes in a binary setup. Scale positive class weight adjusts the balance of positive and negative weights to handle imbalanced data, sampled uniformly between a range of values (for example, 1 and 5) to give more weight to the positive class. In one example, at the sub-act 1308b, the hyperparameters for each of the five models are fine-tuned using a Bayesian optimization procedure. The goal of the optimization is to identify Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) the optimal hyperparameter set λ∗that maximizes the AUC-ROC score, expressed as an objective function ^^λ^. Let ^^^^represent the AUC-ROC score of the XGBoost model with hyperparameters ^. The optimization problem is defined as: λ∗ = arg m^∈a^x ^ ^λ^,where ^ represents the hyperparameters to be optimized (for example, learning rate, maximum depth, and regularization terms), and Λ is the space of possible hyperparameters. For surrogate model fitting, a TPE is used as the surrogate model to approximate the objective function ^^^^. TPE models the likelihood of good and bad hyperparameter configurations based on previous observations. Let ^^^^be the likelihood of high-performing hyperparameters (those improving AUC-ROC) and ^^^^be the likelihood of low-performing hyperparameters (those reducing AUC-ROC). These distributions are updated based on observed evaluations, and the surrogate model is used to predict the performance of new hyperparameter configurations. In various examples, the surrogate model is iteratively refined as more real-time data is collected. For acquisition maximization, an acquisition function is used to guide the selection of the next hyperparameters for evaluation. This function maximizes the expected improvement by selecting configurations that optimize the ratio λ^ = arg m ^^^^^∈a^x ^^^^. This ratio may direct the optimization process, balancing exploration (trying hyperparameters where the model is uncertain) and exploitation (choosing hyperparameters that are likely to perform well based on the surrogate model). For example, the Bayesian optimization procedures start at step one of initialization, in which a few initial random hyperparameter configurations are evaluated to gather baseline data. These configurations are chosen randomly within the specified hyperparameter space Λ and provide the initial observations necessary to build a surrogate model. At step two of surrogate Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) model fitting, the surrogate model is fitted based on the observed data, constructing the ^^^^ and ^^^^distributions. The surrogate model serves as a probabilistic estimator that guides the search for optimal hyperparameters, predicting how different configurations will perform without needing to evaluate each one directly. At step three of acquisition maximization, the next hyperparameter configuration is selected by maximizing the acquisition function, which balances exploration (testing hyperparameters where uncertainty is high) and exploitation (testing configurations likely to yield high performance based on the surrogate model). This ensures that the search efficiently converges towards optimal hyperparameters, even in complex search spaces. At step four of evaluation, for each selected hyperparameter configuration, the model is fit using XGBoost with a maximum number of boosting rounds per trial (for example, 2500 boosting rounds per trial). Additionally, if there is no improvement in model performance after a certain number of boosting rounds (for example, 100 boosting rounds), early stopping is triggered to prevent further unnecessary iterations. Performance is evaluated using the AUC- ROC score, which is particularly relevant for our imbalanced healthcare dataset, focusing on precision and recall. At step five of iteration, the optimization continues by repeating steps two to four. In one example, the total number of trials may be limited to a maximum number (for example, 50) to ensure that the search process remains efficient without overfitting the hyperparameter space. If, within these trials, the model reaches a plateau where further boosting rounds yield no significant improvement in AUC-ROC scores, the optimization is stopped and the hyperparameter fine-tuning is completed. In certain examples, feature culling may also be performed at the sub-act 1308b. The importance of each feature for each model is determined using SHAP analysis. SHAP is a model-agnostic approach that uses coalitional game theory to evaluate each model feature representing how much that feature contributes to the model’s output. Features with zero contribution, based on the SHAP analysis, are dropped, and models are retrained without them. Moreover, in various examples, the sub-act 1308a may include investigating and, when necessary, mitigating biases of various types. Subsets of results from all fine-tuned models are used to check for biases by comparing them against the performance of the overall model. For example, the performance on a subset of results including only female patients may be compared to the performance of the entire model. For example, a bias check may be performed for the Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) various categories including race, ethnicity, sex, language, religion, and census tract. If an unacceptable level of bias is discovered, attempts to mitigate that bias may be made. Mitigation may be done by over-sampling the biased population or re-weighting training samples to put more emphasis on the biased population. At the sub-act 1308a, in one example, the final model is built using train-0 (a combination of all folds) and subsequently tested against test-0, a chronologically “most recent encounters” hold-out set at the sub-act 1308b. At the sub-act 1308a, hyperparameters for this final model are derived by averaging hyperparameters across all five split-based models. The feature set for the final model is a union of feature sets from all split-based models. The final model is built using the complete data set. Hyperparameters and the feature set are the same as for the train-0 model. Isotonic regression coefficients are calculated specifically for the final model. At the sub-act 1308c, the final model is validated. If the performance for the final model, including levels of bias, is consistent with the split-based models obtained at the sub-act 1308a (“YES”), the process 1300 proceeds to a sub-act 1308d. Otherwise (“NO”), the process 1300 returns to the sub-act 1308a to find and fix the causes. At the sub-act 1308d, in one example, it is determined whether new real-time data of a first type are available for updating the dataset for training. For example, the new data of the first type may include relevant information such as whether certain care units become opened or closed which will affect the workflow through the hospital, or whether a new initiative is introduced at the hospital that affects the workflow of the nurses or doctors and changes where and when data are documented. In some examples, the sub-act 1308d may be configured to be performed periodically, for example, daily, weekly, monthly, or quarterly, to search for new data of the first type. If new data are available (“YES”), the process 1300 proceeds to the sub-act 1308e to extract, process, and insert the new first-type data to update the dataset. After the dataset is updated, the process 1300 returns to the sub-act 1308b to retrain the final model with the updated dataset. If no new first-type data are available (“NO”) at the sub-act 1308d, the process 1300 proceeds to a sub-act 1310 to execute the final model to output the readmission risk prediction. Discretization of the output prediction from the sub-act 1314 may still be needed because machine-learning models, even those that produce continuous results in the range of 0 to 1, do Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) not generally produce outputs that resemble probabilities. Probabilistic alignment is desirable for two reasons. First, non-probabilistic results can cause end-user cognitive dissonance. People not trained in machine learning, statistics, or similar disciplines may not be familiar with numbers that have no inherent meaning beyond rank. Second, model retraining may be done regularly (for example, quarterly) to incorporate new data and discover new patterns. Retrained models are likely to produce outputs with different characteristics (ranges, distributions, and so forth) than their predecessors. In one example, to alleviate these problems, at sub-act 1316, the model outputs are transformed to more closely match probabilities while preserving overall rank. If the error distribution of the final model exhibits sigmoidal characteristics, isotonic regression may be chosen as the transformation technique. Other transformation techniques such as Platt scaling may also be considered. In one example, the pseudo-probabilities are discretized pyramidally into 5 categories, where category 5 (highest risk) contains the smallest number of patients, and category 1 (lowest risk) contains the largest number of patients. This facilitates color coding and at-a-glance interpretation for end-users. In other examples, other numbers of discrete categories may be used for the pseudo-probabilities of the final model. While the creation of the predictive model may include only static historical data, per- patient deterioration risk scores may change over time (sometimes quickly) as new EMR data of a second type becomes available. For example, the new second-type data may include new information associated with the patient or the care unit where the patient is currently bedded. The readmission risk scores may be calculated and sent to the EMR in as timely a fashion as possible, which requires near-real-time data acquisition. Industry-standard mechanisms, such as HL7 and FHIR, are the primary near-real-time acquisition methods. Several other data acquisition methods are also used, such as data analytics reporting tools, web services, and KB_SQL queries. This allows an automatic near-real-time two-way data pipeline. At the sub-act 1310, in one example, the process 1300 proceeds through sub-act 318 depending on whether new second-type data becomes available. In practice, for example, each readmission risk score may be updated in the EMR system display every few minutes (for example, every 8 to 12 minutes), depending on the availability of new data, to reduce the amount of variability in the displayed score over time and enhance the usability of the deterioration risk scores for clinical users. If there is new second-type data available from, for example, a near- Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) real-time data pipeline via HL7, FHIR, or other means, the sub-act 318 is executed to extract, process, and insert the new data to update the training dataset. The process 1300 then returns to the sub-act 1310 to re-execute the final model. If there is no new second-type data available at the sub-act 318, the process 1300 stays at the sub-act 318 to keep searching for new second-type data. In other examples, the sub-act 1308d and the sub-act 318 may search for new data of the same type to be updated but may be performed at different periodicities. For example, the sub- act 318 may be performed more frequently than the sub-act 1308d. The machine-learning process 1300 for executing the act 130 to predict the patient’s readmission risk may be performed via the user interface 204. The user interface 204 may display a GUI associated with the act 130. FIG.13 illustrates a GUI 1400 associated with predicting 30-day readmission risks of patients at a hospital system level according to an example. A first column 1402 displays the predicted readmission results in descending order (from top to bottom) for patients to assist in the decision-making of which patients may have a high risk for readmission to the hospital. A second column 1404 displays the discretized readmission risk scores of the patients in a transparent and straightforward manner. In this example, because all the patients have a relatively high readmission score (for example, a readmission score of 4 or 5), all the readmission risk scores may be highlighted by a background in red or of a first texture. Although not shown, lower levels of readmission scores may be displayed in backgrounds of other colors or textures, such as yellow or a second texture (for a score of, for example, 2 or 3) and green or a third texture (for a score of, for example, 1). A third column 1406 displays the current location information for each patient. For example, if the patient is still in the hospital (that is, the process 1300 is performed before the patient’s discharge), the background of the patient’s location information is highlighted in yellow. Otherwise, if the patient is located outside the hospital such as at home possibly against medical advice (that is, the process 1300 is performed after the patient’s discharge), the background of the patient’s location information is not highlighted. The fourth column 1408 and the fifth column 1410 may display the patient's last clinical service and the associated admission complaint, respectively, to provide context to the readmission risk prediction. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) As noted above, the anticipatory system 201 includes a controller 202, a user interface 204, memory 206, and a network interface 208, which may be coupled to the external devices 210. The controller 202 may execute various operations discussed above. The controller 202 may also execute one or more instructions stored on one or more non-transitory computer- readable media. For example, the memory 206 and / or the external devices 210 may include or be coupled to the non-transitory computer-readable media which store instructions 214. The controller 202 may execute the instructions 214 to execute various operations discussed above, including the processes 100, 400, 500, 700, 800, 1000, 1100, and 1300. In some examples, the controller 202 may include one or more processors or other types of controllers. In one example, the controller 202 is or includes at least one processor. In another example, the controller 202 performs at least a portion of the operations discussed above using an application-specific integrated circuit tailored to perform particular operations in addition to, or in lieu of, a processor. As illustrated by these examples, examples in accordance with the present disclosure may perform the operations described herein using many specific combinations of hardware and software and the disclosure is not limited to any particular combination of hardware and software components. Examples of the disclosure may include a computer-program product configured to execute methods, processes, and / or operations discussed above. The computer-program product may be, or include, one or more controllers and / or processors configured to execute instructions to perform methods, processes, and / or operations discussed above. The user interface 204 may include one or more user inputs, one or more user outputs, or a combination thereof. The user interface 204 may include user-input devices such as a keyboard, a mouse, a touchscreen, and so forth. Users, such as medical personnel, may use the user inputs to input information indicative of a patient’s current status in the hospital and / or a current status of various units in the hospital. The user interface 204 may also include user- output devices such as a computer monitor, sound-emitting devices such as speakers or buzzers, light-emitting devices such as light-emitting diodes, and so forth. The user interface 204 may include one or more GUIs. Users, such as medical personnel, may use the user outputs to receive various information related to clinical decision-making on changing patients’ care settings. Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) The memory 206 may include non-transitory computer-readable media, such as memory devices (for example, read-only memory, random-access memory, and so forth) and / or storage devices (for example, hard drives, optical disks, and so forth). The network interface 208 may include one or more devices or components to interface with external devices, such as the external devices 210. For example, the network interface 208 may include wired-communication components that enable wired communication (for example, wired-communication ports to receive a communication wire), wireless-communication components that enable wireless communication (for example, antennas), a combination thereof, and so forth. The external devices 210 may include any devices or components which are physically external to the anticipatory system 201, such as external computing devices (for example, other computing devices within a hospital), cloud computers, servers, external data storage, and so forth. In some examples, the external devices 210 may include devices substantially similar to the anticipatory system 201. For example, a hospital may include several computing devices implemented as or including the anticipatory system 201, each of which may be networked together. In one example, each hospital unit may include a dedicated team of discharge professionals who manage patient discharges, and each of these teams (or even each member of each team) may have one or more computing devices substantially similar to the anticipatory system 201. Having thus described several aspects of at least one embodiment, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be part of, and within the spirit and scope of, this disclosure. Accordingly, the foregoing description and drawings are by way of example only. What is claimed is:

Claims

Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) CLAIMS 1. At least one non-transitory computer-readable medium storing thereon sequences of computer-executable instructions for quantizing a likelihood of discharging a patient from a hospital, the sequences of computer-executable instructions including instructions that instruct at least one processor to: receive patient information about the patient, the patient information including information about a current hospitalization of the patient; receive hospital-unit-volume information corresponding to a rolling window of time, the hospital-unit-volume information indicating a number of patients admitted to, transferred into, or discharged from a hospital unit in which the patient currently resides; convert the patient information and the hospital-unit-volume information into a machine- interpretable format tailored to at least one binary output machine learning algorithm; execute the binary output machine learning algorithm to generate a plurality of binary models that predict the likelihood of discharging the patient within each timeframe of a plurality of timeframes; combine the plurality of binary models into a single combined discharge model, wherein combining the plurality of binary models includes optimizing weightings of discharge predictions for each binary model of the plurality of binary models; determine, using the single combined discharge model, at least one weighted discharge readiness quantization for the patient; transform the at least one weighted discharge readiness quantization into at least one discharge prediction for the patient; and control a user interface to provide the at least one discharge prediction to a user.

2. The at least one non-transitory computer-readable medium of claim 1, wherein receiving the patient information includes accessing an electronic medical record (EMR) of the patient in real-time.

3. The at least one non-transitory computer-readable medium of claim 1, wherein the rolling window of time corresponds to a most recent 12-hour span of time.Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) 4. The at least one non-transitory computer-readable medium of claim 1, wherein the plurality of binary models predict the likelihood of discharging the patient within one or more of a 12-hour timeframe, a 24-hour timeframe, a 36-hour timeframe, a 48-hour timeframe, a 60-hour timeframe, and a 72-hour timeframe.

5. The at least one non-transitory computer-readable medium of claim 1, wherein the instructions further instruct the at least one processor to optimize the plurality of binary models for each timeframe according to one or more optimization metrics.

6. The at least one non-transitory computer-readable medium of claim 5, wherein the optimization metrics include accuracy, precision, recall, and F1-score.

7. The at least one non-transitory computer-readable medium of claim 6, wherein the instructions further instruct the at least one processor to execute a Bayesian optimization algorithm to fine-tune one or more hyperparameters of the at least one binary output machine learning algorithm.

8. The at least one non-transitory computer-readable medium of claim 7, wherein fine- tuning the one or more hyperparameters of the at least one binary output machine learning algorithm includes selecting values for the one or more hyperparameters that maximize an area- under-the-precision-recall curve (AUC-PR) for imbalanced datasets.

9. The at least one non-transitory computer-readable medium of claim 1, wherein optimizing the weightings of discharge predictions for each binary model of the plurality of binary models includes: assigning a weight to a discharge prediction of each timeframe of the plurality of timeframes to produce a plurality of weighted discharge predictions; and identifying an optimal value of each weight.Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) 10. The at least one non-transitory computer-readable medium of claim 9, wherein identifying the optimal value of each weight includes determining a value of each weight that maximizes a median of a sum of the plurality of weighted discharge predictions.

11. The at least one non-transitory computer-readable medium of claim 10, wherein identifying the optimal value of each weight includes imposing: a first restriction on the sum of the plurality of weighted discharge predictions to maximize a distribution of discharge predictions for patients likely to be discharged; and a second restriction on the sum of the plurality of weighted discharge predictions to minimize a distribution of discharge predictions for patients not likely to be discharged.

12. The at least one non-transitory computer-readable medium of claim 11, wherein the first restriction includes imposing a minimum-value threshold on a first quartile of the sum of the plurality of weighted discharge predictions.

13. The at least one non-transitory computer-readable medium of claim 11, wherein the second restriction includes imposing a maximum-value threshold on a third quartile of the sum of the plurality of weighted discharge predictions.

14. The at least one non-transitory computer-readable medium of claim 10, wherein the sum of the plurality of weighted discharge predictions is the at least one weighted discharge readiness quantization.

15. The at least one non-transitory computer-readable medium of claim 14, wherein transforming the at least one weighted discharge readiness quantization into the at least one discharge prediction for the patient includes converting a likelihood of patient discharge into a value on a standardized scale of a plurality of standardized values.

16. The at least one non-transitory computer-readable medium of claim 15, wherein the at least one discharge prediction is the value on the standardized scale of the plurality of standardized values.Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) 17. The at least one non-transitory computer-readable medium of claim 15, wherein the instructions further instruct the at least one processor to train each binary model of the plurality of binary models using at least one of Random Forest, Gradient Boosting, Support Vector Machines, or Neural Networks.

18. The at least one non-transitory computer-readable medium of claim 1, wherein the binary output machine learning algorithm includes one or more gradient-boosted decision trees, transformer-based models, at least one custom deep learning architecture, Random Forest, support vector machine (SVM), k-nearest neighbors (KNN), or Lasso / Ridge regression.

19. The at least one non-transitory computer-readable medium of claim 18, wherein the at least one custom deep learning architecture includes at least one of a convolutional neural network, a recurrent neural network, or a hybrid model.

20. The at least one non-transitory computer-readable medium of claim 1, wherein the instructions further instruct the at least one processor to: receive at least one of new patient information or new hospital-unit-volume information; and re-train the binary output machine learning algorithm using the at least one of the new patient information or the new hospital-unit-volume information.

21. The at least one non-transitory computer-readable medium of claim 20, wherein the instructions further instruct the at least one processor to: execute the re-trained binary output machine learning algorithm to determine at least one updated weighted discharge readiness quantization for the patient; transform the at least one updated weighted discharge readiness quantization into at least one updated discharge prediction for the patient; and control the user interface to provide the at least one updated discharge prediction to the user.Attorney Docket No.: M2212-7001WO(UMMS23-0003 / WO.10) 22. The at least one non-transitory computer-readable medium of claim 1, wherein the instructions further instruct the at least one processor to: receive at least one of new patient information or new hospital-unit-volume information; execute the binary output machine learning algorithm with respect to the at least one of new patient information or the new hospital-unit-volume information to determine at least one updated weighted discharge readiness quantization for the patient; transform the at least one updated weighted discharge readiness quantization into at least one updated discharge prediction for the patient; and control the user interface to provide the at least one updated discharge prediction to the user.

23. A method of quantizing a likelihood of discharging a patient from a hospital, the method comprising: receiving patient information about the patient, the patient information including information about a current hospitalization of the patient; receiving hospital-unit-volume information corresponding to a rolling window of time, the hospital-unit-volume information indicating a number of patients admitted to, transferred into, or discharged from a hospital unit in which the patient currently resides; converting the patient information and the hospital-unit-volume information into a machine-interpretable format tailored to at least one binary output machine learning algorithm; executing the at least one binary output machine learning algorithm to generate a plurality of binary models that predict the likelihood of discharging the patient within each timeframe of a plurality of timeframes; combining the plurality of binary models into a single combined discharge model, wherein combining the plurality of binary models includes optimizing weightings of discharge predictions for each binary model of the plurality of binary models; determining, using the single combined discharge model, at least one weighted discharge readiness quantization for the patient; transforming the at least one weighted discharge readiness quantization into at least one discharge prediction for the patient; and controlling a user interface to provide the at least one discharge prediction to a user.

Images