Prediction of disease progression in portal hypertension using machine learning

Abstract

Example embodiments may involve obtaining observations of demographic, co-disease, vital sign, and / or blood test values of an individual, wherein the individual is diagnosed with portal hypertension and / or cirrhosis; applying a machine learning model to the observations, where the machine learning model is trained with a training dataset, where the training dataset includes observations for a plurality of individuals diagnosed with portal hypertension and / or cirrhosis of corresponding demographic values, co-disease values, vital sign values, blood test values, and / or disease progression values, and wherein the machine learning model is configured to provide a prediction of (i) whether the individual is expected to exhibit a risk ratio of progression to a condition associated with portal hypertension or cirrhosis, and / or (ii) a time period between a newly observed performance and a further diagnosis of a condition; and providing the prediction based on the observation.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 346,189, filed on May 26, 2022, which is incorporated herein by reference in its entirety. Background Art

[0002] The portal vein system supplies blood to the liver. Portal hypertension is the elevated blood pressure in these veins and is usually caused by cirrhosis (liver scarring) or thrombosis (blood clotting). In some cases, portal hypertension can lead to dilated veins (varicose veins) in the esophagus and / or stomach that may bleed, leading to life-threatening bleeding. Portal hypertension may also lead to fluid accumulation in the abdomen (ascites). Beta-blockers are the preferred treatment for portal hypertension, but are only effective in controlling the condition in less than half of patients. Other therapies (such as liver shunts or liver transplants) are more invasive.

[0003] There have been no large epidemiologic studies published on portal hypertension in 20 years or more. As a result, the medical community's knowledge about the prognosis and clinical outcomes of patients with portal hypertension is limited. Summary of the invention

[0004] Portal hypertension usually progresses from mild cases to clinically significant cases to more severe cases and ultimately death. However, different patients with portal hypertension progress differently and at different rates. In addition, the type of treatment that can help a patient is highly sensitive not only to the patient's current diagnosis but also to how their disease progresses. Therefore, a single diagnosis of portal hypertension does not provide enough information for health care providers to make successful patient-specific treatment recommendations.

[0005] Embodiments herein relate to development, training and use of machine learning models to predict disease progression in portal hypertension patients. The predicted progress can indicate results (e.g., varicose veins, varicose bleeding, recurrent varicose bleeding, ascites, refractory ascites, hepatic encephalopathy, recurrent hepatic encephalopathy and / or jaundice, to name a few). The predicted progress can also provide the expected time to reach that result. In this way, patients with complications and / or risk of death can be identified earlier and more accurately. Then, health care providers can make more sensible suggestions about treatment plans and their timing.

[0006] Thus, a first example embodiment involves obtaining, by a computing system, a training data set, wherein the training data set comprises observations of corresponding demographic values, comorbidity values, vital sign values, blood test values, and / or disease progression values ​​for a plurality of individuals diagnosed with portal hypertension and / or cirrhosis; and applying, by the computing system, a machine learning trainer to the training data set, wherein the machine learning trainer generates a plurality of machine learning models, and wherein each of the machine learning models is configured to take as input a new observation of a new demographic value, a new comorbidity value, a new vital sign value, and / or a new blood test value and provide a prediction of: (i) whether an individual diagnosed with portal hypertension and / or cirrhosis who exhibits the new observation is expected to exhibit a hazard ratio for progression to a corresponding condition associated with portal hypertension or cirrhosis, and / or (ii) a time period between the manifestation of the new observation and a further diagnosis of the corresponding condition.

[0007] A second example embodiment relates to obtaining, by a computing system, observations of demographic values ​​for an individual, comorbidity values ​​for the individual, vital sign values ​​for the individual, and / or blood test values ​​for the individual, wherein the individual is diagnosed with portal hypertension and / or cirrhosis; applying, by the computing system, a machine learning model to the observations, wherein the machine learning model is trained using a training data set, wherein the training data set contains observations of corresponding demographic values, comorbidity values, vital sign values, blood test values, and / or disease progression values ​​for a plurality of individuals diagnosed with portal hypertension and / or cirrhosis, and wherein the machine learning model is configured to provide a prediction of: (i) a risk ratio for whether the individual is expected to exhibit progression to a condition associated with portal hypertension or cirrhosis, and / or (ii) a time period between the manifestation of the observation and further diagnosis of the condition; and providing, by the computing system, the prediction based on the observations.

[0008] In a third example embodiment, an article of manufacture includes a non-transitory computer-readable medium having program instructions stored thereon that, when executed by a computing system, cause the computing system to perform operations according to the first and / or second embodiments.

[0009] In a fourth exemplary embodiment, a computing system includes at least one processor and a memory and program instructions. The program instructions may be stored in the memory and, when executed by the at least one processor, cause the computing system to perform operations according to the first and / or second exemplary embodiments.

[0010] In a fifth example embodiment, a system includes various components for performing each of the operations of the first and / or second embodiments.

[0011] These and other embodiments, aspects, advantages and alternatives will become apparent to those of ordinary skill in the art by reading the following detailed description with reference to the accompanying drawings where appropriate. In addition, the present disclosure and other descriptions and drawings provided herein are intended to illustrate the embodiments only by way of example, and therefore, many variations are possible. For example, structural elements and process steps may be rearranged, combined, distributed, eliminated or otherwise changed while remaining within the scope of the embodiments as claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A schematic diagram illustrating a computing device according to an example embodiment is shown.

[0013] Figure 2 A schematic diagram illustrating a cluster of server devices according to an example embodiment.

[0014] Figure 3 The training and use of a gradient boosting model according to an example embodiment is shown.

[0015] Figure 4 Depicted is a progression pathway for portal hypertension according to an example embodiment.

[0016] Figure 5 Depicted is an example timeline for the progression of portal hypertension according to an example embodiment.

[0017] Figure 6 Depicted are two timelines of the progression of portal hypertension or liver disease in general, according to example embodiments.

[0018] Figure 7 Depicting the training and use of an array of machine learning models according to example embodiments.

[0019] Figure 8 Depicting the use of a trained machine learning model according to an example embodiment.

[0020] Fig. 9 is a graph of area under the curve values ​​demonstrating that the machine learning model described herein outperforms conventional techniques according to example embodiments.

[0021] Fig.10 and Fig.11 is a flow chart according to an example embodiment. DETAILED DESCRIPTION

[0022] Example methods, devices, and systems are described herein. It should be understood that the words "example" and "exemplary" are used herein to mean "serving as an example, instance, or illustration." Unless so stated, any embodiment or feature described herein as "example" or "exemplary" is not necessarily to be construed as having priority or superiority over other embodiments or features. Therefore, other embodiments may be utilized and other changes may be made without departing from the scope of the subject matter presented herein. Other embodiments may be utilized and other changes may be made without departing from the scope of the subject matter presented herein.

[0023] Therefore, the example embodiments described herein are not meant to be limiting. It will be readily appreciated that aspects of the present disclosure as generally described herein and illustrated in the accompanying drawings may be arranged, replaced, combined, separated, and designed in a variety of different configurations. For example, separation of features into "client" and "server" components may be performed in a variety of ways.

[0024] Furthermore, unless the context suggests otherwise, the features shown in each of the figures may be used in combination with each other. Therefore, the figures should generally be viewed as component aspects of one or more general embodiments, with the understanding that not all of the shown features are required for each embodiment.

[0025] In addition, any listing of elements, frames or steps in this specification or claims is for clarity purposes. Therefore, such listing should not be interpreted as requiring or implying that these elements, frames or steps follow a specific arrangement or are performed in a specific order. I. Example Computing Devices and Cloud-Based Computing Environments

[0026] Figure 1 is a simplified block diagram of an example computing device 100, which shows some of the components that may be included in a computing device arranged to operate according to embodiments herein. Computing device 100 may be a client device (e.g., a device actively operated by a user), a server device (e.g., a device that provides computing services to client devices), or some other type of computing platform. Some server devices may sometimes operate as client devices in order to perform certain operations, and some client devices may incorporate server features.

[0027] In this example, computing device 100 includes processor 102, memory 104, network interface 106, and input / output unit 108, all of which may be coupled via system bus 110 or similar mechanism. In some embodiments, computing device 100 may include other components and / or peripherals (e.g., removable storage devices, printers, etc.).

