Systems and methods for comorbidity disease progression monitoring

Abstract

Embodiments are described herein for automated tracking of disease progression with personalization for different cohorts or clusters of individuals and predictions of future progression with different treatment regimens. A dataset may be received related to individuals with a medical condition and a comorbidity. Training data may be extracted from the dataset for training a supervised learning model to classify individuals into a class of comorbidity progression. Correlations and / or the recommendations for treatment may be determined for different clusters or cohorts of individuals using an unsupervised learning model. Recommendations for treatment of the medical condition and / or the comorbidity may be based on the cluster or cohort with which an individual is associated.

Description

SYSTEMS AND METHODS FOR COMORBIDITY DISEASE PROGRESSIONMONITORINGBACKGROUND

[0001] A number of people are diagnosed with comorbidities after being diagnosed with a medical condition. For example, a person with diabetes (PwD) may be diagnosed with Type 2 diabetes and later diagnosed with one or more comorbidities, such as chronic kidney disease (CKD), neuropathy, retinopathy, or heart disease. Identifying and / or monitoring factors related to the progression of the comorbidity can be challenging. Additionally, methods of treatment to slow or cease the progression of the comorbidity can be difficult to identify. In many instances, the progression or types of treatment is often specific to the person, which can add layers of complexity to monitoring and / or treating comorbidities.SUMMARY

[0002] Embodiments are described herein for automated tracking of disease progression with personalization for different cohorts or clusters of individuals and predictions of future progression with different treatment regimens. Examples are described herein for providing correlations and / or recommendations for treatment related to at least one medical condition and / or at least one comorbidity. For example, supervised learning models may be trained for classifying individuals into comorbidity classes and correlations and / or recommendations for treatment may be provided based on the classification.

[0003] As described herein, one or more computing devices may be implemented for receiving a dataset related to a plurality of individuals with a medical condition and a comorbidity. Training data may be extracted from the dataset. The training data may be related to a subset of the plurality of individuals that developed the comorbidity at least a predefined period of time after being diagnosed with the medical condition. The training data may comprise data related to a plurality of features related to at least one of the medical condition or the comorbidity.

[0004] Based on the features of the training data related to at least one of the medical condition or the comorbidity, a supervised learning model may be trained to classify individuals into a class of progression of a plurality of classes of progression for developing the comorbidity.Each class of the plurality of classes of progression may have a different rate of progression for developing the comorbidity from the diagnosis of the medical condition. The plurality of classes of progression may comprise at least a high-risk class and a low-risk class.

[0005] For at least one class of the plurality of classes of progression, a correlation may be determined between at least one feature of the plurality of features related to the at least one of the medical condition or the comorbidity and the at least one class of progression for developing the comorbidity. At least one of the correlation or a recommendation for treatment related to the at least one of the at least one of the medical condition or the comorbidity may be output.

[0006] The correlation and / or the recommendation for treatment may be determined using an unsupervised learning model, such as a clustering model. The at least one feature may be input into the unsupervised learning model. The input into the unsupervised clustering model may comprise the at least one feature related to clinical data and drug-related information related to each of the plurality of individuals in the at least one class.

[0007] The medical condition may comprise a diabetic condition. The comorbidity may comprise at least one of chronic kidney disease, neuropathy, retinopathy, or heart disease. The at least one feature of the plurality of features may comprise at least one of genetic biomarkers, phenotype biomarkers, demographic information, natural language processing (NLP) translated healthcare provider (HCP) notes, contextual information, or other clinical, diagnostic, medial, or demographic information. The at least one feature may comprise a hemoglobin A1C (HbAlc) value, a creatinine value, an albumin value, a glucose value, an Estimated Glomerular Filtration Rate (EGFR) value, a body mass index (BMI) value, or an age at diagnosis of the medical condition. The drug-related information may comprise prescription data. The prescription data may be one-hot encoded before inputting the prescription data into the unsupervised clustering model.

[0008] A drug profile may be identified for the at least one class of the plurality of classes of progression. The drug profile may comprise at least one drug determined to slow the progression of the comorbidity in the at least one class of the plurality of classes. The recommendation for treatment related to the at least one of the at medical condition or the comorbidity is based on the drug profile.

[0009] The dataset is related to the plurality of individuals having the medical condition may include a plurality of comorbidities. The training data may be extracted and the supervised learning model may be trained for each comorbidity. The comorbidities may be prioritized. An indication may be output of the at least one comorbidity as the more critical comorbidity of the plurality of comorbidities. The indication may comprise a ranking of the plurality of comorbidities.

[0010] The trained supervised learning model may be implemented for classifying a comorbidity progression of an individual. An indication of a medical condition of the individual may be received. A value may be received for each of a plurality of features related to at least one of the medical condition or the individual. The values of data may be received in notes from a healthcare provider, for example. The value of each feature of the plurality of features may be input into the supervised learning model trained to classify the individual into a class of progression of a plurality of classes of progression for developing at least one comorbidity. Each class of the plurality of classes of progression having a different rate of progression for developing the comorbidity from the diagnosis of the medical condition. At least one of the class of progression or a recommendation for treatment related to the medical condition or the comorbidity may be output based on the class of progression identified for the individual.

[0011] The recommendation for treatment may be based on a correlation between the class of progression and the recommendation that is determined using an unsupervised clustering model. The data related to the plurality of features may be input into the unsupervised clustering model with drug-related information related to a plurality of individuals in the at least one class.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG. 1A is a perspective view of a representative system environment.

[0013] FIG. IB is a system flow diagram that illustrates a system that may be implemented to provide data indicating one or more classes of progression related to one or more comorbidities of the medical condition of a person and / or a recommendation for treatment related to the medical condition and / or the one or more comorbidities.

[0014] FIG. 2 is a graph illustrating a distribution of time between diagnosis of a comorbidity and a medical condition for different records of individuals in the dataset.

[0015] FIG. 3 A is a diagram illustrating a model and / or process that may be implemented on one or more computing devices to provide data indicating one or more classes of progression related to one or more comorbidities of the medical condition of a person and / or one or more correlations or recommendations for treatment.

[0016] FIG. 3B is a graph illustrating a period of time over which a subset of records is selected from records of clinical and / or drug-related data.

[0017] FIG. 3C is a table that shows example feature scores that may be generated by an algorithm for features identified in a hierarchical clustering model.

[0018] FIG. 3D is a diagram showing an example process for pre-processing records in a dataset to extract and format feature data for input as training data to the supervised learning model during training, as input data to the trained model during production and / or implementation, and / or as input data to the unsupervised learning model.

[0019] FIG. 3E include tables that include forms of treatment and corresponding one-hot encoded vectors that may be generated for being input into a learning model.

[0020] FIG. 3F includes a graph illustrating an example hierarchy of clusters of data generated by an unsupervised hierarchical clustering model.

[0021] FIG. 4 illustrates an example system environment and / or process for training and / or implementing a supervised learning model (e.g., Al and / or ML model).

[0022] FIG. 5 shows an example of an unsupervised learning model that may be implemented during unsupervised learning.

[0023] FIG. 6 shows a flowchart of an example process for training a model to predict a class of comorbidity progression for an individual and identifying correlations and / or forms of treatment for slowing the progression of the comorbidity.

[0024] FIG. 7 shows a flowchart of an example process for providing a predicted class of progression for one or more comorbidities of a medical condition of an individual and / or one or more recommendations for treatment.

[0025] FIGs. 8A-8F depict illustrations of an example graphical user interface for displaying example user interfaces for providing data to a user related to a medical condition and / or one or more comorbidities.

[0026] FIG. 9 is a block diagram of an example computing device.

[0027] FIG. 10 is a block diagram of an example continuous monitoring device.

[0028] FIG. 11 is a block diagram of an example blood glucose meter (BGM) device.DETAILED DESCRIPTION

[0029] FIG. 1A is a perspective view of a representative system environment. As shown in FIG. 1A, the system environment may include one or more computing devices configured to assist with treatment of one or more medical conditions of a person. For example, a person 100 may be a person with a medical condition, such as diabetes, another chronic progressive medical condition, or another medical condition. A non-limiting list of chronic progressive medical conditions may include neurodegenerative diseases, asthma, multiple sclerosis, heart disease, obesity, polycystic ovary syndrome, and / or chronic kidney disease. The system environment may include one or more computing devices, such as computing devices 122a, 122b, that may be implemented for collecting health-related data and providing information to assist in identifying and / or treating one or more medical conditions of the person 100.

[0030] As shown in FIG. 1A, the computing device 122b may be a computing device capable of being accessible by a healthcare provider (HCP), such as a doctor, a nurse, or another type of healthcare provider. The healthcare provider may input data into the computing device 122b that is related to the health of the person 100. The data related to the health of the person may include clinical data, diagnostic data, medical data, demographic data, and / or other data related to the person 100. For example, the data may be provided as healthcare provider notes to the system that are related to the health of the person. The diagnostic data may include data related to a medical condition of the person 100 and / or one or more comorbidities. The medical data may include one or more analyte levels measured for the person 100 and associated with one or more medical conditions. A comorbidity may be identified by the simultaneous presence of two or more diseases or medical conditions in the person 100.

[0031] The data related to the health of the person 100 may be provided to one or more subsystems implemented by the computing device 122b. For example, the data related to the health of the person 100 may be entered on one or more computing devices 122a via a healthcare provider subsystem 125 through which patient data may be recorded. The healthcare provider subsystem 125 may be implemented as hardware, software, or a combination of both hardware and software. The healthcare provider subsystem 125 may be in communication with and / or provide the data related to the health of the person 100 to other computing devices and / orsubsystems operating thereon, or store the data in a location accessible by other computing devices and / or subsystems operating thereon, for assisting with the treatment of the one or more medical conditions of the person 100.

[0032] In one example, the data related to the health of the person 100 may be provided to and / or accessed by a comorbidity progression monitoring subsystem 123. As shown in FIG. 1A, the comorbidity progression monitoring subsystem 123 may be implemented on one or more separate computing devices 122a from the one or more computing devices 122b of the healthcare provider subsystem 125 and / or on the same computing device(s) 122b as the healthcare provider subsystem 125. The comorbidity progression monitoring subsystem 123 may be implemented as hardware, software, or a combination of both hardware and software. The comorbidity progression monitoring subsystem 123 may share hardware and / or software resources with the healthcare provider subsystem 125. The comorbidity progression monitoring subsystem 123 and the healthcare provider subsystem 125 may be stored as computer-executable instructions in memory for being executed by one or more processors for operating, as described herein. For example, the comorbidity progression monitoring subsystem 123 may receive data related to the health of the patient, either directly or from the healthcare provider subsystem 125, and monitor / provide treatment for the progression of one or more comorbidities of the person 100. Additionally, though the comorbidity progression monitoring subsystem 123 and the healthcare provider subsystem 125 are provided as separate subsystems, they may be operated in the same subsystem.

[0033] The computing devices 122a, 122b may communicate directly with each other (e.g., via a wired or wireless communication link) or via a network 120. The network 120 may be a wired or wireless network capable of communicating via a wired or wireless communication protocol. The network 120 may be capable of communicating within a particular wireless communication band or frequency. For example, the network 120 may include a WI-FI® network, a cellular network, a WI-MAX® network, or another wireless network. The network 120 is used to communicate over the Internet to other devices.

[0034] The computing devices 122a, 122b may be capable of accessing one or more datastores 124 directly or via the network 120. For example, the computing devices 122a, 122b may store data in and / or retrieve data from one or more datastores 124. The datastores 124 may include one or more forms of memory, such as a non-removable memory (e.g., random -accessmemory (RAM), read-only memory (ROM), a hard disk, or any other type of non-removable memory storage) or a removable memory (e.g., a subscriber identity module (SIM) card, a memory stick, a memory card, or any other type of removable memory) configured to store data. The datastores 124 may include data from third-party sources. For example, the datastores may include one or more electronic health record (EHR) datasets accessible by the comorbidity progression monitoring subsystem 123 and / or the healthcare provider subsystem 125.

[0035] The person 100 may use one or more other devices to help monitor and / or treat their medical conditions. These devices may be configured to collect data related to the health of the person 100 for being provided to the healthcare provider subsystem 125 or the comorbidity progression monitoring subsystem, and / or stored in the one or more datastores 124. For example, the person 100 may use one or more devices to help monitor an analyte level and / or treat their medical conditions. In one example, the medical condition may include a diabetic condition. The diabetic condition may include a metabolic syndrome, pre-diabetes, type 1 diabetes, type 2 diabetes, and / or gestational diabetes. The person 100 may be in an extreme diabetic state, such as hypoglycemia or hyperglycemia, when the blood glucose level of the person 100 is above or below a threshold blood glucose level.

[0036] A glucose monitoring device may include any device that detects and reports a level of glucose in the blood of the person, either through direct measurement of the blood or through an indirect detection process. A blood glucose level is also referred to as a blood sugar level. Examples of glucose monitoring devices include, but are not strictly limited to, continuous glucose monitoring devices, flash glucose monitoring devices, and blood glucose meters that provide a single measurement of blood glucose levels from a blood sample in a “spot” monitoring process. A blood glucose treatment device may include any device that treats a diabetic condition of the person, either through direct treatment into the blood or through an indirect treatment process or by providing information to allow for treatment.

[0037] In some embodiments, the blood glucose monitoring device and / or blood glucose treatment device is a pen device 103. The pen device 103 may include any injector pen capable of monitoring and / or managing insulin delivery. Example pen devices may communicate with an external device, such as a mobile device 104 and / or a computing device 122a, 122b, to determine insulin levels, calculate doses, track doses, deliver insulin, and / or provide other information such as notifications or alerts. In some examples, pen devices may periodicallycommunicate data indicating the blood glucose levels of the person 100 to an external device, such as a mobile device 104, for computing or storing the blood glucose levels of the person 100.

