Patent Application
20220344018
The disclosed implementations relate generally to healthcare applications and more specifically to a method, system, and device for machine learning derived multimorbidity risk scores for healthcare.
Health assessments and clinical risk score calculations are an important part of primary clinical care and provide a snapshot of a patient's health status and health risks. In addition to health assessment tools, computable risk scores tools can be used to assess patient health status for specific conditions. Risk scores can help identify specific interventions to benefit patients, and provide actionable information to guide tests and medications. Multimorbidity risk scores, which factor in the presence of several chronic conditions, can provide insights into general morbidity and mortality. Examples of multimorbidity scores include the Charlson Index, Elixhauser Index, Adjusted Clinical Groups System, Chronic Disease Score, and the Duke Severity of Illness. In general, the number of co-occurring medical conditions is associated with increased adverse medical outcomes as well as the increased use of medical services. This is particularly true for older individuals since the number of co-occurring medical conditions will increase with age. Conventional methods that develop and assess the quality of risk scores, include condition-specific risk scores and multimorbidity scores that typically suffer from various limitations. For instance, the GRASP framework assesses risk scores based on the target population, internal or external validation, potential effects, and usability which vary widely across different scores. Aside from risk scores, several laboratory measurement-based risk models (using regression techniques and machine learning approaches) have been developed to predict the presence or severity of specific conditions. Obtaining a snapshot of patient health frequently involves integrating several different sources and thoroughly reviewing diagnostic, procedure, prescription, and laboratory data. This integration process is non-trivial: interpreting various disease-specific and diagnosis-derived multimorbidity risk scores can result in an incomplete, patchwork profile of a patient's health, and information can be missed during chart reviews. Currently, there is no unified, integrated risk score model that incorporates diagnostic, procedural, prescription, and laboratory data into a comprehensible single score or set of scores that reflects the clinical risk of an adverse outcome irrespective of age, and derived from a large, statistically-powered, representative population of patients.
Accordingly, there is a need for a total health profile, a set of machine-learning derived measures of an individual's comprehensive clinical risk. The total health profile presents clinical risk in five separate models (sometimes called “Component Scores”, or CS) producing risk-scores specific to cardiovascular (“heart score”), respiratory (“lung score”), neuropsychiatric (“neuro score”), renal (“kidney score”), and gastrointestinal (“digestive score”) conditions, according to some implementations. From these Component Scores, some implementations derive a total health score (sometimes called THS), a single, multimorbid, and unified view of a patient's overall health risks across the Component Scores. In some implementations, each of these six scores are independently modeled using medical claims data consisting of demographic information, diagnostic codes, laboratory results, prescriptions, and medical procedural data. Each scores' estimate of clinical risk represents the likelihood of score-related inpatient hospital visits over a future time period (e.g., the next 24 months). Inpatient visits are known to correlate with the number of morbidities and the general health of an individual. After training, testing, and calibrating the THS and the five organ-system specific CS, some implementations analyze the properties of each score and their intercorrelations for further tuning. Subsequently, some implementations post-process the THS and component scores to visualize data for easy interpretation and/or to inform patient care.
In one aspect, some implementations include a computer-implemented method of generating health care plans for patients. The method is executed at a computing device coupled to one or more memory units each operable to store at least one program. One or more servers having at least one processor communicatively coupled to the one or more memory units, in which the at least one program, when executed by the at least one processor, causes the at least one processor to perform the method.
The method includes extracting data items from age-agnostic medical claims data for a plurality of patients. The method also includes, for each organ-system-specific health condition of a plurality of organ-system-specific health conditions for a respective patient: (i) aggregating one or more of the data items into one or more feature sets based at least on a data item type and a set of rules, and (ii) applying one or more machine learning models to the one or more feature sets to predict a respective risk score for the respective health condition for a respective patient. In some implementations, the one or more machine learning models were previously trained by performing risk classification analysis on the data items from the age-agnostic medical claims data for the plurality of patients to calculate organ-system-specific risk score representing health risks for a specific organ-system. The method also includes computing a total health score based on the predicted respective risk score for each health condition for the respective patient. For example, the total health score is calculated independently from the predicted specific organ-system scores, and has the boolean sum of the labels of the predicted specific organ-system scores (sometimes called component scores or CS). For example, if the heart CS label is 1, the total health score (sometimes called THS) label will also be 1. In some implementations, the minimum of all CS scores is nearly equivalent to the THS, as the THS is supposed to reflect all risks.
The method also includes generating a report that indicates a health care plan for the respective patient based on the total health score in relation to a particular age group.
In some implementations, the respective risk score represents the likelihood of inpatient hospital visits over a predetermined future time period for the respective health condition.
In some implementations, the one or more machine learning models include a respective machine learning model for each health condition of the plurality of health conditions. The method further includes applying the respective machine learning model for the respective health condition to the one or more feature sets to predict the respective risk score for the respective health condition for a respective patient.
In some implementations, the plurality of health conditions includes cardiovascular, respiratory, neuropsychiatric, renal, and gastrointestinal conditions.
In some implementations, the medical claims data includes demographic information, diagnostic codes, laboratory results, prescriptions, and medical procedural data.
In some implementations, the one or more machine learning models include a respective gradient boosted classifier for each health condition. In some implementations, the method further includes aggregating the one or more of the data items into one or more feature sets further based on selecting a predetermined number of features of the respective gradient boosted classifier for the respective health condition. In some implementations, the predetermined number of features includes number of inpatient hospital visitations during the data-collection period.
In some implementations, the method further includes performing steps of inversion, scaling to 0-100, and normalization by age, on the respective score, for generating the report. In some implementations, the one or more machine learning models includes a gradient-boosted tree model that outputs calibrated likelihoods of an inpatient visitation between [0, 1], where 1 represents a 100% chance that a patient will have an inpatient visitation during a predetermined follow-up period, and wherein the inversion comprises subtracting the likelihood from 1, scaling includes multiplying result of the inversion by 100, and normalization by age includes calculating percentile amongst patients of a predetermined age group.
In some implementations, the method further includes calculating correlation between the respective score for each health condition and the total health score, while generating the report.
In some implementations, the one or more machine learning models include a gradient-boosted tree classifier that is trained using a training dataset that includes diagnoses, laboratory values, procedures, and prescription data as inputs and inpatient visits as binary labels, and calibrated using an isotonic regression with 3-fold cross-validation over the training dataset.
In some implementations, generating the report includes displaying the total health score and a breakdown of the total health score in terms of the respective score for each health condition, a comparison of the total health score of the respective patient to other patients in same age group as the respective patient, vitals, and/or data used to compute the total health score, in addition to a health care plan for alleviating at least some of the health conditions.
In another aspect, some implementations include a system configured to perform any of the methods described herein.
For a better understanding of the various described implementations, reference should be made to the Description of Implementations below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures.
heart, lung, neuro, kidney, digestive, and Total-Health risk scores.
Reference will now be made in detail to implementations, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the various described implementations. However, it will be apparent to one of ordinary skill in the art that the various described implementations may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the implementations.
It will also be understood that, although the terms first, second, etc. are, in some instances, used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first electronic device could be termed a second electronic device, and, similarly, a second electronic device could be termed a first electronic device, without departing from the scope of the various described implementations. The first electronic device and the second electronic device are both electronic devices, but they are not necessarily the same electronic device.
The terminology used in the description of the various described implementations herein is for the purpose of describing particular implementations only and is not intended to be limiting. As used in the description of the various described implementations and the appended claims, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “includes,” “including,” “comprises,” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
As used herein, the term “if” is, optionally, construed to mean “when” or “upon” or “in response to determining” or “in response to detecting” or “in accordance with a determination that,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” is, optionally, construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event]” or “in accordance with a determination that [a stated condition or event] is detected,” depending on the context.
As described above in the Summary section, there is a need for an automated, machine-learning-derived multi-morbidity risk profile for acute clinical events that can be used for individualized patient care management and patient education, at scale and continuously adjusted. This task is challenging because risk is an abstract concept, and there are no one good, ground-truth for calculating it. Some implementations determine which directly obtainable data sources would serve as the most useful proxies for comprehensive patient health and risk. In some implementations, as described below, this score is calculated automatically and at scale, without relying on clinician time/effort. Conventional scoring techniques, on the other hand, generally require patient behavior and/or familial history as input. In order to facilitate clinical decision making, as described below, some implementations create a profile that could be broken apart into organ-system-specific component scores, such as cardiovascular, respiratory, neuropsychiatric, renal, and gastrointestinal health. The profile is easily extended to include other organ systems.
Clinical risk scores are scalar values that measure a patients risk for a certain clinical outcome. Such scores have been used in clinical practice a long time, serving as useful ways for doctors to quickly ascertain patient risk for a certain condition (e.g., diabetes), procedural outcome (e.g., ER visit), and also as a healthcare education tool for patients to understand their own health status. Conventional risk scores, such as Framingham, are suboptimal for a variety of reasons. Multimorbidity is often extremely important when considering a patients risk for any single morbidity, but typical clinical risk scores usually only focus on one comorbidity. Of the multimorbidity scores that exist, they cannot be broken apart to reflect single-comorbidity risks. Moreover, these scores often overly rely on diagnoses or procedures (disregarding prescriptions and lab values), and often require behavior and familial history data, which can be difficult to collect when scaling risk scores to millions of patients. Finally, none of these scores claim to measure the abstract idea of general health.
In some implementations, the total health score is an interpretable, calibrated multimorbidity risk score that can be further broken down into cardiovascular, respiratory, neuropsychiatric, renal, and gastrointestinal risk scores. This allows the systems to comprehensively quantify patient health from their overall health to organ-system-specific health. In some implementations, the system calculates the scores passively and automatically using a machine-learning model trained on data from a patient's Electronic Health Record and requires no additional user input as to their behavior, familial history, and genetics.
Some implementations generate a clinical total health score and component organ scores. Some implementations group raw clinical data so as to get a data-driven aggregate view of health from the collection of a patient's clinical events, which is somewhat conceptually analogous in utility to generating a credit score from the collection of person's financial transactions. The total health score has additional advantages over a credit score in that a score of 80 (out of 100) is directly interpretable clinically (unlike a credit score of 720), and the score is designed in such a way that the actions necessary to improve a score are clear and follow clinical best practices.
Some implementations include an automated method to calculate the scores. Some implementations include a machine learning system that generates the scores and continuously monitors health data and processes the data, updating scores for individuals constantly and using more data when the data becomes available from each individual to generate more precise scores for every individual. In some implementations, every clinical visit would result in an updated score (though not an updated model). In some implementations, an updated model is generated once a year, and would largely just be composed of making a brand new model on the extra year's worth of data. In some implementations, the techniques described herein are extended to include additional types of data, such as data from sensors on wearables that track activity. Examples of such data include PPG signals, ECG signals, respiratory rate, and heart-rate. In some implementations, static variables, such as frequency or average amplitude, are derived from these bio-signals and then input into the models as extra variables. In some implementations, the system is also designed in a way that it can be extended to include additional organ systems or health components.
Some implementations split the risk scores into organ-system risk scores. Some implementations automatically collect healthcare information. Some implementations use manually input data or augmented data. Some implementations provide clinical guidelines alongside a risk score. Some implementations quantify health, rather than just the risk of developing a medical condition. Some implementations predict general health via risk of an inpatient hospital visit related to a medical condition. Unlike conventional systems that only provide the probability that a patient may develop Type 2 Diabetes in the next year, the total health score indicates how large an impact a patient's health conditions are likely to have on the patient's overall quality of life, and additionally provide how each part of the patients' health contributes to that impact (e.g., each component score is shown independently), and what the patient can do to improve health. The techniques described herein can be used to derive a unified multi-morbid set of clinical risk scores that cover most pathophysiologies, using tabular clinical information of a patient for its calculation, based on a configurable definition of what clinical risk means in a given context (e.g., a patient cohort, within a geographic region, in a demography, etc.), and provide an immediate clinical interpretation. Conventional clinical risk scores are specific to a single group of conditions, and combining the risk scores could potentially result in a patch-work understanding of patient health. Having a unified risk score of overall patient clinical risk, alongside condition-specific risk scores, is likely very useful for clinicians.
The distributions of the THS and the component scores among various age groups for healthy patients with no comorbidities and unhealthy patients with at least one Elixhauser comorbidity related to the given component, were plotted and analyzed as shown in
To further inspect the results of the models, the intercorrelations between the various model scores were calculated using Pearson's R (shown in
A simplified feature set was fit to the above discussed labels and otherwise identical models, in order to establish a baseline for all six scoring models. The simplified feature set is limited to binary Elixhauser comorbidities, filtered to only the relevant ones for a given component score model (mappings shown in
A sensitivity analysis was performed by calculating the model properties for specific age groups, namely young (under 27 years of age; table shown in
The AUC values were consistently high across all age groups, and decreased with age. The young group of patients showed AUCs between 0.761-0.848, adults 0.759-0.831, and seniors 0.733-0.810. Sensitivity increased with age (0.190-0.534 in youth, 0.578-0.694 in adults, and 0.914-0.984 in seniors) as well as calibration, while specificity decreased with age (0.934-0.996 in youth, 0.766-0.917 in adults, and 0.112-0.319 in seniors).
The top most important features (e.g., 10 or 15 features) of the gradient boosted classifiers for each score were selected, as shown in
Some implementations post-process the score to better meet principles of clear medical communication, via inversion, scaling to 0-100, and normalizing by age. This process is performed for each of the six scores. The distributions of the resulting scores for healthy (no inpatient visits) and unhealthy individuals (with at least one inpatient visit) were plotted as illustrated in
Some implementations obtain a snapshot of overall clinical risk, or total health profile, for a patient, via organ-system-specific risk scores (CS) (e.g., five organ-specific risk scores) and a single overall risk score (sometimes called total health score or THS), using a large set of representative patients.
Existing clinical risk scores play a vital role in health assessments and making decisions about patient management. While many EMRs have population health-based modules which can apply multiple risk scores, such as the Diabetes Risk Score or Framingham Risk score at the population level, obtaining a snapshot of a patient's complete health status would require integrating several risk scores that may not be applicable to specific patients (e.g., the CHADS2 stroke score in patients with chronic renal disease). The THS integrates diagnoses, prescriptions, procedures, and laboratory results to produce a single, scaled risk score together with organ-system Component Scores to provide a snapshot of health. This snapshot can be used for patients irrespective of age and does not require integrating several different risk scores. The score can be provided as a relative percentile on a scale from 0-100 with post-processing, making it more interpretable by patients and healthcare providers.
Although there are some limitations to the experimental study described above, these limitations are alleviated with longer or more diverse datasets or by ensuring that the data biases are not resulting in harmful model outputs. First, the population covered in the insurance claims database was drawn from zip codes that were disproportionately white, meaning that it may not be entirely representative of the US populations. Additionally, the follow-up period is two years which is shorter than the 5-10 year follow-up period of other clinical risk scores such as Framingham and the Diabetes Risk Score. Another limitation is that while the claims dataset used for this study includes populations on Medicaid and Medicare, they were likely dwarfed by those on employer plans. Thus, it is possible that the results presented here may not generalize to these likely underrepresented populations or uninsured patients. An additional potential limitation is the use of inpatient visits as a proxy for overall clinical risk. While this is a reasonable adverse health event to balance the models, due to it being positively correlated with a known indicator of unhealthiness (age) and being a tangible negative outcome patients would rather avoid, there are other options, such as a longer follow-up period with all-cause mortality as the outcome. Furthermore, the experiments assumed that the inpatient visit is related to the given Component Score, given the specified inclusion criteria. However, it should be noted that given the large and diverse cohort used in training the models, it is unlikely that this particular limitation skewed the THS and CS away from its core clinical purpose.
The results of this investigation suggest that the total health or total health score could serve as a useful, data-driven snapshot of health for healthcare professionals. Some implementations include new organ system component scores, use an expanded training set that includes more diverse populations, incorporate results from analyzing any distribution shift using more longitudinal data (e.g., using a follow-up period that is longer than two years), and/or include more forms of data (such as genomic or wearables data). Some implementations analyze the impact and potential actionability of the total health profile within care management, and introduce ways for the risk-scores to be directly actionable via therapeutics. For example, some implementations identify that the reason the heart risk score is poor is because the patient is suspected to be prediabetic. In the case that the patient receives treatment for that, some implementations adjust the score.
Some implementations use an administrative claims database (e.g., a claims database with 52 million patients provided by Anthem, an American healthcare insurance company) for a retrospective cohort study. Some implementations include patients of ages up to 90, who are enrolled in commercial, Medicare, Medicaid, and exchange plans with Anthem. Some implementations collect available diagnoses, medical procedures, prescriptions, and laboratory results from a time period (e.g., Jan. 1, 2016 through Dec. 31, 2019) for all patients who meet the selection criteria. Some implementations define a data collection period (e.g., Jan. 1, 2016 through Dec. 31, 2017), and a follow-up period (e.g., Jan. 1, 2018 through Dec. 31, 2019). Some implementations de-identify patient information by removing names, addresses, contact information, and claims identifier numbers.
Some implementations then extract diagnosis (in the form of International Classification of Disease (ICD-10) codes), medical procedures (using Current Procedural Terminology (CPT) codes), laboratory data (using Logical Observation Identifiers Names and Codes (LOINC) codes), and prescription data (derived from General Product Identifier (GPI) codes) for selected patients. In some implementations, patients who had at least one medical claim of any of these codes in each year during the time period (e.g., between 2016-2019), and had a known sex, birthdate, and zip code, are considered for inclusion in the study. Some implementations randomly select a group of patients (e.g., 992,868 patients) from the resulting patients (e.g., 14 million patients) to use as a cohort. Some implementations perform an 80:20 split on selected patients for training and testing. For example, 794,294 patients are placed in the training group and 198,574 patients are placed in in the testing group.
Referring back to
In some implementations, demographic information is extracted from a public database (e.g., the United States Census American Community Survey (ACS) for 2017) at the zip code level. In some implementations, this information includes population, household count, racial percentages for that zip code (such as African American, non-Hispanic White, Hispanic, Asian, Native American), sex percentages, and economic indicators including mean and median income. In some implementations, demographic data also includes the age and sex of the patient. In some implementations, chronic disease diagnoses are counted as the presence of a chronic disease, while acute diagnoses are counted as the number of those diagnoses in the study period, summed over the component (for instance, 3 atrial fibrillation codes and 2 acute heart failure codes during the two-year data collection period result in the number of acute heart diagnoses being 5). In some implementations, the presence of prescriptions is incorporated as binary values. In some implementations, four main groups of prescriptions were included: antihypertensives, hypoglycemics, lipid-lowering medications, and antithrombotic agents. In some implementations, laboratory data and physical measurements or vitals are included. An example list of all laboratory results or physiological measurements or vitals used in the calculation of each risk score is shown in
In some implementations, all demographic data and all labs or vitals are included as input features for the CS and THS model. In some implementations, for inpatient procedure features, only the IP visit count specific to the component (and the associated diagnostic inclusion criteria) are used as input to a given component model. For all other feature groups, features are stratified according to the model.
In some implementations, the set of input features used over all CS models are used as input for the THS model (with an exception for chronic diagnoses shown in
The presence of multiple health conditions is known to contribute to reductions in total health, reflected by functional decline and declines in the quality of life particularly in older adults, as measured by quality-adjusted life years (QALY), and can increase the risk of limitations in function. Additionally, these reductions in overall health are associated with increased hospital visits. Therefore, in some implementations, inpatient visits are selected together with diagnostic codes as a surrogate measure of overall risk, which reflects both the diagnosis of a condition and exacerbations of those conditions.
The CS label is a binary indicator referring to whether a patient had an inpatient visit within the follow-up period, given that they also had acute or chronic diagnoses within 12 months prior to the inpatient visit and within 7 days after the inpatient visit; establishing both a history of that condition and that the inpatient visit was (likely) related to that condition. In some implementations, these diagnoses are specific to each component, given by the Elixhauser comorbidities shown in the table in
In some implementations, scores are calculated using a gradient-boosted tree classifier, with default hyperparameters (e.g., using the Scikit-Learn Python 3.6 package (version 0.24.1)). In some implementations, using the diagnoses, laboratory values, procedures, and prescription data as inputs and inpatient visits as binary labels, separate models are trained for each score and subsequently calibrated using an isotonic regression with 3-fold cross-validation over the training set. In 3-fold cross-validation, the original sample is randomly partitioned into three equal sized subsamples. Subsequently, of the three subsamples, a single subsample is retained as the validation data for testing the model, and the remaining subsamples are used as training data. This cross-validation process is then repeated three times, with each of the three subsamples used exactly once as the validation data. The three results are averaged to produce a single estimation. In this way, some implementations use cross-validation during the calibration process to select which calibrator to use, as cross-validation gives a very robust estimation of accuracy levels. Some implementations obtain discriminative results from the models using the optimal threshold point of the training set (given by the threshold that yielded the smallest difference between the true-positive rate and the false-positive-rate) applied to the testing set. In some implementations, missing values are mean-imputed, and all input features for each model are mean-normalized using the training data.
Some implementations use, for a baseline model, a logistic regression model with default hyperparameters using the statsmodel package (version 0.12.0). In some implementations, the baseline model is a simplified version of the CS/THS models, using a smaller and/or less user-defined set of features and/or a less complicated model. In some implementations, the baseline model is used to assert the need for the larger set of features and a more complicated model. In some implementations, the feature inputs used for the baseline model are limited to Elixhauser Comorbidities, defined by the mapping of component score/THS shown in the table in
Some implementations use a different model, such as logistic regression, Support Vector Machine (SVM), or deep learning. Some implementations use similar labels as described above, but using a different set of ICD-10 codes for each condition as inclusion criteria. Some implementations use the same model or label as described above, but alter the exact feature inputs used in each risk score model.
To assess the discriminative performance of each model in the THS, an experiment was conducted to generate receiver-operator curves (ROCs) and calculate the area under the curve (AUC), sensitivity, specificity, positive predictive value (PPV), and negative predictive value (NPV) using scikit-learn for the test-set of 198,574 patients. The precision-recall curve was plotted for all scores on the test-set, as shown in
To perform sensitivity analysis of all of the models, patients were classified into three age ranges: youth (<27 years old), adults (27-64 years old inclusive), and senior (>64 years old), and quantitative discrimination and calibration metrics were calculated for each group. The distributions of the scores were plotted for healthy (no comorbidities) and unhealthy (1+ comorbidities) patients to assess expected trends. Finally, a correlation matrix between all predicted scores was created to analyze relationships, which was generated using Python Pandas (version 0.25.3).
Some implementations derive feature importances from the trained, gradient-boosted trees from their normalized Gini importance/information gain (e.g., using scikit-learn). Due to the isotonic calibration performed on the gradient boosted classifier and the cross-validation size of three, there are three different models with unique (but likely similar) feature rankings for each score prediction. In order to report a single set of ranks for a given model, some implementations average relative feature importance of each feature of these three models.
Score post-processing includes inversion, re-scaling, and normalization by age, according to some implementations. Outputs of the calibrated, gradient-boosted tree model represent calibrated likelihoods of an inpatient visitation from [0, 1], where 1 can be considered as a 100% chance that a patient will have an inpatient visitation during the follow-up period. For the inversion step, some implementations subtract the likelihood from 1. Some implementations multiply the resulting number by 100 to scale the number between 0 to 100. To normalize by age, the score is replaced by the percentile it is amongst patients of the same age-group (e.g., ages 0-10, 10-20). This processed value is interpreted as a patients percentile amongst those in a similar age-bucket, where higher value is better. A graphical representation of this process is shown in the right-side of
Some implementations use the total health score to assess patient risk, explain that risk to both patients and clinicians in an actionable manner, and allocate healthcare resources accordingly. Because the scores are calculated passively or ahead of time, clinicians or healthcare professions do not need to ask questions to patient at the time of service. Furthermore, the calculated scores or models are applicable for a vast general population of patients, and for different age groups.
As an example of the process of age score conversion, suppose a 33 year-olds patient's THS is 0.22, representing a calibrated probability of 22% of a patient having any of the predefined medical events in the next two years. Some implementations convert this score to 78. Subsequently, some implementations calculate the percentile of this patient against those in the same decade age-range as them (in this example, against patients between 30 and 40). Suppose further that this score of 78 directly translates to the 25th percentile of all other patients in the patient's age group, so the final THS score would be 25. In this light, the patient can be more easily informed that they are drastically unhealthy for their age group and take precautionary measures by looking at which of their component scores is causing the unhealth.
Although some of various drawings illustrate a number of logical stages in a particular order, stages that are not order dependent may be reordered and other stages may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be obvious to those of ordinary skill in the art, so the ordering and groupings presented herein are not an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.
The foregoing description, for purpose of explanation, has been described with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or to limit the scope of the claims to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The implementations were chosen in order to best explain the principles underlying the claims and their practical applications, to thereby enable others skilled in the art to best use the implementations with various modifications as are suited to the particular uses contemplated.