[0028] Processor 102 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a coprocessor (e.g., a math, graphics or cryptographic coprocessor), a digital signal processor (DSP), a network processor, and / or an integrated circuit or controller that performs processor operations. In some cases, processor 102 may be one or more single-core processors. In other cases, processor 102 may be one or more multi-core processors with multiple independent processing units. Processor 102 may also include register memory for temporarily storing instructions being executed and associated data, and a cache memory for temporarily storing recently used instructions and data.

[0029] Memory 104 may be any form of computer usable memory, including but not limited to random access memory (RAM), read-only memory (ROM), and non-volatile memory (e.g., flash memory, hard disk drives, solid-state drives, and / or tape storage). Thus, memory 104 represents a main memory unit as well as a long-term storage device. Other types of memory may include biological memory.

[0030] The memory 104 may store program instructions and / or data on which the program instructions may operate. As an example, the memory 104 may store these program instructions on a non-transitory computer-readable medium so that the instructions may be executed by the processor 102 to implement any of the methods, processes, or operations disclosed in this specification or the accompanying drawings.

[0031] like Figure 1 As shown in , memory 104 may include firmware 104A, kernel 104B and / or application 104C. Firmware 104A may be program code for booting or otherwise starting some or all of computing device 100. Kernel 104B may be an operating system, including modules for memory management, process scheduling and management, input / output and communication. Kernel 104B may also include device drivers that allow the operating system to communicate with hardware modules (e.g., memory units, networking interfaces, ports and buses) of computing device 100. Application 104C may be one or more user space software programs, such as a web browser or email client, and any software libraries used by these programs. Memory 104 may also store data used by these and other programs and applications.

[0032] The network interface 106 may take the form of one or more wired interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet, etc.). The network interface 106 may also support communication over one or more non-Ethernet media, such as coaxial cables or power lines, or over wide area media, such as Synchronous Optical Networking (SONET) or Software Defined Wide Area Networking (SD-WAN) technologies. The network interface 106 may additionally take the form of one or more wireless interfaces, such as IEEE 802.11 (Wifi), Global Positioning System (GPS) or wide area wireless interface. However, other forms of physical layer interfaces and other types of standard or proprietary communication protocols may be used through network interface 106. In addition, network interface 106 may include multiple physical interfaces. For example, some embodiments of computing device 100 may include Ethernet, And Wifi interface.

[0033] The input / output unit 108 may facilitate interaction of users and peripheral devices with the computing device 100. The input / output unit 108 may include one or more types of input devices, such as a keyboard, a mouse, a touch screen, etc. Similarly, the input / output unit 108 may include one or more types of output devices, such as a screen, a monitor, a printer, and / or one or more light emitting diodes (LEDs). Additionally or alternatively, the computing device 100 may communicate with other devices using, for example, a Universal Serial Bus (USB) or High Definition Multimedia Interface (HDMI) port interface.

[0034] To support the embodiments herein, one or more computing devices such as computing device 100 may be deployed. The exact physical location, connectivity, and configuration of these computing devices may be unknown and / or unimportant to the client devices. Thus, the computing devices may be referred to as "cloud-based" devices that may be housed at various remote data center locations.

[0035] Figure 2 Depicts a cloud-based server cluster 200 according to an example embodiment. Figure 2 In the embodiment of the present invention, the operation of a computing device (e.g., computing device 100) can be distributed among server devices 202, data storage devices 204, and routers 206, all of which can be connected through a local cluster network 208. The number of server devices 202, data storage devices 204, and routers 206 in server cluster 200 can depend on the computing task(s) and / or application(s) assigned to server cluster 200.

[0036] For example, the server device 202 can be configured to perform various computing tasks of the computing device 100. Therefore, the computing tasks can be distributed among one or more of the server devices 202. To the extent that these computing tasks can be performed in parallel, such task distribution can reduce the total time to complete these tasks and return results. For simplicity, both the server cluster 200 and the individual server devices 202 can be referred to as "server devices". This nomenclature should be understood to imply that one or more different server devices, data storage devices, and cluster routers can be involved in the server device operation.

[0037] The data storage device 204 may be a data storage array including a drive array controller configured to manage read and write access to a group of hard disk drives and / or solid state drives. The drive array controller, alone or in conjunction with the server device 202, may also be configured to manage backup or redundant copies of data stored in the data storage device 204 to protect against drive failures or other types of failures that prevent one or more units in the server device 202 from accessing the data storage device 204. Other types of storage besides drives may be used.

[0038] The router 206 may include a networking device configured to provide internal and external communications for the server cluster 200. For example, the router 206 may include one or more packet switching and / or routing devices (including switches and / or gateways) configured to provide (i) network communications between the server devices 202 and the data storage devices 204 via the local cluster network 208, and / or (ii) network communications between the server cluster 200 and other devices via the communication link 210 to the network 212.

[0039] Additionally, the configuration of router 206 may be based at least in part on data communication requirements of server device 202 and data storage device 204, latency and throughput of local cluster network 208, latency, throughput, and cost of communication link 210, and / or other factors that may contribute to cost, speed, fault tolerance, resilience, efficiency, and / or other design goals of the system architecture.

[0040] As a possible example, data storage device 204 may include any form of database, such as a structured query language (SQL) database. Various types of data structures may store information in such a database, including but not limited to tables, arrays, lists, trees, and tuples. In addition, any database in data storage device 204 may be monolithic or distributed across multiple physical devices.

[0041] Server device 202 can be configured to transmit data to data storage device 204 and receive data from data storage device 204. Such transmission and retrieval can take the form of SQL query or other type of database query and the output of such query respectively. Additional text, image, video and / or audio can also be included. In addition, server device 202 can organize the received data into web page or web application representation, or in some other way for use by software application. Such representation can take the form of markup language, such as HTML, extensible markup language (XML) or some other standardized or proprietary format.

[0042] In addition, the server device 202 may have the ability to execute various types of computerized scripting languages, such as, but not limited to, Perl, Python, PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP), Etc. Computer program codes written in these languages ​​can facilitate providing web pages to client devices, and interaction between client devices and web pages. Alternatively or additionally, Can be used to facilitate the generation of web pages and / or provide web application functionality. II. Example Gradient Boosting Model

[0043] The gradient boosting algorithm is a machine learning technique that can be used to develop a predictive model for a multidimensional data set. For convenience, these sets are usually represented in matrix form using columns and rows. One or more columns represent input variables, and additional columns represent output variables. The output variable is an unknown function of one or more of the input variables. The rows represent observations of the input variables and their corresponding output variables, usually based on real-world data. In many cases, the number of rows may be quite large, hundreds, thousands or more. The machine learning process involves training a gradient boosting model so that the output variable can be predicted for new observations of the input variables. In other words, the model attempts to learn or at least approximate an unknown function from existing instances of the input variables and their corresponding output variables.

[0044] Figure 3 To further illustrate these concepts, a training data set 300 includes a set of training observations (rows), each consisting of input variables X1, X2, and X3 and their corresponding output variable Y. These input and output variables are related by some unknown function f, where Y = f (X1, X2, X3). The output variable Y can take various forms, such as an integer or real number, a text, or a Boolean value.

[0045] The training data set 300 may be collected from actual patient medical data, e.g., from health professionals, hospitals, clinical trials, or other sources. In such a training data set, the value of the output variable for each observation is expected to be known, but not every value of the input variable needs to exist—e.g., the training data set may be sparsely populated.

[0046] The training data set 300 is provided to a gradient boosting trainer 302, which applies one or more training techniques to produce a gradient boosting model 304. The gradient boosting model 304 may be an algorithm or a set of parameters that control the behavior of an algorithm that may be used to apply an approximation of an unknown function f to new observations of input variables.

[0047] Thus, the gradient boosting model 304 can receive new observations 306 and produce predicted output variables 308. The accuracy of such predictions can vary based on the operation of the gradient boosting trainer 302 and the quality of the training data set 300. The goal is to make the gradient boosting model 304 as accurate as reasonably possible given a sufficiently rich training data set and a reasonable amount of time spent on training. This accuracy can be measured in a variety of ways, as described in more detail below.

[0048] The operation of the gradient boosting trainer 302 may involve training a set of decision trees (colloquially referred to as a "forest"), each of which has a limited depth or has a limited number of leaves. Therefore, these trees are weak learners because they generally do not consider all of the available information in the training data set, and therefore their individual predictions may or may not have high accuracy. However, gradient boosting makes an overall prediction based on the weighting of the predictions from the individual trees. These overall predictions take into account most, if not all, of the training data set, and therefore may be more accurate than the predictions from any of the individual trees.