[0038] In some embodiments, the glucose monitoring device is a continuous glucose monitor (CGM) 102. The CGM 102 includes a subcutaneous sensor that is used to sense and monitor the amount of glucose in interstitial fluid of the person 100. The CGM 102 includes a transmitting device that is located directly over the sensor that wirelessly powers the data transfer from the sensor. The CGM 102 periodically communicates data indicating the blood glucose levels of the person 100 to an external device, such as a mobile device 104, for computing or storing the blood glucose levels of the person 100.

[0039] Some embodiments of the mobile device 104 operate as a CGM controller device. Though the mobile device 104 is provided as an example of a device with which the CGM 102 communicates, the CGM 102 may communicate with other dedicated CGM controller devices for providing similar functionality that is described herein for the mobile device 104. In some cases, the CGM 102 processes the blood glucose data to provide an amount of glucose in interstitial fluid of the person 100. In some cases, the CGM 102 provides the blood glucose data to the mobile device 104 and / or pen device 103, and the mobile device 104 and / or pen device 103 processes the blood glucose data to manage the diabetic condition and provide treatment notifications.

[0040] In some embodiments, the blood glucose monitoring device is a flash glucose monitor (FGM) 111. The FGM 111 includes a subcutaneous sensor that is used to sense and monitor the amount of glucose in interstitial fluid of the person 100. A separate reader device, such as the mobile device 104, pen device 103, or another reader device, receives the blood glucose data from the sensor of the FGM 111 when the device is within range, such as but not limited to the RF range, of the sensor. The FGM 111 transmits an instantaneous blood glucose level or a graphical trend of the blood glucose level to the reader device for display. The mobile device 104 processes the blood glucose data to manage the diabetic condition and provide treatment notifications.

[0041] In some embodiments, the person 100 uses a blood glucose meter (BGM) 106 as a blood glucose monitoring device to monitor blood glucose levels. The BGM 106 includes a port 108 that receives a blood glucose measurement strip 110. The person 100 deposits a sample of blood on the blood glucose measurement strip 110. The BGM 106 analyzes the sample andmeasures the blood glucose level in the sample. The blood glucose level measured from the sample is displayed on a display 112 of the BGM 106 or communicated to an external device, such as the mobile device 104. The mobile device 104 processes the blood glucose data to manage the diabetic condition and provide treatment notifications.

[0042] The blood glucose level measured by the pen device 103 or BGM 106 or computed using data received from the CGM 102 or FGM 111, is used to treat the diabetic condition of the person 100. The mobile device 104 communicates with the CGM 102, FGM 111, the BGM 106, and / or pen device 103 using wired or wireless communications that are transmitted and received between devices on a wired or wireless communication medium. The mobile device 104 may also, or alternatively, receive data from a monitoring device (e.g., the CGM 102, FGM 111, the BGM 106, and / or pen device 103) indirectly via one or more other devices (e.g., a computing device 122a, 122b or another computing device). For example, a monitoring device may be capable of communicating data to one or more intermediate computing device for storing data thereon for being transmitted to and / or requested by the mobile device 104. The mobile device 104, the CGM 102, a CGM controller, the BGM 106, the FGM 111, or pen device 103 may be collectively referred to as user devices or computing devices. The mobile device 104 communicates with the CGM 102, the FGM 111, the BGM 106, and / or pen device 103 using the same or different wired or wireless protocols. For example, the mobile device 104 communicates with the CGM 102, FGM 111, the BGM 106, and / or pen device 103 using BLUETOOTH®, near field communication (NFC), THREAD®, WIFI®, ZIGBEE®, WI-MAX®, a cellular communication protocol, a proprietary wireless communication protocol, or another radio frequency (RF) communication protocol.

[0043] Though various blood glucose monitoring devices (e.g., pen device 103, CGM 102, BGM 106, FGM 111, and / or another blood glucose monitoring device) are provided as examples of analyte monitoring devices, other analyte monitoring devices may be implemented for measuring and / or monitoring other analyte levels of the person 100. For example, the person 100 may have a potassium condition or disorder, such as hypokalemia (e.g., a potassium deficiency in which a person has blood potassium levels below a predefined threshold) or hyperkalemia (e.g., a condition in which a person has blood potassium levels above a predefined threshold.) The person 100 may use a blood potassium monitoring device to monitor blood potassium levels. The person 100 may deposit a sample of blood in the blood potassiummonitoring device, which analyzes the sample and measure the blood potassium level in the sample. The blood potassium level measured from the sample may be communicated to an external device, such as the mobile device 104. The mobile device 104 may process the blood potassium data to manage the condition and provide treatment notifications as described herein. For example, the notifications may alert the person 100 to ingest potassium or diuretics, take medication, perform dialysis, and / or conduct another form of treatment. As described herein, while some analytes such as blood glucose levels may be monitored on a continuous or periodic (e.g., daily) basis, other analytes and looked at clinical variables, such as GFR and creatine levels, and potassium levels may be measured via a clinical test such as a blood or urine test, for example.

[0044] The mobile device 104 may communicate with other devices directly via a wired communication and / or a short-range wireless communication (e.g, WI-FI®, BLUETOOTH®, BLE, NFC, or another suitable short-range wireless communication). The mobile device 104 may communicate indirectly with computing device(s) 122a, 122b via a network 120 (e.g, using a WI-FI® network, a cellular network, a WLMAX® network, or another wired or wireless network).

