Classifications

• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
  • G16H50/80—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for detecting, monitoring or modelling epidemics or pandemics, e.g. flu
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N20/00—Machine learning
  • G06N20/10—Machine learning using kernel methods, e.g. support vector machines [SVM]
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N20/00—Machine learning
  • G06N20/20—Ensemble learning
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N3/00—Computing arrangements based on biological models
  • G06N3/02—Neural networks
  • G06N3/04—Architecture, e.g. interconnection topology
  • G06N3/044—Recurrent networks, e.g. Hopfield networks
  • G06N3/0442—Recurrent networks, e.g. Hopfield networks characterised by memory or gating, e.g. long short-term memory [LSTM] or gated recurrent units [GRU]
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N3/00—Computing arrangements based on biological models
  • G06N3/02—Neural networks
  • G06N3/04—Architecture, e.g. interconnection topology
  • G06N3/045—Combinations of networks
  • G06N3/0455—Auto-encoder networks; Encoder-decoder networks
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N3/00—Computing arrangements based on biological models
  • G06N3/02—Neural networks
  • G06N3/04—Architecture, e.g. interconnection topology
  • G06N3/0464—Convolutional networks [CNN, ConvNet]
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N3/00—Computing arrangements based on biological models
  • G06N3/02—Neural networks
  • G06N3/04—Architecture, e.g. interconnection topology
  • G06N3/0475—Generative networks
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N3/00—Computing arrangements based on biological models
  • G06N3/02—Neural networks
  • G06N3/08—Learning methods
  • G06N3/088—Non-supervised learning, e.g. competitive learning
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N3/00—Computing arrangements based on biological models
  • G06N3/02—Neural networks
  • G06N3/08—Learning methods
  • G06N3/0895—Weakly supervised learning, e.g. semi-supervised or self-supervised learning
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N3/00—Computing arrangements based on biological models
  • G06N3/02—Neural networks
  • G06N3/08—Learning methods
  • G06N3/09—Supervised learning
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N5/00—Computing arrangements using knowledge-based models
  • G06N5/01—Dynamic search techniques; Heuristics; Dynamic trees; Branch-and-bound
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N5/00—Computing arrangements using knowledge-based models
  • G06N5/02—Knowledge representation; Symbolic representation
  • G06N5/022—Knowledge engineering; Knowledge acquisition
  • G06N5/025—Extracting rules from data
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N7/00—Computing arrangements based on specific mathematical models
  • G06N7/01—Probabilistic graphical models, e.g. probabilistic networks
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
  • G16H10/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
  • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
  • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
  • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
  • G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
  • G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
  • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
  • G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
  • Y02A—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
  • Y02A90/00—Technologies having an indirect contribution to adaptation to climate change
  • Y02A90/10—Information and communication technologies [ICT] supporting adaptation to climate change, e.g. for weather forecasting or climate simulation

Definitions