[0049] But unlike random forests, where each tree is independent of the others, the construction of subsequent trees in a gradient boosting model can be based on the errors (or residuals) of one or more of the previously constructed trees. In some cases, subsequent trees that compensate well for the errors of previous trees are given more weight relative to the overall prediction, while in other cases all trees may be weighted equally. Gradient boosting continues to construct trees in this manner until it has constructed a predetermined number of trees or the new trees fail to improve the accuracy of the prediction by more than a predetermined margin.

[0050] When the output variable takes continuous values ​​(e.g., integers falling in a range), the tree is constructed based on the magnitude of the residuals between the actual values ​​of the training data output variable and the associated predicted values. This can be referred to as gradient boosting for regression. In some cases, these residuals are referred to as "pseudo-residuals" to distinguish gradient boosting from linear regression, but the terms "residuals" and "pseudo-residuals" will be used interchangeably in this article. For each observation i, p i,0 The initial predictions for can take the same value p0, such as the mean of some or all output variables in the training dataset. In other words,

[0051] Here, the symbol p i,j refers to the prediction for observation i made using trees 0 to n (see below for more details on how predictions are computed using multiple trees). The initial prediction p0 can take the form of a single node rather than a tree, since it is typically based only on the value of the output variable.

[0052] In any case, a tree is constructed to predict the value of the residual. The non-leaf nodes of the tree represent conditions on the input variables. For example, the root node in the tree constructed from the training data set 300 may represent the condition X2>5, such that when the condition is true, the left branch of the node is followed, and when the condition is false, the right branch of the node is followed. Any of these branches may lead to another non-leaf node representing a condition or a leaf node representing a residual. There may be more than two branches, but for convenience, a binary tree is used in the examples herein.

[0053] The tree construction can be based on various algorithms for decision trees. In some cases, this may involve selecting input variables and associated cutoff values ​​that may be based on entropy or Gini impurity. The cutoff value is selected so that it divides the values ​​of the input variables in a way that makes the input variables reasonably predict the output variable. The input variables are then arranged into nodes in the tree, where more predictive input variables are typically placed higher in the tree (e.g., closer to the root node). In some cases, randomness can be added to the process of determining where to place the input variables in the tree.

[0054] Since the number of observations is usually much larger than the number of leaves in a finite-sized tree, the residuals for each observation that leads to the same leaf are usually averaged and then placed in the leaf. Thus, a leaf can represent a set of observations for multiple observations r i,0 Here, the symbol r i,j refers to the residual for observation i from using trees 0 to n (see below for more details on how residuals are computed with multiple trees).

[0055] We then iterate predictions for the observations in the training dataset. Each prediction p in the first iteration i,1 involves traversing the tree 1 for observations until a leaf is reached, and then adding the residual of that leaf to the initial prediction according to the learning rate 0<α<1. In other words, p i,1 =p i,0 +αr i,0 The learning rate helps prevent overfitting the training dataset and allows small steps towards higher prediction accuracy.

[0056] According to the prediction p i,1 , calculate the new residual r i,1 . Again, the residuals are based on the differences between the actual output variable values ​​in the training dataset and the associated predicted values, with possible aggregation as described above. It is expected that these new residuals will typically be smaller than r i,0 , but not every residual is true.

[0057] The next tree, Tree 2, can be constructed based on these new residuals. This tree can have the same structure as Tree 1, or can be constructed differently, with nodes representing input variables appearing in different positions (e.g., using randomness).

[0058] Then, each prediction p of the second iteration i,2 involves traversing both tree 1 and tree 2 for observations until their corresponding leaves are reached, and then scaling the associated residuals r according to the learning rate i,0 and r i,1 Add to the initial prediction. In other words, p i,2 =p i,0 +ar i,0 +αr i,1 .

[0059] According to the prediction p i,2 , calculate the new residual r i,2 It is expected that these residuals will continue to get smaller as the number of trees grows.

[0060] The process of constructing new trees based on the residuals and making new predictions continues until a predetermined number of trees have been constructed or the addition of new trees has failed to reduce the size of the residuals by more than a predetermined margin, as described above. At this point, training is complete and the trained gradient boosting model is ready to make predictions for new observations of the input variables.

[0061] Given such a new observation, the model starts with an initial prediction p0 and traverses all the trees in the tree based on the value of the input variable, adding the resulting residuals. Therefore, assuming there are n trees in addition to the initial node, the predicted value of the output variable for a new observation is where r0 is the initial residual, and rj is the residual of the jth tree for that observation, 1≤j≤n.

[0062] Gradient boosting can also be used to predict the value of an output variable from a limited number of possible values. For example, when the output variable is Boolean, gradient boosting can be used to train a binary classifier. This can be referred to as gradient boosting for classification.

[0063] In this case, the prediction can be based on (i) the natural logarithm of the odds that the output variable is true, and (ii) the probability that the output variable is true, across all observations in the training dataset. For example, suppose there are 100 observations, 70 of which are "true" and 30 are "false." The natural logarithm of the odds that the observation is true would be ln(70 / 30) = 0.847, while the probability that the output variable is true is 0.7.

[0064] The natural logarithm of the odds (0.847) is used as the initial prediction for all observations, and the probability (0.7) is used to calculate the residuals. Since 0.7 is greater than 0.5, the initial prediction is "true" for all observations (note that values ​​other than 0.5 can be used as cutoffs in this process). Clearly, these initial predictions are not accurate, as indicated by their residuals. Assigning 1.0 to true and 0.0 to false, the residual will be 0.3 for each observation where the output variable is "true" and -0.7 for each observation where the output variable is "false".

[0065] Furthermore, the residuals are usually transformed to generate the output values ​​of the leaves. This is because they are based on probabilities, while the predictions are based on the natural logarithm of the odds. k The residual r k An example transformation of a leaf is:

[0066] These output values ​​for the leaves are then scaled by the learning rate and added to the initial predictions. Since these predictions are still in the form of the natural logarithm of the odds, they can be converted to the probability form used by the residuals by applying the logistic function. For example, the predicted values ​​of p will have the following probabilities:

[0067] These residuals are then determined as the difference between the value and the probability of the output value from the training data set. As previously described, new trees can be calculated based on these residuals. This process continues until a predetermined number of trees have been constructed or the addition of new trees fails to reduce the size of the residuals by more than a predetermined margin.

[0068] The trained gradient boosting model is then applied to new observations in a similar manner. The process adds the initial prediction and the transformed output value of each leaf associated with the new observation to find the natural logarithm of the predicted odds. A logistic function is then applied to the prediction to provide a probability. The final prediction for this new observation is "true" if the probability is greater than 0.5, otherwise it is "false".

[0069] Note that the above description only provides a general overview of several methods for performing gradient boosting. Other techniques are also possible. In addition, other types of machine learning models (such as artificial neural networks or expert systems) can be used instead of gradient boosting techniques or in combination with gradient boosting techniques. Nevertheless, gradient boosting can usually work well with certain types of data and produce interpretable models-the model can be analyzed to understand how and why it produces its answers, which may not be the case for artificial neural networks. In addition, when the training data set is sparse (e.g., many observations with at least one missing input variable), the gradient boosting model also tends to perform well, while artificial neural networks tend to be less efficient in the case of sparse data.

[0070] There are two popular gradient boosting frameworks that can be used to train and deploy gradient boosting models, XGBoost and LightGBM. For example purposes, each is briefly discussed below. However, other frameworks can also be used. A. XGBoost

[0071] When the output variable takes continuous values, XGBoost constructs a tree by placing all residuals in the root node, and then calculates a similarity score for the residuals. The similarity score can be calculated as the sum of the residuals divided by the square of the number of residuals. In some cases, a regularization constant is also added to the denominator to reduce sensitivity to outliers and overfitting of the training dataset. In any case, the higher the similarity score, the more similar the residuals are.

[0072] Various ways of partitioning the residuals into groups are then considered to see if any of these partitions result in a higher overall similarity score. This can be determined by calculating the gain of the partition over the original grouping of all residuals in the root node. The gain can be the similarity score of the root node subtracted from the sum of the similarity scores of each node of the partition. The partition that produces the largest gain among all the partitions is then selected to create a branch from the root node (i.e., each group of residuals in the selected partition becomes a child of the root node).

[0073] The same process is then performed for each of the new child nodes. If a child node contains only one residual, it cannot be split further and becomes a leaf. Additionally, the tree can be limited to a maximum number of levels (e.g., 4, 6, or 8), and nodes at that maximum depth will not be split further. In some cases, XGBoost may require a minimum number of residuals to be represented in each node (e.g., 2, 3, 4, ...).