[0045] The mobile device 104 may be a connected smart device and / or may be in communication with other connected smart devices. Example connected smart devices may include a wearable device. The connected smart device may be an armband (e.g., a smart watch, such as an APPLE® watch, a FITBIT® armband, or other device capable of being worn on the arm of the person 100), a ring, glasses (e.g., GOOGLE® GLASS™), a headset (e.g., BLUETOOTH® headset), clothing (e.g., shirts, gloves, etc. or another wearable device capable of being worn by the person 100. The connected smart device may be a wearable device or other device capable of monitoring the heart rate of the person 100, such as a heart rate monitor.

[0046] The mobile device 104 may provide information to the person 100 about the person’s medical condition. For example, the mobile device 104 may provide blood glucose levels, blood potassium levels, meal -related information, exercise-related information, treatment notifications, and / or graphs and other graphical user interfaces, such as alerts or notifications, for display. The mobile device 104 may provide therapeutic protocol data to the pen device 103. For example, the mobile device 104 may provide insulin dose levels for an associated medication titration event (e.g, basal insulin titration event) to the pen device 103. Havingreceived the insulin dose level, the pen device 103 may be configured to administer a corresponding amount of insulin.

[0047] As described herein, the healthcare provider subsystem 125 may display information to a healthcare provider that is related to the medical condition and / or one or more comorbidities of the person 100. The information may assist in treatment of the person’s medical condition and / or comorbidities. For example, as described herein, the healthcare provider subsystem 125 may provide information to the healthcare provider that identifies a class of progression of the one or more comorbidities related to the medical condition of the person 100. The healthcare provider subsystem 125 may output a correlation between the class of progression and one or more pieces of data related to the health of the person 100 that contribute to the selected class of progression. For example, the healthcare provider subsystem 125 may output a correlation between the class of progression and clinical data, diagnostic data, medical data, demographic data, and / or other data related to the person 100. The healthcare provider subsystem 125 may output a recommendation for treatment related to the medical condition and / or one or more comorbidities.

[0048] When managing and / or treating a medical condition, the existence of comorbidities adds another layer of challenges for healthcare providers and people with the medical condition. For example, for a person with diabetes, the person may develop other comorbidities that need to be managed, such as chronic kidney disease (CKD), neuropathy, retinopathy, and / or heart disease. Over 90% of people with diabetes have at least one other chronic condition identified as a comorbidity. Given the number of potential contributing factors to the development of one or more comorbidities, it is challenging to identify a class of progression associated with the comorbidity of a user and proper treatment to help slow the level of progression.

[0049] With the amount of data available through patient datasets, systems, methods, and apparatus are described herein for leveraging such data for developing a personalized action plan for assisting healthcare professionals and people with a medical condition with diagnosis and treatment of their medical condition and / or one or more comorbidities. For example, the use of data from datastores 124 that include data such as clinical data and / or drug-related data, such as EHR datasets, may be leveraged with one or more algorithms implemented by a comorbidity progression monitoring system 123 to identify features related to classes of comorbidityprogression and / or forms of treatment that can be provided to a healthcare provider and / or person with the medical condition.

[0050] FIG. IB is a system flow diagram that illustrates a system 150 that may be implemented to provide data indicating one or more classes of progression related to one or more comorbidities of the medical condition of a person and / or a recommendation for treatment related to the medical condition and / or the one or more comorbidities. The system 150 may be implemented for different medical conditions and / or comorbidities. For example, the system 150 may be implemented for generating classes of comorbidity progression for one or more comorbidities related to a diabetic condition.

[0051] As shown in FIG. IB, the comorbidity progression monitoring subsystem 123 may receive a dataset at 152 that comprises data related to individuals with the medical condition and one or more identified comorbidities. For example, the medical condition may be identified as a diabetic condition or another medical condition. The one or more comorbidities may be identified as being related to the identified medical condition, such as CKD, neuropathy, retinopathy, and / or heart disease related to the diabetic condition. The data may include clinical data and / or drug-related data. The clinical data may include a collection of data comprising electronic health records (EHRs) of a plurality of individuals. The clinical data may include diagnostic data, demographic data, genetic or epigenetic data, and / or other medical data related to individuals having the identified medical condition and / or one or more comorbidities.

[0052] The diagnostic data in the dataset 152 may identify a diagnosis of the identified medical condition and / or one or more comorbidities. For example, the diagnostic data may include the identified medical condition, such as a diabetic condition, and / or one or more comorbidities. The diagnostic data may indicate a date or other time at which each individual in the dataset was diagnosed with the medical condition and / or comorbidities. The diagnostic data may identify an age at which each individual in the dataset was diagnosed with the medical conditions and / or comorbidities.

[0053] The demographic data in the dataset may include population-based data, such as age, race, gender, and / or other demographic information of each of the individuals having the identified medical condition and / or one or more comorbidities in the dataset. The demographic data may include socioeconomic information expressed statistically, including employment,education, income, marriage rates, birth rates, death rates, and / or other socioeconomic information.

[0054] The other medical data in the clinical data in the dataset may identify measurable parameters related to the health of each individual in the dataset. For example, the medical data may identify a height, a weight, and / or one or more biomarkers. The biomarkers may include defined characteristics that are measured as an indicator of biological processes, pathogenic processes, and / or responses to exposures or intervention. The biomarkers may include genetic biomarkers or phenotype biomarkers. As examples, the biomarkers may include a blood pressure value, a body mass index (BMI) value, and / or one or more analyte levels. The analyte levels may include, a hemoglobin A1C (HbAlc) value, a creatinine value, an albumin value, a glucose value, an Estimated Glomerular Filtration Rate (EGFR) value, and / or another analyte level.

[0055] The other medical data in the clinical data in the dataset may identify a level of physical activity of each individual, data related to smoking and / or drinking habits or regularity of each individual in the dataset, and / or other information related to the health of the individuals. The other medical data in the clinical data in the dataset may identify exposures, such as exposures to radiation, laboratory tests and / or results, family relationships and / or clinical data associated with family members, and / or other clinical data.

[0056] The drug-related data in the dataset may identify one or more medications taken by each individual in the dataset. The drug-related data may identify a start and / or discontinuation date for which the medications have been prescribed, the drug name, drug class, strength, dosage, formulation, number of refills, and / or a time or regularity with which the medications have been taken. The drug-related data may be determined by filtering for drug classes that are intended to treat the medical conditions and / or comorbidities to reduce the large number of combinations of drug profiles.

[0057] Supervised learning models (e.g., Al and / or ML algorithms) may be trained on training data that includes data related to features for each class of comorbidity progression. Each class of comorbidity progression may have a different rate of progression of the one or more comorbidities. The training data may be generated from raw data selected from the dataset received at 152 by the comorbidity progression monitoring subsystem 123. The raw data may be preprocessed for training the supervised learning model.

[0058] As part of the preprocessing of the training data, the comorbidity progression monitoring subsystem 123 may identify a subset of records of individuals within a comorbidity diagnosis threshold at 153. The comorbidity diagnosis threshold may be a period of time within which the individuals within the dataset developed and / or were diagnosed with one or more identified comorbidities after being diagnosed with the medical condition.

[0059] The subset of records that are used for generating training data may comprise records within the comorbidity diagnosis threshold that also include each of the types of clinical data and / or drug -related data that correspond to features for training the Al and / or ML algorithms. For example, the subset of records that are used for generating training data may comprise records related to individuals in the dataset having each of, or at least a threshold number of, the types of clinical and / or drug-related data that correspond to the features that are used (e.g., as input) by the Al and / or ML algorithms. Some records may be missing data corresponding to one or more features that are used for training the Al and / or ML algorithms. For example, the features that are used for the Al and / or ML algorithms to classify progression of an individual’s comorbidity of CKD may include features related to multiple biomarkers, such as blood pressure values, BMI values, HbAlc values, creatinine values, albumin values, glucose values, EGFR values, and / or one or more other biomarker values. As the number of features increases, the number of records that include data corresponding to each of the features may be reduced. The comorbidity diagnosis threshold may be increased to gather more training data, particularly where the number of features is increased or where certain types of data is limited in the dataset. The training data may include data related to these features. The training data may also, or alternatively, include an age of the individuals at diagnosis.

[0060] The comorbidity progression monitoring subsystem 123 may identify a corresponding class of comorbidity progression for each of the records within the comorbidity diagnosis threshold at 154. The records of individuals identified at 153 as being within the comorbidity diagnosis threshold may be further segregated as separate training data for different classes of comorbidity progression. The comorbidity progression monitoring subsystem 123 may identify a number and / or identity of the classes of comorbidity progression at 154 for categorizing the records of individuals identified at 153 as being within the comorbidity diagnosis threshold. The number of classes of comorbidity progression may be predefined. Inone example, three classes may be defined, having class identifiers of “slow,” “medium,” and “fast.” However, other numbers of classes and / or class identifiers may be implemented.

[0061] The training data for each class of comorbidity progression may be further selected based on defined criteria. For example, the training data for each class of comorbidity progression may be based on the difference between date of diagnosis of the medical condition for an individual in the records and the development and diagnosis of the one or more comorbidities. The difference between the date of diagnosis of the medical condition and the development and diagnosis of the one or more comorbidities may be a number of years, such as two years, three years, four years, eight years, or another timeframe. In one example, when the comorbidity diagnosis threshold comprises a three year period, each of the classes of comorbidity progression (e.g., “slow,” “medium,” and “fast”) may be defined by a period of time or a percentage of the three-year period (e.g., “fast” progressors within one year, “medium” progressors between one and two years, and “slow” progressors between two and three years).

[0062] The distribution of time between diagnosis of an individual with a medical condition and one or more comorbidities may not be evenly distributed across the dataset using a defined period of time within the period of time set by the comorbidity diagnosis threshold. FIG. 2 is a graph 200 illustrating a distribution of time between diagnosis of a comorbidity and a medical condition for different records of individuals in the dataset. As illustrated in the graph 200 of FIG. 2, a larger number of individuals may be diagnosed with a given comorbidity within a shorter period of time than others. As a result, the training data for each class of comorbidity progression may be selected based on the difference between date of diagnosis of the medical condition and diagnosis of the one or more comorbidities, as well as the number of individuals or records within each class. For example, the number of individuals or records selected for training data for each class of comorbidity progression may be within a threshold of the number of individuals or records in each of the other classes.

[0063] Referring again to FIG. IB, at 156, the comorbidity progression monitoring subsystem 123 may determine one or more features in the clinical and / or drug-related data related to the comorbidity progression. Based on the data received in the dataset at 152, the comorbidity progression monitoring subsystem 123 may determine feature parameters for predicting different classes of comorbidity progression. The features may be predefined features related to types of clinical data and / or drug-related data for a given medical condition, one ormore comorbidities, and / or demographic. The comorbidity progression monitoring subsystem 123 may additionally, or alternatively, identify features related to the classes of comorbidity progression using one or more algorithms configured to identify features related to the one or more comorbidities based on the data in the dataset. In one example, the algorithms may include artificial intelligence (Al) and / or machine learning (ML) algorithms, such as unsupervised learning algorithms, configured to cluster data by features that relate to different groups of individuals. As the Al and / or ML algorithms may be identifying features of different classes, the Al and / or ML algorithms may include a supervised classifier.

[0064] The feature parameters (e.g., weights and / or coefficients) may be learned using the one or more Al and / or ML algorithms. The one or more Al and / or ML algorithms may include a supervised learning model. For example, the comorbidity progression monitoring subsystem 123 may be implemented to train a supervised learning model using the training data for each class of comorbidity progression to learn the feature parameters for each comorbidity progression class. A target value may be set for training a supervised classifier for each comorbidity progression class based on the training data identified for the comorbidity progression class. For example, the target value may be set to the latest, mean, or average difference between the date of diagnosis of the medical condition and diagnosis of the one or more comorbidities for the records in the training data. The test subject or the patient using this model need not be diagnosed or suffering from the comorbidity, and the target value for such patient may be decided on the time between date of diagnosis of the chronic disease and the date of visit at the HCP office for evaluation. During the supervised training, the feature parameters for classification in a given comorbidity progression class may be modified by parameters, such as weights or coefficients. These weights and coefficients, which may also be referred to as hyperparameters, may be stored in the memory of the comorbidity progression monitoring subsystem 123, and which may be used to save time on training. For example, the weights, coefficients, and / or other parameters of the trained classifier may be stored to identify and classify comorbidity progression of individuals by the comorbidity progression monitoring subsystem 123 in production on input data. The relevance of each of the features may be defined for the development of the comorbidity from the diagnosis of the medical condition.

[0065] At 157, the comorbidity progression monitoring subsystem 123 may determine correlations between individuals in different classes of comorbidity progression and / or forms oftreatment for slowing comorbidity progression. The correlations and / or forms of treatment may be determined using the one or more Al and / or ML algorithms. The one or more Al and / or ML algorithms may include an unsupervised clustering model to identify clusters of records across the classes of comorbidity progression. The results of each cluster may be analyzed and correlations and / or forms of treatment may be identified between comorbidity progression classes with a slower rate of progression and comorbidity progression classes with higher rate of progression. The correlations and / or forms of treatment may be determined automatically by the comorbidity progression monitoring subsystem 123 or may be received by the comorbidity progression monitoring subsystem 123 as input based on the results of the clustering.

[0066] The correlations and / or forms of treatment may be determined based on a value difference between features in records having different classes of comorbidity progression, but that are in the same data cluster. Records for individuals may be in the same cluster that are classified in different comorbidity progression classes (e.g., classified as having a low -risk or “slow” comorbidity progression and a high-risk or “fast” comorbidity progression) may include feature values that identify correlations and / or forms of treatment that may be recommended for slowing comorbidity progression. A comparison of the records in different comorbidity progression classes (e.g., the low-risk or “slow” comorbidity progression class and the high-risk or “fast” comorbidity progression class) in the same cluster may indicate that the individuals in the records, or a threshold number of records, in one comorbidity progression class (e.g., the high-risk or “fast” comorbidity progression class) are taking a different form of medication than the individuals in the records in another comorbidity progression class (e.g., the low -risk or “slow” comorbidity progression class). The comparison of the records in different comorbidity progression classes (e.g., the low-risk or “slow” and high-risk or “fast” comorbidity progression classes) in the same cluster may indicate that the individuals in the records, or a threshold number of records, in one comorbidity progression class (e.g., the high-risk or “fast” comorbidity progression class) may not be taking a medication that has been taken by the individuals in the records in another comorbidity progression class (e.g., the low-risk or “slow” comorbidity progression class), or that a dosage of the medication may be increased. The comparison of the records in different comorbidity progression classes (e.g., the low-risk or “slow” and high-risk or “fast” comorbidity progression classes) in the same cluster may indicate that the individuals in the records, or a threshold number of records, in one comorbidity progression class (e.g., thehigh-risk or “fast” comorbidity progression class) may have a biomarker value (e.g, a blood pressure value) or another clinical data value that is a threshold greater than the individuals in the records in another comorbidity progression class (e.g, the low-risk or “slow” comorbidity progression class). As such, a treatment of the identified biomarker or other medical condition or disease may be recommended. The correlation and / or form of treatment may be stored and / or output to a user.

[0067] The correlations and / or forms of treatment may be stored in a drug profile for a given cohort or cluster of individuals. For example, each cohort or cluster of records for individuals may be associated with a drug profile having at least one drug that is determined to slow the progression of comorbidity. In another example, each group of individuals within a class of progression may be associated with a drug profile having at least one drug that is determined to slow the progression of the comorbidity. A relatively lower risk comorbidity progression class (e.g, low-risk or “slow” comorbidity progression class) may have a component of drug profile (e.g, identified drug or form of treatment) that contributes to a rate of progression, which may be assigned to the drug profile for the cohort of cluster of individuals. For example, the drug profile may include at least one recommendation of one or more drugs that have the most effective incremental change (e.g., addition, subtraction, or substitution) from a current drug list of an individual.

[0068] At 158, the comorbidity progression monitoring subsystem 123 may receive data related to one or more particular individuals (e.g., patients) for identifying an existence of a comorbidity and / or a comorbidity progression. The data may be related to the health of the individual. The data may be received from a healthcare provider subsystem 125. For example, the data may be provided as healthcare provider notes to the system that are related to the health of the individual. The data may be provided via an analyte monitoring device, such as a glucose monitoring device and / or another type of analyte monitoring device, as described herein.

[0069] The data related to the individual that is received by the comorbidity progression monitoring subsystem 123 at 158 may identify a medical condition of the individual. For example, the medical condition may be identified as a diabetic condition or another medical condition. The one or more comorbidities may be identified in the data, or may be identified by the comorbidity progression monitoring subsystem 123 based on other data that is provided. The one or more comorbidities may be identified as being related to the identified medical condition,such as CKD, neuropathy, retinopathy, and / or heart disease related to the diabetic condition. The data that is received by the comorbidity progression monitoring subsystem 123 at 158 may include clinical data and / or drug-related data, as described herein, that is specific to the individual. The data may include one or more portions of the clinical data and / or drug related data that may be implemented by the comorbidity progression monitoring subsystem 123 to identify the existence of the comorbidity and / or the comorbidity progression. For example, the data related to the individual that is received by the comorbidity progression monitoring subsystem 123 at 158 may include the clinical data and / or drug-related data corresponding to one or more features that are input into the Al and / or ML model (e.g., the trained classifier) implemented by the comorbidity progression monitoring subsystem 123. The classifier may be trained with data missing from one or more of the features, or may include data for each of the features. When the classifier is trained with data missing from one or more of the features, it may be able to better handle missing data in implementation, which may occur due to the data being non-uniform or non-standardized.

[0070] The comorbidity progression monitoring subsystem 123 may use the data related to the particular individual and input the data into the one or more Al and / or ML models for identifying the existence of a comorbidity and / or a comorbidity progression. For example, based on the values of the clinical data that is input into the comorbidity progression monitoring subsystem 123, a trained classifier may predict a likelihood of development of one or more comorbidities of a medical condition of an individual and / or classify the individual as being in a particular comorbidity progression class (e.g., based on a predicted a date at which the individual may develop and / or be diagnosed with a comorbidity).

[0071] At 160, the comorbidity monitoring subsystem 123 may provide data related to the comorbidity progression and / or forms of treatment. For example, the comorbidity monitoring subsystem 123 may identify one or more correlations and / or forms of treatment for a cohort or cluster of records related to the individual and provide the correlations and / or forms of treatment as output. In one example, the individual may be classified as being in a high-risk comorbidity progression class and the comorbidity monitoring subsystem 123 may retrieve the correlations and / or forms of treatment may that are stored in a drug profile for the high-risk comorbidity progression class for the given medical condition and comorbidity.

[0072] FIG. 3 A is a diagram illustrating a model and / or process 300 that may be implemented on one or more computing devices to provide data indicating one or more classes of progression related to one or more comorbidities of the medical condition of a person and / or one or more correlations or recommendations for treatment. For example, the model and / or process 300 may be implemented by one or more subsystems, such as the comorbidity progression monitoring subsystem 123 shown in FIG. IB, operating in computer-executable instructions on one or more computing devices. The model and / or process 300 may be implemented for different medical conditions and / or comorbidities. In one example, the model and / or process 300 may be implemented for generating classes of comorbidity progression for one or more comorbidities related to a diabetic condition.

[0073] As shown in FIG. 3 A, the model and / or process 300 may implement supervised learning using one or more supervised learning models 309. The supervised learning model 309 may be an Al and / or ML model that may include model data and one or more algorithms and / or functions trained to predict a likelihood of development of one or more comorbidities of a medical condition of an individual and / or a class of comorbidity progression as output. Supervised learning may be implemented for various types of AI / ML models, including algorithms that implement non-linear classification, logistic regression, neural networks (NNs), decision trees, Bayesian logics, random forests, and / or support vector machines (SVMs). NNs and Deep NNs (DNNs) are popular examples of algorithms utilized in Al and / or ML models that may be trained using supervised learning. An example of the supervised learning model 309 described herein includes a classifier trained on training data extracted from a dataset 305 to predict a likelihood of development of one or more comorbidities of a medical condition of an individual and / or a class of comorbidity progression for one or more comorbidities of a medical condition of an individual. A classifier may perform classification as a form of pattern recognition. However, other model types may be similarly implemented, as described herein. The supervised learning model 309 may be trained on the data in the dataset 305 to classify individuals as having a comorbidity and / or being in a certain comorbidity progression class at 310.

[0074] As shown in FIG. 3 A, the model and / or process 300 may also, or alternatively, implement unsupervised learning using one or more unsupervised learning models 311. The unsupervised learning model 311 may be an Al and / or ML model that may include one or morealgorithms and / or functions that receive data from the dataset 305 and assist in identifying correlations between records of individuals in different classes of comorbidity progression and / or forms of treatment for slowing comorbidity progression. The algorithms of the unsupervised learning model 311 may be implemented in a separate model or the same model as the algorithms of the supervised learning model 309 that are used for predicting the likelihood of development of the one or more comorbidities of the medical condition of individuals and / or the class of comorbidity progression. Unsupervised learning may be implemented utilizing Al and / or ML models or algorithms that learn from input data without being trained toward a particular target output. The unsupervised learning model 311 may include algorithms configured for identifying patterns, groupings, clusters, anomalies, and / or similarities or other associations in the input data. For example, the unsupervised learning models 311 may implement hierarchical clustering algorithms, k-means clustering algorithms, k nearest neighbors (K-NN) algorithms, anomaly detection algorithms, principal component analysis algorithms, and / or apriori algorithms.

[0075] The unsupervised learning model 311 may receive data from the dataset 305 and determine patterns or similarities for groups of records in the dataset 305. These groups of records may be identified as clusters of similar records at 313 via a clustering algorithm, such as a hierarchical clustering algorithm or a k-means clustering algorithm, for example. The hierarchical clustering algorithm may group features and / or data into a tree of clusters.However, other forms of unsupervised learning models may be similarly implemented. The clusters may be further analyzed at 315 to identify correlations and / or forms of treatment.

[0076] As shown in FIG. 3A, the supervised learning model 309 may be trained on data from the same dataset 305 as is used for being input into the unsupervised learning model 311 for performing the clustering of records at 313. The dataset 305 may include a subset of data that is extracted from a larger dataset, such as an EHR dataset, that may include clinical data and / or drug-related data. The dataset 305 may be preprocessed for training the supervised learning model 309 and / or being input into the unsupervised learning model 311. The dataset 305 may include a subset of data that is extracted from a larger dataset based on the difference between the date of diagnosis of the medical condition for the individuals in the records and the development and diagnosis of the one or more comorbidities of the individuals in the records. The number of years between the date of diagnosis of the medical condition and the developmentor diagnosis of the one or more comorbidities may be based on a comorbidity diagnosis threshold.

[0077] Different datasets 305 may be generated and used as training data for the supervised learning model 309 and / or input into the unsupervised learning model 311 to provide better correlations and / or treatment recommendations for different cohorts. The comorbidity diagnosis threshold may be adjusted to allow for different subsets of data 305 to be used for training the supervised classification model 309 for classification of comorbidity progression and / or for being input into the unsupervised clustering model 311 for identifying correlations and / or forms of treatment across records of individuals in different classes. For example, the comorbidity diagnosis threshold may be set to two years, three years, four years, eight years, or another timeframe. The use of different datasets 305 comprising different periods of time between the diagnosis of the medical condition and the comorbidity may allow the supervised learning model 309, or different supervised learning models, to be trained on data that is closer to the data received on a specific individual for better predicting the likelihood of development of the comorbidity and / or the class of comorbidity of an individual. The use of different datasets 305 comprising different periods of time between the diagnosis of the medical condition and the comorbidity may allow the unsupervised learning model 311 to identify correlations and / or forms of treatment for data that is closer to the data received on a specific individual. One individual may be diagnosed with a comorbidity within two years of diagnosis of a medical condition, while another individual may be diagnosed with a comorbidity within four years of diagnosis of a medical condition. The use of different datasets corresponding to the different periods of time may enable better classification and / or identification of correlations and / or treatment.

[0078] FIG. 3B is a graph 320 illustrating a period of time 330 over which a subset of records 305a is selected from records of clinical and / or drug-related data. The graph 320 shows records of individuals 305a having a difference of time 330 between date of diagnosis of the medical condition and diagnosis of the one or more comorbidities. The difference in time 330 may be defined by a comorbidity diagnosis threshold. The period of time 330 may be a number of years, such as two years, three years, four years, eight years, or another period of time (e.g., based on the number of records available with relevant features for the training data). The clinical variables may increase or decline over time.

[0079] The graph 320 illustrates longitudinal clinical data and / or drug-related data of the individual records 305a having the identified medical condition and / or the one or more comorbidities. For example, the graph 320 illustrates longitudinal data of individual feature values within the clinical data over the period of time 330 that indicate the progression of the medical condition and / or the one or more comorbidities. The longitudinal data may include data collected through a series of repeated observations of each individual over the period of time 330. In the graph 320, the feature values identified in the longitudinal clinical data may relate to predefined feature values identified for input at the supervised learning model 309 and / or the unsupervised learning model 311.

[0080] Referring again to FIG. 3 A, different diagnostic information may be included in the datasets 305 for classifying individuals and / or making recommendations to individuals having different medical conditions and / or comorbidities. For example, different datasets 305 may include diagnostic data related to the diagnosis of different medical conditions and / or comorbidities to train the supervised learning model 309 for classification of individuals at 310 with different medical conditions and / or comorbidities. Different diagnostic data related to the diagnosis of different medical conditions and / or comorbidities may also be used as input into the unsupervised learning model 311 to identify relevant features for a given cohort, correlations between features, and / or forms of treatment for different medical conditions and / or comorbidities.

[0081] Different demographic information may be included in the datasets 305 for classifying individuals and / or making recommendations to individuals in different demographics. For example, different datasets 305 may include data related to age, race, gender, and / or other demographic information of each of the individuals having the identified medical condition and / or one or more comorbidities in the dataset. The demographic data may include socioeconomic information expressed statistically, including employment, education, income, marriage rates, birth rates, death rates, and / or other socioeconomic information. Different demographic information may be used to train the supervised learning model 309 for classification of individuals at 310 with different demographics. Different demographic data may also be used as input into the unsupervised learning model 311 to identify correlations and / or forms of treatment for individuals having different demographics.

[0082] The dataset 305 may include other medical data that may identify measurable parameters related to the health of each individual in the dataset. For example, the medical data may identify a height, a weight, and / or one or more biomarkers. The biomarkers may include genetic biomarkers or phenotype biomarkers. Different biomarkers may be used to train the supervised learning model 309 for classification of individuals at 310. Different biomarkers may also be used as input into the unsupervised learning model 311 to identify correlations and / or forms of treatment.

[0083] During pre-processing of the dataset 305, feature values may be extracted from the records in the dataset 305 for training the supervised learning model 309 and / or being input into the unsupervised learning model 311. The feature values may be further formatted for being input into the supervised learning model 309 and / or the unsupervised learning model 311. The feature values may be pre-processed to a format that is more efficiently processed by the supervised learning model 309 and / or the unsupervised learning model 311. In one example the feature values corresponding to different clinical data and / or drug-related data may be predefined. In another example, the dataset 305 may be prepared based on certain predefined parameters (e.g., a period of time between diagnosis of the comorbidity and the medical condition, demographic data, or other parameters) and the dataset 305 may be input into the unsupervised learning model 311 for clustering cohorts of individuals with similar features on which the supervised learning model 309 may be trained. While the particular example described herein selects features with relevance to CKD, alternative configurations that target different chronic comorbidities may select different relevant features.

[0084] One or more features may be identified from each cluster that correspond to different clinical data and / or drug-related data. More features may enable for more accurate training of the supervised learning model 309, however, less features may allow for faster training and / or processing. To reduce the number of features and / or data on which the supervised learning model 309 is trained, the supervised learning model 309 may be configured to receive clinical data related to predefined features, without being trained on drug-related data, for predicting a progression rate and / or class of progression for the comorbidity. The unsupervised learning model 311 may receive the clinical data along with the drug-related data as input data for performing the clustering of records at 313 and enabling identification of correlations and / or forms of treatment in the drug-related information.

[0085] A subset of features may be identified and / or defined for training / input into the supervised learning model 309 and / or the unsupervised learning model 311 based on a feature importance related to a given cluster or cohort. The use of a subset of features may remove classification noise that may result from using the entire dataset for training the supervised learning model 309. An algorithm (e.g., XGBoost or another algorithm) may be implemented to identify feature importance for each of the features in the data that is input into the unsupervised learning model 311. The feature importance may allow for selection of one or more features that are above a certain quality score, or a predefined number of features with a highest quality score, to be selected for a given cluster of data. The selected features may be used for training the supervised learning model 309.

[0086] FIG. 3C is a table 335 that shows example feature scores 337 that may be generated by an algorithm for features 339 identified in a hierarchical clustering model. In one example, the learning model may be a gradient-boosted model, such that after the trees are constructed the feature scores may be generated in the table 335 that indicates a relative importance of each of the features 339. The feature scores 337 may be calculated for a single decision tree by the amount that each attribute’s split point improves a performance measure, weighted by the number of observations for which the split (e.g., node) in the tree is responsible The algorithm may sum up how much splitting on each feature allowed the model to reduce the impurity across all the splits (e.g., nodes) in the tree The feature importance values may be averaged across all of the decision trees within the model

[0087] Referring again to FIG. 3A, the training of the supervised learning model 309 on specific features for a given cluster of records for individuals in a cohort may allow the supervised learning model 309 to more accurately predict a progression rate and / or class of progression for the comorbidity of individuals in that cohort. Additionally, the selection of different features for different clusters of records for individuals in a cohort may allow for better correlations and / or forms of treatment to be identified.

[0088] The extracted feature data may be further pre-processed for being input into the supervised learning model 309 and / or the unsupervised learning model 311. FIG. 3D is a diagram showing an example process 340 for pre-processing records in a dataset 305b to extract and format feature data for input as training data to the supervised learning model during training, as input data to the trained model during production and / or implementation, and / or asinput data to the unsupervised learning model. As shown in FIG. 3D, the records in a dataset 305b may include clinical data 342 and / or drug-related data 344. The clinical data 342 may be used to calculate or aggregate values of one or more features 346, such as minimum, maximum, mean, slope, and / or intercept for multiple records of the same data type related to an individual. As shown in FIG. 3D, the identified features 346 include specific biomarkers that relate to an individual’s comorbidity of CKD, such as BMI values, HbAlc values, creatinine values, albumin values, glucose values, GFR values (e.g., EGFR values), and / or one or more other biomarker values. The features 346 may include other features in the clinical data 342, such as demographic information (e.g., an age of an individual at diagnosis of the medical conditions and / or comorbidities), for example. Though specific features are provided here as example features 346 extracted from the clinical data 342, other features may be used that relate to other medical conditions and / or comorbidities. Additionally, though a specific number of features 346 are provided as an example, a greater or fewer number of features may be defined. The type and / or number of features may be defined for different medical conditions and / or comorbidities. The values of the features 346 may be further formatted, such as in the form of a tensor, or other matrix or vector, for being input into a supervised learning model or an unsupervised learning model.

[0089] The records in a dataset 305b may also include drug-related data 344. The drug- related data 344 may be pre-processed for being input into the same models or different models as the feature data corresponding to the clinical data 342. The drug-related data 344 may include data that is used to train the supervised learning model 309 and / or that is input into the unsupervised learning model 311, as described herein. The drug-related data 344 may be converted to one-hot encoded drug vector 348 for being input into one or more models. The one- hot encoding may be used to represent categorical drugs, drug types, medical procedures, and / or types of medical procedures as numerical values that may be formatted, such as in the form of a tensor, matrix, or vector, for being input into the one or more models.

[0090] The drug-related data 344 may be further filtered during pre-processing based on one or more other criteria. For example, the drug-related data 344 may be filtered after the date of diagnosis of the medical condition and / or the comorbidity. The drug-related data 344 may be further filtered to exclude drugs that were prescribed for limited periods of time (e.g., one month,three months, or another predefined period of time) to remove drugs that are less likely to have an impact on a given medical condition or comorbidity.

[0091] FIG. 3E include tables 345a, 345b that include forms of treatment and corresponding one-hot encoded vectors 347a, 347b that may be generated for being input into a learning model. The one-hot encoded vectors 347a, 347b may include binary vectors that represent a presence of a category of treatment with each binary value. As shown in FIG. 3E, the table 345b may include a subset of the forms of treatment in the table 345a, which may include different levels of drug-related data. Different levels of one-hot encoded vectors 347a, 347b may be generated for providing different levels of input into the learning models. As there are a large number of drug names and even country specific variations, the one-hot encoded vectors may be utilized to map each of the drug names to a pharmaceutical class. The different levels may be implemented for a separate one-hot encoded vector for each level to allow for multiple drug classes treating the same condition. A smaller vector size may be more efficiently processed by the learning models. The one-hot encoders may store a numeric representation of data corresponding to classes of pharmaceutical medications that are commonly administered to patients, with examples in the diabetes treatment space including long and short acting insulin, biguanides, glucagon-like peptide- 1 (GLP-1) agonists, sodium-glucose cotransporter 2 (SGLT2) inhibitors, thiazolidinediones (TZDs), and the like. The one-hot encoding of the categories of treatment may enable more efficient processing and / or storage of the drug-related data in memory, as the binary vectors may be shorter and sparser than corresponding integer encodings and / or text.

[0092] Referring again to FIG. 3A, the subset of records in the dataset 305 may be filtered to require each of the feature values, or at least certain or a predefined number of feature values, that are used as input into the supervised learning model 309 and / or the unsupervised learning model 311. The records in the dataset 305 may include records that are further limited by a predefined period of time (e.g., the last five years, the last ten years, the last twenty years, or another period of time) in addition to the period of time 330 defined by the comorbidity diagnosis threshold. This may limit the records to a certain overall time period.

[0093] As described herein, the comorbidity progression monitoring subsystem may implement the model and / or process 300 for cluster-specific classification modeling to refine the classification of the data from the dataset 305 that is input into the supervised learning model 309and identify correlations and / or forms of treatment for slowing progression of comorbidities across classes for individuals identified within specific clusters of data. Thus, the clustering algorithms may be implemented for providing cluster-level personalization for identifying correlations and / or forms of treatment.

[0094] As described herein, the clusters of similar records identified at 313 may be analyzed to identify correlations and / or forms of treatment across comorbidity progression classes. FIG. 3F includes a graph 350 illustrating an example hierarchy of clusters of data generated by an unsupervised hierarchical clustering model. The process of cluster detection for identifying different clusters of data within the hierarchical dataset may be referred to as tree cutting, branch cutting, or branch pruning, for example. A tree cutting method may be implemented that is referred to as a static tree cut, which may define each contiguous branch below a fixed height in the tree as being cutoff as a separate cluster. As shown in FIG. 3F, the tree of clusters generated by the unsupervised hierarchical clustering model may be cut at a tree definition of four, generating four clusters of records each having similar feature values for the defined features in the dataset. However, other numbers of clusters may be identified based on different tree definitions.

[0095] The table 355 in FIG. 3F illustrates the number of records in each class of comorbidity progression for each cluster. In the example, shown in FIG. 3F, there are 3 classes of comorbidity progression (e.g., “slow,” “medium,” and “fast”). The clusters of records may be analyzed to identify correlations and / or forms of treatment across comorbidity progression classes. Each cluster may include features with the same or similar feature values that may indicate correlations and / or forms of treatment for being provided as output. The clusters of data may group relevant features across comorbidity progression classes.

[0096] Different types of analysis may be performed on the clusters of data to identify correlations and / or forms of treatment. For example, drug-related data in the records 357a that are classified as having the slowest rate of progression for the comorbidity may be analyzed for determining drugs, drug types, medical procedures, and / or types of medical procedures. The drug-related data in the records 357a may be compared against the drug-related data in the records 357b, 357c that are classified as having a relatively higher rate of progression for the comorbidity within the same cluster. The comparison may be performed to identify drugs, drug types, medical procedures, and / or types of medical procedures that are different or absent thatmay be recommended for slowing the progression of the comorbidity. As the drug-related data may include longitudinal data or other data identifying drugs, drug types, medical procedures, and / or types of medical procedures that may change over time, a pathway for updating a recommended form of treatment based on accepted guidelines from the American Diabetic Association or other medical body may be identified for changing one or more forms of treatment over time, as may be observed in the data related to the relatively slower progressing class in the cluster. One or more forms of treatment, or pathways for treatment, may be stored for a corresponding cluster as a recommended form of treatment for individuals.

[0097] Though examples are described herein for identifying correlations and / or forms of treatment by comparing records of data within the same cluster, the cluster may be identified as being disqualified for consideration in recommending forms of treatment. Within each cluster, the slowest progressing group may be used as a benchmark to compare treatment efficacy while ignoring treatments that are associated with fast progressors. For example, a cluster or cohort may be determined to include a number of records above a threshold having a rate of progression of the comorbidity that is relatively high. For example, the cluster 359a (e.g., cluster “0”) shown in the table 355 may include a number of “fast” progressors and / or “medium” progressors that is above a threshold, which may indicate that the forms of treatment are relatively lower quality or less effective than others. Other clusters may be looked to for forms of treatment recommendations. A cluster or cohort may be determined to include a number of records above a threshold having a rate of progression of the comorbidity that is relatively low. For example, the cluster 359b e.g., cluster “1”) shown in the table 355 may include a number of “slow” progressors and / or “medium” progressors that is above a threshold, which may indicate that the forms of treatment are relatively higher quality or more effective than others.