• Acute health conditions or illnesses may present challenges for the researchers who track and monitor their prevalences within, and effects on, a population.
• researchers may have short time windows in which to study these acute illnesses and may thus need to gather suitable subjects for analysis quickly.
• Suitable subjects may be those most likely to contract an acute illness or suffer an acute health condition of interest within a short time period.
• methods, systems, computer-readable media, and techniques described herein may implement a machine learning model to identify the factors that best predict infection of acute illnesses or acute health conditions (e.g., COVID-19 infection) in a subject. Information determined from this machine learning analysis may assist with predicting, detecting, and monitoring acute illnesses in a subject or in a population.
• the methods, the systems, the computer-readable media, and the techniques described herein may analyze factors such as local prevalence of the acute illness, based on, for example, information from the Centers for Disease Control and Prevention (CDC).
• CDC Centers for Disease Control and Prevention
• Various other factors may be used to predict infection of a subject, a zone, or a population for the acute illness including the number of potentially risky contacts (e.g., household size and residential situation), location (e.g., living in a city with numerous COVID-19 cases at the time of recruitment), and working in a risky occupation (e.g., healthcare jobs).
• answers to a survey with health queries or wearable device data may also be ingested by the machine learning model to predict infection risk. Based on some or all these factors, the machine learning model may then calculate an infection risk score for a subject, a zone, or a population.
• a health reward platform that encourages its members to develop healthy habits such as walking, meditating, and logging meals.
• the health reward platform may also incentivize members to participate in research by completing surveys and sharing data from commercially available wearable devices provided by companies, such as Fitbit®.
• the health reward platform may be used to monitor annual waves of infectious diseases (e.g., influenza, COVID-19, etc.).
• recruitment for acute illness studies or trials may be done very quickly and in a decentralized manner. For example, participants may be able to participate in the study or trial without having to travel to a center. Rather, testing kits may be mailed and surveys can be taken frequently via a mobile device. Accordingly, these capabilities may improve rapid response to crises, such as COVID-19, and speed up enrollment of the participants for the study or trial.
• subjects with the highest risk scores may be targeted for recruitment for studies or trials (and in some cases, the subjects may be balanced for age, sex, and ethnicity).
• the subjects with the highest risk score may in addition or in alternative, be alerted to their heightened risk for the acute illness so that they may seek appropriate medical care or precautions.
• the subjects with the highest risk score may be prioritized for vaccine distribution, can be flagged for preventative mandates (e.g., quarantines, masks, school or business closures, public health campaigns or education, etc.), or can be notified (e.g., via notification transmission via SMS or emergency communication channels) in advance of potential outbreaks or contractions of the acute illness.
• the machine learning model was applied to recruiting subjects who are currently negative for COVID-19, but are at risk for catching COVID-19.
• the machine learning model was used to select subjects with incidence rates of COVID-19 of a factor of 4 to 7 times higher than the actual incidence rate seen in the placebo arm for three vaccine trials run in the US, which can be considered as a baseline for incidence rate in a representative, non-enriched, population.
• the machine learning model may enable trials or studies (e.g., for developing vaccines) to cut their candidate populations by the same factor (four to seven times) or allow studies or trials to be performed much more quickly, thereby reducing costs, saving resources, and potentially improving public health and safety.
• FIG. 1 shows a non-limiting example of a block diagram of an environment for modeling an outbreak
• FIG. 2A shows a non-limiting example of a flowchart illustrating a method for assembling a pool of high-risk subjects for developing an acute illness
• FIG. 2B shows a non-limiting example of a flowchart illustrating a method for presenting information to a subject about an acute illness
• FIG. 3 shows a non-limiting example of data illustrating feature importance
• Fig. 4 shows a non-limiting example of a workflow for collecting data
• Fig. 5A shows a non-limiting example of a workflow for onboarding and enrolling users
• Fig. 5B shows a non-limiting example of a workflow for user participation
• Figs. 6A-6F show various a non-limiting examples of user interfaces used for collecting data
• FIG. 7 shows a non-limiting example of a computing device; in this case, a device with one or more processors, memory, storage, and a network interface; and
• Fig. 8 shows a non-limiting example of a random forest with a plurality of decision trees.
• Recruiting for clinical trials may be conducted by techniques such as advertisements, direct provider contact, etc.
• the techniques of advertising, direct provider contact, etc. may be costly (in terms of financial resources, time, communication resources, etc.).
• the techniques of advertising, direct provider contact, etc. may be too slow to achieve enrollment for spreading and contracting of acute illnesses.
• the slowness of the techniques of advertising, direct provider contact, etc. may be particularly problematic for infectious diseases, such as COVID-19.
• the methods, the systems, the computer-readable media, and the techniques described herein may predict, detect, or monitor subjects, zones, populations, etc. that are at high risk for an acute illness (e.g., infectious disease). These high-risk subjects, zones, populations, etc. can be prioritized for vaccine distribution, can be flagged for preventative mandates (e.g., quarantines, masks, school or business closures, public health campaigns or education, etc.), or can be notified (e.g., via notification transmission via SMS or emergency communication channels) in advance of potential outbreaks or contractions of the acute illness.
• the methods, the systems, the computer-readable media, and the techniques can be used to recruit subjects, zones, populations, etc. for participation in studies or trials, based on, for example, their risk for the acute illness.
• artificial intelligence As used in this specification and the appended claims, the terms “artificial intelligence,” “artificial intelligence techniques,” “artificial intelligence operation,” and “artificial intelligence algorithm” generally refer to any system or computational procedure that may take one or more actions to enhance or maximize a chance of achieving a goal.
• artificial intelligence may include “generative modeling,” “machine learning” (ML), or “reinforcement learning” (RL).
• machine learning As used in this specification and the appended claims, the terms “machine learning,” “machine learning techniques,” “machine learning operation,” and “machine learning model” generally refer to any system or analytical or statistical procedure that may progressively improve computer performance of a task.
• acute illness may generally refer to an abnormal or detrimental condition of the body that may develop rapidly and last for a short period, including infectious diseases.
• acute illness may be used interchangeably herein with “acute condition” or “acute health condition.”
• the indefinite articles “a” or “an,” and the corresponding associated definite articles “the” or “said,” are each intended to mean one or more unless otherwise stated, implied, or physically impossible. Yet further, it should be understood that the expressions “at least one of A and B, etc.,” “at least one of A or B, etc.,” “selected from A and B, etc.” and “selected from A or B, etc.” are each intended to mean either any recited element individually or any combination of two or more elements, for example, any of the elements from the group consisting of “A,” “B,” and “A AND B together,” etc.
• “about” or “approximately” may mean within an acceptable error range for the value, which will depend in part on how the value is measured or determined, e.g., the limitations of the measurement system. For example, “about” may mean within 1 or more than 1 standard deviation, per the practice in the art. Alternatively, “about” may mean a range of up to 20%, up to 10%, up to 5%, or up to 1% of a given value. Where values are described in the application and claims, unless otherwise stated the term “about” meaning within an acceptable error range for the particular value may be assumed.
• machine learning may generally involve identifying and recognizing patterns in existing data in order to facilitate making predictions for subsequent data.
• Machine learning may include a machine learning model (which may include, for example, a machine learning algorithm).
• Machine learning whether analytical or statistical in nature, may provide deductive or abductive inference based on real or simulated data.
• the machine learning model may be a trained model.
• Machine learning may comprise one or more supervised, semi-supervised, self-supervised, or unsupervised machine learning techniques.
• an ML model may be a trained model that is trained through supervised learning (e.g., various parameters are determined as weights or scaling factors).
• Training the machine learning model may include, in some cases, selecting one or more untrained data models to train using a training data set.
• the selected untrained data models may include any type of untrained machine learning models for supervised, semi-supervised, selfsupervised, or unsupervised machine learning.
• the selected untrained data models be specified based upon input (e.g., user input) specifying relevant parameters to use as predicted variables or other variables to use as potential explanatory variables.
• the selected untrained data models may be specified to generate an output (e.g., a prediction) based upon the input.
• Conditions for training the machine learning model from the selected untrained data models may likewise be selected, such as limits on the machine learning model complexity or limits on the machine learning model refinement past a certain point.
• the machine learning model may be trained (e.g., via a computer system such as a server) using the training data set.
• a first subset of the training data set may be selected to train the machine learning model.
• the selected untrained data models may then be trained on the first subset of training data set using appropriate machine learning techniques, based upon the type of machine learning model selected and any conditions specified for training the machine learning model.
• the selected untrained data models may be trained using additional computing resources (e.g., cloud computing resources). Such training may continue, in some cases, until at least one aspect of the machine learning model is validated and meets selection criteria to be used as a predictive model.
• one or more aspects of the machine learning model may be validated using a second subset of the training data set (e.g., distinct from the first subset of the training data set) to determine accuracy and robustness of the machine learning model.
• Such validation may include applying the machine learning model to the second subset of the training data set to make predictions derived from the second subset of the training data.
• the machine learning model may then be evaluated to determine whether performance is sufficient based upon the derived predictions.
• the sufficiency criteria applied to the machine learning model may vary depending upon the size of the training data set available for training, the performance of previous iterations of trained models, or user-specified performance requirements. If the machine learning model does not achieve sufficient performance, additional training may be performed.
• Additional training may include refinement of the machine learning model or retraining on a different first subset of the training dataset, after which the new machine learning model may again be validated and assessed.
• the machine learning may be stored for present or future use.
• the machine learning model may be stored as sets of parameter values or weights for analysis of further input (e.g., further relevant parameters to use as further predicted variables, further explanatory variables, further user interaction data, etc.), which may also include analysis logic or indications of model validity in some instances.
• a plurality of machine learning models may be stored for generating predictions under different sets of input data conditions.
• the machine learning model may be stored in a database (e.g., associated with server).
• ML may comprise one or more of regression analysis, regularization, classification, dimensionality reduction, ensemble learning, meta learning, association rule learning, cluster analysis, anomaly detection, deep learning, or ultra-deep learning.
• ML may comprise, but is not limited to: k-means, k-means clustering, k-nearest neighbors, learning vector quantization, linear regression, non-linear regression, least squares regression, partial least squares regression, logistic regression, stepwise regression, multivariate adaptive regression splines, ridge regression, principal component regression, least absolute shrinkage and selection operation, least angle regression, canonical correlation analysis, factor analysis, independent component analysis, linear discriminant analysis, multidimensional scaling, non-negative matrix factorization, principal components analysis, principal coordinates analysis, projection pursuit, Sammon mapping, t-distributed stochastic neighbor embedding, AdaBoosting, boosting, gradient boosting, bootstrap aggregation, ensemble averaging, decision trees, conditional decision trees, boosted decision trees, gradient boosted decision trees, random forests, stacked general
• the machine learning model may implement a decision tree.
• a decision tree may be a supervised machine learning algorithm that can be applied to both regression and classification problems. Decision trees may mimic the decision-making process of a human brain. For example, a decision tree may grow from a root (base condition), and when it meets a condition (internal node/feature), it may split into multiple branches. The end of the branch that does not split anymore may be an outcome (leaf).
• a decision tree can be generated using a training data set according to the following operations: (1) Starting from a root node (the entire dataset), the algorithm may split the dataset in two branches using a decision rule or branching criterion; (2) each of these two branches may generate a new child node; (3) for each new child node, the branching process may be repeated until the dataset cannot be split any further; (4) each branching criterion may be chosen to maximize information gain (e.g., a quantification of how much a branching criterion reduces a quantification of how mixed the labels are in the children nodes).
• the labels may be the data or the classification that is predicted by the decision tree.
• a random forest regression is an extension of the decision tree model that tends to yield more robust predictions by stretching the use of the training data partition. Whereas a decision tree may make a single pass through the data, a random forest regression may bootstrap 50% of the data (e.g., with replacement) and build many trees. Rather than using all explanatory variables as candidates for splitting, a random subset of candidate variables may be used for splitting, which may enable trees that have completely different data and different variables (hence the term random). The predictions from the trees, collectively referred to as the “forest,” may be then averaged together to produce the final prediction.
• Random forests may be trained in a similar way as decision trees. Specifically, training a random forest may include the following operations: (1) select randomly k features from the total number of features; (2) create a decision tree from these k features using the same operations as for generating a decision tree; and (3) repeat the previous two operations until a target number of trees is created.
• Fig. 8 illustrates a random forest 800.
• the random forest 800 (which may also be referred to as random forest model) is an ensemble of decision trees 805, 810, and 815 with randomly selected features in each of the decision trees 805, 810, and 815 so that it can provide more stable and accurate outcomes. Outcomes may be determined by majority voting in the case of a classification problem.
• the random forest 800 which has been trained previously by a training method, is used to decide between classifications A, B and C.
• the random forest 800 with only the three decision trees shown in Fig. 8, would return the classification A by majority voting.
• Acute illnesses may be severe. Acute illnesses may last a few days or a few weeks. An acute illness may develop in periods of fractions of a second, seconds, minutes, hours, a few days, or a few weeks. Chronic conditions, or long-developing conditions, may cause acute conditions or illnesses. For example, osteoporosis may result in a broken bone.
• An acute illness or acute health condition may be a disease.
• An acute illness or health condition may be an infectious disease.
• An acute illness may be a viral or bacterial infection.
• An acute illness may be a respiratory illness such as the common cold, influenza, a coronavirus disease (e.g., coronavirus disease 2019 (COVID-19) or severe acute respiratory syndrome (SARS)), acute respiratory distress syndrome, pharyngitis, acute bronchitis, or acute asthma.
• An acute illness may be a non-infectious disease, such as acute leukemia, acute myocardial infarction, acute gastroenteritis, or acute hepatitis.
• An acute illness or acute health condtion may be an injury.
• An injury may be caused by an external trauma to the body or by a sudden movement of the body, for example, during exercise or a sport.
• An injury may be a broken bone, a sprain, a strain, a dislocation, a bruise, a cut, a gash, or a tear.
• An acute illness or acute health condition may be a mental condition.
• Non-limiting examples of acute mental conditions may be depressive episodes, manic episodes, psychotic episodes, panic attacks, acute stress disorder, or post-traumatic stress disorder.
• Fig. l is a block diagram of an environment 100 for modeling risk of an acute illness to one or more subjects, in accordance with some cases.
• the environment 100 of FIG. 1 includes one or more user devices 110(l)-110(N), a network 120, and a computer system 130 with a modeling unit 135.
• the user devices 110(l)-110(N) may be used by one or more users (e.g., humans, animals, etc.) to collect or provide, via the network 120, data about the one or more users to the computer system 130 so that the computer system 130, using the modeling unit 135, can predict risk of an acute illness to the one or more subjects or a population (e.g., including at least a portion of the one or more subjects).
• the user devices 110(l)-110(N) may be one or more electronic devices.
• the electronic devices may be mobile devices.
• the mobile devices may be smartphones (e.g., the user device 110(2)) or tablets (e.g., see the user device 110(N)).
• the electronic devices may be wearable devices.
• the wearable devices may be smartwatches (e.g., the user device 110(1)), smartbands (e.g., a Fitbit® device), smartclothing, smart jewelry, smartshoes, or the like.
• the electronic devices may be a laptop or desktop computer.
• the electronic devices may be gaming devices (e.g., the gaming device may collect data as part of a game or may reward users based on certain collected data or outcomes).
• the user devices 110(l)-110(N) may be any device suitable for collecting data such as wearable device data, responses to queries, geographical data, demographical data, or any other health data or the like.
• the user devices 110(1)- 110(N) may be any one or more of desktop computers, laptop computers, notebook computers, sub-notebook computers, netbook computers, netpad computers, set-top computers, media streaming devices, handheld computers, Internet appliances, mobile smartphones, tablet computers, personal digital assistants, video game consoles, vehicles, televisions, exercise equipment, video players, digital music players, booklet tablet computers, slate tablet computers, convertible tablet computers, or the like.
• Each of the user devices 110(l)-110(N) may be linked to, and collect data from, a single user.
• Each the user devices 110(l)-110(N) may be linked to, and collect data from, multiple users (e.g., a household).
• the user devices 110(l)-110(N) can be wearable devices or other device capable of providing physical (e.g., medical, activity, nutrition, etc.) statistics about one or more users.
• the user devices 110(l)-110(N) can be a dedicated fitness tracker, a pedometer, a sleep tracker, a smart watch, smartphone, or mobile device (e.g., a tablet computer or a personal digital assistant (PDA)) with physical statistic monitoring functionality.
• the user devices 110(l)-110(N) can be a smartphone of one or more users with an installed physical statistic monitoring application using one or more sensors of the smartphone to measure steps, activity, movement, sleep time, or other physical statistics.
• a user may be associated with multiple devices of the user devices 110(l)-110(N) measuring overlapping or distinct physical statistics about the user.
• a smartphone may measure sleep behavior or sleep efficiency of the user (e.g., based on when the user uses the device)
• a pedometer may measure step counts of the user
• a smart exercise machine may measure blood pressure of the user.
• the physical statistic data gathered by the user devices 110(l)-110(N) can be sent to the computer system 130 directly from the user devices 110(1)- 110(N), manually uploaded to the computer system 130 by the associated users or transmitted via a third-party system to the computer system 130.
• a user may authorize a third- party service associated with the user devices 110(l)-110(N) to transmit physical activity data to the computer system 130.
• a user can interact with the computer system 130 via the user devices 110(l)-110(N).
• a user may be able to update information about themself stored in the computer system 130 via the user devices 110(l)-110(N).
• a user can interact with the user devices 110(l)-110(N) via an external device (not shown; e.g., a laptop, a smartphone, etc.).
• the user may configure settings the user devices 110(l)-110(N) through the external device (e.g., turn one or more of the user devices 110(1)- 110(N) on/off, change a sampling rate, etc.).
• a user may further be able to provide feedback relating to one or more predictions generated using the computer system 130 or manually report health information to the computer system 130 via the user devices 110(1)- 110(N).
• the user may, e.g., through one or more of the user devices 110(l)-110(N), report to the computer system 130 that they have the flu or an influenza-like illness, which may be used by the computer system 130 in training models to recognize features of received physical statistical data indicative of certain health conditions.
• Each user of the user devices 110(l)-110(N) may be a member of a population monitored by the computer system 130.
• each user is associated with one or more of the user devices 110(l)-110(N) measuring physical statistics of that user.
• the user devices 110(l)-110(N) can measure a user’s resting heart rate (RHR) over time, a daily number of steps (or other measure of activity level such as distance walked), and sleep statistics (such as duration of sleep, number of times sleep was interrupted, sleep start and end times, etc.) for the user.
• RHR resting heart rate
• sleep statistics such as duration of sleep, number of times sleep was interrupted, sleep start and end times, etc.
• Recorded physical statistics from the user devices 110(l)-110(N) may be stored as physical statistic data and sent by the user devices 110(l)-110(N) to the computer system 130 for analysis.
• some or all physical statistic data is collected as time series data, or periodically recorded measurements of physical statistics of the user over time.
• the frequency of measurements included in the physical statistics data sent to the computer system 130 can depend on the user devices 110(l)-110(N), user preference selections, or the type of physical statistic data being collected.
• the user devices 110(l)-110(N) may send time series data for average RHR multiple times per day, but send hours slept data once per day.
• the user devices 110(l)-110(N) may send physical statistic data to the computer system 130 frequently, for example, hourly or in real time.
• the user devices 110(l)-110(N) may communicate with the computer system 130 over the network 120.
• the network 120 may be a network or system of networks connecting the computer system 130 to the user devices 110(l)-110(N)
• the network 120 may comprise any combination of local area or wide area networks, using wired or wireless communication systems.
• the network 120 uses standard communications technologies or protocols.
• the network 120 can include communication links using technologies such as Ethernet, 3G, 4G, CDMA, WIFI, and Bluetooth.
• Data or information exchanged over the network 120 may be represented using any suitable format, such as hypertext markup language (HTML) or extensible markup language (XML).
• HTML hypertext markup language
• XML extensible markup language
• the network 120 also facilitates communication between the computer system 130, the user devices 110(1)- 110(N), and other entities of the environment 100 such as the modeling unit 135, users (not shown) or other external devices (not shown).
• the computer system 130 may comprise computer devices such as a server, server cluster, distributed server, or cloud-based server capable of predicting health conditions, statistics, risks, etc.
• the computer system 130 using the modeling unit 135, may predict chronic health conditions (CHC) symptoms, acute illness symptoms, or any other health issue for a user within a population based on physical statistics received from that user.
• the computer system 130 gathers physical statistics about a set of users within a population (e.g., through data from one or more of the user devices 110(l)-110(N)). Physical statistics may be measurements characterizing a user’s activity level or current health state (such as from the user devices 110(l)-110(N), or other sources).
• physical statistics can include measurements of the user’s vital signs such as body temperature, resting heart rate (RHR), blood pressure, current heart rate (for example, presented as a time series), heart rate variability, respiration rate, or galvanic skin response, measurements of user activity such as daily number of steps, distance walked, time active, or exercise amount, sleep statistics such as time slept, number of times sleep was interrupted, or sleep start and end times, or other similar metrics.
• vital signs such as body temperature, resting heart rate (RHR), blood pressure, current heart rate (for example, presented as a time series), heart rate variability, respiration rate, or galvanic skin response
• measurements of user activity such as daily number of steps, distance walked, time active, or exercise amount
• sleep statistics such as time slept, number of times sleep was interrupted, or sleep start and end times, or other similar metrics.
• the computer system 130 can analyze received physical statistic data to extract learned features or generate a learned representation of the physical statistic data using the modeling unit 135.
• the learned representation generated by the modeling unit 135 may store a transformed, modified, or compressed version of raw physical statistic data. This version of the raw physical statistic data (or wearable device data) may preserve richness of information and useful features that may be used to identify trends or outliers among data gathered across a large population, predict health conditions, segment, cluster, or categorize data from different users, or the like.
• outputs e.g., predictions of risk of an acute illness to a user or a population
• from the computer system 130 may be shared.
• the outputs from the computer system 130 may be shared with the corresponding user.
• the outputs from the computer system 130 may be shared with researchers or a laboratory (e.g., for studying infectious diseases), with consent from the corresponding user.
• the outputs from the computer system 130 may be shared with healthcare providers (e.g., the corresponding user’s primary care physician), with consent from the corresponding user.
• the healthcare providers may maintain a computing system such as a server, set of servers, server cluster, etc. which can create or modify an individual treatment plan or perform interventions based on predicted health conditions generated using the computer system 130.
• the computing system of the healthcare providers can be managed by a medical provider, doctor, or other entity providing medical care to a user for a health condition.
• Fig. 2A is a flowchart illustrating an example method 200A for assembling a pool of high-risk subjects for developing an acute illness, in accordance with some embodiments.
• the method 200A may be implemented using one or more systems (e.g., hardware or software) described herein (e.g., the environment 100).
• the method 200A may implement one or more techniques described herein (e.g., the workflow 400).
• the method 200A may include obtaining, from a plurality of subjects, (i) one or more responses to one or more health queries, and (ii) geographic incidence data for an acute illness (block 205A); predicting, using a machine learning model, a risk of developing the acute illness for the plurality of subjects based on the one or more responses and the geographic incidence data (block 210A); identifying a pool of high-risk subjects from the plurality of subjects, wherein the risk of developing the acute illness for each subject of the pool of high-risk subjects satisfies a threshold (block 215A); and outputting the pool of high-risk subjects (block 220A).
• the method 200A may be implemented using systems that may be the same as or similar to the systems of the environment 100 of Fig.
• One or more operations in the method 200B may be performed on a repeating or iterative basis, for example, at some time interval or frequency.
• the method 200A may begin with obtaining, from the plurality of subjects (i) the one or more responses to the health queries, and (ii) the geographic incidence data for the acute illness at the block 205A.
• the health queries may include one or more of the health queries described with respect to Fig. 3, or queries of a similar nature. In general, the health queries may be used to assess a subject’s, zone’s, population’s, etc. risk of an acute illness.
• the health queries may comprise one or more of a household composition query, an occupation query, a residence query, or an infected contact query.
• the responses to the one or more health queries may be obtained at a computer system.
• the responses may be obtained at a mobile device, such as a smartphone or a wearable device.
• the responses may include text data, video data, audio data, etc.
• the responses may include physiological data that includes one or more of resting heart rate data, sleep data, step count data, blood pressure data, caloric data, nutrition data, or body temperature data.
• the geographic incidence data may generally be data about the spread of an acute illness over a geographic area.
• the geographic incidence data may be over a continent, a country, a region, a state, a province, a county, a jurisdiction, a zip code, a city, a township, a village, a neighborhood, a street, a block, a property, etc.
• the geographic incidence data is associated with a plurality of zip code tabulation areas (ZCTAs).
• ZCTAs zip code tabulation areas
• the method 200A may include predicting, using the machine learning model, the risk of developing the acute illness for the plurality of subjects based on the one or more responses and the geographic incidence data at the block 210A.
• the machine learning model may be built to predict risk for the plurality of subjects developing the acute illness.
• the machine learning model may be a decision tree algorithm.
• the machine learning model may be a random forest model.
• the machine learning model may be a generative additive model (GAM).
• GAM generative additive model
• the machine learning model may be built using county-level incidence rates as the geographic incidence data. In some cases, the county-level incidence rates may be reported by a news organization or government entity.
• a three-dimensional GAM may be fit to the geographic incidence data, with the geographic positioning (e.g., latitude and longitude of the county centroid, borders of the county, etc.) and week number as predictors.
• the mean squared error of the machine learning model’s predictions for weeks following the training period may be calculated across the following hyperparameters: smoother for the longitude and latitude (tensor product or cubic regression with shrinkage) and the rank of the smooths (4, 6, or 8).
• the best-performing machine learning model uses a rank-6 temporal product smoother for the spatial components, and a rank-4 cubic regression spline with shrinkage for week number.
• These hyper-parameters may then be used to build a series of machine learning models that predict the incidence rate for each ZCTA and week number of the response period using county-level incidence rate for the preceding 10 weeks.
• three predictors were added using these models: the predicted COVID- 19 incidence rate for the respondents' home ZCTA at the week of diagnosis, and the predictions for the preceding two weeks.
• respondents who did not report a COVID-19 diagnosis may be assigned a random "week of diagnosis" for this purpose.
• the machine learning model described herein can be used to identify high risk individuals, to identify high risk zones, or a combination of the two.
• These high-risk individuals and high-risk zones can be prioritized for vaccine distribution, can be flagged for preventative mandates (e.g., masks, school/business closures, etc.), or can be notified in advance of potential outbreaks (e.g., via notification transmission via SMS or emergency communication channel).
• preventative mandates e.g., masks, school/business closures, etc.
• potential outbreaks e.g., via notification transmission via SMS or emergency communication channel.
• the machine learning model described herein can also be used to recruit individuals for participation in studies or trials, as described below.
• the method 200A may include identifying the pool of high-risk subjects from the plurality of subjects, wherein the risk of developing the acute illness for each subject of the pool of high-risk subjects satisfies the threshold at the block 215A.
• the threshold for each subject of the pool of high-risk subjects may be a likelihood (e.g., percentage) that the subject will contract the acute illness.
• the pool of high-risk subjects may include any number of subjects, provided each of the subjects has a certain likelihood (e.g., 70% likelihood over the next month) of contracting the acute illness.
• the pool of high- risk subjects may have a specified number (e.g., a maximum, minimum, a target number, etc.) of subjects to be included in the pool of high-risk subjects.
• the pool of high-risk subjects may have a threshold such that the 100 subjects with the highest risk are identified to be in the pool of high-risk subjects.
• the method 200A may include outputting the pool of high-risk subjects at the block 220A.
• the output may include identifiers (e.g., name, contact information, identification number, etc.) of the subjects identified in the pool of high-risk subjects.
• Outputting the pool of high-risk subjects may include providing the output (e.g., the identifiers) as text, audio, video, image, or the like.
• the output may be displayed on a graphical user interface.
• the output may be stored (e.g., in a memory or database) for later use.
• the method 200A may include predicting an incidence of the acute illness for a population (e.g., for a population comprising the pool of high-risk subjects or for a population similar in at least one characteristic common to the pool of high-risk subjects). Predicting the incidence rate for the acute illness for the population may comprise processing wearable device sensor data, demographic data, and/or geographic data with a second machine learning model that may be different from the machine learning model used for generating the high-risk pool.
• predicting the incidence rate for the acute illness for the population may comprise processing data with the same machine learning model (e.g., applied in a different manner) as the machine learning model used generating the high-risk pool.
• the incidence rate over the population may be predicted for a past, present, or future time period.
• the method 200A may include conducting a study for a vaccine for the acute illness by a population (e.g., a population comprising the pool of high-risk subjects).
• a vaccine trial e.g., a phase II or phase III trial
• vaccine efficacy may be determined based on comparing infection rates between subjects with the placebo and subjects with the actual vaccine.
• An effective vaccine may be a vaccine for which the subjects with the placebo are infected at a higher rate than the subjects with the vaccine, where the higher rate is statistically significant. By enriching the vaccine trial with more subjects who are likely to become infected, the overall pool of subjects recruited for the vaccine trial may be smaller.
• Conducting the vaccine study may comprise processing wearable device sensor data, demographic data, and/or geographic data with a second machine learning model that may be different from the machine learning model used for generating the pool of high-risk subjects.
• conducting the vaccine study may comprise processing data with the same machine learning model (e.g., applied in a different manner) as the machine learning model used for genering the high-risk pool.
• the vaccine study may be conducted for a past, present or future time period.
• Fig. 2B is a flowchart illustrating an example method 200B for presenting information about an acute illness to a subject, in accordance with some cases.
• the method 200B may be implemented using one or more systems (e.g., hardware or software) described herein (e.g., the environment 100).
• the method 200B may implement one or more techniques described herein (e.g., the workflow 400).
• the method 200B may include obtaining wearable device sensor data from the subject (block 205B); obtaining, via a mobile device, a response to a health query of whether the subject has a symptom associated with the acute illness (block 210B); predicting, using a machine learning model, a risk of the subject developing the acute illness based at least in part on the wearable device sensor data and the response to the health query (block 215B); and causing an electronic display to indicate the risk to the subject (block 220B).
• the method 200B may be implemented using systems that may be the same as or similar to the systems of the environment 100 of Fig. 1, or the computer system 700 of Fig. 7. One or more operations in the method 200B may be performed on a repeating or iterative basis, for example, at some time interval or frequency.
• the method 200B may begin with obtaining wearable device sensor data from the subject at the block 205B.
• the wearable device sensor data may be collected via one or more wearable devices worn by the subject.
• the wearable devices may be smartwatches (e.g., the user device 110(1) of Fig. 1), smartbands (e.g., a Fitbit® device), smartclothing, smartshoes, or the like.
• the wearable device sensor data may include physiological data that includes one or more of resting heart rate data, sleep data, step count data, blood pressure data, caloric data, nutrition data, or body temperature data.
• the wearable device sensor data may include physical statistics of the subject.
• the physical statistics can include measurements of the subject’s vital signs such as body temperature, resting heart rate (RHR), blood pressure, current heart rate (for example, presented as a time series), heart rate variability, respiration rate, or galvanic skin response, measurements of user activity such as daily number of steps, distance walked, time active, or exercise amount, sleep statistics such as time slept, number of times sleep was interrupted, or sleep start and end times, or other similar metrics.
• the wearable device may present the wearable device data to the subject using, for example, a graphical user interface or speakers.
• the wearable device may collect (and, in some cases, provide to a machine learning model) the wearable device sensor data on a repeating basis (e.g., at some time interval or frequency).
• the method 200B may include obtaining, via the mobile device, the response to the health query of whether the subject has the symptom associated with the acute illness at the block 210B. Similar to the health queries described with respect to the block 205A, the health query may ask a subject directly (e.g., “Do you have symptoms of COVID-19?”, etc.) or indirectly (e.g., “Do you have a fever?”, “Do you feel tired?”, etc.) if they have symptoms associated with the acute illness.
• the response from the subject may be a string. The string may be interpreted (e.g., categorized) by algorithms.
• the method 200B may include predicting, using the machine learning model, the risk of the subject developing the acute illness based at least in part on the wearable device sensor data and the response to the health query at the block 215B.
• the machine learning model may leverage the wearable device sensor data to identify the high-risk subjects at the right time, and possibly match them with an according action.
• the machine learning model may be a decision tree algorithm.
• the machine learning model may be a random forest model.
• the machine learning model may be a GAM.
• the machine learning model may be the same as or similar to, in at least some aspects, the machine learning model described with respect to the block 210A.
• Fig. 3 shows a non-limiting example of data 300 illustrating feature importance of different variables.
• the variables may be responses to one or more health queries.
• the data 300 illustrates feature importance for predicting an incidence rate of an acute illness in a pool of subjects, where the acute illness is COVID-19 and the prediction is made via a random forest machine learning model.
• feature importance is measured as the total decrease in node impurities (measured with the Gini index) from splitting on that variable.
• the data 300 includes variables of adult household size, lag 1 cases per 1000, lag 0 cases per 1000, lag 2 cases per 1000, self primary healthcare setting, contact with COVID-19, self healthcare occupation, self COVID-19 risk, residential situation, and number contact without distancing.
• the most important variable, as illustrated, is adult household size.
• the adult household size variable may be an integer that is the response, from each of the subjects in the pool to a question, "How many adults (age 18+) currently live in your household (including yourself)? Include roommates, or if you are living in a group home, the total number of adults you share common living spaces with.”
• the variables Lag (0, 1, 2) may correspond to a series of hotspot prediction models built using county-level prevalence data provided by public data sources (e.g., government entity, news outlets, etc.).
• a three-dimensional generative adversarial model may be fit to prevalence values with latitude, longitude, and (week number) as predictors, for weeks 1-N. In some cases, this model may predict for week N+l .
• the predicted prevalence rate may be determined for the associated zip code for the week number of the response and the preceding two weeks.
• the variable self primary healthcare setting may correspond to a response (e.g., subject response) to, "In which healthcare setting do you primarily work in?"
• the variable contact with COVID-19 may correspond to a response (e.g., subject response) to, "Have you been in prolonged close contact (e.g., within 6 feet for at least 10 minutes) with someone who was diagnosed with COVID-19?"
• the variable self healthcare operation may correspond to a response (e.g., subject response) to, "Do you work in one of the following healthcare-related occupations?"
• the variable self COVID-19 risk may correspond to a response (e.g., subject response) to, "What do you believe is your personal risk of getting COVID-19?
• variable residential situation may correspond to a response (e.g., subject response) to, “What is your current residential situation?"
• the variable number contacted without distancing may correspond to a response (e.g., subject response) to “"On an average workday, how many individuals do you closely interact with that do not follow social distancing recommendations (e.g., have a face-to-face conversation, help with a task and do not stay at least 6 feet apart)?”
• One or more of the responses to the above questions may be a string.
• the string may be interpreted (e.g., categorized) by algorithms.
• One or more of the responses to the above questions may be selected (e.g., by a user) from a series of options (e.g., multiple choice options for different careers).
• One or more of the responses to the above questions may be positive or negative (e.g., yes or no).
• Fig. 4 shows an example of a workflow 400 for collecting data that may be used in conjunction with systems, methods, computer-readable media, or techniques described herein.
• the workflow 400 may be used for assembling a pool of high-risk subjects for developing an acute illness or for presenting information to a subject about an acute illness, such as described with respect to the method 200A of Fig. 2A and method 200B of Fig. 2B, respectively.
• the workflow 400 may be implemented using systems that may be the same as or similar to the systems of the environment 100 of Fig. 1, or the computer system 700 of Fig. 7.
• the workflow 400 may begin with ingesting wearable device sensor data from a plurality of users.
• the users may be nearby a clinical site.
• the wearable device sensor data may be ingested from users who are within 30 miles of a clinical site, as illustrated.
• the users may be any distance from a clinical site.
• the wearable device sensor data may be ingested at some frequency.
• the wearable device sensor data may be ingested hourly, twice a day, daily, weekly, monthly, or some other suitable frequency.
• the wearable device sensor data may be ingested daily.
• the wearable device sensor data may be collected via one or more wearable devices worn by a user.
• the wearable devices may be smartwatches (e.g., the user device 110(1) of Fig. 1), smartbands (e.g., a Fitbit® device), smartclothing, smartshoes, or the like.
• the wearable device sensor data may include physiological data that includes one or more of resting heart rate data, sleep data, step count data, blood pressure data, caloric data, nutrition data, or body temperature data.
• the wearable device sensor data may include physical statistics of the user.
• the physical statistics can include measurements of the user’s vital signs such as body temperature, resting heart rate (RHR), blood pressure, current heart rate (for example, presented as a time series), heart rate variability, respiration rate, or galvanic skin response, measurements of user activity such as daily number of steps, distance walked, time active, or exercise amount, sleep statistics such as time slept, number of times sleep was interrupted, or sleep start and end times, or other similar metrics.
• the wearable device may present the wearable device data to the user using, for example, a graphical user interface or speakers.
• the wearable device sensor data may be provided to a machine learning model for analysis.
• the machine learning model may predict the risk of each user developing an acute illness (e.g., influenza-like illness, as illustrated) based at least in part on the wearable device sensor data.
• the machine learning model may leverage the wearable device sensor data to identify the high-risk subjects at the right time, and possibly match them with an according action (e.g., refer them to a nearby clinical site).
• the machine learning model may be a decision tree algorithm.
• the machine learning model may be a random forest model.
• the machine learning model may be a generative additive model.
• the machine learning model may be the same as or similar to, in at least some aspects, the machine learning model described with respect to the block 210A or the block 210B
• the machine learning model predicts that a user has symptoms consistent with the acute illness (e.g., influenza-like illness, as illustrated), then the user may be prompted with additional health queries.
• the additional health queries may be about risk factors (e.g., household size and residential situation, location, occupation, etc.), about physiological data (e.g., resting heart rate data, sleep data, step count data, blood pressure data, caloric data, nutrition data, or body temperature data), or about symptoms (e.g., fever, cough, congestion, aches, nausea, etc.).
• the workflow 400 may exit. In some cases, if a user does not answer the additional health queries, the workflow 400 may exit. In some cases, if a user does provide answers to the additional health queries, but the answers suggest that the user does not have, or is not at a high risk of having, the acute illness, the workflow 400 may exit. Similarly, in some cases, if the machine learning model predicts that a user does not have symptoms consistent with the acute illness, the workflow 400 may exit rather than prompt the user with the additional health queries.
• the workflow 400 may take action.
• the action may include enabling the user to enroll in a study or trial (e.g., at a nearby clinical site).
• the action may include alerting the user that they have a high risk of having the acute illness (e.g., via a graphical user interface).
• the action may include suggesting medication (e.g., over the counter, behind-the-counter, prescription, non-traditional, etc.) or behavior (e.g., resting, eating fruit, apply cold or hot compresses, etc.) to help reduce the effects of, or prevent, the acute illness.
• the action may include contacting a medical provider on behalf of the user.
• the action may include sharing (with user consent) the wearable device sensor data with the study or trial or with the medical provider.
• the action may include sharing (with user consent) the acute illness risk prediction with the study or trial or with the medical provider.
• Fig. 5A shows an example of a workflow 500A for onboarding and enrolling users that may be used in conjunction with systems, methods, computer-readable media, or techniques described herein.
• the workflow 500A may be used for assembling a pool of high- risk subjects for developing an acute illness or for presenting information to a subject about an acute illness, such as described with respect to the method 200A of Fig. 2A and method 200B of Fig. 2B, respectively.
• the workflow 500A may be implemented using systems that may be the same as or similar to the systems of the environment 100 of Fig. 1, or the computer system 700 of Fig. 7.
• the workflow 500A may begin with onboarding a new user or enabling a returning user to login to their account.
• Onboarding a new user may include obtaining information (e.g., health history, demographics, contact information, biographical information, occupation, residential information, etc.) of the user.
• information e.g., health history, demographics, contact information, biographical information, occupation, residential information, etc.
• the user may be able to enroll in a study or trial.
• the study or trial may be specific to an acute illness, such as influenza-like symptoms, as illustrated.
• the workflow 500A may include providing information about the acute illness or the process predicting risk of the acute illness.
• the user may agree to consent and terms of service in the workflow 500A.
• the user may agree to collection of certain types of data (e.g., wearable device sensor data), sharing certain types of data (e.g., with the trial or study, with healthcare providers, etc.), etc.
• the workflow 500A may further include determining if the user is eligible to participate in the study or trial. Eligibility may be based on demographics, symptoms, size of the study or trial, health history, or other suitable factors. If the user is eligible, the user may confirm enrollment in the study or trial in the workflow 500A.
• Fig. 5B shows an example of a workflow 500B for user participation that may be used in conjunction with systems, methods, computer-readable media, or techniques described herein.
• the workflow 500B may be used for assembling a pool of high-risk subjects for developing an acute illness or for presenting information to a subject about an acute illness, such as described with respect to the method 200A of Fig. 2A and method 200B of Fig. 2B, respectively.
• the workflow 500B may be implemented using systems that may be the same as or similar to the systems of the environment 100 of Fig. 1, or the computer system 700 of Fig. 7.
• the workflow 500B may be executed in response to a user being enrolled in a trial or study, such as described with respect to the workflow 500A.
• One or more aspects of the workflow 500B may be the same as or similar to the workflow 500A.
• the workflow 500B may begin with a user logging in to an account.
• the user may be able to complete a baseline survey after logging in.
• the baseline survey may obtain information (e.g., health history, demographics, contact information, biographical information, occupation, residential information, etc.) of the user while the user is not experiencing one or more acute illnesses.
• the user may be able to view curated content (e.g., the same as or similar to the user interfaces 600A-600F) based on information about the user.
• One or more offer cards (e.g., the same as or similar to the user interfaces 600A-600F) may be presented to the user at the workflow 500B. The offer cards may prompt the user to participate in a study or trial.
• the workflow 500B may conduct a survey. The user may be prompted about how long ago their symptoms started. Also or alternatively, wearable device sensor data may be analyzed to determine how long ago symptoms started. In any case, if the symptoms started longer than a threshold amount of time ago, the workflow 500B may exit. For example, with faster developing illnesses the threshold amount of time may be shorter than for slower developing illnesses. In some examples, the threshold amount of time may be 1 hour, 4 hours, 6 hours, 12 hours, 18 hours, 24 hours, 36 hours, 2 days, 4 days, one week, two weeks, one month, 3 months, 6 months, one year, etc.
• the workflow 500B may include sending (with user consent) data (e.g., wearable device sensor data, responses to health queries, demographic information, health history information, symptom data, etc.) to the study or trial.
• user consent e.g., wearable device sensor data, responses to health queries, demographic information, health history information, symptom data, etc.
• the workflow 500B may include participating in the study or trial that may implement the systems, the methods, the computer-readable media, or the techniques described herein.
• the study or trial may implement methods that are the same as or similar to the method 200A or the method 200B.
• a user interface that may be presented on a graphical user interface (e.g., the display 732 of Fig, 7).
• Figs. 6A-6F illustrate example user interfaces 600A-600F.
• the user interfaces 600A-600F may be used for assembling a pool of high-risk subjects for developing an acute illness or for presenting information to a subject about an acute illness.
• Fig. 6 A shows the example user interface 600 A of an enrollment interface.
• the user interface 600A includes text explaining example techniques for identifying acute illnesses (e.g., influenza-like illnesses, as illustrated).
• the user interface 600A may be accessible from a mobile computing device (e.g., a smartphone, a tablet, a wearable device, etc.).
• the user interface 600A may be displayed in response to opening an email, a text, an application, etc.
• the user interface 600A may be accessible from a non-mobile computing device (e.g., a desktop computer).
• the user interface 600A includes an enrollment function (e.g., the “SIGN UP NOW” button, as illustrated).
• an enrollment function e.g., the “SIGN UP NOW” button, as illustrated).
• a user may initiate enrollment in one or more of the systems, the methods, the computer-readable media, or the techniques described herein.
• the user may initiate the workflow 500A for onboarding and enrolling users.
• Fig. 6B shows the example user interface 600B of an enrollment interface.
• the user interface 600B includes text explaining example techniques for identifying acute illnesses (e.g., influenza-like illnesses, as illustrated).
• the user interface 600B may be accessible from a mobile computing device (e.g., a smartphone, a tablet, a wearable device, etc.).
• the user interface 600B may be displayed in response to opening an email, a text, an application, etc.
• the user interface 600B may be accessible from a non-mobile computing device (e.g., a desktop computer).
• the user interface 600B includes an enrollment function (e.g., the “YES” button, as illustrated).
• an enrollment function e.g., the “YES” button, as illustrated.
• a user may initiate enrollment in one or more of the systems, the methods, the computer-readable media, or the techniques described herein.
• the user may initiate the workflow 500A for onboarding and enrolling users.
• Fig. 6C shows the example user interface 600C of a participation interface.
• the user interface 600C includes text displaying a health query of whether a subject has a symptom associated with an acute illness (e.g., flu-like symptoms, as illustrated).
• the user interface 600C may be accessible from a mobile computing device (e.g., a smartphone, a tablet, a wearable device, etc.).
• the user interface 600C may be displayed in response to opening an email, a text, an application, etc.
• the user interface 600C may be accessible from a non-mobile computing device (e.g., a desktop computer).
• the user interface 600C includes a multiple choice response function (e.g., the “YES” or “NO” button, as illustrated).
• selecting one of the multiple choice response functions a user may participate in one or more of the systems, the methods, the computer-readable media, or the techniques described herein. For example, selecting one of the options in the multiple choice response function may be included in the workflow 500B for user participation.
• Fig. 6D shows the example user interface 600D of a participation interface.
• the user interface 600D includes text displaying a health query of whether a subject lives with at least two people who are over the age of two.
• the user interface 600D may be accessible from a mobile computing device (e.g., a smartphone, a tablet, a wearable device, etc.).
• the user interface 600D may be displayed in response to opening an email, a text, an application, etc.
• the user interface 600D may be accessible from a non-mobile computing device (e.g., a desktop computer).
• the user interface 600D includes a multiple choice response function (e.g., the “YES” or “NO” button, as illustrated).
• selecting one of the multiple choice response functions a user may participate in one or more of the systems, the methods, the computer-readable media, or the techniques described herein. For example, selecting one of the options in the multiple choice response function may be included in the workflow 500B for user participation and may initiate prompting of additional health queries.
• Fig. 6E shows the example user interface 600E of a participation interface.
• the user interface 600E includes text indicating a change in a user’s behavior (e.g., based on wearable device sensor data).
• the user interface 600E includes a view health query function enabling the user to access one or more health queries (e.g., regarding symptoms).
• the user interface 600E may be accessible from a mobile computing device (e.g., a smartphone, a tablet, a wearable device, etc.).
• the user interface 600E may be displayed in response to opening an email, a text, an application, etc.
• the user interface 600E may be accessible from a non-mobile computing device (e.g., a desktop computer).
• the user interface 600E includes a multiple choice response function (e.g., the “YES” or “NO” button, as illustrated).
• a multiple choice response function e.g., the “YES” or “NO” button, as illustrated.
• the view health query function e.g., the “CLICK TO ANSWER” button, as illustrated
• the user may initiate presentation of one or more health queries in accordance with in one or more of the systems, the methods, the computer-readable media, or the techniques described herein.
• the user may initiate the workflow 500B for user participation.
• Fig. 6F shows the example user interface 600F of a participation interface.
• the user interface 600F includes text displaying a health query of whether a subject has a symptom associated with an acute illness (e.g., flu-like symptoms, as illustrated).
• the user interface 600F may be accessible from a mobile computing device (e.g., a smartphone, a tablet, a wearable device, etc.).
• the user interface 600F may be displayed in response to opening an email, a text, an application, etc.
• the user interface 600F may be accessible from a non-mobile computing device (e.g., a desktop computer).
• the user interface 600F includes a multiple choice response function (e.g., the “YES” or “NO” button, as illustrated).
• selecting one of the multiple choice response functions a user may participate in one or more of the systems, the methods, the computer-readable media, or the techniques described herein. For example, selecting one of the options in the multiple choice response function may be included in the workflow 500B for user participation.
• FIG. 7 a block diagram is shown depicting an example machine that includes a computer system 700 (e.g., a processing or computing system) within which a set of instructions can execute for causing a device to perform or execute any one or more of the aspects or methodologies for static code scheduling of the present disclosure.
• a computer system 700 e.g., a processing or computing system
• the components in Fig- 7 are examples and do not limit the scope of use or functionality of any hardware, software, embedded logic component, or a combination of two or more such components with particular implementations.
• Computer system 700 may include one or more processors 701, a memory 703, and a storage 708 that communicate with each other, and with other components, via a bus 740.
• the bus 740 may also link a display 732, one or more input devices 733 (which may, for example, include a keypad, a keyboard, a mouse, a stylus, etc.), one or more output devices 734, one or more storage devices 735, and various tangible storage media 736. All of these elements may interface directly or via one or more interfaces or adaptors to the bus 740.
• the various tangible storage media 736 can interface with the bus 740 via storage medium interface 726.
• Computer system 700 may have any suitable physical form, including but not limited to one or more integrated circuits (ICs), printed circuit boards (PCBs), mobile handheld devices (such as mobile telephones or PDAs), laptop or notebook computers, distributed computer systems, computing grids, or servers.
• ICs integrated circuits
• PCBs printed circuit boards
• mobile handheld devices such as mobile telephones
• Computer system 700 includes one or more processor(s) 707 (e.g., central processing units (CPUs), general purpose graphics processing units (GPGPUs), or quantum processing units (QPUs)) that carry out functions.
• processor(s) 701 optionally contains a cache memory unit 702 for temporary local storage of instructions, data, or computer addresses.
• Processor(s) 701 are configured to assist in execution of computer readable instructions.
• Computer system 700 may provide functionality for the components depicted in Fig. 7 as a result of the processor(s) 701 executing non-transitory, processor-executable instructions embodied in one or more tangible computer-readable storage media, such as memory 703, storage 708, storage devices 735, or storage medium 736.
• the computer-readable media may store software that implements particular operations, and processor(s) 701 may execute the software.
• Memory 703 may read the software from one or more other computer-readable media (such as mass storage device(s) 735, 736) or from one or more other sources through a suitable interface, such as network interface 720.
• the software may cause processor(s) 701 to carry out one or more processes or one or more operations of one or more processes described or illustrated herein. Carrying out such processes or operations may include defining data structures stored in memory 703 and modifying the data structures as directed by the software.
• the memory 703 may include various components (e.g., machine readable media) including, but not limited to, a random access memory component (e.g., RAM 704) (e.g., static RAM (SRAM), dynamic RAM (DRAM), ferroelectric random access memory (FRAM), phasechange random access memory (PRAM), etc.), a read-only memory component (e.g., ROM 705), and any combinations thereof.
• ROM 705 may act to communicate data and instructions unidirectionally to processor(s) 701
• RAM 704 may act to communicate data and instructions bidirectionally with processor(s) 701.
• ROM 705 and RAM 704 may include any suitable tangible computer-readable media described below.
• a basic input/output system 706 (BIOS) including basic routines that help to transfer information between elements within computer system 700, such as during start-up, may be stored in the memory 703.
• Fixed storage 708 is connected bidirectionally to processor(s) 701, optionally through storage control unit 707.
• Fixed storage 708 provides additional data storage capacity and may also include any suitable tangible computer-readable media described herein.
• Storage 708 may be used to store operating system 709, executable(s) 710, data 711, applications 712 (application programs), and the like.
• Storage 708 can also include an optical disk drive, a solid-state memory device (e.g., flash-based systems), or a combination of any of the above.
• Information in storage 708 may, in appropriate cases, be incorporated as virtual memory in memory 703.
• storage device(s) 735 may be removably interfaced with computer system 700 (e.g., via an external port connector (not shown)) via a storage device interface 725.
• storage device(s) 735 and an associated machine-readable medium may provide non-volatile or volatile storage of machine-readable instructions, data structures, program modules, or other data for the computer system 700.
• software may reside, completely or partially, within a machine-readable medium on storage device(s) 735.
• software may reside, completely or partially, within processor(s) 701.
• Bus 740 connects a wide variety of subsystems.
• reference to a bus may encompass one or more digital signal lines serving a common function, where appropriate.
• Bus 740 may be any of several types of bus structures including, but not limited to, a memory bus, a memory controller, a peripheral bus, a local bus, and any combinations thereof, using any of a variety of bus architectures.
• such architectures include an Industry Standard Architecture (ISA) bus, an Enhanced ISA (EISA) bus, a Micro Channel Architecture (MCA) bus, a Video Electronics Standards Association local bus (VLB), a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, an Accelerated Graphics Port (AGP) bus, HyperTransport (HTX) bus, serial advanced technology attachment (SATA) bus, and any combinations thereof.
• ISA Industry Standard Architecture
• EISA Enhanced ISA
• MCA Micro Channel Architecture
• VLB Video Electronics Standards Association local bus
• PCI Peripheral Component Interconnect
• PCI-X PCI-Express
• AGP Accelerated Graphics Port
• HTTP HyperTransport
• SATA serial advanced technology attachment
• Computer system 700 may also include an input device 733.
• a user of computer system 700 may enter commands or other information into computer system 700 via input device(s) 733.
• Examples of an input device(s) 733 include, but are not limited to, an alphanumeric input device (e.g., a keyboard), a pointing device (e.g., a mouse or touchpad), a touchpad, a touch screen, a multi-touch screen, a joystick, a stylus, a gamepad, an audio input device (e.g., a microphone, a voice response system, etc.), an optical scanner, a video or still image capture device (e.g., a camera), and any combinations thereof.
• an alphanumeric input device e.g., a keyboard
• a pointing device e.g., a mouse or touchpad
• a touchpad e.g., a touch screen
• a multi-touch screen e.g., a joystick, a stylus,
• the input device is a Kinect, Leap Motion, or the like.
• Input device(s) 733 may be interfaced to bus 740 via any of a variety of input interfaces 723 (e.g., input interface 723) including, but not limited to, serial, parallel, game port, USB, FIREWIRE, THUNDERBOLT, or any combination of the above.
• input interfaces 723 e.g., input interface 723
• computer system 700 may communicate with other devices, specifically mobile devices and enterprise systems, distributed computing systems, cloud storage systems, cloud computing systems, and the like, connected to network 730. Communications to and from computer system 700 may be sent through network interface 720.
• network interface 720 may receive incoming communications (such as requests or responses from other devices) in the form of one or more packets (such as Internet Protocol (IP) packets) from network 730, and computer system 700 may store the incoming communications in memory 703 for processing.
• Computer system 700 may similarly store outgoing communications (such as requests or responses to other devices) in the form of one or more packets in memory 703 and communicated to network 730 from network interface 720.
• Processor(s) 701 may access these communication packets stored in memory 703 for processing.
• Examples of the network interface 720 include, but are not limited to, a network interface card, a modem, and any combination thereof.
• Examples of a network 730 or network segment 730 include, but are not limited to, a distributed computing system, a cloud computing system, a wide area network (WAN) (e.g., the Internet, an enterprise network), a local area network (LAN) (e.g., a network associated with an office, a building, a campus or other relatively small geographic space), a telephone network, a direct connection between two computing devices, a peer-to-peer network, and any combinations thereof.
• a network, such as network 730 may employ a wired or a wireless mode of communication. In general, any network topology may be used.
• Information and data can be displayed through a display 732.
• a display 732 include, but are not limited to, a cathode ray tube (CRT), a liquid crystal display (LCD), a thin film transistor liquid crystal display (TFT-LCD), an organic liquid crystal display (OLED) such as a passive-matrix OLED (PMOLED) or active-matrix OLED (AMOLED) display, a plasma display, and any combinations thereof.
• the display 732 can interface to the processor(s) 701, memory 703, and fixed storage 708, as well as other devices, such as input device(s) 733, via the bus 740.
• the display 732 is linked to the bus 740 via a video interface 722, and transport of data between the display 732 and the bus 740 can be controlled via the graphics control 721.
• the display is a video projector.
• the display is a head-mounted display (HMD) such as a VR headset.
• suitable VR headsets include, by way of nonlimiting examples, HTC Vive, Oculus Rift, Samsung Gear VR, Microsoft HoloLens, Razer OSVR, FOVE VR, Zeiss VR One, Avegant Glyph, Freefly VR headset, and the like.
• the display is a combination of devices such as those disclosed herein.
• computer system 700 may include one or more other peripheral output devices 734 including, but not limited to, an audio speaker, a printer, a storage device, and any combinations thereof.
• peripheral output devices may be connected to the bus 740 via an output interface 724.
• Examples of an output interface 724 include, but are not limited to, a serial port, a parallel connection, a USB port, a FIREWIRE port, a THUNDERBOLT port, and any combinations thereof.
• computer system 700 may provide functionality as a result of logic hardwired or otherwise embodied in a circuit, which may operate in place of or together with software to execute one or more processes or one or more operations of one or more processes described or illustrated herein.
• Reference to software in this disclosure may encompass logic, and reference to logic may encompass software.
• reference to a computer-readable medium may encompass a circuit (such as an IC) storing software for execution, a circuit embodying logic for execution, or both, where appropriate.
• the present disclosure encompasses any suitable combination of hardware, software, or both.
• DSP digital signal processor
• ASIC application specific integrated circuit
• FPGA field programmable gate array
• a general purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or state machine.
• a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
• a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
• An example storage medium may be coupled to the processor such the processor can read information from, and write information to, the storage medium.
• the storage medium may be integral to the processor.
• the processor and the storage medium may reside in an ASIC.
• the ASIC may reside in a user terminal.
• the processor and the storage medium may reside as discrete components in a user terminal.
• suitable computing devices include, by way of non-limiting examples, server computers, desktop computers, laptop computers, notebook computers, sub-notebook computers, netbook computers, netpad computers, set-top computers, media streaming devices, handheld computers, Internet appliances, mobile smartphones, tablet computers, personal digital assistants, video game consoles, and vehicles. Select televisions, video players, and digital music players with optional computer network connectivity may be suitable for use in the system described herein.
• Suitable tablet computers in various cases, include those with booklet, slate, and convertible configurations.
• the computing device includes an operating system configured to perform executable instructions.
• the operating system is, for example, software, including programs and data, which manages the device’s hardware and provides services for execution of applications.
• Suitable server operating systems may include, by way of non-limiting examples, FreeBSD, OpenBSD, NetBSD®, Linux, Apple® Mac OS X Server®, Oracle® Solaris®, Windows Server®, and Novell® NetWare®.
• Suitable personal computer operating systems may include, by way of non-limiting examples, Microsoft® Windows®, Apple® Mac OS X®, UNIX®, and UNIX-like operating systems such as GNU/Linux®.
• the operating system is provided by cloud computing.
• Suitable mobile smartphone operating systems may include, by way of nonlimiting examples, Nokia® Symbian® OS, Apple® iOS®, Research In Motion® BlackBerry OS®, Google® Android®, Microsoft® Windows Phone® OS, Microsoft® Windows Mobile® OS, Linux®, and Palm® WebOS®.
• the platforms, systems, media, and methods disclosed herein include one or more non-transitory computer readable storage media encoded with a program including instructions executable by the operating system of an optionally networked computing device.
• a computer readable storage medium is a tangible component of a computing device.
• a computer readable storage medium is optionally removable from a computing device.
• a computer readable storage medium includes, by way of non-limiting examples, CD-ROMs, DVDs, flash memory devices, solid state memory, magnetic disk drives, magnetic tape drives, optical disk drives, distributed computing systems including cloud computing systems and services, and the like.
• the program and instructions are permanently, substantially permanently, semi-permanently, or non-transitorily encoded on the media.
• the platforms, systems, media, and methods disclosed herein include at least one computer program, or use of the same.
• a computer program includes a sequence of instructions, executable by one or more processor(s) of the computing device’s CPU, written to perform a specified task.
• Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), computing data structures, and the like, that perform particular tasks or implement particular abstract data types.
• APIs Application Programming Interfaces
• a computer program may be written in various versions of various languages.
• a computer program comprises one sequence of instructions.
• a computer program comprises a plurality of sequences of instructions.
• a computer program is provided from one location.
• a computer program is provided from a plurality of locations.
• a computer program includes one or more software modules.
• a computer program includes, in part or in whole, one or more web applications, one or more mobile applications, one or more standalone applications, one or more web browser plug-ins, extensions, add-ins, or add-ons, or combinations thereof.
• a computer program includes a web application.
• a web application in various cases, may utilize one or more software frameworks and one or more database systems.
• a web application is created upon a software framework such as Microsoft® .NET or Ruby on Rails (RoR).
• a web application utilizes one or more database systems including, by way of non-limiting examples, relational, non-relational, object oriented, associative, XML, and document oriented database systems.
• suitable relational database systems include, by way of non-limiting examples, Microsoft® SQL Server, mySQLTM, and Oracle®.
• a web application in some cases, may be written in one or more versions of one or more languages.
• a web application may be written in one or more markup languages, presentation definition languages, client-side scripting languages, server-side coding languages, database query languages, or combinations thereof.
• a web application is written to some extent in a markup language such as Hypertext Markup Language (HTML), Extensible Hypertext Markup Language (XHTML), or extensible Markup Language (XML).
• a web application is written to some extent in a presentation definition language such as Cascading Style Sheets (CSS).
• a web application is written to some extent in a client-side scripting language such as Asynchronous JavaScript and XML (AJAX), Flash® ActionScript, JavaScript, or Silveriight®.
• AJAX Asynchronous JavaScript and XML
• Flash® ActionScript JavaScript
• JavaScript JavaScript
• Silveriight® Silveriight®
• a web application is written to some extent in a server-side coding language such as Active Server Pages (ASP), ColdFusion®, Perl, JavaTM, JavaServer Pages (JSP), Hypertext Preprocessor (PHP), PythonTM, Ruby, Tel, Smalltalk, WebDNA®, or Groovy.
• a web application is written to some extent in a database query language such as Structured Query Language (SQL).
• SQL Structured Query Language
• a web application integrates enterprise server products such as IBM® Lotus Domino®.
• a web application includes a media player element.
• a media player element utilizes one or more of many suitable multimedia technologies including, by way of non-limiting examples, Adobe® Flash®, HTML 5, Apple® QuickTime®, Microsoft® Silveriight®, JavaTM, and Unity®.
• a computer program includes a mobile application provided to a mobile computing device.
• the mobile application is provided to a mobile computing device at the time it is manufactured. In other cases, the mobile application is provided to a mobile computing device via the computer network described herein.
• a mobile application may be created using hardware, languages, and development environments known to the art. In some cases, mobile applications are written in several languages. Suitable programming languages may include, by way of non-limiting examples, C, C++, C#, Objective-C, JavaTM, JavaScript, Pascal, Object Pascal, PythonTM, Ruby, VB.NET, WML, and XHTML/HTML with or without CSS, or combinations thereof.
• Suitable mobile application development environments are available from several sources. Commercially available development environments include, by way of non-limiting examples, AirplaySDK, alcheMo, Appcelerator®, Celsius, Bedrock, Flash Lite, .NET Compact Framework, Rhomobile, and WorkLight Mobile Platform. Other development environments are available without cost including, by way of non-limiting examples, Lazarus, MobiFlex, MoSync, and PhoneGap. Also, mobile device manufacturers distribute software developer kits including, by way of non-limiting examples, iPhone and iPad (iOS) SDK, AndroidTM SDK, BlackBerry® SDK, BREW SDK, Palm® OS SDK, Symbian SDK, webOS SDK, and Windows® Mobile SDK.
• iOS iPhone and iPad
• a computer program includes a standalone application, which is a program that is run as an independent computer process, not an add-on to an existing process, e.g., not a plug-in. Standalone applications may be compiled.
• a compiler may be a computer program(s) that transforms source code written in a programming language into binary object code such as assembly language or machine code.
• Suitable compiled programming languages include, by way of non-limiting examples, C, C++, Objective-C, COBOL, Delphi, Eiffel, JavaTM, Lisp, PythonTM, Visual Basic, and VB .NET, or combinations thereof. Compilation is often performed, at least in part, to create an executable program.
• a computer program includes one or more executable complied applications.
• the computer program includes a web browser plug-in (e.g., extension, etc.).
• a plug-in is one or more software components that add specific functionality to a larger software application. Makers of software applications support plug-ins to enable third-party developers to create abilities which extend an application, to support easily adding new features, and to reduce the size of an application. When supported, plug-ins enable customizing the functionality of a software application. For example, plug-ins are commonly used in web browsers to play video, generate interactivity, scan for viruses, and display particular file types. Web browser plug-ins may include Adobe® Flash® Player, Microsoft® Silverlight®, and Apple® QuickTime®.
• the toolbar comprises one or more web browser extensions, add-ins, or add-ons. In some cases, the toolbar comprises one or more explorer bars, tool bands, or desk bands.
• plug-in frameworks may be available that enable development of plug-ins in various programming languages, including, by way of non-limiting examples, C++, Delphi, JavaTM, PHP, PythonTM, and VB .NET, or combinations thereof.
• Web browsers are software applications, designed for use with network-connected computing devices, for retrieving, presenting, and traversing information resources on the World Wide Web. Suitable web browsers include, by way of nonlimiting examples, Microsoft® Internet Explorer®, Mozilla® Firefox®, Google® Chrome, Apple® Safari®, Opera Software® Opera®, and KDE Konqueror. In some cases, the web browser is a mobile web browser. Mobile web browsers (also called microbrowsers, mini-browsers, and wireless browsers) are designed for use on mobile computing devices including, by way of nonlimiting examples, handheld computers, tablet computers, netbook computers, subnotebook computers, smartphones, music players, personal digital assistants (PDAs), and handheld video game systems.
• PDAs personal digital assistants
• Suitable mobile web browsers include, by way of non-limiting examples, Google® Android® browser, RIM BlackBerry® Browser, Apple® Safari®, Palm® Blazer, Palm® WebOS® Browser, Mozilla® Firefox® for mobile, Microsoft® Internet Explorer® Mobile, Amazon® Kindle® Basic Web, Nokia® Browser, Opera Software® Opera® Mobile, and Sony® PSPTM browser.
• the platforms, systems, media, and methods disclosed herein include software, server, or database modules, or use of the same.
• Software modules may be created by techniques using machines, software, and languages.
• the software modules disclosed herein are implemented in a multitude of ways.
• a software module comprises a file, a section of code, a programming object, a programming structure, a distributed computing resource, a cloud computing resource, or combinations thereof.
• a software module comprises a plurality of files, a plurality of sections of code, a plurality of programming objects, a plurality of programming structures, a plurality of distributed computing resources, a plurality of cloud computing resources, or combinations thereof.
• the one or more software modules comprise, by way of non-limiting examples, a web application, a mobile application, a standalone application, and a distributed or cloud computing application.
• software modules are in one computer program or application.
• software modules are in more than one computer program or application.
• software modules are hosted on one machine.
• software modules are hosted on more than one machine.
• software modules are hosted on a distributed computing platform such as a cloud computing platform.
• software modules are hosted on one or more machines in one location.
• software modules are hosted on one or more machines in more than one location.
• the platforms, systems, media, and methods disclosed herein include one or more databases, or use of the same.
• various databases may be suitable for storage and retrieval of one or more of (i) wearable data, (ii) responses to health queries, (iii) geographic data, etc., one or more of which may be historical, present, or future data or information.
• suitable databases include, by way of non-limiting examples, relational databases, non-relational databases, object oriented databases, object databases, entity - relationship model databases, associative databases, XML databases, document oriented databases, and graph databases. Further non-limiting examples include SQL, PostgreSQL, MySQL, Oracle, DB2, Sybase, and MongoDB.
• a database is Internet-based. In further cases, a database is web-based. In still further cases, a database is cloud computingbased. In a particular case, a database is a distributed database. In other cases, a database is based on one or more local computer storage devices.
• assembling a pool of high-risk subjects for developing an acute illness may include obtaining, from a plurality of subjects, (i) one or more responses to one or more health queries, and (ii) geographic incidence data for the acute illness.
• a risk of developing the acute illness for the plurality of subjects may be predicted, using a machine learning model, based on the one or more responses and the geographic incidence data.
• the pool of high-risk subjects may be identified from the plurality of subjects, where the risk of developing the acute illness for each subject of the pool of high-risk subjects satisfies a threshold.
• the pool of high-risk subjects may be output.
• presenting information to a subject about an acute illness may include obtaining wearable device sensor data from the subject.
• a response to a health query of whether the subject has a symptom associated with the acute illness may be obtained via a mobile device.
• a risk of the subject developing the acute illness may be predicted, using a machine learning model, based at least in part on the wearable device sensor data and the response to the health query.
• an electronic display may be caused to indicate the risk to the subject.