[0074] Once the XGBoost tree is constructed in this way, some branches that produce less than a threshold gain can be pruned. The pruning process regroups them into their respective parent nodes.

[0075] Predictions are made by traversing the tree with the values ​​of the input variables until a leaf is reached. The output value of a leaf is the sum of the residuals in that leaf divided by the number of residuals in that leaf. Similarly, a regularization constant can also be added to the denominator.

[0076] As with standard gradient boosting, this tree is then used to make predictions scaled by the learning rate. The residuals from these predictions are then used to construct the next tree, and so on. Tree construction ends when a predetermined maximum number of trees has been constructed or the residual becomes less than a predetermined threshold.

[0077] When the output variable takes one of a discrete number of values ​​(e.g., for classification), XGBoost maps these values ​​into a numeric range. For example, each value for a Boolean output variable will be mapped to either 1.0 or 0.0. Then, partitioning is performed as described above.

[0078] However, a different similarity score calculation is used for each node, which is the sum of the squares of the residuals in the node divided by the sum of all observations, i.e., the product of (i) the prior probability and (ii) the prior probability minus 1. A regularization constant may also be added to the denominator. Tree construction also occurs as above, although this different similarity score calculation is used to determine the gain.

[0079] As mentioned above, XGBoost may require a minimum number of residuals to be represented in each leaf. However, in this version of XGBoost, a value called "cover" is used instead of residual counts. Cover is the denominator of the similarity score minus a regularization constant. Leaves with less than a cover threshold can be removed from the tree, effectively pruning the tree. Other pruning techniques described above can also be used.

[0080] For prediction, the output value of a leaf is the sum of the residuals in the leaf divided by the sum of all observations, that is, the product of (i) the prior probability and (ii) the prior probability subtracted from 1. A regularization constant may also be added to the denominator. Across multiple trees, the prediction for an observation is the natural logarithm of the odds for the initial output value, plus the output value of each tree scaled by the learning rate.

[0081] A logistic function can be applied to this result in order to convert it back into a probability. Based on the value of this probability (e.g., above or below 0.5 for a binary output variable), the value of the output variable can be selected.

[0082] XGBoost also employs a number of techniques that speed up its processing of large training datasets. These techniques include using an approximate greedy algorithm for selecting partitions, a weighted sketch algorithm for focusing on difficult-to-predict observations, distributed training across multiple processors or computers, and / or keeping commonly used variables and constants in processor caches. Other techniques may also be applied. B. LightGBM

[0083] LightGBM also employs gradient boosting, but does so in a way that generally increases training speed, reduces memory utilization, and improves accuracy. In particular, instead of considering all values ​​of the input variables, LightGBM bins these values ​​to form a histogram and operates on the bins instead of the values. In addition, when two or more features tend to take on mutually exclusive values, LightGBM uses exclusive feature bundling to reduce the dimensionality of the feature space. Furthermore, LightGBM uses gradient-based one-sided sampling to identify the observation with the largest residual and operates only on that observation and on observations with lower residuals.

[0084] Therefore, LightGBM focuses computation where it is needed most — on input variables that differ from each other and on observations that have the largest errors for its earlier trees. As a result, in practice, LightGBM can execute about ten times faster than other gradient boosting implementations with similar accuracy. III. Survival analysis

[0085] Survival time analysis is a group of statistical methods that provide estimates of the amount of time (e.g., days, weeks, months, years) until an event occurs. An example use of such an analysis would be to predict the number of days between when a patient is diagnosed with a condition (e.g., portal hypertension) and when the patient is expected to show an outcome (such as an indication or diagnosis of another condition (e.g., varicose veins, ascites, or death)). This analysis can be performed on patients being treated as well as untreated patients. Typically, the goal of a survival time analysis is to determine whether a specific treatment has an effect on the predicted survival time.

[0086] It is important to note that survival time analysis is not limited to predicting the time until a patient dies - it is used to predict the time between two events. However, it is often used to predict how long a patient will survive, hence the name.

[0087] Survival time analysis is usually implemented as a form of regression using a training data set of observations. Each observation can indicate whether the patient exhibited an outcome (a binary value of true or false), and if so, the time between some initial state and that outcome. For example, the initial state may be a diagnosis of portal hypertension, and the outcome may be varicose veins. If the patient is diagnosed with varicose veins during the observation period, the amount of time between the two diagnoses is the survival time. Since some conditions (like portal hypertension) have more than one possible progression, each can be modeled separately.

[0088] Most survival time analyses must account for censored data. For example, in a clinical trial, some patients may drop out of the trial before their results can be observed. This may be due to a variety of reasons, such as the study ending before the results are observed in the patient, or the patient leaving the study early for some reason (e.g., losing interest, moving to a different location, or dying). Such data are considered "right-censored" and are generally considered non-informative. In other words, right-censored observations are not considered by the model.

[0089] Cox regression is a survival time analysis technique that allows the use of multiple input variables to predict outcomes (output variables). The Cox model assumes that the observed logarithmic risk is a linear function of its covariates and a time-varying population-level baseline risk function. Since the embodiments herein relate to a training data set with multiple input variables, and the impact of each input variable on various outcomes is unknown, Cox regression is a good candidate for predicting survival time.

[0090] Another method for survival time analysis is accelerated failure time (AFT). AFT is also a regression-based method that supports multiple input variables. Unlike Cox regression, AFT allows for a fully parameterized specification of the hazard function. However, other parametric, semiparametric or nonparametric survival functions can be used.

[0091] The XGBoost implementation supports Cox regression and AFT, and can therefore be used for survival analysis. Other gradient boosting implementations may provide similar functionality. Another package, NGBoost, includes an AFT feature integrated into the gradient boosting framework (e.g., as a random survival forest), which allows the gradient to be characterized as a probability distribution. IV. Predicting the progression of portal hypertension

[0092] As described above, portal hypertension is a condition in which liver damage (e.g., cirrhosis) or portal vein obstruction (intrinsic or extrinsic) leads to elevated venous blood pressure in the portal venous system, which carries blood from the gastrointestinal organs to the liver. Untreated portal hypertension can lead to a variety of conditions, including, but not limited to, varicose veins, varicose bleeding, recurrent varicose bleeding, ascites, refractory ascites, hepatic encephalopathy, recurrent hepatic encephalopathy, jaundice, lower extremity swelling, coagulopathy, pulmonary complications, portosystemic shunts, and death.

[0093] Figure 4 Example progression pathways for portal hypertension are depicted. These pathways generally progress from observation of compensated cirrhosis to observation of decompensated cirrhosis to observation of further decompensation.

[0094] Patients with compensated cirrhosis may be essentially asymptomatic and may not have ascites, variceal bleeding, hepatic encephalopathy, or jaundice. Nevertheless, such patients may be diagnosed with mild portal hypertension (where no symptoms are usually observed). Mild portal hypertension may progress to clinically significant portal hypertension (where one or more symptoms, such as varicose veins, have been observed).

[0095] Clinically significant portal hypertension may progress to decompensated cirrhosis. Patients suffering from decompensated cirrhosis may show one or more conditions (e.g. ascites, variceal bleeding, hepatic encephalopathy and / or jaundice). Patients suffering from late decompensated cirrhosis may have more serious conditions, such as recurrent variceal bleeding, refractory ascites, hepatic encephalopathy, portosystemic shunt and / or jaundice. The life expectancy for patients suffering from decompensated cirrhosis can be calculated in months or years.

[0096] Thus, a possible progression pathway for portal hypertension is from compensated cirrhosis without varicose veins to compensated cirrhosis with varicose veins, to decompensated cirrhosis with variceal bleeding, to recurrent variceal bleeding, and ultimately death. Other progression pathways are also possible.

[0097] The treatment of portal hypertension lacks effectiveness for many patients at present, or is invasive. Therefore, it is desirable to have a framework for assessing whether a particular patient may progress to one or more of these diseases, and the prediction of the time frame of progress. With such a framework, it is possible to identify a patient who may progress faster towards an undesirable disease in its early stage of progress. Then it can be considered that these patients are treated more actively to slow down their progress. In other cases, the clinical trial of a new treatment (for example, diet, supplements and / or medicine) can be selected for the patient with any predicted rate of progression. The embodiments herein may include software for analyzing a patient database, and the ranking of these patients is provided in the order of the risk of progression, so as to be included in the inclusion of the clinical trial (the trial about the patient with a higher risk of progression can shorten the length of the trial and reduce the placebo effect). Therefore, the embodiments herein may potentially lead to the improved life span and the improved quality of life of the patient with portal hypertension.