[0098] Treatment of certain types of clinical data defined in the features may be prioritized for having a greater impact on the comorbidity. The priority of different features may be predefined or based on the trained parameters of the supervised learning model, such as the weights or coefficients, for predicting the progression of comorbidity. Different records may be analyzed in different comorbidity progression classes (e.g., the “slow” and “fast” comorbidity progression classes) in the same cluster to identify treatment of a prioritized feature (e.g., a biomarker value, such as a blood pressure value) or another feature generated from the clinical data. For a given cluster, higher feature values (e.g., feature values indicating a higher biomarkervalue, such as a blood pressure value) may be identified for identifying forms of treatment in slower progressing classes that may be recommended for higher priority classes. For example, a high BMI value may be identified as correlating to high blood pressure in faster progressing classes. As a result, a recommendation may be provided for treatment of the high BMI value. The action plan may vary based on different correlations between symptoms and other comorbidity factors in individual patients. The correlations and / or forms of treatment may be stored and / or output to a user, such as during production and in response to identifying a user as being in a certain class of progression for which the correlations and / or forms of treatment have been identified.

[0099] Referring again to FIG. 3 A, the automated clustering of cohorts in a dataset 305 to extract features (e.g., clinical and / or drug-related) using the unsupervised learning model 311 for different classes of comorbidity progression may be combined with the supervised learning model 309 that identifies or predicts the most likely cohort for a person with the medical condition and for which clinical and / or drug related data is received (e.g., from a healthcare provider) during production and / or implementation of the supervised learning model 309. Though examples are provided for the supervised learning model 309 being trained for predicting a progression of a comorbidity for a medical condition, and the features relate to the progression of a single comorbidity, the supervised learning model 309 may be trained on features for identifying progression of multiple comorbidities. The unsupervised learning model 311 may also receive as input features that relate to multiple comorbidities and cluster groups of records across comorbidity classes at 313 for identifying correlations and / or forms of treatment for multiple comorbidities at 315. The correlations and / or forms of treatment may be identified based on a priority of the comorbidities. For example, for individuals having a diabetic condition, features related to different comorbidities (e.g., chronic kidney disease, neuropathy, retinopathy, and / or heart disease) may be received as input and the features related to each of the comorbidities may be prioritized. Forms of treatment in faster progressing classes that are identified in slower progressing classes may also be identified and prioritized based on the priority of the corresponding comorbidity that is treated. Additionally, where multiple comorbidities are identified as being able to be treated by a single form of treatment, the form of treatment may be prioritized.