Landscapes

• Engineering & Computer Science (AREA)
• Health & Medical Sciences (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• Data Mining & Analysis (AREA)
• Biomedical Technology (AREA)
• Medical Informatics (AREA)
• Public Health (AREA)
• General Health & Medical Sciences (AREA)
• Software Systems (AREA)
• General Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• Artificial Intelligence (AREA)
• Evolutionary Computation (AREA)
• Mathematical Physics (AREA)
• Computing Systems (AREA)
• Computational Linguistics (AREA)
• Epidemiology (AREA)
• Primary Health Care (AREA)
• Molecular Biology (AREA)
• Biophysics (AREA)
• Life Sciences & Earth Sciences (AREA)
• Databases & Information Systems (AREA)
• Pathology (AREA)
• Computer Vision & Pattern Recognition (AREA)
• Algebra (AREA)
• Pure & Applied Mathematics (AREA)
• Mathematical Optimization (AREA)
• Mathematical Analysis (AREA)
• Computational Mathematics (AREA)
• Probability & Statistics with Applications (AREA)
• Business, Economics & Management (AREA)
• General Business, Economics & Management (AREA)
• Medical Treatment And Welfare Office Work (AREA)

Applications Claiming Priority (3)

Publications (2)

Family

ID=86694864

Family Applications (1)

Country Status (2)

Families Citing this family (6)

Family Cites Families (2)

• 2022
  • 2022-12-13 EP EP22908630.1A patent/EP4449446A4/de active Pending
  • 2022-12-30 US US18/148,991 patent/US20230187073A1/en active Pending

Also Published As

Similar Documents

Legal Events