[0098] Thus, an array of n machine learning models - one for each condition of interest - can be trained on patient data to predict whether the condition is expected to occur, and the length of time until the condition is expected to be observed. For example, there may be a model for each of varicose veins, ascites, variceal bleeding, hepatic encephalopathy, and death. Thus n=5 in this example. Further overall models can be trained on patient data to predict whether any of these conditions is expected to occur, and the length of time until that condition is expected to be observed. Thus, there may be a total of n+1 machine learning models. In some cases, a model can predict the progression of an early complication to a later, more severe complication (e.g., from portal hypertension without bleeding varicose veins to varicose veins with bleeding).

[0099] These machine learning models can be operated on based on observed timelines of progress. The general framework for such timelines is Figure 5 500. In particular, timeline 500 includes four main points of interest for modeling possible progressions. These progressions include where an outcome is observed, an unknown outcome is observed, or an outcome is not observed. The progression of portal hypertension for each patient can be fitted into timeline 500.

[0100] Point 504 is an index date, which is a reference date for prediction. The index date may be the first recorded diagnosis of portal hypertension and / or cirrhosis in a patient, or may be a point in time from which predictions are made for patients who have already been diagnosed with portal hypertension and / or cirrhosis. In some cases, these patients are selected so that they have no previously recorded complications of portal hypertension or causes of non-cirrhotic portal hypertension. Patients who exhibit certain characteristics or who have not been observed, such as patients who had liver transplants or severe cirrhosis prior to the index date, may be excluded from the training data.

[0101] Thus, point 504 is the time from measurement to outcome (if any). In practice, it is desirable to have at least 6 months of observation prior to point 504 to increase the chances of identifying patients with an onset of the disease. Thus, the time between point 502 and point 504 should be at least 6 months, although a minimum time period other than 6 months may be used.

[0102] Point 506 is the time at which the result is observed. As described above, in some cases no result is observed. In these cases, point 506 will not exist. The result may be known (e.g., varicose veins, varicose bleeding, recurrent varicose bleeding, ascites, refractory ascites, hepatic encephalopathy, recurrent hepatic encephalopathy and / or jaundice). In other cases, the result may be unknown. For example, a disease may have been observed, but the exact nature of the disease cannot be determined from the available data (e.g., it may be known that the patient suffers from varicose veins, but whether the varicose veins bleed may be unknown because the patient has not yet undergone an endoscopic examination to make this determination).

[0103] Point 508 represents the end of the data for patients for whom no outcome was observed. For example, the patient may have died, exited the health care system from which the data was collected, or the study period ended. The data for such patients may be right-censored.

[0104] Figure 6 Here is another way to depict this patient data. Chart 600 includes two example timelines of portal hypertension progression. Both assume that the patient has been diagnosed with cirrhosis and portal hypertension. Both also include monthly aggregated health data (e.g., results of examinations, procedures, vital sign measurements, and / or laboratory tests) represented by asterisks. For simplicity, the Figure 6 Only three asterisks are shown per timeline in the , but these health data entries may span many months. Regardless, the health data can be considered a sparse dataset, with at least some values ​​missing from some months. Perhaps up to 20%-60% of all expected health data entries are absent.

[0105] Timeline 602 is referred to as a "Type 1" timeline because it shows the progression of liver disease to an outcome (e.g., varicose veins, variceal bleeding, recurrent variceal bleeding, ascites, refractory ascites, hepatic encephalopathy, recurrent hepatic encephalopathy, and / or jaundice). Timeline 604 is referred to as a "Type 2" timeline because no progression of liver disease was observed and the associated data is right-censored.

[0106] Patient health records can be formed into a training data set according to such a timeline. As a possible example, an index date is determined for each patient. This can be the date when the patient data is considered for inclusion in the training data set. Any patient whose portal hypertension has been observed for at least 6 months before the index date can have their data incorporated into the training data set. Then, for patients with known or unknown results, the corresponding results and associated result times are determined. Patients without results are right-censored. Alternatively, the progress can be represented as the amount of time (e.g., in days) between points 504 and 506, with an indication of the results observed at point 506.

[0107] Some data may also be left-censored because some unknown outcome may define a lower bound on the time of progression of the condition, e.g., if a patient did not have varicose veins before a given date, and now does have varicose veins, and the patient's bleeding status is unknown. Table 1

[0108] Table 1 provides a simple example of possible training data. In this table, patient A is observed to have varicose veins 432 days from the index date of May 22, 2019, patient B is observed to have refractory ascites 325 days from the index date of June 1, 2019, and patient C is observed to have an unknown condition 517 days from the index date of May 27, 2019. In some cases, there may be multiple entries for each patient when multiple conditions are observed. For example, there may be a second entry for patient A in Table 1 indicating that patient A was also observed to have varicose veins and bleeding 489 days later. Alternatively or additionally, there may also be entries for monthly aggregated health data (not shown). Monthly laboratory results may be aggregated over the 6 months prior to the index date or observation, with the last observation carried forward to the index date.

[0109] In any case, the format and content of Table 1 are for illustrative purposes, and other formats and / or content of the training data are possible. As described above, for each patient, the training data may also include demographic data, comorbidities, laboratory results, vital signs, and / or other health data (e.g., medications, prescriptions, treatments, exercise, nutrition, mental health), etc.

[0110] Figure 7 Depicting the training and prediction phases of an array of machine learning models. The training data set 700 may include observations from patients related to the progression of portal hypertension. As noted, these may include input variables (e.g., demographics, comorbidities, laboratory results, and / or vital signs) and output variables (indications of the diagnosis of one or more additional conditions and the number of days from the index date to when one or more of these additional conditions were diagnosed).

[0111] The machine learning trainer 702 can be applied to the training dataset 700 to produce an array of n trained machine learning models. The machine learning trainer 702 can employ gradient boosting and survival time aspects in a robust manner when the training dataset 700 is sparse.

[0112] Given a new input variable from a patient (not shown), each trained model can predict whether that patient is expected to be diagnosed with a particular condition and how many days are expected before such a diagnosis can be made. For example, model 704A can be trained to predict whether 706A will make a diagnosis of varicose veins and, if so, how many days are there from the index date to the diagnosis. Similarly, model 704B can be trained to predict whether 706B will make a diagnosis of ascites and, if so, how many days are there from the index date to the diagnosis. Similarly, model 704C can be trained to predict whether 706C will make a diagnosis of hepatic encephalopathy and, if so, how many days are there from the index date to the diagnosis. Each of these models can be trained independently and can also operate independently when making predictions.

[0113] The prediction of whether a patient is expected to be diagnosed with a particular condition can be in the form of a hazard ratio of whether an individual is expected to exhibit progression to a condition associated with portal hypertension or cirrhosis. The hazard ratio can be referenced to the general population, i.e., whether the patient is expected to progress faster or slower. The hazard ratio can be a non-negative value used to compare a specific cohort with the general population. Thus, a hazard ratio of 0.1 means that a specific cohort is one tenth as likely to exhibit the condition, while a hazard ratio of 2 means that a specific group is twice as likely to exhibit the condition. The hazard ratio can be thresholded as a Boolean true or false value for inclusion or exclusion (e.g., if the hazard ratio is above 0.1, the Boolean value is "true", and if the hazard ratio is equal to or below 0.1, the Boolean value is "false").

[0114] Or, in Figure 3 In the context of , the output variable in the training data set 300 can be a time range, where the upper and lower limits of the range are the same if the event is observed at the exact time. In addition, the predicted output variable 308 can be a risk ratio and / or a predicted time value (e.g., number of days).

[0115] Additionally, the machine learning trainer 702 can be applied to the training data set 700 to further generate general models (making for a total of n+1 trained models) that predict whether any such condition will be diagnosed and how many days are expected before such a general diagnosis is likely to be made. For patients predicted to be diagnosed with more than one condition (e.g., varicose veins and ascites), the number of days predicted can be the time from the index date to when the earliest diagnosis is expected to occur. Thus, the model 704D can be trained to predict 706D whether a diagnosis of any one or more conditions related to varicose veins will be made, and if so, how many days from the index date to the diagnosis.

[0116] If Figure 7 As shown by the ellipsis in , n may take various values. In some cases, n may be 1 or 2, and in other cases n may be 7, 8, or even higher. Therefore, the embodiments herein may use any value of n. These embodiments may or may not include a general model.