[0100] FIG. 4 illustrates an example system environment and / or process 400 fortraining and / or implementing a supervised learning model 409 (e.g., Al and / or ML model), as described herein. For example, the comorbidity progression monitoring subsystem 123 shown in FIG. IB may be implemented to train and / or implement the supervised learning model 409. The supervised learning model 409 may be a trained classifier for classifying records of individuals into different comorbidity progression classes. However, other Al and / or ML models may be similarly trained and / or implemented during production. As shown in FIG. 1 A, the comorbidity progression monitoring subsystem 123 may be operating on one or more computing devices 122a, 122b. As such, the supervised learning model 409 operating thereon may be trained and / or implemented during production on the same computing device or different computing devices, such as in a federated learning environment, for example.

[0101] As shown in FIG. 4, the supervised learning model 409 may include model data and one or more algorithms and / or functions trained to predict a likelihood of development of one or more comorbidities of a medical condition of an individual and / or a class of comorbidity progression. The supervised learning model 409 may include one or more algorithms configured for supervised learning. Supervised learning may be implemented utilizing a supervised learning model 409 that is trained during a training process to determine a predictive model using known outcomes.

[0102] The supervised learning model 409 may be characterized by parameters and / or hyperparameters 417 that may be trained during the training process to configure the structure of the supervised learning model 409. The parameters may include values derived during the training process. The parameters may include a number of layers / nodes, weights(c. ., coefficients), and / or biases. The supervised learning model 409 may also include hyperparameters. The hyperparameters may include values used to control the learning process. The hyperparameters may include a learning rate, a number of epochs, a batch size, a number of layers, a number of nodes in each layer, and / or other hyperparameters. Some may use certain parameters and hyperparameters interchangeably.

[0103] The supervised learning model 409 may be trained during supervised learning by inputting training data 407a to the supervised learning model 409 and adjusting the parameters and / or hyperparameters 417 toward a known target output 415 while minimizing a loss or error in the output generated by the supervised learning model 409. Raw clinical and / or drug-relateddata 403a may be extracted from a dataset and formatted into the training data 407a, validation data, and / or test data for training, validation, and / or testing, respectively, the supervised learning model 409 during supervised learning. The training data, validation data, and / or test data may be pre-processed at 405, as described herein, from the raw clinical and / or drug-related data 403a for being input into the supervised learning model 409.

[0104] The training data 407a and / or the input data 407b may be input into the supervised learning model 409 in one or more formats, such as a tensor format, a vector format, an array format (e.g., including single-dimensional or multi-dimensional arrays) and / or another data format capable of being input into the supervised learning model 409. The training data 407a and / or the input data 407b may be the result of pre-processing 405 that may be performed on raw data 403a, 403b. In another example, the training data 407a and / or the input data 407b may include the raw data 403a, 403b itself. The pre-processing 405 may include format changes or other types of processing in order to generate the training data 407a and / or input data 407b in a format for being input into the supervised learning model 409, as described herein. In the configuration illustrated in FIG. 4, the raw data specific to each individual 403b may form a dependency for the selection of relevant raw clinical / drug data 403a and the pre-processing 405 because the relevant clinical / drug data and the steps for pre-processing may be based on the comorbidities and other disease progression data that are indicated for each patient in the individual raw data 403b.

[0105] In one example, the pre-processing 405 of the training data 407a may include extracting the training data 407a from the raw clinical and / or drug-related data 403a. The training data for each class of comorbidity progression may be extracted from a larger clinical and / or drug-related dataset based on the difference between the date of diagnosis of the medical condition for an individual in the records and the development and diagnosis of the one or more comorbidities of the individual records. The subset of records in the training data 307a may be based on a number of years between the date of diagnosis of the medical condition and the development or diagnosis of the one or more comorbidities, such as two years, three years, four years, eight years, or another timeframe.

[0106] Different sets of training data 407a may be prepared through pre-processing at 405 for training the supervised learning model 409, or different Al and / or ML models, to provide better results for making recommendations to individuals during production and / orimplementation. For example, different periods of time may be selected for the comorbidity diagnosis threshold to train supervised learning models on data that may be closer to a specific individual for which data may be submitted to the system for providing recommendations. One individual may be diagnosed with a comorbidity within two years of diagnosis of a medical condition, while another individual may be diagnosed with a comorbidity within four years of diagnosis of a medical condition. The supervised learning model 409, or separate supervised learning models, may be trained on different sets of data that have different timeframes for diagnosis of the comorbidity within the diagnosis of the medical condition.

[0107] Different sets of training data 407a may also, or alternatively, be prepared for training the supervised learning model 409, or different supervised learning models, to provide better results for making recommendations to individuals having different medical conditions and / or comorbidities. For example, the training data 407a may include diagnostic data related to the diagnosis of different medical conditions and / or comorbidities to provide recommendations to individuals having different medical conditions and / or comorbidities.

[0108] Different sets of training data 407a may also, or alternatively, be prepared for training the supervised learning model 409, or different supervised learning models, to provide better results for making recommendations to individuals having different demographics. For example, the training data 407a may include data related to age, race, gender, and / or other demographic information of each of the individuals having the identified medical condition and / or one or more comorbidities in the dataset. The demographic data may include socioeconomic information expressed statistically, including employment, education, income, marriage rates, birth rates, death rates, and / or other socioeconomic information.

[0109] The training data 407a may include other medical data that may identify measurable parameters related to the health of each individual in the dataset. For example, the medical data may identify a height, a weight, and / or one or more biomarkers. The biomarkers may include genetic biomarkers or phenotype biomarkers.

[0110] The training data 407a may be further pre-processed at 405, as described herein (e.g., with reference to FIGs. 3A-3E and / or elsewhere herein). The preprocessing 405 of the training data 407a may include separating the records into training data for each of the number of comorbidity classes. The training data 407a for each class of comorbidity progression may be selected based on the difference between date of diagnosis of the medical condition anddiagnosis of the one or more comorbidities, as well as the number of individuals or records within each class. For example, when the number of comorbidity classes includes three classes (e.g., “slow,” “medium,” and “fast”), the number of individuals or records selected for the training data 407a for each class of comorbidity progression may be within a threshold of the number of individuals or records in each of the other classes. As illustrated in the graph 200 of FIG. 2, the records identified for the training data for each class of comorbidity progression may be selected based on the difference between date of diagnosis of the medical condition and diagnosis of the one or more comorbidities, as well as the number of individuals or records within each class. For example, the number of individuals or records selected for training data for each class of comorbidity progression may be within a threshold of the number of individuals or records in each of the other classes.[OHl] Referring again to FIG. 4, the pre-processing 405 of the training data 407a may include extracting the feature data, or data for a predefined number of features, that are used as input into the supervised learning model 409 and / or formatting the training data 407a for input into the supervised learning model 409. The features may relate to particular types of diagnostic data, demographic data, and / or other medical data, such as one or more biomarkers. The features may be defined that relate to different classes of comorbidity progression. For example, the features that are used for the supervised learning model 409 to classify progression of an individual’s comorbidity of CKD may include features related to multiple biomarkers, such as blood pressure values, BMI values, HbAlc values, creatinine values, albumin values, glucose values, EGFR values, and / or one or more other biomarker values.

[0112] During supervised learning, the training data 407a may be labeled prior to being input into the supervised learning model 409. The training data 407a may be labeled to teach the supervised learning model 409 to learn from the labeled data and to test the accuracy of the supervised learning model 409 for being Implemented on unlabeled input data 407b during production / implementation of the supervised learning model 409, or similar supervised learning models utilizing similar parameters and / or hyperparameters 417. The training data 407a may be used to fit the parameters of the supervised learning model 409 using optimization functions, such as a loss or error function 413. Often the training data 407a may include pairs of input data and a corresponding target output 415 to which the parameters 417 may be trained to generate (e.g., within a threshold loss or error) a predicted output 419 during production and / orimplementation. The training data 407a may be input into the supervised learning model 409 to train the supervised learning model 409 to predict one or more comorbidities of a medical condition of an individual, a period of time to diagnosis of one or more comorbidities, and / or a class of comorbidity progression.