[0117] Figure 8 Depicts how any of these trained models perform in making predictions. Demographic data 800 (e.g., age, gender, race), comorbidities 802 (e.g., diabetes, obesity), and lab results and vital signs data 804 (e.g., body mass index, blood pressure, heart rate, blood test data) are provided as inputs to a trained machine learning model 806. Other data (such as medications taken) may be included in the inputs.

[0118] As described above, the training data set may indicate an index date for the patient, which represents a point in time at which the patient was known to have, or at least suspected to have, portal hypertension and / or cirrhosis. Additionally, the laboratory results and vital signs data 804 may include multiple measurements taken over time, optionally aggregated by month.

[0119] The machine learning model 806 may employ some form of survival time technique (e.g., Cox proportional hazards and / or accelerated failure time) to predict the number of days from the index date to diagnosis of further conditions. The machine learning model 806 may be based on LightGBM or XGBoost as shown, or it may be based on NGBoost or some other gradient boosting technique that supports survival analysis. In alternative embodiments, the machine learning model 806 may be based at least in part on an artificial neural network, an expert system, or some integrated combination of any of these or other models.

[0120] The machine learning model 806 may generate a prediction 508 for each patient, which may indicate whether the condition is expected to be observed and the amount of data between the index date and the time when the condition is expected to be observed.

[0121] The data used to train and validate the machine learning model 806 can come from a variety of sources, including hospitals, health care providers, clinical sources, and / or insurance claims. For example, the machine learning model 806 can be trained on insurance claims data, as that data can include demographics, vital signs, and blood test results for patients with and without portal hypertension and / or cirrhosis. The training data can be preprocessed in various ways, for example, to remove outliers, de-skew, and / or normalize.

[0122] The trained machine learning model 806 can then be validated on clinical data to determine how well it accurately predicts the progression of portal hypertension in patients. Once validated, the machine learning model 806 can be applied to identify patients in the hospital or using hospital services who are candidates for further testing, treatment, or inclusion in clinical trials.

[0123] In some cases, training data may be collected from multiple geographic regions. However, the data may be segmented by region to develop region-specific models. In some cases, information from identified patients may be checked for novelty—e.g., whether the input variables for these patients are consistent with the input variables in the training data. To this end, a similarity model may be applied to the information from the identified patients as well as the training data, with different patients identified for further processing before finalizing the prediction. This may be helpful if the machine learning model is trained on data from one population of individuals (e.g., located in North America) but applied to another population of individuals (e.g., located in Europe). V. Experimental Results

[0124] The embodiments herein are applied to training data, including a cohort of 10429 patients matching inclusion and exclusion criteria, of which 41% of these patients have observed severe conditions. The median progression time of these patients is 190 days. Patient data are collected from the Optum Clinformatics Data Mart (Optum) data set (de-identified U.S. electronic health records, 2007-2021). The risk rate of progression is modeled using a machine learning survival time model that is robust to sparse data. Model performance is evaluated using 3-fold cross validation of the cumulative dynamic area under the curve (AUC), and compared with four established liver disease scores (fib-4, ALBI, PALBI, and MELD) and patient age as baselines.

[0125] The AUC metric can be based on a receiver operating characteristic (ROC) curve or a precision-recall curve generated from the model results. The ROC curve plots the true positive rate (the number of true positives divided by the sum of true positives and false negatives) of the model relative to the false positive rate (the number of false positives divided by the sum of false positives and true negatives). The ROC curve intuitively describes the trade-off between the true positive rate and the false positive rate. One measure of model quality is the AUC of the ROC curve. This value is usually between 0.5 and 1.0, with higher values ​​indicating better model performance across various parameter settings. The precision-recall curve plots the precision (the number of true positives divided by the sum of true positives and false positives) of the model versus the recall rate (the number of true positives divided by the sum of true positives and false negatives). Similarly, AUC can be used to assess model quality, with higher values ​​indicating higher quality.

[0126] Fig. 9 Describe the evaluation of the model in the figure using a general model that predicts progression to any condition of the condition. As shown, the embodiments herein produce models that are superior to all of the fib-4, ALBI, PALBI, and MELD technologies at least in their ability to predict disease progression in patients with portal hypertension. As a baseline for comparison, age is also used as a predictor, which results in an AUC of 0.49, no better than random guessing.

[0127] Thus, the prediction model described herein provides an improvement in AUC compared to conventional techniques for predicting portal hypertension progression. The model also performs well on partially observed data, and the condition-specific model can differentiate progression risk by individual comorbidities, which is an improvement over existing techniques. VI. Deployment Scenarios

[0128] Embodiments herein can be deployed in a variety of arrangements. With respect to the training of one or more machine learning models, this can occur on one or more computing devices within a server cluster, such as in a public cloud network (e.g., Amazon AWS or Microsoft Azure) or on a private system. With respect to executing these models on new observations, these models can be hosted in different locations and environments.

[0129] In one possible example, the trained model can be hosted on a public cloud network or a private network and provide results to a client device via a web or application interface. For example, a client device can transmit a request to a remotely hosted model, the request containing a set of new input variables including new observations. The model can take these as inputs and produce corresponding outputs, which are then transmitted to the client device in response to the request. These trained models can be operated by various entities (such as hospitals, hospital networks, doctors, doctor networks, universities, pharmaceutical companies, or some alliance of one or more of these to other entities).

[0130] Alternatively, the trained model can be packaged with a client application that can be downloaded and installed on a desktop, laptop, or mobile computing device. Thus, the client application will include a user interface that allows the user to enter or otherwise indicate input variables for a new observation. The client application then applies the new observation to the model and generates corresponding output that is displayed and / or stored by the client device. This scenario has the advantage that no real-time network connection is required for using the model.

[0131] In other alternatives, the trained model can be used to develop simple clinical prediction rules, such as decision trees, that health care providers can follow to predict portal hypertension progression and / or prognosis.

[0132] There may be other deployment scenarios. Therefore, the embodiments of this document are not limited to these scenarios. VII. Example Operation

[0133] Fig.10 and Fig.11 is a flow chart illustrating an example embodiment. Fig.10 and Fig.11 The operations shown may be performed by a computing system or computing device including a software application configured to perform any of the embodiments herein. Non-limiting examples of computing systems or computing devices include, for example, computing device 100 or server cluster 200. However, the operations may be performed by other types of devices or device subsystems. For example, the operations may be performed by a portable computer such as a laptop or tablet device.

[0134] Fig.10 and Fig.11 The embodiments of the present invention may be simplified by removing any one or more features shown therein. In addition, these embodiments may be combined with any of the features, aspects, and / or implementations previously described in the drawings or otherwise herein. Such embodiments may include instructions that can be executed by one or more processors of one or more computing devices of a system or virtual machine or container. For example, the instructions may take the form of software and / or hardware and / or firmware instructions. In an example embodiment, the instructions may be stored on a non-transitory computer-readable medium. When executed by one or more processors of one or more computing devices, the instructions may cause one or more computing devices to perform various operations of the embodiments.

[0135] In these embodiments, individuals diagnosed with portal hypertension and / or cirrhosis may include individuals diagnosed with compensated cirrhosis, individuals with compensated cirrhosis, or individuals exhibiting symptoms of compensated cirrhosis. Thus, the term "portal hypertension and / or cirrhosis" may include compensated cirrhosis without a specific diagnosis of portal hypertension.

[0136] Fig.10 Block 1000 of involves obtaining, by a computing system, a training data set, wherein the training data set comprises observations of corresponding demographic values, comorbidity values, vital sign values, blood test values, and / or disease progression values ​​for a plurality of individuals diagnosed with portal hypertension and / or cirrhosis.

[0137] Fig.10 Box 1002 involves applying, by a computing system, a machine learning trainer to a training data set, wherein the machine learning trainer generates a plurality of machine learning models, and wherein each of the machine learning models is configured to take as input a new observation of new demographic values, new comorbidity values, new vital sign values, and / or new blood test values ​​and provide a prediction of: (i) whether an individual diagnosed with portal hypertension and / or cirrhosis who exhibits the new observation is expected to exhibit a hazard ratio for progression to a corresponding condition associated with portal hypertension or cirrhosis, and / or (ii) a time period between the presentation of the new observation and a further diagnosis of the corresponding condition.

[0138] In some embodiments, the machine learning trainer also generates a further machine learning model that is configured to take as input the new observation and provide further predictions of: (i) whether the individual is expected to exhibit a further hazard ratio for progression to any condition associated with portal hypertension or cirrhosis, and / or (ii) a further time period between the presentation of the new observation and an additional diagnosis of any condition associated with portal hypertension or cirrhosis.

[0139] In some embodiments, the disease progression value for a particular individual among the plurality of individuals comprises an index date and one or more results, and wherein each of the one or more results indicates a particular condition and an observed time period between its index date and a diagnosis of the particular condition.

[0140] In some embodiments, the disease progression value also includes one or more additional results, wherein each of the one or more additional results indicates an unknown condition and an additional observed time period between the index date and when the unknown condition was identified. For example, in a patient with varicose veins, the bleeding status of the condition may be unknown.

[0141] In some embodiments, in the disease progression values ​​for the plurality of individuals, there are at least six months of vital sign values ​​or blood test values ​​prior to the index date.

[0142] In some embodiments, the specific condition is one of varicose veins, variceal bleeding, recurrent variceal bleeding, ascites, refractory ascites, hepatic encephalopathy, recurrent hepatic encephalopathy, portosystemic shunt, or jaundice.

[0143] In some embodiments, the demographic values ​​include age, gender, race, or ethnicity of the plurality of individuals.

[0144] In some embodiments, the vital sign values ​​include body mass index, blood pressure readings, or heart rate for the plurality of individuals.

[0145] In some embodiments, the comorbidity value includes an indication of diabetes or obesity.

[0146] In some embodiments, the values ​​in the training data set are padded between 20% and 60%.

[0147] In some embodiments, the machine learning model is based on gradient boosting.

[0148] In some embodiments, the machine learning model is based on gradient boosting and survival time analysis.

[0149] In some embodiments, the training dataset includes at least 10,000 observations collected from medical claims records or electronic health records.

[0150] In some embodiments, the hazard ratio is provided as a Boolean indication of progression to the corresponding condition (e.g., the hazard ratio can be thresholded to a "true" value indicating that progression to the corresponding condition is predicted or a "false" value indicating that progression to the corresponding condition is not predicted).

[0151] In some embodiments, the observations in the training data set also include indications of medications, prescriptions, or treatments associated with the plurality of individuals, wherein the new observation also includes indications of medications, prescriptions, and / or treatments associated with the individuals.

[0152] Fig.11 Block 1100 involves obtaining, by a computing system, an observation of demographic values ​​for an individual, comorbidity values ​​for an individual, vital sign values ​​for an individual, and / or blood test values ​​for an individual, wherein the individual is diagnosed with portal hypertension and / or cirrhosis.

[0153] Fig.11Box 1102 involves applying, by a computing system, a machine learning model to an observation, wherein the machine learning model is trained with a training data set, wherein the training data set comprises observations of corresponding demographic values, comorbidity values, vital sign values, blood test values, and / or disease progression values ​​for a plurality of individuals diagnosed with portal hypertension and / or cirrhosis, and wherein the machine learning model is configured to provide a prediction of: (i) a hazard ratio for whether the individual is expected to exhibit progression to a condition associated with portal hypertension or cirrhosis, and / or (ii) a time period between an observed presentation and further diagnosis of the condition.

[0154] Fig.11 Block 1104 involves providing, by the computing system, a prediction based on the observation.

[0155] Some embodiments may further involve applying, by a computing system, a second machine learning model to an observation, wherein the second machine learning model is trained using at least a portion of a training dataset, and wherein the second machine learning model is configured to provide a second prediction of: (i) whether the individual is expected to exhibit a second hazard ratio for progression to a second condition associated with portal hypertension or cirrhosis, and / or (ii) a second time period between presentation of the observation and a second further diagnosis of the second condition; and providing, by the computing system, the second prediction based on the observation.

[0156] Some embodiments may also involve applying, by the computing system, a further machine learning model to the observation, wherein the further machine learning model is trained with at least a portion of the training data set, and wherein the further machine learning model is configured to provide a further prediction of: (i) whether the individual is expected to exhibit a further risk ratio for progression to any condition associated with portal hypertension or cirrhosis, and / or (ii) a further time period between the observed presentation and a further diagnosis of any condition associated with portal hypertension or cirrhosis; and providing the further prediction by the computing system based on the observation.

[0157] In some embodiments, providing the prediction includes displaying the prediction on a graphical user interface.

[0158] In some embodiments, obtaining the observations includes receiving the observations from a client device in communication with the computing system over a network, and wherein providing the predictions includes transmitting the predictions to the client device.

[0159] In some embodiments, the disease progression value for a particular individual among the plurality of individuals comprises an index date and one or more results, wherein each of the one or more results indicates a particular condition and an observed time period between its index date and a diagnosis of the particular condition.

[0160] In some embodiments, the disease progression value further includes one or more additional results, wherein each of the one or more additional results indicates an unknown condition and an additional observed time period between the index date and when the unknown condition was identified.

[0161] In some embodiments, among the disease progression values ​​for the plurality of individuals, there are at least six months of vital sign values ​​or blood test values ​​prior to the index date.

[0162] In some embodiments, the specific condition is one of varicose veins, variceal bleeding, recurrent variceal bleeding, ascites, refractory ascites, hepatic encephalopathy, recurrent hepatic encephalopathy, portosystemic shunt, or jaundice.

[0163] In some embodiments, the demographic values ​​include age, gender, race, or ethnicity of the plurality of individuals.

[0164] In some embodiments, the vital sign values ​​include body mass index, blood pressure readings, or heart rate for the plurality of individuals.

[0165] In some embodiments, the comorbidity value includes an indication of diabetes or obesity.

[0166] In some embodiments, the values ​​in the training data set are padded between 20% and 60%.

[0167] In some embodiments, the machine learning model is based on gradient boosting.

[0168] In some embodiments, the machine learning model is based on gradient boosting and survival time analysis.

[0169] In some embodiments, the training dataset includes at least 10,000 observations collected from medical claims records or electronic health records.

[0170] In some embodiments, the hazard ratio is provided as a Boolean indication of progression to the corresponding condition (e.g., the hazard ratio can be thresholded to a "true" value indicating that progression to the corresponding condition is predicted or a "false" value indicating that progression to the corresponding condition is not predicted).

[0171] In some embodiments, the observations in the training data set also include indications of medications, prescriptions, or treatments associated with the plurality of individuals, wherein the observations also include indications of medications, prescriptions, or treatments associated with the individuals. VIII. Conclusion

[0172] The present disclosure is not limited to the aspects of the specific embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its scope, which will be apparent to those skilled in the art. In addition to those described herein, functionally equivalent methods and devices within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims.

[0173] The above detailed description describes various features and operations of the disclosed systems, devices, and methods with reference to the accompanying drawings. The example embodiments described herein and in the accompanying drawings are not meant to be limiting. Other embodiments may be utilized and other changes may be made without departing from the scope of the subject matter presented herein. It will be readily understood that aspects of the present disclosure as generally described herein and shown in the accompanying drawings may be arranged, replaced, combined, separated, and designed in a variety of different configurations.

[0174] With respect to any or all of the message flow diagrams, scenarios, and flow charts in the accompanying drawings and as discussed herein, each step, box, and / or communication may represent information processing and / or information transmission according to the example embodiments. Alternative embodiments are included within the scope of these example embodiments. In these alternative embodiments, for example, the operations described as steps, boxes, transmissions, communications, requests, responses, and / or messages may be performed differently from the order shown or discussed, including substantially simultaneously or in reverse order, depending on the functionality involved. In addition, more or fewer boxes and / or operations may be used with any of the message flow diagrams, scenarios, and flow charts discussed herein. Figure 1 The message flow diagrams, scenarios and flowcharts may be used together, and these message flow diagrams, scenarios and flowcharts may be combined with each other in part or in whole.

[0175] The steps or boxes representing the processing of information may correspond to a circuit system that may be configured to perform a specific logical function of the method or technology described herein. Alternatively or additionally, the steps or boxes representing the processing of information may correspond to a module, segment, or portion of a program code (including associated data). The program code may include one or more instructions that can be executed by a processor to implement a specific logical operation or action in a method or technology. The program code and / or associated data may be stored on any type of computer-readable medium such as a storage device, including RAM, a disk drive, a solid-state drive, or other storage medium.

[0176] Computer-readable media may also include non-transitory computer-readable media, such as non-transitory computer-readable media that store data in a short period of time, such as register memory and processor cache. Non-transitory computer-readable media may also include non-transitory computer-readable media that store program code and / or data for a longer period of time. Therefore, non-transitory computer-readable media may include auxiliary or persistent long-term storage devices, such as ROM, optical or magnetic disks, solid-state drives, or compact disk read-only memories (CD-ROMs). Non-transitory computer-readable media may also be any other volatile or non-volatile storage system. For example, non-transitory computer-readable media may be considered to be computer-readable storage media or tangible storage devices.