[0113] Supervised learning may be implemented for various types of supervised learning model 409, including algorithms that implement, for example, non-linear classification, logistic regression, neural networks (NNs), decision trees, Bayesian logics, random forests, and / or support vector machines (SVMs). NNs and Deep NNs (DNNs) are popular examples of algorithms utilized in Al and / or ML models that may be trained using supervised learning. An example of the supervised learning model 409 described herein includes a classifier trained to predict a likelihood of development of one or more comorbidities of a medical condition of an individual and / or a class of comorbidity progression for one or more comorbidities of a medical condition of an individual. A classifier may perform classification as a form of pattern recognition. The classifier may apply classification algorithms to the training data 407a to find the same pattern in future input data 407b that may be received during implementation. The classifier may include NN and / or non-NN-based algorithms. The classifier may include a Random Forest classifier. The classifier may include one or more classification layers configured to compute the cross-entropy loss for classification and / or weighted classification tasks with exclusive classes. Each classification layer may infer the number of classes from the output size of the previous layer.

[0114] Though a classifier is provided as an example of the supervised learning model 409, the supervised learning model 409 may implement one or more NN and / or non-NN-based algorithms. Various examples of NNs include: perceptrons, multilayer perceptrons (MLPs), feed-forward NNs, fully-connected NNs, convolutional Neural Networks (CNNs), recurrent NNs (RNNs), long-short term memory (LSTM) NNs, and / or residual NNs (ResNets). A perceptron is a NN that includes a function that multiplies its input by a learned weight coefficient to generate an output value. A feed-forward NN is a NN that receives input at one or more nodes of an input layer and moves information in a direction through one or more hidden layers to one or more nodes of an output layer. In a feed-forward NN, one or more nodes of a given layer may be connected to one or more nodes of another layer. A fully connected NN is a NN that includes an input layer, one or more hidden layers, and an output layer. In a fully connected NN, each nodein a layer is connected to each node in another layer of the NN. An MLP is a fully connected class of feed-forward NNs. A CNN is a NN having one or more convolutional layers configured to perform a convolution. Various types of NNs may have elements that include one or more CNNs or convolutional layers, such as Generative Adversarial Networks (GANs). A GAN may include a generator sub-model and a discriminator sub-model. The generator sub-model may be configured to receive input data and pass true and independently generated data to the discriminator sub-model. The discriminator sub-model may be configured to receive the true and independently generated data from the generator, discriminate the true and independently generated data, and provide feedback to the generator sub-model during training to improve the function of the generator sub-model in independently generating an output based on a received input. The GAN is a popular model for generating data types or data sequences, such as image data, audio data, and / or text, for example. An RNN is a NN that is recurrent in nature, as the nodes include feedback connections and an internal hidden state (e.g., memory) that allows output from nodes in the NN to affect subsequent input to the same nodes. LSTM NNs may be similar to RNNs in that the nodes have feedback connections and an internal hidden state (e.g., memory). However, the LSTM NNs may include additional gates to allow the LSTM NNs to learn longer-term dependencies between sequences of data. A ResNet is a NN that may include skip connections to skip one or more layers of the NN. Some NNs include one or more attention layers or functions to enhance or focus on some portions of the input data, while diminishing or de-emphasizing other portions.

[0115] The supervised learning model 409 may include layers of a similar type (e.g., convolutional layers, feed-forward layers, fully-connected layers, etc.) and / or having a similar or different configuration (e.g., size, number of nodes, etc.) for each layer. The supervised learning model 409 may also, or alternatively, include one or more layers having different types or different subsets of NNs that may be interconnected for training and / or implementation, as described herein. For example, a NN may include both convolutional layers and feed-forward or fully-connected layers.

[0116] During the training process, the training data 407a may be input into the supervised learning model 409 and may be used to learn the parameters and / or tune the hyperparameters 417. The training may be performed by initializing parameters and / or hyperparameters of the supervised learning model 409, generating and / or accessing the trainingdata 407a, inputting the training data 407a into the supervised learning model 409, calculating the error or loss from the output of the supervised learning model 409 to a target output 415 via a loss function 413 (e.g., utilizing gradient descent and / or associated back propagation), and / or updating the parameters and / or hyperparameters 417.

[0117] The loss function 413 may be implemented using backpropagati on-based gradient updates and / or gradient descent techniques, such as Stochastic Gradient Descent (SGD), synchronous SGD, asynchronous SGD, batch gradient descent, and / or mini-batch gradient descent. Examples of loss or error functions may include functions for determining a squared- error loss, a mean squared error (MSE) loss, a mean absolute error loss, a mean absolute percentage error loss, a mean squared logarithmic error loss, and / or a cross-entropy loss.

[0118] An optimizer may be implemented along with the loss function 413. The optimizer may be an algorithm or function that is configured to adapt attributes of the supervised learning model 409, such as a learning rate and / or weights, to improve the accuracy of the supervised learning model 409 and / or reduce the loss or error. The optimizer may be implemented to update the parameters and / or hyperparameters 417 of the supervised learning model 409.

[0119] The training process may be iterated to update the parameters and / or hyperparameters 417 until an end condition is achieved. The end condition may be achieved when the output of the supervised learning model 409 is within a predefined threshold of the target output 415.

[0120] The trained or fitted supervised learning model 409 may receive the validation data as input to evaluate the model fit on the training data set 407a, while tuning the hyperparameters 417 of the supervised learning model 409. The supervised learning model 409 may receive the test data to evaluate a final model fit on the training data set and to assess the performance of the supervised learning model 409. One or more of the training, validation, and / or testing may be performed during supervised learning for different types of supervised learning models.

[0121] Hyperparameter tuning may be performed to obtain a supervised learning model 409 without overfitting for the dataset. In one example, a supervised learning model comprising a hierarchical classifier was tested with testing data comprising 468 subjects (90-10-10 split of training data, optimization data, validation data) having a diabetic condition and a comorbidity ofCKD. In this embodiment, the supervised learning model was trained with Optuna hyperparameter optimization, which is an automated tuner using a Bayesian selection method for choosing a combination of parameters, of 5000 trials. The input data for the supervised learning model included aggregated HbAlc data, creatinine data, albumin data, glucose data, EGFR data, BMI data, and an age at diabetes diagnosis. Over the course of training the ratio of features used for input into the supervised learning model was reduced to under a threshold to avoid overfitting. The ratio of training instances used was reduced to under a threshold to avoid overfitting. The maximum depth of the tree definition was reduced to under a threshold (e.g., four) to avoid overfitting. Since XGBoost is a tree building algorithm, the parameter threshold while training may be set to a maximum tree size, such that the hyperparameters run through a testing dataset may be checked for the overfitting while the final result is actually performed on a validation dataset that separate from the testing or the training. The overall training accuracy of the model reached 65% for classification enabling four separate groups of individuals to be distinguished with varying proportions of progression pace towards CKD that met the standards of the classification result.

[0122] After the training and / or validation process is complete, the trained supervised learning model 409, or portions thereof, may be stored for being implemented by one or more devices. For example, the trained parameters and / or hyperparameters 417 may be stored, which may include weights and / or coefficients for different features. The trained supervised learning model 409, or portions thereof, may be implemented in other downstream algorithms or processes, as may be further described herein. The trained supervised learning model 409, or portions thereof, may be implemented as a trained classifier trained to predict a likelihood of development of one or more comorbidities of a medical condition of an individual and / or a class of comorbidity progression. The trained supervised learning model 409, or portions thereof, may be implemented on the same device on which the training was performed. The trained supervised learning model 409, or portions thereof, may be transmitted or otherwise provided to another device for being implemented. For example, supervised learning model 409 or the one or more trained param eters / hyperparameters 417 may be stored in memory for being accessed at one or more devices during production and / or implementation.

[0123] The trained supervised learning model 409 may receive respective input data 407b that corresponds to a specific individual during production and / or implementation of thetrained supervised learning model 409. The raw data 403b that is specific to an individual may be received as notes or input from a healthcare provider or other individual. The raw data 403b may be pre-processed, as described herein, to generate the input data 407b. The pre-processing at 405 may be similar to that of the training data 407a for being input into the supervised learning model 409. For example the data 403b specific to an individual may include clinical data and / or drug-related data. The features that are configured to be input into the supervised learning model 409 may be extracted from the data 403b. The data 403b may include clinical data that may be used to calculate or include values of one or more features related to the specific individual to be input into the trained supervised learning model 409. For example, as described herein, the features that are used for input into the supervised learning model 409 to classify progression of an individual’s comorbidity of CKD may include features related to multiple biomarkers, such as BMI values, HbAlc values, creatinine values, albumin values, glucose values, GFR values (e.g, EGFR values), and / or one or more other biomarker values. Demographic information specific to the individual (e.g, such as the age of the individual and / or other demographic information) may also be input into the supervised learning model 409 in a preprocessed format. Though specific features are provided here as example features for input into the model to identify a class of comorbidity progression for CKD for an individual with a diabetic condition, more or less features may be used. Other features may also be similarly implemented for being input into another model to identify classes of comorbidity progression for other comorbidities of the same or other medical conditions. The values of the one or more features may be further formatted, such as in the form of a tensor, or other matrix or vector, that includes specific information of an individual for being input into the trained supervised learning model 409.

[0124] During production and / or implementation, the trained supervised learning model 409 may generate an output 419. The output 419 may be generated in one or more formats, such as a tensor, matrix, vector, a text format (e.g, a word, sentence, or other sequence of text), a numerical format (e.g, a prediction), another data sequence format, and / or another output format. The output 419 may indicate a likelihood of development of one or more comorbidities of a medical condition of the individual and / or a class of comorbidity progression (e.g, based on a predicted a date at which the individual may develop and / or be diagnosed with the comorbidity based on the input features specific to the individual). The output 419 may be further processedand / or implemented in other downstream algorithms or processes, as may be further described herein.

[0125] Referring again to FIG. IB, the comorbidity progression monitoring subsystem 123 may implement one or more unsupervised learning algorithms for assisting in identifying correlations between records of individuals in different classes of comorbidity progression and / or forms of treatment for slowing comorbidity progression. The unsupervised learning algorithms may be implemented in a separate model or the same model as the supervised learning algorithms that are used for predicting a likelihood of development of the one or more comorbidities of the medical condition of individuals and / or a class of comorbidity progression. For example, the comorbidity progression monitoring subsystem 123 may implement one or more algorithms configured for unsupervised learning. Unsupervised learning may be implemented utilizing Al and / or ML models or algorithms that learn from input data without being trained toward a particular target output. The Al and / or ML models that are configured for implementing unsupervised learning may include algorithms configured for identifying patterns, groupings, clusters, anomalies, and / or similarities or other associations in the input data. For example, the AI / ML may implement hierarchical clustering algorithms, k-means clustering algorithms, k nearest neighbors (K-NN) algorithms, anomaly detection algorithms, principal component analysis algorithms, and / or apriori algorithms.

[0126] As one example, the comorbidity progression monitoring subsystem 123 may implement a cluster-specific classification model to refine the classification of the data input into the supervised classification algorithm and identify correlations and / or forms of treatment for slowing progression of comorbidities. Though clustering algorithms may be implemented for providing cluster-level personalization for correlations and / or forms of treatment, other unsupervised models or algorithms may be implemented.

[0127] FIG. 5 shows an example of an unsupervised learning model 500 that may be implemented during unsupervised learning. As shown in FIG. 5, the unsupervised learning model 500 is a hierarchical clustering model. Though other unsupervised learning models may be similarly implemented. The unsupervised learning model 500 may receive unlabeled input data 502 and determine patterns or similarities in the input data 502 without additional intervention (e.g., updating parameters and / or hyperparameters). The input data may include pre-processed data (e.g., as described herein) or raw data. In one example, the pre-processing ofthe input data 502 may include extracting the input data 502 from a larger dataset of raw clinical and / or drug-related data. The extracted data may include a subset of records related to feature values similar to the feature values that are used for the supervised learning model, as described herein. For example, the subset of records in the input data 502 may be based on a number of years between the date of diagnosis of the medical condition and the development or diagnosis of the one or more comorbidities, such as two years, three years, four years, eight years, or another timeframe. The subset of records in the input data may include different diagnostic data related to different medical conditions or comorbidities, different demographic data, drug-related data, and / or other medical data, as described herein. However, the input data 502 may include drug- related data in some instances in which the training data and / or the input data for the supervised learning model may be limited to clinical data. The unsupervised learning model 500 configured may be implemented on a single device or distributed across multiple devices.

[0128] FIG. 6 shows a flowchart of an example process 600 for training a model to predict a class of comorbidity progression for an individual and identifying correlations and / or forms of treatment for slowing the progression of the comorbidity. One or more portions of the process 600 may be performed by one or more computing devices. For example, the one or more portions of the process 600 may be performed by one or more computing devices, such as computing devices 122a, 122b and / or the mobile device 104 shown in FIG. 1 A . One or more portions of the process 600 may be performed by one or more subsystems (e.g., comorbidity progression monitoring subsystem 123 shown in FIGs. 1 A and IB) operating on one or more computing devices. One or more portions of the process 600 may be performed on a single computing device or may be distributed across computing devices. One or more portions of the process 600 may be stored in memory as computer-readable or machine-readable instructions that may be executed by a processor of the one or more computing devices. Though portions of the process 600 may be described herein as being performed by a particular computing device or by a particular subsystem, the process 600 may be performed by another computing device or distributed across multiple computing devices and / or subsystems.

[0129] As illustrated in FIG. 6, at 602 a medical condition and one or more comorbidities may be identified. For example, the medical condition may be identified as a diabetic condition or another medical condition. The one or more comorbidities may beidentified as being related to the identified medical condition, such as CKD, neuropathy, retinopathy, and / or heart disease related to the diabetic condition.