[0177] In addition, the steps or boxes representing one or more information transfers may correspond to information transfers between software and / or hardware modules in the same physical device. However, other information transfers may be performed between software modules and / or hardware modules in different physical devices.

[0178] The particular arrangements shown in the accompanying drawings should not be considered restrictive. It should be understood that other embodiments may include more or less of each element shown in a given figure. In addition, some of the elements shown may be combined or omitted. Further, example embodiments may include elements not shown in the figures.

[0179] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope being indicated by the following claims.

Claims

1. A method comprising: obtaining, by a computing system, a training data set, wherein the training data set comprises observations of corresponding demographic values, comorbidity values, vital sign values, blood test values, or disease progression values ​​for a plurality of individuals diagnosed with portal hypertension or cirrhosis; and A machine learning trainer is applied by the computing system to the training data set, wherein the machine learning trainer generates a plurality of machine learning models, and wherein each of the machine learning models is configured to take as input a new observation of a new demographic value, a new comorbidity value, a new vital sign value, or a new blood test value and provide a prediction of: (i) whether an individual diagnosed with portal hypertension or cirrhosis who presents with the new observation is expected to present a hazard ratio for progression to a corresponding condition associated with portal hypertension or cirrhosis, or (ii) a time period between presentation of the new observation and further diagnosis of the corresponding condition.

2. The method according to claim 1, wherein: The machine learning trainer also generates a further machine learning model configured to take the new observation as input and provide a further prediction of: (i) whether the individual is expected to exhibit a further hazard ratio for progression to any condition associated with portal hypertension or cirrhosis, or (ii) a further time period between the presentation of the new observation and an additional diagnosis of any condition associated with portal hypertension or cirrhosis.

3. The method according to claim 1, wherein: The disease progression value for a particular individual among the plurality of individuals comprises an index date and one or more results, and wherein each of the one or more results indicates a particular condition and an observed time period between its index date and when the particular condition was diagnosed.

4. The method according to claim 3, wherein: The disease progression value also includes one or more additional results, and wherein each of the one or more additional results indicates an unknown condition and an additional observed time period between the index date and when the unknown condition was identified.

5. The method according to claim 3, wherein: In the disease progression values ​​for the plurality of individuals, there are at least six months of vital sign values ​​or blood test values ​​prior to the index date.

6. The method according to claim 3, wherein: The specific condition is one of varicose veins, varicose bleeding, recurrent varicose bleeding, ascites, refractory ascites, hepatic encephalopathy, recurrent hepatic encephalopathy, portosystemic shunt or jaundice.

7. The method according to claim 1, wherein: The demographic values ​​include age, gender, race or ethnicity of the plurality of individuals.

8. The method according to claim 1, wherein: The vital sign values ​​include body mass index, blood pressure readings, or heart rates of the plurality of individuals.

9. The method according to claim 1, wherein: The comorbidity values ​​include an indication of diabetes or obesity.

10. The method according to claim 1, wherein: The values ​​in the training data set are filled by 20%-60%.

11. The method according to claim 1, wherein: The machine learning model is based on gradient boosting.

12. The method according to claim 1, wherein: The machine learning model is based on gradient boosting and survival time analysis.

13. The method according to claim 1, wherein: The training dataset includes at least 10,000 observations collected from medical claims records or electronic health records.

14. The method according to claim 1, wherein: The hazard ratio is provided as a Boolean indication of progression to the corresponding condition.

15. The method according to claim 1, wherein: The observations in the training data set also include an indication of a medication, prescription, or treatment associated with the plurality of individuals, and wherein the new observation also includes an indication of a medication, prescription, or treatment associated with the individual.

16. An article of manufacture comprising a non-transitory computer-readable medium having program instructions stored thereon that, when executed by a computing system, cause the computing system to perform operations according to any one of claims 1-15.

17. A computing system comprising: one or more processors; as well as A memory containing program instructions that, when executed by the one or more processors, cause the computing system to perform operations according to any one of claims 1-15.

18. A method comprising: obtaining, by a computing system, observations of demographic values ​​of an individual, comorbidity values ​​of the individual, vital sign values ​​of the individual, or blood test values ​​of an individual, wherein the individual is diagnosed with portal hypertension or cirrhosis; applying, by the computing system, a machine learning model to the observation, wherein the machine learning model is trained using a training data set, wherein the training data set comprises observations of corresponding demographic values, comorbidity values, vital sign values, blood test values, or disease progression values ​​for a plurality of individuals diagnosed with portal hypertension or cirrhosis, and wherein the machine learning model is configured to provide a prediction of: (i) a hazard ratio for whether the individual is expected to exhibit progression to a condition associated with portal hypertension or cirrhosis, or (ii) a time period between presentation of the observation and further diagnosis of the condition; and The prediction is provided by the computing system based on the observation.

19. The method according to claim 18, further comprising: applying, by the computing system, a second machine learning model to the observation, wherein the second machine learning model is trained with at least a portion of the training data set, and wherein the second machine learning model is configured to provide a second prediction of: (i) whether the individual is expected to exhibit a second hazard ratio for progression to a second condition associated with portal hypertension or cirrhosis, or (ii) a second time period between presentation of the observation and a second further diagnosis of the second condition; as well as The second prediction is provided by the computing system based on the observation.

20. The method according to claim 19, further comprising: applying, by the computing system, a further machine learning model to the observation, wherein the further machine learning model is trained using at least a portion of the training data set, and wherein the further machine learning model is configured to provide a further prediction of: (i) whether the individual is expected to exhibit a further hazard ratio for progression to any condition associated with portal hypertension or cirrhosis, and (ii) a further time period between presentation of the observation and a further diagnosis of any condition associated with portal hypertension or cirrhosis; and The further prediction is provided by the computing system based on the observation.

21. The method according to claim 18, wherein: Providing the forecast includes displaying the forecast on a graphical user interface.

22. The method according to claim 18, wherein: Obtaining the observations includes receiving the observations from a client device in communication with the computing system over a network, and wherein providing the predictions includes transmitting the predictions to the client device.

23. The method according to claim 18, wherein: The disease progression value for a particular individual among the plurality of individuals comprises an index date and one or more results, and wherein each of the one or more results indicates a particular condition and an observed time period between its index date and when the particular condition was diagnosed.

24. The method according to claim 23, wherein: The disease progression value also includes one or more additional results, and wherein each of the one or more additional results indicates an unknown condition and an additional observed time period between the index date and when the unknown condition was identified.

25. The method according to claim 23, wherein: In the disease progression values ​​for the plurality of individuals, there are at least six months of vital sign values ​​or blood test values ​​prior to the index date.

26. The method of claim 23, wherein: The specific condition is one of varicose veins, varicose bleeding, recurrent varicose bleeding, ascites, refractory ascites, hepatic encephalopathy, recurrent hepatic encephalopathy, portosystemic shunt or jaundice.

27. The method according to claim 18, wherein: The demographic values ​​include age, gender, race or ethnicity of the plurality of individuals.

28. The method of claim 18, wherein: The vital sign values ​​include body mass index, blood pressure readings, or heart rates of the plurality of individuals.

29. The method of claim 18, wherein: The comorbidity values ​​include an indication of diabetes or obesity.

30. The method of claim 18, wherein: The values ​​in the training data set are filled by 20%-60%.

31. The method of claim 18, wherein: The machine learning model is based on gradient boosting.

32. The method of claim 18, wherein: The machine learning model is based on gradient boosting and survival time analysis.

33. The method of claim 18, wherein: The training dataset includes at least 10,000 observations collected from medical claims records or electronic health records.

34. The method of claim 18, wherein: The hazard ratio is provided as a Boolean indication of progression to the corresponding condition.

35. The method of claim 18, wherein: The observations in the training data set also include an indication of a medication, prescription, or treatment associated with the plurality of individuals, and wherein the new observation also includes an indication of a medication, prescription, or treatment associated with the individual.

36. An article comprising a non-transitory computer-readable medium having program instructions stored thereon that, when executed by a computing system, cause the computing system to perform operations according to any one of claims 18-35.

37. A computing system comprising: one or more processors; as well as A memory containing program instructions that, when executed by the one or more processors, cause the computing system to perform operations according to any one of claims 18-35.

Images