[0130] At 604, training data may be extracted from a dataset that is related to the medical condition and the one or more comorbidities. The dataset may include clinical data and / or drug- related data. The clinical data may include diagnostic data, demographic data, and / or other medical data related to individuals having the identified medical condition and / or one or more comorbidities. The extracted training data may include data from records of individuals that developed the comorbidity at least a predefined period of time after being diagnosed with the medical condition. The training data may include data related to a plurality of features related to the medical condition or the comorbidity. The extracted training data may relate to one or more demographics. The extracted training data may include other medical data, such as one or more biomarkers, for example. As examples, the biomarkers may include a blood pressure value, a body mass index (BMI) value, and / or one or more analyte levels. The analyte levels may include, a hemoglobin A1C (HbAlc) value, a creatinine value, an albumin value, a glucose value, an Estimated Glomerular Filtration Rate (EGFR) value, and / or another analyte level.

[0131] At 606, a supervised learning model may be trained to classify individuals into cohorts or classes of progression of the comorbidity. The classes of progression may be predefined. The training data may be separated into training data for each class of progression. Features may be identified in the training data for being input for training the supervised learning model. The features may be predefined for a given medical condition, one or more comorbidities, and / or demographic. In another example the features may be automatically generated. For example, an unsupervised learning model, such as a hierarchical clustering model or another clustering algorithm, may be implemented to identify features that may be used to train the supervised learning model, as described herein. The parameters (e.g., weights and / or coefficients) and / or hyperparameters associated with the supervised learning model may be updated during the training process. The trained parameters and / or hyperparameters may be stored for production and / or implementation of the trained supervised learning model.

[0132] At 608 one or more correlations and / or forms of treatment may be determined based on different classes of individuals. For example, an unsupervised learning model, such as the hierarchical clustering model or another clustering algorithm, may be used to identify clusters of records of individuals having correlations between features for which data is input into themodel. The correlations and / or forms of treatment may be stored at 610 in a drug profile for a given cohort or cluster of individuals. For example, each cohort or cluster of records for individuals may be associated with a drug profile having at least one drug that is determined to slow the progression of comorbidity. A relatively lower risk comorbidity progression class (e.g., low-risk or “slow” comorbidity progression class) may have a component of drug profile e.g., identified drug or form of treatment) that contributes to a rate of progression, which may be assigned to the drug profile for the cohort of cluster of individuals. The correlations and / or forms of treatment may be stored for being used as recommendations for individuals based on data specific to the individual that is received at a later date.

[0133] FIG. 7 shows a flowchart of an example process 700 for providing a predicted class of progression for one or more comorbidities of a medical condition of an individual and / or one or more recommendations for treatment. One or more portions of the process 700 may be performed by one or more computing devices. For example, the one or more portions of the process 700 may be performed by one or more computing devices, such as computing devices 122a, 122b and / or the mobile device 104 shown in FIG. 1A . One or more portions of the process 700 may be performed by one or more subsystems (e.g., comorbidity progression monitoring subsystem 123 shown in FIGs. 1 A and IB) operating on one or more computing devices. One or more portions of the process 700 may be performed on a single computing device or may be distributed across computing devices. One or more portions of the process 700 may be stored in memory as computer-readable or machine-readable instructions that may be executed by a processor of the one or more computing devices. Though portions of the process 700 may be described herein as being performed by a particular computing device or by a particular subsystem, the process 700 may be performed by another computing device or distributed across multiple computing devices and / or subsystems.

[0134] As illustrated in FIG. 7, at 702 an indication of a medical condition of an individual may be received. The indication of the medical condition may be input with diagnostic information by a healthcare provider or another individual. For example, the medical condition may be identified as a diabetic condition or another medical condition. The medical condition may be received with other diagnostic data specific to an individual, such as one or more comorbidities, a date of diagnosis of the medical condition, and / or a date of diagnosis of the one or more comorbidities. The one or more comorbidities may be identified as being relatedto the identified medical condition, such as CKD, neuropathy, retinopathy, and / or heart disease related to the diabetic condition.

[0135] At 704, other data may be received that include values for other features related to the medical condition and / or the individual. The data may include clinical data and / or drug related data related to a plurality of features used as input into the supervised learning model and / or the unsupervised learning model. The data may relate to one or more demographics. The data may include data related to other medical data, such as one or more biomarkers, for example. As examples, the biomarkers may include a blood pressure value, a body mass index (BMI) value, and / or one or more analyte levels. The analyte levels may include, a hemoglobin A1C (HbAlc) value, a creatinine value, an albumin value, a glucose value, an Estimated Glomerular Filtration Rate (EGFR) value, and / or another analyte level.

[0136] The values in the data for each feature may be input at 706 into the supervised learning model that is trained to classify the individual into a cohort of class of comorbidity progression. The cohort or class of comorbidity progression is associated with stored data, such as correlations and / or forms of treatment. In one example, the individual may be classified as being in a relatively higher risk or relatively lower risk class of comorbidity progression. The data that is stored for the user’s classification may be retrieved from memory. At 708, at least one of the class of progression of the comorbidity or the recommendation for treatment may be output to the user or sent to a system, such as a healthcare provider system, for being output to a user (e.g., healthcare provider).

[0137] FIGs. 8A-8F depict illustrations of an example graphical user interface for displaying example user interfaces for providing data to a user related to a medical condition and / or one or more comorbidities. The example graphical user interfaces may be provided on a display 804 of a computing device. The graphical user interfaces may be generated by software executing on the computing device. The graphical user interfaces may be displayed via a local application (e.g., an app, a browser, etc.) and / or generated on a local or remote computing device. As shown in FIG. 8A, a graphical user interface 800 may display information related to a comorbidity of CDK for individuals with a diabetic condition. In particular, the interface 800 may display recommendations for additional diagnostic tests, top clinical variables for further HCP review, and / or a list of additional symptoms that may be unobserved in the progressivedisease. However, similar types of information may be provided to individuals with other medical conditions and / or comorbidities.

[0138] As shown in FIG. 8A, the graphical user interface 800 may identify the comorbidity 802 and / or the individual 804. Different individuals may be selected through the graphical user interface 800 for displaying different data. Demographic information 806 may be displayed for the individual, such as age, sex, gender, race, and / or other demographic information. Diagnostic information 808 may be displayed, such as a date and / or age of diagnosis of the medical condition and / or the comorbidity. The graphical user interface 800 may display a predicted pace of progression 810 for the comorbidity, which may identify the class of comorbidity progression that the individual is within. The graphical user interface 800 may provide information 812 related to the model features that were used in the prediction. For example, the information 812 may identify relevant or important features for model prediction and / or a strength of each feature. In particular, the model may calculate which input features have the highest weight in predicting the output. Some configurations may incorporate Shapley values, which may identify marginal probability contributions of the input features on the final output and may be clinically most accepted to obtain relevant features. The graphical user interface 800 may provide information and / or graphical illustrations 814 related to the specific data of the user for one or more of the features used for model prediction.

[0139] The features may be related to demographics and / or biomarkers, for example. As shown in FIG. 8B, the information 812 may identify the specific reference values for each feature, where the reference values may correspond to results from clinical tests and / or the like. The reference values may be parameterized into numeric values that are compatible with the model. Additionally, or alternatively, as shown in FIG. 8C, the information 812 may identify a model performance. The area under the ROC Curve (AUC) measures the area under the receiver operating characteristic (ROC) curve that illustrates the performance of a classification model at all classification thresholds. The AUC is the measure of the ability of a binary classifier to distinguish between classes and s used as a summary of the ROC cuive. The higher the AUC, the better the model's performance at distinguishing between the positive and negative classes. As shown in FIG. 8C the model performance for each class may be represented in the information 812.

[0140] As shown in FIG. 8D, the graphical user interface 800 may include drug-related information 816. The drug-related information 816 may identify current drug-related information of the individual, such as current prescriptions and / or other forms of treatment. The drug-related information 816 may include information from the drug profile (e.g., stored for a cohort or cluster). For example, the drug-related information may identify drug-related information for the low-risk or slow progressors in the cohort or cluster associated with the individual’s data. The drug-related information may identify one or more drugs or drug types (e.g., top threshold number of drugs and / or drug types) that are prescribed to the low-risk or slow progressors in the cohort or cluster associated with the individual’s data. As shown in FIG. 8E, the drug-related information 816 may identify one or more drugs from the drug profile (e.g., stored for a cohort or cluster) that are prescribed by dosage. These may be for the low-risk or slow progressors, or across the cohort or cluster.

[0141] As shown in FIG. 8F, the graphical user interface 800 may include personalized cohort or cluster recommendation information 818 to individuals that are predicted to fall within a cohort or cluster. The recommendation information 818 may include information about the cohort or cluster within which the individual is predicted using an unsupervised clustering method. The recommendation information 818 may include recommended drugs, drug types, and / or other forms of treatment, as described herein. The cohort with-in each cluster may be provided using the supervised learning model. The cluster itself may be generated with the unsupervised clustering model.

[0142] FIG. 9 is a block diagram of an example computing device 900. The computing device 900 may be a mobile computing device, such as a tablet, a cellular phone, a wearable device, an analyte monitoring device (e.g., a CGM controller device), a remote computing device, or another computing device, for example. In an example, the computing device 900 may be a computing device on which the comorbidity progression monitoring subsystem, the healthcare provider subsystem, and / or one or more other subsystems may be implemented. As shown in FIG. 9, the computing device 900 may include a processor 902 for controlling the functionality of the computing device 900. The processor 902 may include one or more circuits, such as general-purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, integrated circuits, a programmable logic device (PLD), application specific integrated circuits (ASICs), or the like. The processor 902 mayperform signal coding, data processing, power control, image processing, input / output processing, or any other functionality that enables the computing device 900 to perform as described herein.

[0143] The processor 902 may store information in or retrieve information from the memory 916. The memory 916 includes a non-removable memory or a removable memory. The non-removable memory includes random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of non-removable memory storage. The removable memory includes a subscriber identity module (SIM) card, a memory stick, a memory card (e.g., a digital camera memory card), or any other type of removable memory. The processor 902 may access the memory 916 for executable instructions or other information that is used by the computing device 900. For example, the memory 916 may include computer-readable or machine-readable instructions that may be executed by the processor 902 for performing one or more methods, processes, or procedures, or portions thereof, as described herein.

[0144] The computing device 900 may include a camera 906 that is in communication with the processor 902. The camera 906 may be a digital camera or other optical device capable of generating images or videos (e.g., image sequences) for being captured at the computing device 900. The camera 906 may include a lighting device capable of flashing to in response to signals from the processor 902.

[0145] The computing device 900 may include one or more communication circuits 918. The processor 902 may be in electrical communication with the communication circuit 918 for sending or receiving information. The communication circuit 918 may be capable of performing wired and / or wireless communications. For example, the communication circuit 918 may include one or more radio frequency (RF) transceivers for transmitting and receiving RF signals (e.g., BLUETOOTH®, near field communication (NFC), WIFI®, WI-MAX®, cellular, or other RF signals) via an antenna, or other communications module capable of performing wireless communications. In some embodiments, one or more communication circuits 918 are capable of performing infrared (IR) communications.

[0146] The processor 902 may be in electrical communication with a keypad 924 for providing input to the processor 902. The keypad 924 may include one or more keys for receiving input from a user. The keypad 924 may include hard or soft keys for which the function of the keys changes as a user performs selections.

[0147] Other input into the processor 902 may be provided by one or more sensors 926. The sensors 926 include a motion sensor, a proximity sensor, a heartrate monitoring sensor, an accelerometer, a gyroscope, and / or another sensor on the computing device 900. The motion sensor may transmit infrared signals or use image processing to sense movement. The proximity sensor may transmit infrared signals to detect when an object is within a predefined proximity. The heartrate monitoring sensor may implement photoplethysmography to detect the amount of blood flow in the user. The heartrate monitoring sensor may include one or more LED or photodiodes to detect the amount of blood flow in the user. The heartrate monitoring sensor may implement infrared technology to detect the amount of blood flow in the user. The heartrate monitoring sensor may take an electrocardiogram (ECG) and detect information about the user’s heartrate from the ECG. The accelerometer may measure the non -gravitational acceleration of the computing device 800 in a given direction. The accelerometer may respond to vibrations associated with movement in a given direction. The measurements from the accelerometer may be used by the processor 902 to determine the magnitude or direction of the relative movement of the computing device 900, or the user’s relative position (e.g., standing, sitting, or lying down). The gyroscope may be used to determine the orientation of the computing device 900.

[0148] The processor 902 may be in electrical communication with or generate images on a display 920 for providing information to a user. The communication between the display 920 and the processor 902 may be a two-way communication, as the display 920 may include a touch screen module capable of receiving information from a user and providing such information to the processor 902. For example, the display 920 may provide soft buttons for selection by a user that are recognized by the touch screen module and provided to the processor 902 as input.

[0149] The processor 902 may be in electrical communication with or control a speaker 908. The speaker 908 may provide an audible sound e.g., tone, beep, or buzz) in response to a triggering event detected by the processor 902.

[0150] The computing device 900 may include an electric motor 910 that is in electrical communication with or controlled by the processor 902. The electric motor 910 may rotate and causes the computing device 900 to vibrate (e.g., to indicate a notification) or provide haptic feedback in response to a triggering event detected by the processor 902.

[0151] The processor 902 may be in electrical communication with or receive information from a microphone 914. For example, the processor 902 may receive audio signals via the microphone 914.

[0152] The computing device 900 may include a global positioning system (GPS) circuit 904. The GPS circuit 904 may be capable of receiving GPS information. The processor 902 may be capable of determining the GPS coordinates (e.g., latitude and longitude) of the computing device 900 based on the GPS information received via the GPS circuit.

[0153] The computing device 900 may include a visual indicator, such as one or more light-emitting diodes (LEDs) 912. In some embodiments, one or more LEDs 912 are illuminated or flashed to provide an alert or communicate other information to the user (e.g., low battery or turning on of the device).

[0154] FIG. 10 is a block diagram of an example continuous monitoring device 1000. In some embodiments, the continuous monitoring device 1000 is a CGM or FGM, for example. The continuous monitoring device 1000 may include a subcutaneous sensor 1026 that is used to sense and monitor the amount of glucose in interstitial fluid of the user. Data is transmitted from the sensor 1026 to a transmitting device 1004. When the continuous monitoring device 1000 is a CGM, the transmitting device 1004 is located directly over the sensor 1026 and wirelessly powers the data transfer from the sensor 1026 via power supply 1020. When the continuous monitoring device 1000 is an FGM, the transmitting device 1004 is a mobile device or other reader device that instantaneously receives the information from the sensor 1026 when the device is within the RF range of the sensor 1026.

[0155] The transmitting device 1004 receives data communications from the sensor 1026 via a communication circuit 1018. The communication circuit 1018 may be in electrical communication with a processor 1002. The processor 1002 may include one or more circuits, such as general-purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, integrated circuits, a programmable logic device (PLD), application specific integrated circuits (ASICs), or the like. The processor 1002 may perform signal coding, data processing, power control, input / output processing, or any other functionality that enables the transmitting device 1004 to perform as described herein.

[0156] The transmitting device 1004 may include another communication circuit 1016 for communicating with other devices. The processor 1002 may be in electrical communicationwith the communication circuit 1016 for sending or receiving information. The communication circuits 1016, 1018 are capable of performing wired or wireless communications. For example, the communication circuits 1016, 1018 may include one or more radio frequency (RF) transceivers for transmitting and receiving RF signals (e.g., BLUETOOTH®, near field communication (NFC), WIFI®, WI-MAX®, cellular, or other RF signals) via an antenna, or other communications module capable of performing wireless communications. The communication circuits 1016, 1018 may communicate using the same RF protocol or a different RF protocol.

[0157] The processor 1002 may store information in or retrieve information from the memory 1012. The memory 1012 may include a non-removable memory or a removable memory. The non-removable memory may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of non-removable memory storage. The removable memory may include a subscriber identity module (SIM) card, a memory stick, a memory card (e.g., a digital camera memory card), or any other type of removable memory. For example, the memory 1012 may include computer-readable or machine-readable instructions that may be executed by the processor 1002 for performing one or more methods, processes, or procedures, or portions thereof, as described herein. The processor 1002 may access the memory 1012 for executable instructions or other information that is used by the transmitting device 1004. The processor 1002 is in electrical communication with one or more input keys 1024 for providing input to the processor 1002.

[0158] The processor 1002 may be in electrical communication with or control a speaker 1014. The speaker 1014 may provide an audible sound (e.g., tone, beep, or buzz) in response to a triggering event detected by the processor 1002.

[0159] The continuous monitoring device 1000 may include an electric motor 1010 that is in electrical communication with or controlled by the processor 1002. The electric motor 1010 may rotate and causes the continuous monitoring device 1000 to vibrate (e.g., to indicate a notification) or provide haptic feedback in response to a triggering event detected by the processor 1002. The electric motor 1010 may provide an alert to supplement the audible alarm or replace the audible alarm provided by the speaker 1014.

[0160] FIG. 11 is a block diagram of an example blood glucose meter (BGM) device 1100. As shown in FIG. 11, the BGM device 1100 may include a processor 1102 for controllingthe functionality of the BGM device 1100. The processor 1102 may include one or more circuits, such as general-purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, integrated circuits, a programmable logic device (PLD), application specific integrated circuits (ASICs), or the like. The processor 1102 may perform signal coding, data processing, power control, image processing, input / output processing, and / or any other functionality that enables the BGM device 1100 to perform as described herein.

[0161] The processor 1102 may store information in or retrieve information from the memory 1116. The memory 1116 may include a non-removable memory or a removable memory. The non-removable memory may include random-access memory (RAM), read-only memory (ROM), a hard disk, and / or any other type of non-removable memory storage. The removable memory may include a subscriber identity module (SIM) card, a memory stick, a memory card (e.g., a digital camera memory card), and / or any other type of removable memory. The memory 1116 may include computer-readable or machine-readable instructions that may be executed by the processor 1102 for performing one or more methods, processes, or procedures, or portions thereof, as described herein. The processor 1102 may access the memory 1116 for executable instructions or other information that is used by the BGM device 1100.

[0162] The BGM device 1100 may include one or more communication circuits 1118. The processor 1102 may be in electrical communication with the communication circuit 1118 for sending or receiving information. The communication circuit 1118 may be capable of performing wired and / or wireless communications. For example, the communication circuit 1118 may include one or more radio frequency (RF) transceivers for transmitting and receiving RF signals (e.g., BLUETOOTH®, near field communication (NFC), WIFI®, WLMAX®, cellular, or other RF signals) via an antenna, or other communications module capable of performing wireless communications. In some embodiments, one or more communication circuits 1118 may be capable of performing infrared (IR) communications.

[0163] The processor 1102 may be in electrical communication with a keypad 1124 for providing input to the processor 1102. The keypad 1124 may include one or more keys for receiving input from a user. The keypad 1124 may include hard or soft keys for which the function of the keys changes as a user performs selections.

[0164] Other input into the processor 1102 may be provided by the BGM sensor module 1104. The BGM sensor module 1104 may include a blood glucose measuring engine that may analyze blood samples provided by a patient on a blood glucose measurement strip and measure the amount of blood glucose in the samples.

[0165] The processor 1102 may be in electrical communication with or generate images on a display 1106 for providing information to a user. The communication between the display 1106 and the processor 1102 may be a two-way communication, as the display 1106 may include a touch screen module capable of receiving information from a user and providing such information to the processor 1102. For example, the display 1106 may provide soft buttons for selection by a user that are recognized by the touch screen module and provided to the processor 1102 as input.

[0166] The processor 1102 may be in electrical communication with or control a speaker 1108. The speaker 1108 may provide an audible sound (e.g., tone, beep, or buzz) in response to a triggering event detected by the processor 1102.

[0167] The BGM device 1100 may include an electric motor 1110 that is in electrical communication with or controlled by the processor 1102. The electric motor 1110 may rotate and cause the BGM device 1100 to vibrate (e.g, to indicate an notification) or provide haptic feedback in response to a triggering event detected by the processor 1102. The electric motor 1110 may provide an alert to supplement the audible alarm or replace the audible alarm provided by the speaker 1108.

[0168] The processor 1102 may be in electrical communication with or receive information from a microphone 1122. For example, the processor 1102 may receive audio signals via the microphone 1122.

[0169] The BGM device 1100 may include a visual indicator, such as one or more one or more light-emitting diodes (LEDs) 1128. In some embodiments, one or more LEDs 1128 are illuminated or flashed to provide an alert or communicate other information to the user (e.g, low battery or turning on of the device).

[0170] Those of skill in the art will recognize that the embodiments described herein will operate with the greatest efficiency and accuracy when following recognized best practices in sanitizing and verifying input data and performing the training process. In particular, the training process should use sufficiently large pools of patient and clinical data and model verificationshould be performed on data sets that are not directly used for the training process in order to ensure that the model provides a sufficiently accurate estimation of disease progression for patients who did not participate in the training process. Additionally, in many cases some data points may be missing from the training data set, and data imputation techniques may be used to generate complete data sets to ensure an effective model training process. The various thresholds described above that assist in decision based on, for example, being above or below a certain blood glucose threshold, HbAlc threshold, BMI threshold, etc. may be selected a priori based on known medical criteria for patient diagnosis and treatment, or may be adjusted as learned parameters during the training process.

[0171] Although features, elements, and functions are described above in particular combinations, a feature, element, or function is used alone or in any combination with the other features, elements, or functions. Various presently unforeseen or unanticipated alternatives, modifications, variations, or improvements may be subsequently made that are also intended to be encompassed by the following claims.

[0172] The methods described herein are implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a randomaccess memory (RAM), removable disks, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).

Claims

CLAIMSWhat is claimed is:

1. A method comprising: receiving a dataset related to a plurality of individuals with a medical condition and a comorbidity; extracting, from the dataset, training data related to a subset the plurality of individuals that developed the comorbidity at least a predefined period of time after being diagnosed with the medical condition, wherein the training data comprises a plurality of features related to at least one of the medical condition or the comorbidity; training, based on the features of the training data related to at least one of the medical condition or the comorbidity, a supervised classification model to classify individuals into a class of progression of a plurality of classes of progression for developing the comorbidity, each class of the plurality of classes of progression having a different rate of progression for developing the comorbidity from the diagnosis of the medical condition; determining, for at least one class of the plurality of classes of progression, a correlation between at least one feature of the plurality of features related to the at least one of the at least one of the medical condition or the comorbidity and the at least one class of progression for developing the comorbidity; and outputting, based on the correlation, at least one of the correlation or a recommendation for treatment related to the at least one of the at least one of the medical condition or the comorbidity.

2. The method of claim 1, wherein the correlation is determined using an unsupervised clustering model, and wherein the at least one feature is input into the unsupervised clustering model.

3. The method of claim 2, wherein the input into the unsupervised clustering model comprises the at least one feature and drug-related information related to each of the plurality of individuals in the at least one class.

4. The method of claim 3, wherein the medical condition comprises a diabetic condition.

5. The method of claim 4, wherein the comorbidity comprises at least one of chronic kidney disease, neuropathy, retinopathy, or heart disease.

6. The method of claim 5, wherein the at least one feature of the plurality of features comprise at least one of genetic biomarkers, phenotype biomarkers, demographic information, natural language processing (NLP) translated healthcare provider (HCP) notes, contextual information, or other clinical, diagnostic, medial, or demographic information.

7. The method of claim 5, wherein the at least one feature comprises a hemoglobin A1C (HbAlc) value, a creatinine value, an albumin value, a glucose value, an Estimated Glomerular Filtration Rate (EGFR) value, a body mass index (BMI) value, or an age at diagnosis of the medical condition.

8. The method of claim 7, wherein the drug-related information comprises prescription data, the method further comprising: preprocessing the prescription data by one-hot encoding the prescription data before inputting the prescription data into the unsupervised clustering model.

9. The method of claim 1, wherein the plurality of classes of progression comprise at least a high-risk class and a low-risk class.

10. The method of claim 1, the method further comprising: identifying a drug profile for the at least one class of the plurality of classes of progression, wherein the drug profile comprises at least one drug determined to slow the progression of the comorbidity in the at least one class of the plurality of classes, and wherein the recommendation for treatment related to the at least one of the at medical condition or the comorbidity is based on the drug profile.11 . The method of claim 1, wherein the comorbidity comprises a first comorbidity, wherein the dataset is related to the plurality of individuals having the medical condition and a plurality of comorbidities comprising the first comorbidity, the method further comprising performing the extraction of the training data and training of the supervised classification model for each comorbidity, the method further comprising: identifying and prioritizing at least one comorbidity that is more critical than at least one other comorbidity of the plurality of comorbidities; and outputting an indication of the at least one comorbidity as the more critical comorbidity of the plurality of comorbidities.

12. The method of claim 11, wherein the indication comprises a ranking of the plurality of comorbidities.

13. A method comprising: receiving an indication of a medical condition of an individual; receiving a value of a plurality of features related to at least one of the medical condition or the individual; inputting the value of each feature of the plurality of features into a classification model trained to classify the individual into a class of progression of a plurality of classes of progression for developing at least one comorbidity, each class of the plurality of classes of progression having a different rate of progression for developing the comorbidity from the diagnosis of the medical condition; and outputting, the value of each feature of the plurality of features, at least one of the class of progression or a recommendation for treatment related to the medical condition or the comorbidity.

14. The method of claim 13, wherein the recommendation for treatment is based on a correlation between the class of progression and the recommendation that is determined using an unsupervised clustering model.

15. The method of claim 14, further comprising: inputting the plurality of features into the unsupervised clustering model with drug-related information related to a plurality of individuals in the at least one class.

16. The method of claim 1, wherein the medical condition comprises a diabetic condition.

17. The method of claim 16, wherein the comorbidity comprises at least one of chronic kidney disease, neuropathy, retinopathy, or heart disease.

18. The method of claim 17, wherein the at least one feature of the plurality of features comprise at least one of genetic biomarkers, phenotype biomarkers, demographic information, natural language processing (NLP) translated healthcare provider (HCP) notes, contextual information, or other clinical, diagnostic, medial, or demographic information.

19. The method of claim 17, wherein the at least one feature comprises a hemoglobin A1C (HbAlc) value, a creatinine value, an albumin value, a glucose value, an Estimated Glomerular Filtration Rate (EGFR) value, a body mass index (BMI) value, or an age at diagnosis of the medical condition.

20. The method of claim 13, wherein the plurality of classes of progression comprise at least a high-risk class and a low-risk class.

21. The method of claim 13, further comprising: identifying a drug profile for the at least one class of the plurality of classes of progression, wherein the drug profile comprises at least one drug determined to slow the progression of the comorbidity in the at least one class of the plurality of classes, and wherein the recommendation for treatment is based on the drug profile.

22. The method of claim 13, wherein the comorbidity comprises a first comorbidity of a plurality of comorbidities, the method further comprising:outputting, based on the inputting of the value of each feature of the plurality of features into the classification model, an indication of a level of criticalness associated with each of the plurality of comorbidities.

23. The method of claim 22, wherein the indication comprises a ranking of the plurality of comorbidities.

24. An apparatus comprising: a processor configured to perform the method as recited in any of claims 1-12.

25. An apparatus comprising: a processor configured to perform the method as recited in any of claims 13-23.

Images