Patent Application
20240412836
Various embodiments of the present disclosure relate generally to the field of healthcare improvement, and, more particularly, to data collection and analysis of the microbiome and the dynamic utilization of that analyzed data to impact diagnosis, treatment, and/or wellness.
The human and animal microbiome has been demonstrated to play a key role in both human and animal health. Despite having been shown that the microbiome can affect early development, immune response, therapy efficacy and even mental and behavioral changes, the role of the microbiome is still poorly understood. One reason why the microbiome is so poorly understood is the lack of frequent, convenient and location-specific microbiome sampling across a population as well as the lack of information about the microbiome at the levels of interacting pairs or groups of individuals. The present disclosure is intended to address this problem by enabling more detailed and widespread data collection about the microbiome as well as the use of that data to impact diagnosis, treatment and wellness.
The background description provided herein is for the purpose of generally presenting context of the disclosure. Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art, or suggestions of the prior art, by inclusion in this section.
In summary, a computer-implemented method of leveraging subject microbiome data is disclosed. The computer-implemented method contains operations including: detecting, on a graphical user interface of an application platform of a user computing device, a selection of a subject by a user; accessing, based on the detecting, data associated with the subject, wherein the data comprises the subject microbiome data; generating, by a processor, an overview report comprising a first set of subject predispositions; and displaying, on the application platform, the generated overview report.
Another aspect provides a user computing device for leveraging subject microbiome data. The user computing device includes: one or more computer processors; and a non-transitory computer-readable storage medium storing instructions executable by the one or more computer processors, the instructions when executed by the one or more computer processors causing the one or more computer processors to perform operations including: detecting, on a graphical user interface of an application platform associated with the user computing device, a selection of a subject by a user; accessing, based on the detecting, data associated with the subject, wherein the data comprises the subject microbiome data; generating, by a processor, an overview report comprising a first set of subject predispositions; and displaying, on the application platform, the generated overview report.
A further aspect provides a non-transitory computer-readable medium storing instructions executable by one or more computer processors of a computer system. The instructions, when executed by the one or more computer processors, cause the one or more computer processors to perform operations including: detecting, on a graphical user interface of an application platform of a user computing device, a selection of a subject by a user; accessing, based on the detecting, data associated with the subject, wherein the data comprises the subject microbiome data; generating, by a processor, an overview report comprising a first set of subject predispositions; and displaying, on the application platform, the generated overview report.
The foregoing is a summary and thus may contain simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting.
For a better understanding of the embodiments, together with other and further features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying drawings. The scope of the invention will be pointed out in the appended claims.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments and together with the description, serve to explain the principles of the disclosure.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed.
The following embodiments describe systems and methods for using the microbiome to improve healthcare. In the context of this application, the term “microbiome” may refer to the one or more portions of the entire aggregate of all microbiota (including all related microbiota biological properties such as genetics, proteins, metabolites, transcriptomics, etc.) and properties of the environment that they reside on or within tissues and biofluids along with the corresponding anatomical sites in which they reside, including the skin, mammary glands, seminal fluid, uterus, placenta, ovarian follicles, lung, saliva, oral mucosa, nasal mucosa, conjunctiva, biliary tract, and gastrointestinal (GI) tract. For clarity, note that the anatomical site may be represented at one or more levels of specificity (“GI tract”, “duodenum”, “upper duodenum”, etc.). For clarity, note that the anatomical sites may vary from subject to subject (e.g., for plant versus animal) and note that the subject may be living or dead (necrobiome). Types of microbiota in our definition include bacteria, archaea, fungi, protists, viruses, phages, plasmids, prions, parasites, mobile genetic elements and micro-animals. The term “subject” is used herein throughout to refer to either humans, animals or plants since the inventive concepts described herein equally apply to both humans, animals and plants. Note that a subject may be sampled directly and/or may be linked to one or more subjects. Any references to “user” refers to either a subject themselves or to a person who has access to the subject's account/data (e.g., a user could be the subject themselves, a user could be a care or medical provider for the subject, a user could be a parent for the subject, etc.). One or more users may be associated with one or more subjects (e.g., a farm owner may be a “user” for multiple animal “subjects” on the farm, both a patient and their doctor may be a “user” for a single patient “subject”, etc.).
At a high level, the embodiments described herein have a variety of different possible components and forms. One aspect includes a subject prediction engine, which may take multiple forms and will be the subject of subsequent sections. Described herein are a plurality of non-limiting, high level characteristics of steps involved in the subject prediction engine.
The system of the embodiments may optionally receive one or more elements of subject data (e.g., context factors, microbiome data, linkages, linked user data, etc.) for one or more subjects and store these measurements in an accessible electronic storage device. The system may further receive one or more measurements of microbiome data for one or more subjects (e.g., at one or more locations of each subject) and store these measurements in the same or different accessible electronic storage device. The system may optionally link these measurements (e.g., using a processor) to either one or more time points of subject measurements and/or measurements of one or more additional subjects and then store these measurements in the same or different electronic storage device. The system may further receive one or more target subject predispositions for one or more subjects and thereafter train or develop (e.g., using a processor) a subject prediction engine that can read these measurements and, if available, other subject data (e.g., context factors, microbiome data, linked subject data, linked user data, etc.) to predict the one or more target subject predispositions. This subject prediction engine can be represented in many different forms such as by storing the system representation on an electronic storage device, in electric memory, distributed across a network, as hardware (e.g., field programmable gate array (FPGA), etc.), and the like.
The system of the embodiments may optionally receive one or more elements of subject data (e.g., context factors, microbiome data, linkages, linked user data, etc.) for a subject and store these measurements in an accessible electronic storage device. The system may further receive one or more measurements of microbiome data for a subject (e.g., at one or more locations of each subject) and store these measurements in the same or different accessible electronic storage device. The system may optionally link these measurements (e.g., using a processor) to either one or more time points of subject measurements and/or measurements of one or more additional subjects and then store these measurements in the same or different electronic storage device. The system may then apply the subject prediction engine to determine one or more subject predispositions about the subject. These determined subject predispositions may be stored one or more electronic storage devices. Additionally or alternatively, the system may output the determined subject predispositions to one or more display devices. The system may optionally provide a user and/or coach with a series of visualizations, recommendations, guidances, interactive capabilities and services using an electronic storage device, visual display, etc.
In the following sections, various embodiments associated with different types of entities, linkages, sampling, data, analysis, and guidances, as well as different example implementations of these embodiments, are more thoroughly described.
Referring now to
The computing device 105 may include a display/user interface (UI) 105A, a processor 105B, a memory 105C, a network interface 105D, and/or a health optimization application (“application”) 105E. The user computing device 105 may be a personal computer (PC), a tablet PC, a television (TV), a smart TV a personal digital assistant (PDA), a mobile device, a palmtop computer, a laptop computer, a desktop computer, etc. The user computing device 105 may execute, by the processor 105B, an operating system (O/S) and at least one application (each stored in memory 105C). The application 105E may be a browser program or a mobile application program (which may also be a browser program in a mobile O/S). Users may be able to provide inputs to and receive outputs from the application 105E via interaction with one or more digital icons resident thereon. In some embodiments, outputs provided by the application 105E may be facilitated based on instructions/information stored in the memory 105C. The output may be visual data presented on the application GUI and may be executed, for instance, based on XML and Android programming languages or Objective-C/Swift. However, one skilled in the art would recognize that this may also be accomplished by other methods, such as webpages executed based on HTML, CSS, and/or scripts, such as JavaScript. The display/UI 105A may be a touch screen or a display with other input systems (e.g., mouse, keyboard, etc.). The network interface 105D may be a TCP/IP network interface for, e.g., Ethernet or wireless communications with the network 110. The processor 105B, while executing the application 105E, may receive user inputs from the display/UI 105A, and perform actions or functions in accordance with the application or other related applications.
The computer server 115 may include a display/UI 115A, a processor 115B, a memory 115C, and/or a network interface 115D. The computer server 115 may be a computer, system of computers (e.g., rack server(s)), and/or or a cloud service computer system. The computer server 115 may execute, by the processor 115B, an operating system (O/S) and at least one instance of a server program (each stored in memory 115C). The computer server 115 may store or have access to information from the database 120. The display/UI 115A may be a touch screen or a display with other input systems (e.g., mouse, keyboard, etc.) for an operator of the computer server 115 to control the functions of the computer server 115 (e.g., update the server program and/or the server information). The network interface 115D may be a TCP/IP network interface for, e.g., Ethernet or wireless communications with the network 110.
The computer server 115 may be configured to receive data over the network 110 from the user computing device(s) 105, including, but not limited to: subject data, user data, coach data, and user command requests. Subject, user, and/or coach data may be stored in the database 120 and may include previously acquired data (e.g., from a subject, user, coach or other sources) such as, for instance, contextual information associated with one or more subjects and/or objective sample measurements associated with one or more subjects.
The methods and systems described herein represent a variety of technical improvements to computer technology. More particularly, the system of the embodiments involves the acquisition and integration of vast amount of microbiome data, subject data, and contextual information from various sources. This data processing requires specialized computer systems, algorithms, and computational resources beyond what can be performed solely within the human mind. Additionally, the application describes the utilization of various machine learning methods to analyze microbiome data and make predictions about subject predispositions. These types of analyses go beyond the capabilities of the human mind to perform efficiently or effectively. Furthermore, the concepts described herein provide users with visualizations, recommendations, and interactive capabilities based on the predictions generated by the system. Although displaying analyzed data to a user is known in the art, the graphical rendering techniques leveraged here to construct an interactive and dynamic user interface are not known in the art and represent a unique computer construct.
Additionally to the foregoing, by enabling frequent, convenient, and location-specific microbiome sample across populations, the embodiments described herein may improve data collection in microbiome research, which may allow for a deeper understanding of the microbiome's role in health and disease. Furthermore, the ability to predict subject predispositions based on microbiome data allows for personalized healthcare interventions. Specifically, clinicians can use these predictions to tailor treatment plans, interventions, and preventive measures to individual patients, thereby improving outcomes and reducing healthcare costs. Additionally, by identifying individuals at risk of certain health conditions or treatment complications based on microbiome analysis, the disclose systems and methods may enable early intervention strategies. This proactive approach may help prevent the onset of diseases, optimize treatment outcomes, and improve overall health and well-being.
Three different types of entities are the primary focus of the concepts described herein: subjects, users and coaches.
Subjects correspond to those entities for which the system of the embodiments is gathering context data, microbiome data, personalized modeling, generating predispositions and providing guidance of suggested changes to achieve a goal. Subjects may represent a variety of different entities, including but not limited to: individual consumers, patients, enrollees in clinical trials, pets, livestock, zoo animals, plants, etc.
Although subjects are a primary focus of the concepts described herein, a subject may or may not always be a user of a system. Although the simplest scenario is where a subject and a user are the same person, there are many other scenarios in which this is not the case. For example, if the subject is a patient, the user of the system might be a doctor or a researcher. In another example, the subject of the system could be a pet and the user could be the pet owner. Therefore, users may represent a variety of different individuals, including but not limited to an individual consumer, family member (e.g., parent, caregiver, etc.), doctor, nutritionist, researcher, economist, epidemiologist, therapist, pet owner, farm owner, veterinarian, etc. Users may be assumed to have an interest in one or more subjects (or populations of subjects) and may or may not set goals for these subjects to achieve.
For clarity, different users may have different levels of access to the same subject. For example, a user who is themselves a subject may have access to all the subject data. However, a doctor user for the subject may have access to less subject information (e.g., restricted to purely medical information) and a researcher may have access to a very limited set of anonymized data over a population of subjects. Subject data access levels may be established for different users via interactions with the application 105E. These access levels may be established and/or adjusted manually (e.g., via selections made in a settings menu, etc.) or, alternatively, may established automatically (e.g., a researcher user that registers with the application 105E may automatically be allocated limited subject data access permissions, etc.).
Note that some implementations of the system may not distinguish users from subjects and just assume that each user corresponds to a subject. In such an implementation of the inventive concepts, any reference to a user would simply be assumed to refer to the subject themselves.
A third entity contemplated herein is a coach, which is entirely optional in an implementation of the system. Coaches are intended to provide support to users to help the users achieve goals, answer questions, etc. Therefore, coaches may represent a variety of different individuals, including but not limited to fitness coaches, diet coaches, pet coaches, agricultural coaches, nutritionists, doctors, therapists, and the like.
Subjects, users, and coaches are linked both within these groups and between each other to represent a variety of relationships and to substantially enhance the information and actionability produced by the inventive concepts. Contemplated herein are several different types of linkage that are referred to in a general sense as “linkages”. When important to specify which type of linkage is referred to, a modifier for the linkage type (e.g., coach-user linkage, subject-subject linkage, etc.) will be used.
Note that user-user, coach-coach, or coach-subject linkages are not further explicitly discussed, although such linkages may be used formally or informally in various embodiments. Some examples include: allowing two users to communicate when they are linked to the same subject, two coaches to communicate when they are linked to the same user, allowing coaches to see one or more elements of subject data linked to a user the coach is working with, and the like.
Each user may be linked with no subjects, a single subject, or with multiple subjects. Similarly, each subject may be linked with no users, a single user, or with multiple users. Some examples include:
Each user may be linked with no coaches, a single coach, or with multiple coaches. Similarly, each coach may be linked with no users, a single user or with multiple users. Some examples include:
One or more subjects may be linked together in various ways. When necessary to distinguish between two subjects who are linked together, the term “pairing” may be utilized and when multiple subjects are linked together, the term “community” may be utilized. The general term “subject-subject linkage” or, if unnecessary to specify, “linkage” may be utilized to refer to either pairings or communities. Samples, subjects, data, or microbiome elements may be linked together in multiple ways to provide a richer and more meaningful analysis. These linkings may be generated in multiple ways and may have multiple representations.
One or more subjects may share microbes with each other as a result of many factors. Knowing that a potential microbial sharing exists between different subjects is useful for many reasons. For instance, one reason is because any sampling and analysis method may undersample a subject. Therefore, obtaining a sample from one subject (e.g., using one or more of the described methods) who is linked by microbial sharing to other subjects potentially provides additional information about all linked subjects. For example, if two subjects share a living environment and are linked via microbial sharing, it may be possible to refine estimates of each subject's microbiome (i.e., improve sampling errors). Alternatively, if one subject's sample(s) were obtained at more recent time points, to update and predict changes to the other subject's data. In the language of graph theory, pairings may be considered as edges between subjects (nodes) which may or may not be signed, directed or undirected, weighted or unweighted.
One or more potential microbial sharing linkages could be defined by one or more of the following relationships between two subjects. These relationships include, but are not limited to, one or more of:
Another example of a linkage type is a shared subject attribute, allergy, trait, sensitivity, behavior or medical condition. Such shared attribute linkages include, but are not limited to one or more of:
Another example of a linkage type is one or more shared (or similar) data element(s) between two subjects. These linkages may or may not require the data elements to be shared within a certain temporal distance or data element distance (e.g., using one or more of any data element distances described below). Such shared data element linkages include, but are not limited to one or more of:
Pairings may also be generated between two subjects via any number of graph-theoretical generation methods for a set or subset of points (subjects) which are represented by a set or subset of their data elements or a dimensionality-reduced representation (see below). Examples of such pairings may include, but are not limited to:
One or more weights for each pairing may be derived from one or more methods, including but not limited to:
Any of these linkages may be generated by one or more methods. The methods to generate a linkage may include, but are not limited to, one or more of the following mechanisms:
Note that one or both subjects (or users concerning the two subjects) may or may not need to agree to a linkage (or removal of a linkage) in order for a linkage to be included (removed) in the subsequent analysis. Linkages may or may not be added, removed or refined over time in response to new data, modified data or user inputs.
For clarity, these subject-subject linkages may or may not be associated with different subtypes to represent different types of subject-subject linkage (e.g., family members, residents of the same town, etc.). This linkage subtype information, if available, is considered part of any linking data or subject data with this sort of linkage.
As with pairings, communities may represent a group of subjects containing more than two subjects. One or more communities may be defined via many methods, including but not limited to one or more methods described above to define pairings. For example, all members of a household, including pets, may be considered as a community. In this example, one member of the household could also belong to a second, distinct community defined by a workplace environment shared with other subjects. In the language of hypergraph theory, communities may be described as triplets, cycles, hyperedges or sets which may or may not be ordered, directed or signed, weighted or unweighted. Note that in the context of hypergraph theory, the hyperedges representing communities may be of one or more different cardinalities.
In addition to the above methods for generating pairing and community structures, embodiments of the application may also derive pairings from communities and vice versa. Methods for generating pairings from one or more communities include, but are not limited to:
Methods for generating communities from a set or subset of subject pairings include, but are not limited to:
As a non-limiting example of the foregoing,
In an embodiment, Subjects 1, 2, and 3 215, 220, 225 may all be linked and may be members of a singular community (e.g., Subjects 1, 2, and 3 215, 220, and 225 may all be members of a group that are frequently around one another). The shared associations between the subjects may enable an unlinked user, such as User 1, to be apprised of hypothetical subject predisposition data 245 of Subjects 2 and 3 220, 225.
In this section, different types of data are detailed that may or may not be associated with a subject. These context factors, measurements, linkages, and the possible time/location of these data points in relation to a subject are collectively referred to as “subject data” and each specific type of data as a data “element”. For clarity, the subject data for different subjects may or may not contain all the same types of data elements and each subject may or may not contain any or all data elements. For clarity, note that subject data for a certain subject may or may not be considered to encompass any or all user data from one or more users that are linked with that subject and any or all user-subject and subject-subject linkages. For clarity, subject data may or may not include microbiome data. For clarity, note that “element” is used in a similar manner to refer to particular data elements for user data and/or coach data as well.
Some data about a subject are not microbiome related, but rather, may be supplied to the system by a user or via other means. The intention of these context factors is to provide the system with additional information that can enable more accurate and reliable predictions to inform the user about the subject's health and disease.
A variety of potential context factors to be obtained are contemplated herein. Some of these context factors can be obtained either via questionnaires for the user about the subject or via connection of the system with other records such as a smartphone, wearable device, home health device, electronic medical record (EMR), social media accounts, other company, etc. These subject factors may represent data obtained from one or more time points or may represent continuous monitoring data. These context factors about the subject may include, but are not limited to, one or more of the following examples:
For clarity, any of the examples of subject predispositions may also be input as subject context factors. For clarity, any mention of a probiotic, prebiotic or postbiotic may also refer to a combination of these, which is sometimes called a synbiotic.
Note that each of these contextual information elements may also be represented as probabilities (e.g., stochastic variables). One reason to use probabilistic representations is to account for the possibility of inaccurately entered information or information that is not current. For example, a user recording 8 hours of sleep for the subject the night before might be inaccurate or imprecise (perhaps it was 7.6 hours), and therefore a probabilistic representation (e.g., a distribution of possibly correct values informed by the entered information or a probability associated with the entered information) might be more appropriate.
Some of these subject context factors may be in the form of unstructured data, free text, audio recordings, video, etc. For clarity, natural language processing (NLP), image/video analysis and/or sentiment analysis may be applied to one or more of these subject context data to add additional subject context data. For one example, NLP could be applied to a doctor's report in the subject's medical record to assess a subject medical condition. As another example, sentiment analysis could be applied to a doctor's report to assess the doctor's level of concern with a written condition. Any outputs of NLP or sentiment analysis used on subject context data is considered as an additional form of subject context data.
The collection of these context factors may be obtained by one or more methods and stored on an electronic storage device. An exemplary list of methods is provided below, which is not intended to be exhaustive:
One or more of these collection devices may or may not be calibrated and the post-calibration data may be used to supply the subject context data. For example, a continuous glucose monitoring device often needs to calibrate to an individual before it can produce reliable readings.
This section details the type of microbiome samples, measurements, data and location information associated with the subject at one or more time points. Recall that the term microbiome is utilized herein to refer to the aggregate of all microbiota (including all related microbiota biological properties such as genetics, proteins, metabolites, transcriptomics, etc.) and properties of the environment that they reside on or within human tissues, solids, biofluids and/or biofilms along with the corresponding anatomical sites in which they reside, including the skin, mammary glands, seminal fluid, uterus, placenta, ovarian follicles, lung, saliva, oral mucosa, nasal mucosa, conjunctiva, biliary tract and gastrointestinal (GI) tract. Types of microbiota in our definition include bacteria, archaea, fungi, protists, viruses, phages, plasmids, prions, parasites, mobile genetic elements and micro-animals.
Therefore, the elements of microbiome data being produced or received will depend on the sample taken (e.g., sample size, sample quality, etc.) and the analysis method. Some examples of microbiome data that may be produced or received include, but are not limited to:
For clarity, the term “species” is utilized to refer to both known (identified) species and/or unknown or genetically distinct microbiota (and/or phylotypes). Genetically distinct may be defined by either an exact genetic match or a genetic similarity measure.
Each element of microbiome data may also include one or more sample data for the one or more samples associated with the element of microbiome data. This sample data may include one or more of a range of different information about the sample, including but not limited to the sample:
Given the optional one or more context factors for a subject, the next step may be to acquire or receive one or more bodily samples of the subject from one or more locations at one or more times and to associate each sample with one or more times and locations. These samples may include, but are not limited to:
In order to obtain one or more samples for the patient, one or more of several different types of sampling device that may be used. In some cases, the samples are obtained manually and may be analyzed either in a central lab and/or a point-of-care (PoC) ex vivo diagnostic device. In some cases, the samples must be retrieved after sampling (e.g., a GI-ingestible pill that performs sampling and requires retrieval from stool after passing) for analysis ex vivo. In some cases, the samples may be analyzed on the device (e.g., a smart endoscope, a GI-ingestible capsule, etc.) in vivo and transmitted to a receiver (e.g., via an antenna, Bluetooth, NFC, etc.) for processing and storage and/or retrieved ex vivo for data retrieval. Both ex vivo and in vivo analysis of the one or more subject samples may be performed and there may be different sample collection and/or sample analysis methods for different samples, where each sample is associated with a time and location.
A wide variety of sampling devices may be used to obtain samples for analysis. Such devices include:
Note that the times and locations of each of these samples may be determined using one or more different methods and technologies, including those on the list above. Each sample may or may not utilize one or more different or similar methods for obtaining time and location information about the sample. Note that in some cases the times and locations for one or more samples may be obtained differently and have different levels of precision. For example, a precisely located and manually recorded skin swab and a categorically located stool excretion (e.g., labeled simply as “colon” or “GI tract”) could both be obtained and analyzed. A hierarchy or taxonomy (ontology) of different locations may or may not be used to define a relationship between different locations and times.
For each sample acquired from the subject, the location and time of the sample may or may not be recorded. These sample times and location may be recorded in one or more multiple different ways. Any of these location methods may be associated with one or more samples and the location may be retrieved wirelessly (e.g., via an antenna, Bluetooth transmitter, etc.) or recorded and accessed when the sample is retrieved (e.g., with a GI-ingestible capsule). For clarity, each individual sample may or may not have multiple time and/or location measurements performed with multiple different time and/or location measurement methods.
Time measurement methods include, but are not limited to:
Location measurement methods include, but are not limited to:
In each of these cases, the sensor or transmitter could be attached to the sample or sample acquisition device. As with all devices described herein, it is presumed that these sensors, transmitters, receivers, transponders, tethers, magnets, controllers, actuators, etc. are appropriately calibrated and sterilized, if necessary.
Depending on the sample type, sample device, and aspect of the microbiome being analyzed the sample may be analyzed with one or more of a large number of in vivo and/or ex vivo methods. In the following, examples are detailed regarding how the microbiome samples might be analyzed for each of the microbiota and/or microbiota environment. For clarity, sample analysis may be performed as part of the invention and/or received from an external source.
i. Sample Analysis of Microbiota
A sample analyzed in vivo (e.g., ingestible capsule) or ex vivo (e.g., a lab and/or point-of-care device) can use a wide variety of different methods to analyze the microbiota, both multi-omic and classical. Examples of these in vivo and/or ex vivo methods potentially include, but are not limited to, one or more of the following methodologies:
Note that subject samples may also be sampled and analyzed in vivo, where the data is either retrieved ex vivo or where the data is transmitted to an external receiver (e.g., via an antenna, Bluetooth, etc.) for processing and storage from the sampling device. Each sample may be independently analyzed either in vivo, ex vivo, received from an external source or a combination of these.
ii. Sample Analysis of Microbiota Environment
A sample analyzed in vivo (e.g., ingestible capsule) or ex vivo (e.g., a lab and/or point-of-care device) can use a wide variety of different methods to analyze the microbiota, both multi-omic and classical. Examples of these in vivo and/or ex vivo methods potentially include, but are not limited to, one or more of the following methodologies:
For each sample taken, the resulting data, including the corresponding time and location information is stored in one or more electronic storage devices for further processing and analysis.
As with the context factors, note that each of these location and microbiome measurements may also be represented as probabilities. One reason to use probabilistic representations is to account for the possibility of inaccurately measured information (e.g., due to sensor precision), insufficiently sampled information or information that is not current.
In this section, different types of data that may or may not be associated with a user are detailed. These user context factors, user engagement data, linked subjects, user-subject linkages, coach-user linkages, user-aggregated coach user interaction data and the possible time/location of these data associated with a subject, are collectively referred to as “user data” and each specific type of data as a data “element”. For clarity, the user data for different subjects may or may not contain all the same types of data elements and each user may or may not contain any or all data elements. Note that user data for a certain user may be considered to encompass some or all subject data from one or more subjects that are associated with that user (including subject-subject linkages and subject data for linked subjects) and may or may not also encompass some or all coach data and user-coach interaction data for one or more coaches linked to the user. For clarity, the subject data for different subjects may or may not contain all the same types of data elements and each subject may or may not contain any or all data elements.
Any or all of these user data may or may not be stored on one or more electronic storage devices.
In order to better serve a user and/or customize the user experience, certain user context factors may or may not be gathered about the user. A variety of potential user context factors to be obtained are contemplated. Some of these context factors can be obtained either via questionnaires for the user or via connection with another system (e.g., a social media account, a hospital account, etc.). These user context factors about the user may include one or more of, but are not limited to, these examples:
For clarity, any of the example of user predispositions may also be input as user context factors.
The user may be interacting with the system in multiple different ways. Some examples of user engagement include but are not limited to:
For clarity, natural language processing (NLP) and/or sentiment analysis may be applied to one or more of these user engagement data elements to add additional user engagement data. For one example, NLP could be applied to audio recording of coach communication to collect data to assess a subject for cognitive decline. As another example, sentiment analysis could be applied to analyze a user (who themselves is the subject) posting on message boards to assess the subject's pain level. Any outputs of NLP or sentiment analysis used on user engagement data is considered as an additional form of user engagement data.
As described below, the user may or may not have interaction with one or more coaches. A combination of one or more user-coach interaction data may or may not be associated with a user. Such a combination may be termed as “user aggregated user-coach interaction data”.
One or more coaches may or may not be associated with one or more users. For example, a user-subject who wanted to both lose weight and who suffered from diabetes may benefit from having two separate coaches to help them lose weight and manage their diabetes. Similarly, two different users may share a coach.
In order to better serve a user and/or customize the user experience, certain coach context factors may or may not be gathered about the coach. A variety of potential coach context factors to be obtained are contemplated herein. Some of these context factors can be obtained either via questionnaires for the coach or via connection with another system (e.g., a social media account, a hospital account, etc.). These coach context factors about the coach may include, but are not limited to, one or more of the following examples:
As described below, the user may or may not interact with one or more coaches. A combination of one or more user-coach interaction data may or may not be associated with a coach. Such a combination may be termed as “coach aggregated user-coach interaction data”.
In the inventive concepts described herein, each subject is represented in the system by a set of data elements that represents one or more of the contextual information and the microbiome measurements. Each microbiome measurement has a location and/or time associated with it, when available. One or more of these data elements may be missing for any particular subject. When a subject is missing one or more elements of subject data, the system may or may not fill in one or more missing elements via sampling likelihoods (e.g., marginal or conditional probabilities) from the system subject database, taking representative values from published scientific literature, etc. Some subjects may have no contextual information or microbiome measurements, created purely as a function of linkages with other subjects in the system. Each data element may also associate a time with that data element indicating either when the data element was generated (e.g., from a patient measurement or context element) or, if not available, when the entry of the data element into the system occurred. When more recent data elements for a subject are input into the system, these elements are added to the data representation of that subject, potentially with a new time associated, without replacing or deleting the previous data element. All subject representations are stored in one or more electronic storages devices. Note that, from time to time, data from multiple subjects may be merged into one subject or data from one subject may be split into multiple subjects. For example, if a new subject entry was created due to a linkage and it was later determined that this new subject entry corresponded to an existing subject in the system, then these subject entries (accounts) may be merged.
All defined linkages are represented on an electronic storage device and may change in response to new data or modified mechanisms for defining linkages. Linkages, weights, signs and directionality may be represented electronically via any number of standard methods, including but not limited to labeling the electronic entry of a subject (e.g., in an array, linked list, object in object-oriented language) with one or more labels representing linkage membership or by storing different types of linkages as groups (e.g., arrays, objects) of subject identifiers. Depending on the representation for linkages, the ordering of subjects in the linkage representation may or may not be considered significant (e.g., to represent directionality and/or sign). Linkages may also be altered over time and, as with subject data changes, these updates are added to the data representation of that subject and linkages, potentially with a new time associated, without replacing or deleting the previous data linkage representation. For example, if two subjects lived in the same household and later changed this living situation, the system may record the new (absence of) linkage between the subjects, while still maintaining a record of the previous linkage.
Because linkages represent potential microbiome interactions between subjects, information about one subject may provide additional or improved information about a linked subject. Each sample taken from a subject most often will not contain all elements of the subject's microbiome. Therefore, if a linkage between subjects represents microbial sharing, then a sample about one subject may further inform knowledge about another subject. Estimating a true population (in this case, the microbiome elements of a subject) from one or more samples is a core problem of sampling theory and parameter estimation methodologies. In this case, although the linkage between two subjects represents an incomplete microbial overlap, two samples from two linked subjects provides an improved estimation of the complete microbiome population of each subject than would be obtained by treating each subject sample independently.
The type of linkage can be treated differently in using multiple samples from linked individuals to better estimate microbiome populations. For example, two subjects with a linkage representing a shared geography may have similar microbial populations due to similarities in ambient temperature, humidity, moisture, weather, local microbial environment etc. In contrast, two subjects with a linkage representing a romantic relationship and shared household, may have a more significant overlap in microbial populations, particularly in certain locations (e.g., the skin microbiome due to physical contact).
Linkages may also be used to inform missing information, including context information, about each subject. For example, if one subject is missing geographical location information and this subject is linked to a localized community (e.g., an employer, church, etc.) where each subject in the community is all in one specific geographical location, then there is a high probability that the subject with missing geographical location information is in this same specific geographical location.
In this manner, linkages associated with a subject provide additional information which can be used to better improve and keep current the information of the subject, enabling more accurate data analysis, predictions and user feedback from the system.
Dimensionality reduction is a method for reducing the number of variables in a dataset in order to better visualize data and/or as a preprocessor for a dataset prior to machine learning and/or other analysis. Dimensionality reduction may be performed by the following steps:
Unsupervised and/or generative learning methods (e.g., clustering, k-means, etc.) may also be used for similar purposes. Specifically, clustering subject data may be used as a preprocessor for subsequent methods, to visualize clusters for data discovery or even as a form of dimensionality reduction (e.g., reducing patient data to belonging to one or more of a small set of clusters).
In order to inform the user (which may be the subject themselves, parent, doctor or some other relation to the subject) about the state of the subject, this part of the disclosure addresses how the subject data in the system may be used to provide more information for the user. There are many ways in which the data in the system may be used to better inform the user, as subsequently described.
Data/information access for a user includes one or more output devices, which may or may not be electronic (e.g., monitor, laptop, smartphone, paper, electronic document, EMR, etc.).
For clarity, there may be multiple types of users accessing information for one or more subjects and these different types of users may have access to different data elements. For example, a first user may be the subject themselves who is able to access and modify detailed information about themselves in the system. In contrast, a second user may be a researcher who can access only a small portion of de-identified subject data in the aggregate across a population of subjects.
One or more elements of the subject and/or user context information may be accessible to the user and may or may not be editable by the user. The context information may be represented as it was input to the system and/or a probabilistic representation of this information may be displayed. Some context information varies with time (e.g., glucose, sleep tracking, nutrition, etc.) and therefore may or may not be visualized for the user with a time-varying plot, graph or display.
When a user is associated with multiple subjects (e.g., a doctor with multiple patient subjects, a farm owner with multiple animal and/or plant subjects), the user may access population-based displays of context information that provides population level statistics, information and comparisons. Context information for one subject may also be displayed to the user in the context of a population, such as all subjects, all linked subjects in the subject's town, all linked subjects in the subject's workplace, all subjects in a certain geography and/or all subjects in a certain demographic range (e.g., males aged 25-35, etc.). The contextual data about a subject in the context of a population could be displayed in multiple ways, e.g., showing where the subject is in a population distribution, whether the subject is above/below mean (medium), etc.
Population data over time may also be displayed in a variety of ways, e.g., as an animation.
As described above, our system may represent each microbiota and each biological property of these microbiota and/or their environment (collectively referred to here as microbiome “elements”) as a number indicating the concentration of that element at a particular location. Alternately, other representations could be used, such as a binary number to represent the presence or absence of an element at a particular location or a probability distribution to represent the probability of that element at a particular location. As described above, these locations may be at different physical levels for different subjects depending on the sampling mechanism used (e.g., “GI tract” compared to “duodenum”).
At a most basic level, the user may access and visualize the microbiome representation at one or more locations on and/or within one or more subjects. These visualizations may take a variety of forms, including but not limited to:
For clarity, these concentrations could reflect one or more of any element of the microbiome (microbes, metabolites, virii, temperature, gas concentrations, etc.). As above, these displays could be altered to represent a population of subjects, one subject in the context of a population of subjects and/or evolving through time. For example, a pie chart could represent changes over time with successive pie charts, concentric pie charts where each rim of the pie represents a different point in time, etc. These populations may be defined in many different ways, such as the entire population represented in the system, a population with a certain medical condition, a population located in a certain geography, a population defined by linkages to a subject, a population of subjects associated with the user's account, etc. Various epidemiological information in one or more populations may or may not also be generated and displayed, such as the rate of change for a certain microbe type within a population, across linked individuals or communities, etc.
As described above, the user may be able to access the raw data display of both the contextual and/or the microbiome data. In addition to this information, or instead of it, the user may also have access to additionally processed information generated by the system to provide more descriptive assessments of the subject data. As with all information processing in this disclosure, this processing is done by the system via any of one or more electronic processors (e.g., CPU, GPU, DSP, smartphone, laptop, desktop, cloud, mainframe, etc.).
These descriptive assessments may be calculated separately for one or more types of microbiota and/or including microbiota biological properties and/or environment (such as genetics, proteins, metabolites, transcriptomics, temperature, pressure, etc.) that have been measured or otherwise input into the system for one or more subjects (e.g., bacteria, archaea, eukaryotes, virii, phages, etc.) and/or at certain taxonomic levels (e.g., kingdom, phyla, family, genus, etc.) and/or within a taxonomic level (e.g., firmicutes, bacteroidetes, etc.). Examples of these descriptive assessments include, but are not limited to:
Note that these microbiome diversity calculations may or may not also take into account a similarity weighting between different microbiome elements. For example, in the case of microbes, this weighting could be determined by one or more of phylogenic distance, Faith phylogenetic distance, molecular similarity (e.g., genetic similarity), or even a similarity weighting between two microbes that is learned by machine learning techniques (e.g., based on learning which microbes have similar metabolic effects, etc.). One or more of these assessments may also be displayed to the user to show how these quantities change over time.
Assessments about the sampling and measurement acquisition for one or more subjects at one or more locations may or may not also be displayed to one or more users. Examples of these sorts of assessments include, but are not limited to:
Any of these assessments could be displayed to one or more users as a function of time or in comparison to a population. For example, comparing a subject's motility (or residency time) from the small intestine to the large intestine to the distribution of motilities from the small intestine to the large intestine of a population (e.g., of similar patients, of the same age range, in a similar geographic location, etc.).
One or more alerts may be created for one or more users (e.g., a person and their doctor) if one or more conditions are met by this data for one or more subjects (e.g., the presence of a significant concentration of a known pathogen in one or more linked subjects). Alerts may also be generated for one or more users associated with a first subject if there are significant changes in the information of one or more linked subjects or if one or more subjects initiates a change in link status with the first subject. These alerts may take one or more different forms, such as push notifications on a smartphone, email, postal mail, web page banners, etc.
The inventive concepts described herein conceptualize connecting together a wide range of subject predispositions (e.g., all medical conditions (physical and mental), traits, behaviors, wellness factors, agricultural outputs, social characteristics, microbiome states, etc.) and subject data to inform the user(s) about risk factors, treatment effectiveness, diet and lifestyle improvement, products and services, etc. related to one or more subjects. Information displayed about one or more subjects to one or more users based on subject data is termed herein as “subject predispositions”. For clarity, these subject predispositions may be determined using all subject data or a subset of subject data. For clarity, these subject predispositions may or may not be determined using only subject context factors (or a subset of subject context factors), only subject microbiome data (or a subset of subject microbiome data elements), only subject linkage information (or a subset of subject linkage information), only subject data associated with one or more linked subjects (or a subset of subject data associated with one or more linked subjects), only user linked data and/or a mixture of these data (or subset of a mixture of these data). For clarity, subject predispositions for different subjects in a single embodiment, or subjects in different embodiments may be determined using different subject data elements, mixtures, etc. For clarity, these subject predispositions may refer to subject predispositions in one or more of the future, present and/or past. A small number of examples of subject predispositions include, but are not limited to:
For clarity, any of the examples of subject context factors may also be produced as subject predispositions, even in cases where the corresponding subject context factors have been entered. In some cases the subject context information is not entered for the subject (e.g., germline genetics) and must be inferred. However, even in examples where the subject data is the same as one or more subject predispositions, it may still be meaningful to display one or more risk scores associated with one or more subject predispositions since the subject data may contain errors, be outdated or there may be a conflict between an element of subject data and a subject disposition which may be useful for the user to be aware of (e.g., knowing that all signs point toward a subject predisposition for the subject to be lean and yet the subject is obese).
Subject predisposition directionality may or may not be additionally determined. For example, if we know that one or more subject data elements are in a state of change, then one or more subject predispositions which depend on that data element may also be in a state of change. Specifically, it has been shown that it is possible to determine which elements of the microbiome are currently in states of significant replication by examining the copy number of microbes. A microbe species where a significant percentage of the population has a large copy number can be determined to be in a state of growth. Therefore, a microbe species in a state of growth may also indicate a direction of change for any subject predispositions that are associated with that microbe.
i. User Display of Subject Predispositions
One or more subject predispositions may be displayed and/or provided to one or more users and/or coaches in a variety of different ways including, but not limited to:
Subject predispositions may be determined from the subject data in multiple different ways. Each determined subject predisposition may or may not also have associated a measure of confidence indicating the subject predisposition quality, reliability, evidence, etc. Each determined subject predisposition may or may not also include information about interpretability/explainability or how that subject predisposition was determined from the subject data (e.g., by linking a scientific study). A system that determines subject predispositions based on one or more elements of subject data and/or one or more subject linkages (possibly also including subject data from linked subjects) may be termed as a “subject prediction engine”. As above, the subject prediction engine may or may not also determine one or more confidences, information about the reasoning behind one or more subject predispositions, etc. In this section, we detail many different examples of methods by which a subject prediction engine may be used to determine subject predispositions. For clarity, a subject prediction engine may or may not use one of these methods and/or may combine one or more methods to determine subject predispositions.
For clarity, the subject data used in any of these methods for a subject prediction engine may be the raw subject data in the system, a transformed set of raw subject data (e.g., normalized, cleaned, dimensionality reduced, etc.), the probabilities/stochastic variables possibly associated with the subject data elements and/or some combination of the above.
In any of the subject prediction engine methods detailed below, the input data and/or output data may or may not be transformed using one or more of many standard techniques. These techniques include, but are not limited to:
For clarity, the inventive concepts described herein conceive that one or more of any data transformation techniques could be applied in different orders in the subject prediction engine.
Many publicly presented studies have been conducted, and more will be conducted in the future, that connect one or more elements of the subject data (e.g., context, associated user data, linkages, microbiome, locations and changes over time) with one or more subject predispositions. As a result of these publicly presented studies, the subject prediction engine may or may not display information to one or more users that connect the results of these studies to one or more subjects (or linked subjects).
In a scenario where this information is being presented to a user, the subject prediction engine may maintain a database or data lake of known connections between various subject data elements and known subject dispositions. This database may represent these connections at one or more levels. For example, if a certain species of bacteria were connected to colon cancer based on a robust set of published scientific studies, then the database could represent this information in one or more ways. For example, a database could represent this information as a connection between that bacteria and colon cancer, between that bacteria at a specific location and colon cancer, between various concentration levels of that bacteria and colon cancer, between that bacteria genus (phyla, etc.) and colon cancer, etc. Each of these representations may also contain information about the confidence in the connection and/or causality (e.g., the bacteria causing colon cancer, the bacteria amplifying severity of colon cancer, colon cancer causing the bacterial growth, mere correlation, etc.). This connection confidence or causality, if included, may be derived from multiple sources, such as the number of published studies showing the connection, the size and quality of those studies, the study population better matching the subject, etc. Thresholds may be defined by the subject prediction engine and/or user such that information about the connection with a subject predisposition is only displayed if the confidence of that connection exceeds the defined threshold. For clarity, the connection between patient data and the patient disposition may be derived from a single element of patient data (e.g., a particular family of bacteria at a particular location in the colon is connected to a subject disposition for colon cancer) and/or multiple elements of subject data (e.g., a certain mixture of subject GI microbes together with certain subject genetics and subject blood biomarker levels are connected to obesity in women). Similarly, subject data about a subject's linkages (or the linked subject data) could also be connected to one or more subject dispositions (e.g., a certain mixture of a first subject's skin microbes together with a certain mixture of skin microbes for a second group of subjects in the set of the first subject's one or more linked romantic partners could be connected to predisposition for increased sexual attractiveness in the first subject). Many different types of subject predispositions could be connected to one or more types of subject data.
The information in such a database could be assembled in many different ways and may be either static or dynamic. Examples include, but are not limited to, one or more of manual entry, a web crawler gathering data from the internet, a publication crawler that mines scientific publications, a software that mines an audio recording of a scientific talk, natural language processing, existing databases, etc. Note that such a database or data lake could be centralized, de-centralized and/or generated dynamically (e.g., a web crawler that searches the web and finds evidence for a connection between subject data and a subject predisposition whenever a connection was displayed to a user).
The microbiome is a large, complex, evolving, spatially differentiated ecosystem that interacts with the subject and linked subjects. In order to better understand and make more accurate predictions of microbiome changes and influences, one method for a subject prediction engine is to model and simulate the microbiome, subject and potentially one or more linked subjects.
i. Microbiome Modeling and Simulation at One Location
Given information about the microbiome from a location, there are multiple methods for performing modeling and simulation of the microbiome at this location by assessing the interaction between elements of the microbiome. Example interactions may include, but are not limited to:
This modeling may be performed categorically (e.g., knowing the rate of metabolite output of a certain microbe in response to a stimulus to model an overall change in metabolite concentration at a location), in one or more spatial dimensions to analyze transient, phase change or steady-state phenomena. The domain and initialization may either be informed and personalized to the subject with measured data (e.g., surface information for a section of the subject's colon, sample measurements, etc.) or a uniform, random or otherwise generic domain and initialization may be used. Data from one or more linked subjects may also be used to inform or personalize the domain and initialization simulation for the subject.
In each of these cases, an initial population must be defined and the change represented by modifications to certain (sub) populations, interactions between (sub) populations, changes to growth (or death) rates for a certain population, spatial interactions, domain changes, boundary condition changes, and the like.
As a non-limiting example of the foregoing, an objective may be to model and calculate the impact of a newly introduced species on the microbiome populations at a location. The concentration of each microbial species (and/or virus, phage, etc.) may be represented by a real number associated with that microbiome element and a real number to represent the newly introduced species. Initial concentrations of each species may be set in accordance with a microbiome measurement at that location, a population (or subpopulation) average, uniformly or randomly. Each species may be assigned an individual baseline death rate over time, a growth rate over time and a rate representing the impact of each pair of species on each other's growth or death rate. These baseline rates and impact rates may established based on one or more of many different factors, but not limited to, the scientific literature, measurements over time, experimental data, other modeling, uniformly and may be fixed, time-dependent or species population dependent.
In this scenario, the impact of a newly introduced species on microbiome populations may be calculated by solving a system of Lotka-Volterra equations either transiently or at steady-state using a computational process. This calculation could be further complexified in many ways, such as by adding terms to represent quorum sensing between microbial populations, changing baseline growth/death rates over time in response to modeled nutritional changes, pH changes, temperature changes or modeling a sudden cross-species drop in population to determine the impact of antibiotic usage in combination with the introduction of a new species.
Another way in which this calculation could be modified is by adding a spatial element to the model to more accurately calculate the impact of a newly introduced species. For example, if the target location was a section of colon, then a generic or personalized spatial surface model of that section of colon could be created (e.g., extracting the subject's individual colon surface from radiological imaging, capsule endoscopy, etc.). In this more complex model, each location in the 3D domain (e.g., a tetrahedral geometric domain representation) of the simulated patient colon could be associated with a real number representing the concentration of each microbiome species at that location (e.g., at each tetrahedron). The initial concentrations of each species at each location may be initialized either via subject sampling information, uniformly, randomly or with any other method. The initial concentration of the newly introduced species could be a single location (e.g., concentration of zero everywhere else), uniformly across tetrahedra or via any other manner. Boundary conditions for the domain may be set using any number of standard methods such as Dirichlet, Neumann, Robin, Helmholtz, Cauchy or a mixed boundary condition. These boundary conditions may be set using subject sampled information or set more generically (e.g., a Dirichlet boundary condition of zero, the population averages, randomly, etc.). Interaction of species concentrations between tetrahedra could be modeled mathematically in many ways, for example as a diffusion relationship (transport equation, etc.) with the Lotka-Volterra equations governing the internal element dynamics. Given this domain, boundary conditions, initialization and coefficients, the transient or steady state may be calculated through a variety of different methods, such as a finite element method (finite difference, etc.).
In this example, multiple different ways in which a microbiome system could be modeled as part of the subject prediction engine were described in order to calculate the impact of the introduction of a new species. This example model could also be used to calculate the impact of a fecal transplant (e.g., by initializing the domain with multiple new species and/or changing the initialization of the concentrations of the existing species) or multiple other of the example models and calculations described above.
The metabolites produced by the ecosystem of species could be further added to the model. For example, each metabolite concentration could be represented as a real number that is a function of one or more species concentrations at a particular location. These functions could be determined from the literature, from experiment, or assumed to follow a standard relationship (e.g., different concentrations are simply proportional to different species). Adding in this metabolite element to the model enables the calculation of a variety of metabolites at different locations over time as species concentrations change. In this example, a decay term for one or more metabolites could be further included to model removal of these metabolites over time (e.g., due to subject bodily consumption, etc.).
ii. Location Interactions
One aspect of the concepts described herein are that microbiome samples may be acquired at one or more locations at one or more time points. These locations may be precisely defined (e.g., first sample from the small intestine 15.2 mm distal to the pyloric valve compared to a second sample from the small intestine 16.1 mm distal to the pyloric valve) or more categorically defined (e.g., first sample from the oral cavity compared to a second sample from the GI tract). These different locations can be modeled as interacting with each other in multiple different ways. In the previous example above, the two samples could be modeled as coming from adjacent tetrahedral subsections of a domain representing the subject's small intestine where the two subject samples are represented as two separate initial conditions for microbial concentrations spread uniformly across all domain elements in the two sections. In this case, the interactions between the subsections might naturally be modeled the same way as any two adjacent domains (e.g., in the above example, via a diffusion or transport relationship).
However, location interactions may also be modeled in a variety of very different ways. For example, the relationship between microbial concentrations in the oral cavity and the microbial concentrations in the GI tract could be modeled by assuming that a certain number of microbes in the oral cavity are swallowed and pass into the GI tract. A simple version of this model could, again, have two sets of real numbers to represent the microbial populations of each species is each of the oral cavity and the GI tract. At each time point in the calculation, a random selection of microbial populations in the oral cavity representation could be subtracted (swallowing) and those same microbial populations (or a diminished amount or subset) could be added to the population representation in the GI tract to model the swallowing interaction.
iii. Subject Ecology Modeling
One embodiment of this microbiome simulation and modeling method is to maintain a microbiome simulation model for each subject at one or more locations that is continuously updated as new information is received and/or measured in the subject data. The model may also be updated as more information about specific or general microbe interactions become known (e.g., via scientific publication) to update subject predispositions. Insofar as there are random, stochastic or otherwise probabilistic components of the simulation, more than one sampling of these random components could be used to calculate distributions or probabilities for subject dispositions. Such an ongoing simulation model for each subject could be considered to be a dynamic digital twin of the subject microbiome ecosystem. Such a simulation could be visualized for a user as well, if so desired.
As the scientific literature expands, there will be an increasing number of established connections between subject data and one or more subject predispositions that may be displayed to a user. Similarly, simulation methods may also accurately enable calculation of interactions between microbes and their environment to provide estimations of subject predispositions. In addition, a subject prediction engine may also be established using one or more machine learning methods. There are multiple methods that may be employed by a subject prediction engine, that we detail below.
i. Supervised Learning
Supervised learning methods may be used by a subject prediction engine to establish a connection between one or more subject data elements, linkages and/or linked subject data elements with one or more subject predispositions. In general, a supervised learning method requires a training and a deployment phase. For instance, referring now to
The deployment phase of such a system may consist of the following steps:
For clarity, the target subject predispositions may have different types of values, such as categorical (e.g., presence of colon cancer vs absence of colon), ordinal (e.g., colon cancer stage 1, 2, 3 or 4), real-valued (e.g., days to colon cancer recurrence following treatment), etc. Subject data may also have different types of values (e.g., subject weight, presence or absence of a certain bacteria species, etc.) which may or may not be converted to a single type (e.g., real-valued) as needed. A wide variety of supervised machine learning methods may be used in this step, including but not limited to deep learning, support vector machines, k-nearest neighbors, random forests, decision trees, logistic regression, graph machine learning, generative adversarial networks, etc. Different variants of these machine learning methods may be applied to match the type of the target subject predisposition as needed (e.g., regression, classification, etc.) and/or the type of the target subject predispositions may also be converted to another type during training (e.g., converting the target predispositions to real values).
Another possibility would be to follow an unsupervised method (e.g., clustering, k-means, etc.) with a discriminative method (e.g., by using a manual or automated method of identifying a discrimination boundary) in the same manner as a supervised classifier to assign subjects in different clusters to different sets of subject predispositions.
One or more knowledge graphs or knowledge bases could be constructed and updated by mining a variety of different sources, including but not limited to public databases, social media, scientific literature, subject data, user data and coach data. These data may be used to connect together various elements of microbiota and other elements of the microbiome with information including, but not limited to, subject predispositions, user predispositions, human, animal and plant health, nutrition, wellness, etc. A knowledge graph may or may not be manually and/or automatically curated and may leverage natural language processing (e.g., large language models, foundation models, etc.), video analysis, audio analysis, sentiment analysis, etc. technologies. Inferences on a knowledge graph may be used to derive subject predispositions from subject data and may or may not also be used to provide the reasoning, explainability and/or causal chain behind these inferences.
A knowledge graph may include a wide variety of entities and/or ontologies of entities. Any element of subject data, user data and/or coach data may represent an entity and/or be contained in an ontology. Examples of entities and ontologies of entities include, but are not limited to, the examples in the knowledge graph 400 illustrated in
A wide variety of connections (i.e., directed and/or undirected edges) may be included in the relationship graph between different entities and/or ontological levels. A small number of examples include, but are not limited to:
For clarity, multiway connections (e.g., hyperedges) similar to the above may or may not also be included. Some examples of multiway connections include but are not limited to:
For clarity, these connections may or may not also account for temporal effects (e.g., the initial introduction of a drug causes microbial proliferation and after two weeks the microbial environment returns to a pre-introduction state, etc.). For clarity, the entities may have one or more of multiple different representations, such as binary, integer, categorical, real valued, etc. (e.g., a drug might be represented as binary (presence or absence) and/or as a real value (dosage quantity over time)).
With these one or more knowledge graphs, the system may include a variety of different methods for searching, querying, reasoning, inference, improvement or other methods for interacting with knowledge from a knowledge graph, including but not limited to schema (e.g., semantic, validating, emergent, quotient graphs, etc.), context methods (e.g., direct representation, reification, higher-arity representation, annotation, contextual knowledge repositories, etc.), deduction, interpretation, property axiom definition, standard ontology operations, classes, semantics, entailment operators, reasoning operations (e.g., rule-based, inference rules, description logics, etc.), induction operators (e.g., numeric, symbolic, unsupervised, self-supervised, supervised, etc.), graph analytics operations (e.g., centrality, community detection, connectivity, node similarity, graph harmonics, graph drawing techniques, graph embeddings, path finding, etc.), machine learning methods (e.g., graph neural networks, recursive graph neural networks, convolutional graph neural networks, symbolic learning, rule mining, axiom mining, etc.). A knowledge graph may also use one or more different identifiers (e.g., persistent identifiers, external identity links, datatypes, lexicalization, existential nodes, etc.) and/or include one or more refinement, quality improvement, correction (e.g., fact validation, inconsistency repair, etc.) and/or completion tools.
In addition to subject predispositions to certain diseases, traits, therapies, etc., the user may or may not also have certain predispositions based on user behavior, personalization, coach interaction, customization, etc. These predispositions may be termed as “user predispositions”. Examples of user predispositions include, but are not limited to:
For clarity, any of the examples of user context factors may also be produced as user predispositions. These user predispositions may be determined from one or more current and/or historical factors including but not limited to:
User predispositions may be determined from the user data in multiple different ways. For clarity, recall that user data may or may not include some or all user coach interaction data, some or all subject data for one or more subjects that the user is linked with, information about subject-subject linkages for those subjects and/or some or all subject data for one or more additional subjects linked to those subjects.
Each determined user predisposition may or may not also have associated a measure of confidence indicating the user predisposition quality, reliability, evidence, etc. Each determined user predisposition may or may not also include information about how that user predisposition was determined from the user data (e.g., by showing the user their prior history). A system that determines user predispositions based on one or more elements of user data may be termed as a “user prediction engine”. As above, the user prediction engine may or may not also determine one or more confidences, information about the reasoning behind one or more user predispositions, etc. In this section, different examples of methods by which a user prediction engine may be used to determine user predispositions are detailed. For clarity, a user prediction engine may or may not use one of these methods and/or may combine one or more methods to determine user predispositions.
Similar to the subject prediction engine, the user prediction engine may employ machine learning, supervised learning, neural networks, etc. In addition, prior to use in the training or deployment of a user prediction engine, the user data may or may not be transformed, augmented, etc. similar to the subject data transformation and augmentation described above.
Some user predispositions are likelihoods that a user would be more likely to benefit from, engage with and/or prefer certain educational topics, products, services, advertisements and/or coaches. For these user predispositions, possibly but not necessarily including others, a user prediction engine may use recommender systems.
The training phase of a recommender system may consist of the following steps:
The deployment phase of such a system consists of the following steps:
A wide variety of recommendation system methods may be used in this step, including but not limited to collaborative filtering, content-based filtering, reinforcement learning methods, session-based methods, risk-aware systems, etc. As one or more user's data changes (e.g., additional interactions with the system, new coaches, new products, new services, etc.) the recommendations may or may not continue to update.
As a non-limiting example, a system associated with the foregoing concepts may be used to recommend education material for a user. In this example, one user for a subject may be the subject themselves. This user may have set a goal for themselves to reduce acne. By assessing the subject's nutrition, GI microbiome, skin microbiome and environmental humidity, the system may recommend educational materials on the causes of acne, the role of nutrition and the subject's skin microbiome. At a later time point, if the user has read the initial educational material and the acne is becoming less severe, the system may recommend new educational material on related skin conditions, how to improve the skin health and recommend vitamins and skin creams. A second user dermatologist with user access to the subject may be recommended some additional educational materials to remind the dermatologist about related conditions and recommend that the dermatologist follow up with the (user, subject) patient in six months. This recommendation could trigger a reminder for the dermatologist to follow us (see more about alerts below).
In the previous sections, descriptions were provided regarding how the system could be used to inform the user about the subject data that has been measured or otherwise input into the system. Additionally, descriptions were provided regarding how the system could be used to provide the user with one or more subject predispositions that could indicate to the user a variety of different risk factors, traits, efficacy of different treatments, etc. In this section, descriptions are provided regarding how the system can use the subject data to provide guidance to a user and enable the user to perform interactions that may benefit the user.
The most basic form of user assessment for one or more subjects is via a subject report. Such a report may or may not be static and may or may not include one or more elements such as, but not limited to: Text summary of subject predispositions and/or guidances, visualization of one or more elements of the subject data, a list of one or more subject predispositions (which may or may not include a confidence level and/or predisposition magnitude), a representation of subject and/or user data, related scientific literature (or other publicly available information) and/or a list of one or more subject guidances (which may or may not include a confidence level and/or guidance importance). One or more elements of this subject report may be generated automatically or manually.
The user may also benefit from exploring different scenarios for one or more subjects, to determine the effect of changes to subject data on subject dispositions. For example, a user/subject may want to know how quitting smoking, relocating geography or adopting a vegan diet might affect their microbiome and ultimately their disease risk or weight loss. As another example, a doctor user may want to explore different possible treatment pathways for a patient subject obtained by different diets, medications, etc. As another example, a farm owner user may want to explore the effects of different diets on their livestock subjects.
In order to make these assessments, the system may enable a user to perform the following steps:
Users may also have other services provided to them, such as:
Note that the user may also make the subject assessment indirectly by assessing how certain changes with the subject would impact the subject data. For example, if the user specified to the system that the subject was going on a calorie-restricted diet, then the system could modify the subject weight and determine the corresponding subject hypothetical predispositions accordingly. As another example, if the subject were to adopt a certain food, supplement, product, lifestyle change, etc. which was known to change the microbiome in a specific way, then the system would allow the user to assess the impact of the food by modifying the subject microbiome to reflect the impact of that adoption and determining the corresponding subject hypothetical predispositions accordingly.
In the last section, descriptions were provided regarding how the system could enable the user to interactively explore the predicted effects of hypothetical changes to one or more subjects. Another interactive mechanism for a user to explore opportunities for the subject is to establish a target subject predisposition to change (e.g., blood glucose, obesity, etc.) and have the system determine which changes in the subject data to make in order to (most closely) achieve that target. The term “goal” may be utilized to represent these targets.
As described above, the user may have set one or more goals for one or more subjects. For this section, it is assumed that one or more goals have been added to the system by one or more users for one or more subjects. The user may have set a goal (e.g., weight loss, pain reduction, reduce cancer risk, endurance, etc.), a goal may have come from a different user and/or a goal might be input separately. It may be assumed that a goal is structured such that it has a measurable objective defined in terms of a subject predisposition (e.g., in the case of weight loss the measurable objective is weight) and the goal can be described as optimizing the objective function. Note that a goal objective may also be binary (e.g., a goal to avoid recurrence of cancer or maintain current weight), although such binary goals may or may not be rephrased as a real-valued measurable objective by rephrasing the goal in terms of probabilities as needed (e.g., the above goal could be rephrased as minimizing the real-valued probability of cancer recurrence). The term “goal data element” may be used to describe the subject predisposition that the goal is targeting.
In working to achieve the goal, only some of the subject data elements may be modifiable for a particular subject at a particular time. For example, a patient with diabetes who has a goal to lose weight cannot simply modify (cure) their diabetes status, even if curing their diabetes could have a strong impact on achieving their goal. Therefore, in order to have the system provide guidance to achieving a goal, a certain set of subject data elements are first identified to establish the “modifiable data elements” for the system to optimize. This set of modifiable data elements may change over time (e.g., a person in a leg cast may have less control over their fitness today then they will in the future after they heal) and may be established in many ways including being set by a user, a set of users, predefined in the system, etc. Some examples of modifiable data elements include, but are not limited to diet, lifestyle, medication, therapy, cosmetics, fitness, geographical location, pets, linkages, etc.
Although multiple data elements may be modifiable, each data element may be modifiable with a different cost. These costs may represent many different types of cost, including but not limited to monetary costs, ease of modification, time required to modify, likelihood of adherence, risks associated with modification, etc. In one example, a person may find it much easier to modify their diet than their smoking habits. In this case, both diet and smoking habits are modifiable data elements, but the cost of a diet change would be less than the cost of a smoking habit change. In another example, a doctor may want to lower blood glucose levels for a patient. In this case, the modifiable data elements could be different medications, therapies and diet changes and the costs may be monetary costs (or time costs) such that the doctor can optimize the lowest cost (fastest) way of achieving a blood glucose reduction. Therefore, every modifiable data element may be associated with one or more costs. These costs may come from multiple different sources, including but not limited to, user input, price catalogues, known risks, uniform costs, etc. For clarity, these costs may or may not also be nonlinear (e.g., 30 minutes of fitness activity per day for the subject is low cost but 4 hours of fitness activity per day is nearly impossible for the subject and therefore has an extremely high cost).
The goal and progress toward the goal may or may not be represented to one or more users with one or more scores. The score could be the goal itself (e.g., if the goal were to lose weight, the score could be current weight), a normalized version of the goal (e.g., if the goal were to lose 15 pounds, then the score could be a percentage toward achieving that goal), a function of multiple goals (e.g., losing weight and sleeping longer) or a purely invented gamified score to help the user achieve their goal. Different users may have different scores. Scores may be displayed and/or may be accessible on one or more user interfaces or devices (e.g., webpage, mobile device, screen, etc.).
Mathematically, the user guidance to achieve a goal may be represented as optimizing a function of goal achievement (e.g., the squared difference of the current goal data element to the target goal data element), modifiable data elements and costs associated with changes in these modifiable data elements. Depending on the goal, modifiable data elements and costs, the optimization of this function may be performed with different methods. In the next sections, descriptions of multiple methods that could be used to optimize the function are described. Before doing so, however, the general steps involved in user guidance are described, which may include:
Note that the above steps may be run in a loop as desired, updating subject data, costs, goals, modifiable data elements, etc.
Determining a second set of guidance in the above system may be accomplished via many different methods. In this section, several examples of methods to enable this step are provided which are not intended to be exhaustive.
User guidance may be based in part or entirely on publicly available information. Specifically, user guidance may be based on clinical recommendations, drug warnings, comorbidities of health conditions, nutrition information and/or the scientific literature. For example, a subject with Crohn's Disease may be recommended to avoid alcohol in accordance with clinical guidelines.
User guidance may also be generated by associating instances in the scientific literature where the subject data linked to certain subject predispositions to other instances in the scientific literature where certain actions have been associated with changes in the subject data that would yield more favorable subject predispositions. For example, low levels of E. rectale, F. prausnitzii and high levels of E. coli have been associated in certain scientific papers with an elevated predisposition for Inflammatory Bowel Disease. A different set of scientific papers have associated a ketogenic diet with low levels of E. rectale and high levels of E. coli. Other scientific papers have also linked aspirin with an increase in E. coli. Therefore, the user guidance may be determined from these scientific papers by guiding the user that the subject avoid a ketogenic diet or taking aspirin because these actions could increase the subject predisposition for Inflammatory Bowel Disease (and avoiding these actions may lower the subject predisposition for Inflammatory Bowel Disease). However, other scientific papers have linked a low-fat diet with increased levels of F. prausnitzii. Therefore, the user guidance may be determined that the subject is recommended to adopt a low-fat diet as a method of improving the subject predisposition to Inflammatory Bowel Disease. Such a system could be automated and scaled via inference on a knowledge graph that is derived from the literature (as discussed in proceeding and following sections).
The ability to assess hypothetical subject predispositions in response to changes in hypothetical subject data enables the ability to perform a gradient descent-like approach to user guidance. One example is:
These perturbed modified data elements define the guidance to a user at that time. For example, the system may determine through this method that adoption of a ketogenic diet and drinking more water daily will have the most significant (and lowest cost) impact on the subject's weight loss goal. The system may also display to the user the hypothetical subject weight after making these changes as a motivational tool. As the subject adopts these changes and the subject's current subject data is updated, the guidance system may be run again to generate a new set of changes (guidance) for the user to implement to keep optimizing toward their goal.
Reinforcement learning is another category of machine learning that can be applied to help provide guidance to users and related individuals, such as coaches, to help a subject achieve a goal. Reinforcement learning has proven extraordinarily effective in teaching AI to excel at game-playing and is generally framed as a method to teach a computer to achieve a complex goal (e.g., winning a game of chess) via a series of actions and reactions (moves). In our case, reinforcement learning can be used to teach the computer to make moves (i.e., guide the user to act) in order to achieve a goal (i.e., the user goal, while minimizing action costs).
The user guidance problem may be mapped into the framework of reinforcement learning (e.g., Markov Decision Process) by associating:
Given this mapping to a reinforcement learning framework, a wide range of reinforcement learning techniques may be applied to provide the user guidance toward a goal including but not limited to Q-learning, SARSA, deep deterministic policy gradient, proximal policy optimization, etc. Reinforcement learning systems could be trained in a variety of ways, including training on historical subject data changes, simulation of users/subjects, etc. At each step of a reinforcement learning system used for guidance, the system may output a suggested set of modifications for the user to make in order to achieve their goal. This usage of a reinforcement learning system for guidance is similar to how a reinforcement learning system trained to play chess could make move suggestions for a human player at every turn in the game.
Inference on a knowledge graph may also be used to determine the most significant modifiable variables impacting a goal data element and how changes in the modifiable variables could impact the goal data element.
In order to help a user achieve their goals, a user may have the option to interact with one or more coaches. The coaches and users may communicate through various means, such as written communication, voice, video, alerts, etc. Each coach associated with one or more users is represented as a coach-user linkage which is stored on one or more electronic storage devices. A coach with a coach-user-linkage to a user may or may not have access to one or more elements of the user data (e.g., user engagement data, user goals, etc.) and may or may not have access to one or more elements of data that a user has access to (e.g., subject data for subjects that the user is linked, etc.).
One or more coaches may be matched with a user in many different ways. For example, a user could be provided information on one or more coaches (e.g., coach expertise, coach gender, coach background, etc.) and given the opportunity to select a coach. As another example, a coach may be matched automatically to a user using one of many matching algorithms including, but not limited to, the Hopcraft-Karp algorithm, Edmonds' blossom algorithm, greedy algorithms, online bipartite graph matching algorithms, etc. Additionally or alternatively, as another example, a quality measure of match for a user to a coach could be determined via some means (e.g., demographic similarity of user and coach, a measure of similarity based on coach data and user data, net promoter score of user for a coach, the success of a coach in helping one or more other similarly situated users in achieving or progressing toward their goal, any combination thereof, etc.) and this quality measure could be used either as an edge weighting in a matching algorithm and/or used as a measure from which to train a machine learning algorithm to determine the optimal coach for a user, for a machine learning algorithm to learn an edge weighting, etc.
These coaches may also be provided with additional information which can support their coaching effectiveness for different users. For example, a coach may also be given access to the interactive subject assessment capabilities described above that would enable the coach to explore different scenarios of changes to subject data and the effectiveness of those changes to subject predispositions. As another example, the coach may also have access to the guidance information that the user may have from the system and the ability to identify new goals or change goals and determine the resulting change in guidance information. The coach may or may not also have access to user predispositions and/or any information the user has access to (e.g., subject data).
The coaches may also have access to further information which can help a coach support a user, such as access to data about populations of users, populations of subjects, trends, coaching effectiveness, subject linkages, subsets of subject and/or users (e.g., possibly defined by a coach), etc. As one example, a coach may look for trends in subject linkages (e.g., increase in a pathogen among those subjects in the same family as a subject or sharing the same water supply as a subject), trends in all subjects linked to a user (e.g., for a doctor user, supporting the doctor by identifying trends in the doctor's subject patients) or look to compare a subject to other subjects from a similar population (e.g., to assess how typical a subject is compared to other subjects with a similar medical condition or demographic information, etc.). Note that any or all information the system supplies to a coach could be supplied directly to one or more users either in addition to a coach or instead of supplying the information to a coach.
Interactions between one or more coaches and one or more users may also be analyzed for many reasons, including to improve the user experience, coach effectiveness, etc. As described, the coach-user interactions may take many different forms, such as written communication, phone, video, etc. Each of these interactions may be analyzed using one or more different types of analysis system such as natural language processing (NLP), sentiment analysis, video analysis, etc. to generate data that describes the interactions and effectiveness of these interactions. The data produced by this analysis may be termed as “coach interaction data”. For example, coach interaction data may show that when a user is not progressing toward achieving their goal, that certain coaching techniques, suggestions, attitudes, etc. are more effective than others for helping the user achieve their goal. As another example, the coach interaction data may show that when a certain user expresses frustration, that the most effective response for a coach is to respond in a caring way. As another example, coach interaction data may show that certain coaches had a more positive attitude in general and others had a more skeptical attitude, which could be used as data to better train a system to match coaches to users more effectively. As another example, the coach interaction data may also be used to suggest certain educational materials for the user. Coaches may also enter data about a user or user interaction prior or subsequent to user interaction to record notes about the user or interaction. These notes could be structured or unstructured data, written, spoken, etc. Any such note data is considered as part of user coach data. Coach user interaction data may be associated with a coach user linkage, with the user and/or with the coach. Similarly, user coach interaction data for all users associated with a coach may or may not be combined into a larger set of data associated with the coach. This combination of coaching data may be termed as “coach aggregated user coach data” for a coach. Similarly, user coach interaction data for all coaches associated with a user may or may not be combined into a larger set of data associated with the user. This combination of coaching data may be termed as “user aggregated user coach data” for a user.
Any coach interaction data and/or coach aggregated user coach data could be used to train and deploy a machine learning system to determine many different types of output to improve a coach. One example is to train and deploy a machine learning system that uses the coach interaction data to provide information to the coaches (in real time during a session to respond to a user, prior to a user session, as feedback after a user session, etc.) to give feedback to the coach and enable the coach to be more effective with helping the users achieve their goals. Another example is to use a machine learning system trained on the coach interaction data (and/or aggregate coach data) to determine that certain coaches are being generally less effective than their peers (or less effective with certain types of users) and to identify those coaches for additional instruction.
Similarly, any coach interaction data and/or user aggregated user coach data could be used to train and deploy a machine learning system to determine many different types of output to improve ways a coach can most effectively work with a user. For example, one user may prefer brief, fact-heavy interactions from their one or more coaches while another user may primarily respond to encouragement from their coaches. This information could be used to help coaches tailor their approach for a particular user, and/or improve matching of a coach to a particular user.
Note that coaches may or may not have a coach-specific (web, mobile, etc.) interface. The coach may also be augmented, supplemented and/or replaced for one or more user interactions with an automated coach system such as a chatbot, conversational AI, generative AI, etc. Some examples of topics that the coach may support a user on include, but are not limited to:
One or more foundation models could be used to provide guidance to coaches (and/or replace coaches) and related individuals. For example, a generative model could observe coaching sessions to determine a generative model of the coaching session and coach interaction.
Reinforcement learning is another category of machine learning that can be applied to help provide guidance to coaches and related individuals, such as coaches to help a subject achieve a goal. Reinforcement learning has proven extraordinarily effective in teaching AI to excel at game-playing and is generally framed as a method to teach a computer to achieve a complex goal (e.g., winning a game of chess) via a series of actions and reactions (moves). In our case, reinforcement learning can be used to teach the computer to make moves (i.e., guide the user to act) in order to achieve a goal (i.e., the user goal, while minimizing action costs).
The user guidance problem may be mapped for coaches into the framework of reinforcement learning (e.g., Markov Decision Process) by associating:
Given this mapping to a reinforcement learning framework, a wide range of reinforcement learning techniques may be applied to provide the user guidance toward a goal including but not limited to Q-learning, SARSA, deep deterministic policy gradient, proximal policy optimization, etc. Reinforcement learning systems could be trained in a variety of ways, including training on historical subject data changes, simulation of users/subjects, etc. At each step of a reinforcement learning system used for guidance, the system may output a suggested set of modifications for the coach to make in order to achieve their goal. This usage of a reinforcement learning system for guidance is similar to how a reinforcement learning system trained to play chess could make move suggestions for a human player at every turn in the game.
A user and/or coach may also receive one or more alerts in one or more different circumstances. For example, a coach may trigger a user alert or a user may trigger a coach alert. As other examples, a user alert may be generated automatically if a subject exhibits a known pathogen, if a subject is eligible for a clinical trial, if there is a substantial change in user or subject data, if a user's goals for a subject aren't being met after a certain period of time, if a subject is starting to exhibit signs of disease onset (e.g., pre-diabetic), if subject linkages start exhibiting signs of disease onset, to indicate the introduction of new educational material, to indicate that new services are available, etc. The user and/or coach may or may not also establish conditions that would trigger an alert for themselves.
Alerts may take many forms, including but not limited to: mobile device push notifications, emails, physical mail, website banner notifications, etc. In an embodiment, alerts may be visual (e.g., a push notification displayed on a display screen of a user's device, etc.), auditory (e.g., an audible alert emitted from a speaker of a user's device, etc.), haptic (e.g., a vibration alert, etc.), any combination of the foregoing, and the like.
Generative AI techniques may be used to generate multiple aspects of the system, including one or more elements of the subject data, one or more elements of the user data, one or more elements of the coach data, one or more elements of the user interaction and/or one or more elements of the user guidance. For example, a Generative AI system could be used to generate a microbiome population for one or more hypothetical subjects. Another example would be to use a Generative AI system to produce one or more elements of the user guidance or report. Another example of a Generative AI system would be to generate possible future states of one or more elements of subject data, one or more elements of user data and/or one or more elements of coach data. Such a system could be trained by observing one or more subjects, changes to modifiable variables (e.g., lifestyle changes, medications, dietary plans, diagnostics, treatment plans, etc.) and the impacts to other subject data elements over time. Generative AI systems could be trained with any number of methodologies, including but not limited to, Generative Adversarial Networks (GANs), Transformers, and/or Variational Auto-Encoders. Any of the exemplary techniques described below could also be used for training a Generative AI model.
One or more foundation models could be built to model subject data, subject predispositions and the evolution of subject data over time. For example, one or more foundation models could be trained by one or more of these methods:
In this section, examples of different scenarios for the inventive concepts are described herein.
In this embodiment, a scenario is described in which a hospital, health system, government or employer has adopted the inventive concepts described herein in order to provide better care for its patients. For simplicity, the term “hospital” is utilized in the description of this embodiment to refer to any of these entities. For this scenario, the following associations can be made:
In this embodiment, the hospital may create subject and user accounts for each patient. In this case, the subject context factors could be initialized through one or more of a variety of factors, including the hospital data for each patient (e.g., EMR, PACS, LIS, etc.), survey questions from the various users about the subject, insurance data for the subject, social media accounts, etc. Subject-subject linkages could be initialized via user input and/or using the subject data about living situations, address, etc. User context factors could be initialized for each user type in one or more of multiple ways, including user questionnaires, hospital accounts, professional profile information, social media, online purchase history, etc. Following initialization, all of this data could be kept current by propagating changes to the hospital data for a patient, additional survey questions, social media updates, etc.
In this scenario, prior to initiating the program, the hospital performs full body imaging of each patient (e.g., MRI, CT, etc.). A digital anatomical model of each patient is then created from these full body images by segmenting out each anatomical structure (including body surface) to create a digital volume and surface model for all anatomical structures for each patient.
The hospital may collect microbiome data for these subjects through many different means, such as:
Recall that any other healthcare data associated with the patient is included in the subject data. Some examples:
A subject prediction engine using this data could be developed in one or more different ways, such as:
Subsequently contemplated are how different users may interact with and benefit from this system.
As a user, each subject may access their account and receive a range of information about themselves and guidance. The user may access their account in one or more of many ways, such as via a mobile device (e.g., tablet, smartphone, etc.), web interface, hospital terminal, etc. This patient could use the prediction engine to understand their risk profile for various conditions, explore additional information about these conditions and how their subject data is related to their subject predispositions. Further, if the patient inputs a goal (e.g., weight loss, pain reduction, etc.) the system may identify suggested changes for the patient. The patient may also use the subject prediction engine to explore one or more of multiple different potential changes they could make, such as dietary, supplements, lifestyle (e.g., smoking cessation), treatment, sexual activity, etc. to see how these changes would be reflected in changes to subject predispositions.
For example, through this exploration and/or system recommendations, the patient may identify that a dietary change, addition of supplements and a medication change is predicted to substantially reduce their pain level. Having identified this possibility, the patient may use the system to alert their primary care doctor with these changes in order to ask the doctor's opinion. The doctor, as a separate user, may access the patient's data, examine the evidence and suggest back to the patient that the patient tries these changes. The patient user may shop and purchase in the system marketplace for supplements, medications and/or meal plans to help them with these changes. In order to help the patient, the system may provide recommendations (e.g., via a user prediction engine), and/or access to user reviews, message board access, etc. to help the patient decide what is best for them. This patient may also select (or be matched to) a coach who can help them achieve their goal of pain reduction and adherence to these changes. This coach could have access to the same information about the patient, patient-doctor interaction, current pain level and the patient's plan for changes. Through coaching sessions, updates to the patient's subject data, coach recommendations and pain tracking the coach can help the patient with the changes and successfully reduce or eliminate pain.
The system may also use the patient data to send the patient one or more alerts, such as the eligibility of the patient for a clinical trial.
Family members and/or caregivers may be users instead of or in addition to the patient and have access to all or a subset of the patient data in order to help provide better care for the patient. Similar to the patient, these users may examine subject predispositions and/or use the subject prediction engine to explore the impact of different changes on subject predisposition. These users may also set goals for the patient and receive guidance and/or recommendations from the system. These users may also access the marketplace, receive product/service recommendations, access message boards, communicate with the patient's doctors, receive coaching, establish alerts, etc.
The patient may collect subject context data about themselves via any one or more of the methods described in Section V.A. For example, the patient may fill out survey data, link their phone (with usage and sensor data) to the system and either have and/or be prescribed one or more of the home health devices which would be linked to the system (e.g., via Bluetooth, Wi-Fi, etc.). The data from these devices may or may not be calibrated to the individual subject by accounting for other subject context factors and/or subject microbiome data. For example, variations in barometric pressure could be normalized by altitude or frequency of smartphone app usage could be stratified by age.
A doctor may access their system account to monitor or interact with one or more patients. The doctor may look to see how changes in treatment are affecting the patient.
As an example, a doctor may notice or receive an alert that a patient with inflammatory disease is getting worse (e.g., by increases in inflammatory markers such as CRP). As a result, the doctor may use the subject prediction engine to explore different treatment and/or dietary and lifestyle choices. Through the use of the subject prediction engine, or a recommendation from the user prediction engine or guidance, the doctor may identify that a certain treatment that the doctor is unfamiliar with is likely to benefit the patient by substantially reducing the predicted inflammation markers. The doctor may connect with a coach, in this case the coach being a doctor specialist at another hospital, to discuss the subject prediction engine results and the use of this treatment for the patient. After the coaching session with the specialist, the doctor may alert the patient through the system that the doctor is changing the patient's medication and then use the system to monitor the patient improvement. The doctor may also set a goal for the patient for adherence to this new medication and suggest a coach for the patient that can help the patient with adherence.
As another example, a doctor may be concerned about a cancer patient who is not responding to the first line treatment. The doctor may use the system to assess whether a new immunotherapy treatment might be more effective for the patient. When the doctor uses a hypothesis of this new treatment for the patient, the subject prediction engine determines a high likelihood for severe side effects of the potential treatment for the patient. However, based on the subject data and connection to a clinical trial database the system may identify that not only is the patient eligible for a clinical trial for a new therapy but, via a knowledge graph, that the mechanism of action in the new therapy creates a higher predisposition of treatment success for this patient. As result, the doctor is able to alert the patient to this new trial and get the patient enrolled.
Another example is for the doctor to use the system as a biomarker, precondition, complementary and/or companion diagnostic for use of a drug or therapy prior to administering the drug or therapy to a patient. One method for using the system as a biomarker is for the system to identify relevant published literature which indicates that a certain therapy is more likely or less likely to be effective for a patient with one or more data elements.
Within a hospital, there may be one or more researchers who are exploring different medical treatments or scientific questions. A hospital researcher may have access to the population of all the subject data in the hospital, without any identifying information for a particular patient or doctor. Through the system, the hospital researcher may use a variety of search and visualization tools in the system to examine different patient trends, subpopulations and/or correlations between different aspects of the subject (patient) data and changes to the subject data (outcomes). These trends, changes, correlations, visualizations, etc. may support or provide evidence against a researcher's hypothesis and possibly develop new avenues of scientific and medical discovery.
Another example is a medical or scientific researcher who is designing a clinical trial and needs to understand baseline subject data and subject predispositions for a patient population to design the protocol for a clinical trial. For example, a researcher might be testing a hypothesis that the introduction of a certain commensal microbe (virus, phage, etc.) and colonization at a certain location in the patient (e.g., small intestine) might improve the patient response to a certain diabetes drug. In order to understand how many patients to enroll and to set the trial endpoints, the researcher may look at subject data from a population to understand how common the commensal microbe is at that location within the subpopulation of diabetics and pre-diabetics, how frequently the introduction of the microbe via oral probiotics establishes a permanent colony of the microbe in the certain location within the population of diabetic patients, and the historical efficacy of the drug in treating those diabetics who have the microbe in sufficient quantity compared to those diabetics who do not have the microbe in sufficient quantity. Based on this information, the researcher could make more informed decisions on population sample size, enrollment criteria for patients and the target endpoints that would prove the scientific hypothesis.
Another example is for the researcher to use the subject prediction engine as a biomarker, precondition, complementary and/or companion diagnostic for use of a drug or therapy prior to enrollment in a trial or to modify the protocol during the trial. For example, if the subject prediction engine determines that a first subject is likely to respond well to a drug then this first patient may be included in the trial and if the subject prediction engine determines that a second subject is not likely to respond well to a drug then this second subject may be excluded from the trial.
Another example is for a researcher at a food and drink company to use the system for food and drink innovation. For example, the researcher may be considering a new food ingredient and uses the subject prediction engine to determine how the patients might respond to this new food by examining predispositions of the patients for changes to the patients' microbiome, likelihood of allergic reactions, etc.
Note that medical or scientific researchers might also be outside a hospital, such as at a medical device company, pharmaceutical company, governmental health agency, agricultural company, food and drink companies, patient advocacy group, etc.
Outside the hospital, other researchers may be interested in using the system to explore different medical, environment, and/or societal questions. Example population researchers are epidemiologists, virologists, public health agencies, economic analysts, account manager, insurance company analysts, defense agencies, etc. A population researcher may have access to one or more populations or subpopulations of all the subject data in the hospital, without any identifying information for a particular patient or doctor. A population researcher may use this data in various ways, including but not limited to:
In this embodiment, it is described how an individual (or group of individuals) consumer could use the inventive concepts described herein to enhance and improve overall wellness.
In this embodiment, the following associations can be made:
In this embodiment the consumer may create their own account and user accounts for other users that the consumer designates or invite other users who have existing accounts to link to the consumer as a subject. The consumer may elect to share only some information with each user. The consumer may also invite or link to other consumers with a proposed subject-subject linkage. These linked consumers may or may not be asked to accept a linkage.
In this case, the subject/user context factors could be initialized through one or more of a variety of factors, including a questionnaire, connection with medical records, insurance data for the consumer, linking with social media accounts, mobile device data, online activity (e.g., purchasing history, etc.), wearable devices (e.g., fitness tracker, glucose monitor, etc.), etc. User context factors could be initialized for each user type in one or more of multiple ways, including user questionnaires, medical records, mobile device data, professional profile information, social media, online purchase history, etc. Following initialization, all of this data could be kept current by propagating changes to any of these data sources, such as be additional survey questions, social media updates, coach-user interactions, etc.
The consumer may adopt either a generic or average anatomical model to describe spatial location, medical imaging data of the consumer (e.g., MRI, ultrasound, CT, etc.), range camera, single or multiple optical camera data of the external body surface. If available, a digital anatomical model of the consumer is then created from this anatomical data by segmenting out each anatomical structure (including body surface) to create a digital volume and surface model for all anatomical structures for each patient (e.g., using multi-view camera algorithms, stitching algorithms, digital surface reconstruction techniques, etc.).
Multiple different ways are contemplated in which the consumer may perform microbiome sampling. As with the healthcare provider scenario, the consumer could collect samples via:
Another scenario for the consumer to collect GI-tract located microbiome data is with one or more ingestible capsules. The consumer may or may not use a test capsule to determine whether a capsule can pass through the patient without difficulty. Calibration of one or more sensors may or may not be performed prior to ingestion. Prior to ingesting a capsule, the consumer may enter into their mobile device, receiver and/or computer a serial number, scan a barcode, scan a QR code, etc. on either the capsule or packaging to identify the capsule. A capsule may also have a transmitter (e.g., radio beacon) that transmits a unique code to a mobile device, receiver, etc. A capsule may be of any size that is effectively ingestible by the consumer (e.g., a 000 sized capsule). A capsule may or may not have one or more of the following elements:
For clarity, note that the consumer may or may not ingest multiple capsules that include one or more different or the same elements described above to achieve sufficient sampling, sensing, monitoring, etc. Multiple capsules may be ingested at multiple different time intervals, (e.g., at the same time, evenly spaced, on a predefined schedule, etc.). For example, the consumer may ingest a first capsule to measure body temperature at different locations, a second capsule with a biosensor designed to detect internal bleeding (heme) at different locations, a third capsule with a biosensor designed to detect and quantify nutritional content (e.g., carbohydrates) at different locations, a fourth capsule with a biosensor designed to detect and quantify a first microbe (e.g., Escherichia coli), a fifth capsule with a biosensor designed to detect and quantify a second microbe (e.g., Lactobacillus gasseri), etc. For clarity, note that each capsule sample may be analyzed in vivo (e.g., via on-board sensors, analysis, transmission, etc.), ex vivo (e.g., via retrieval and lab analysis) and/or a combination thereof. Each capsule may be analyzed differently (e.g., one capsule analyzes and transmits signals in vivo, a second capsule is retrieved for ex vivo analysis, a third capsule is retrieved for data transfer of on-board analysis, etc.).
One or more capsules could be manufactured in many different ways. Some examples include, but are not limited to a 3D printer, stereolithography (e.g., biocompatible methacrylate photocurable polymer), high temperature resin (possibly including photo-curing), etc. A hydrophilic surface modification may be performed on the surface of 3D-printed housing to ensure and facilitate sampling fluid to enter the capsule's aperture (e.g., via surface activation with an air plasma treatment followed by poly-ethylene glycol treatment).
After supplying one or more elements of subject/user context data and performing at least one microbiome sampling, multiple ways are subsequently described in which the consumer may use the system in this embodiment. The user may access their system account via one or more device, including but not limited to a mobile device (e.g., smartphone, tablet, etc.), computer, laptop, network connection, wifi connection, satellite link, etc.
i. Subject/User Predispositions
The user may look through all of their subject/user predispositions to identify health risks, traits, etc. to generally assess their health, wellness, receive recommendations, track changes in predispositions across multiple time points (e.g., microbiome samples, changes in context factor, etc.), purchase products and to compare themselves to other populations (e.g., a total population, local geography, people with a certain medical condition, etc.). Some possibilities include, but are not limited to:
One example of a wellness embodiment is that a user wants to know how a certain product (e.g., a food, beverage, cosmetic, supplement, vitamin, probiotic, prebiotic, postbiotic, symbiotic, medication, etc.) would affect the subject (who could be themselves, a family member, client, etc.) predispositions. To answer this question, the user might input information into the system about the product (e.g., ingredient list, list of active organisms, active compounds in a medication, etc.) via one or more methods (e.g., manually typing the information, voice description, scanning a barcode on the product with a mobile phone that queries a database containing product information, scanning a QR code on the product, etc.). This product information could then be used to create a modified version of the subject data according to the product, which would be used to determine a second set of predispositions.
For example, in the wellness context, a user (who, in this example, is also the subject) may have a disposition for bloating and diarrhea, as well as be concerned about spikes in blood glucose level. At the grocery store, this user may wonder if a certain food product or supplement would help their dispositions. To answer the question, the user could scan the product barcode and the ingredients and/or nutrients of the product could be assessed for known impact on the user's microbiome (e.g., via known scientific literature, proprietary data, computational and biological modeling, etc.) to increase certain species and decrease other species. The system could then establish a second set of subject data with the user's microbiome altered to reflect the increases and decreases of the corresponding species. This second set of subject data could then be used to determine a set of hypothetical subject predispositions that would inform the user about whether the food product would be likely to generate an increased, decreased or unmodified predisposition for bloating, diarrhea and/or blood glucose spikes.
ii. Exemplary User Interface
Referring now to
Referring now to
In an embodiment, the overview summary screen 600 may contain a representative summary of a variety of characteristics associated with the subject. This information may be organized into sections (e.g., Clinical Conditions 605, Food Sensitivities 610, Pathogens 615, Symptoms 620, Progression 625, etc.) that each contain various elements associated with that section. Additionally, each element may contain a corresponding indication of how strongly the subject's microbiome matches what has been described in the literature for the condition and the level of evidence describing that match under the relevant section. For example, the Clinical Conditions section 505 may contain four listed conditions for which there is evidence in the literature describing a microbiome composition associated with a clinical condition that matches the subject's microbiome composition—Crohn's Disease, Ulcerative Colitis, Irritable Bowel Syndrome—D, and Atopic Dermatitis. In this example, the system states that the subject's microbiome closely matches the microbiome of people with Crohn's Disease with significant evidence with the other listed conditions being designated a medium level of evidence. In an embodiment, the overview summary screen 600 may also provide a summarized listing of characteristics of an action plan that a subject can implement to adjust their microbiome in such a way that it would lower the associations with clinical conditions. The information in the action plan may be organized into sections (e.g., Eat 630, Exercise 635, Rest 640, Mind 645, Treatment 650, etc.) that each contain various elements associated with that section. Additionally, each element main contain a corresponding indication of a recommended action the subject can take with respect to that element (e.g., avoid consumption of certain foods, increase exercise of a particular type, avoid certain medications, etc.). Additionally or alternatively to the foregoing, the overview summary screen 600 may also provide an indication of associations of the subject's current microbiome with symptoms, conditions and progressions.
In an embodiment, a user may be apprised of additional information associated with each section or element by interacting with a desired icon. For example, a user interested in obtaining more detail about the subject's microbiome association with Crohn's Disease may select the Crohn's Disease element 605A under the Clinical Conditions section 605. Upon selection, a user may be redirected to a dedicated Crohn's Disease page 700, such as the one illustrated in
iii. Goals and Coaching
The user may decide that the user wants to improve their sleep quality and reduce back pain. The user may also want to maximize their chance of pregnancy (fertility). The user may use the system for this purpose by setting goals and establishing which factors the user is able to modify. The user may either select or be matched with one or more coaches to support the user in their goals. In this example, the user might be matched with three separate coaches to help the user achieve their goals: A sleep coach, a physical therapy coach and a pregnancy and fertility coach.
The user may engage with these coaches via one or more mechanisms including, but not limited to, regular (e.g., biweekly) video/phone discussions, on-demand, as the user needs through messaging, etc. The user may also choose to interact with (read/write) message boards, possibly including one or more other users/coaches. The user may also engage with chatbots through the system to help answer questions and learn more.
Based on coach data, user data, subject data, user-coach interaction data and historical data in the system, each coach may receive one or more guidances to help the coach guide the user interactions between each coach and the user to help the user achieve their goals of better sleep, increased chance of pregnancy and reduced back pain. As the user achieves one or more of these goals, the user may elect to set new goals and/or shift their interaction with these coaches into maintenance and monitoring.
Clinical trials and studies are expensive, time consuming and risky. However, a clinical trial or study is often the only way for a clinical researcher, population researcher or industrial researcher at a drug company, medical device company, food and beverage company, cosmetic company, beauty company, animal supply company, agricultural company, wellness company, etc. to assess the effectiveness and possible safety or side effects of a new treatment, device or product. In this embodiment, it is described how the inventive concepts could be used to perform a virtual trial or study that could substantially reduce costs, ensure safety and improve speed of a trial or study.
Consider a company who wants to test or evaluate a new product. In this example, a new drug to reduce Mild Cognitive Impairment (MCI) is contemplated, which is often a precursor to Alzheimer's disease. The company may target the drug at non-diabetic people over 50. The researcher could use the inventive concepts described herein to perform a virtual clinical trial of this drug by following these steps:
For clarity, this virtual clinical trial could first be run on virtual mice subjects prior to a real mouse trial and then run on virtual human subjects prior to a real human trial.
The same methodology for conducting virtual trials or studies could be used to evaluate a variety of new products and services (clinical, consumer, animal, plant, etc.) including but not limited to new food products (e.g., comparing subject predisposition for food preference in virtual control subjects versus virtual test subjects), new medical devices (e.g., comparing subject predisposition for patient outcome in virtual control subjects versus virtual test subjects), new animal food products (e.g., comparing subject predisposition for milk production quality and quantity in virtual control subjects versus virtual test subjects), new plant fertilizer products (e.g., comparing subject predisposition for crop yield quality and quantity in virtual control subjects versus virtual test subjects), new beauty or cosmetic products (e.g., comparing subject predisposition for consumer dry skin in virtual control subjects versus virtual test subjects of a new moisturizer), etc.
The inventive concepts described herein may also be utilized in the context of forensics to help an investigator or relative better understand a deceased subject. In this embodiment, the following associations may be made:
In this embodiment, subject context factor data may be supplied in one or more of multiple ways, including but not limited to, being entered by one or more users, having been entered previously be the deceased (e.g., if the deceased had an account with the system while still alive), hospital/medical/morgue records (e.g., EMR, PACS, LIS, etc.), farm or agricultural records, law enforcement records/database, etc. Microbiome information about the subject may or may not be obtained in one or more ways, including but not limited to taking biological samples (e.g., fluids, tissue, hair, biofilms, etc.) with one or more of the methods described previously (e.g., swabs, biopsy, fluid collection, surgical removal, autopsy, etc.).
The user may use the subject prediction engine to assess a variety of factors, including subject predispositions about subject mortality (e.g., cause of death, time of death, etc.) as well as assess other subject predispositions that may provide important information (e.g., likely health risk factors that were being untreated, etc.). An investigator may also decide to adjust some hypothesized subject data to account for unknown information and assess different scenarios with the subject prediction engine. If an investigator needed assistance (e.g., advice, further evidence gathering, more information, etc.), the investigator may benefit from accessing a coach such as a law enforcement professional, medical specialist, forensics expert, etc.
An aggrieved family member user may want to use the system on their own in one or more of many different ways, including but not limited to investigating the deceased on their own by learning more about the deceased (e.g., via subject data or determined subject predispositions), adjusting hypothesized subject data to determine the effect of subject predispositions, accessing and interacting with message boards, accessing (possibly personalized and customized) educational materials, accessing related products and services on a marketplace, talking to a grief counselor (coach), etc.
Understanding of plant and animal health and wellness is important for a wide variety of uses, including agriculture (livestock), farming (crops), fishing, veterinary, medical, etc. The inventive concepts described herein may be used to improve animal and plant health, improve agricultural output and better manage environmental resources. In this embodiment, the following associations may be made:
In this embodiment, subject context factor data may be supplied in one or more of multiple ways, including but not limited to, being entered by one or more users, veterinary records, agricultural records (database), fishery records (database), atmospheric databases, water sensors/samples, air sensors/samples, soil sensors/samples, consumer surveys/databases (e.g., if a particular fruit (e.g., plant and/or animal product) was deemed better quality by consumers, sold for a higher price, etc.), etc. Microbiome information about one or more subjects may or may not be obtained in one or more ways, including but not limited to taking biological samples (e.g., fluids, tissue, hair/fur, biofilms, roots, stems, leaves, etc.) with one or more of the methods described previously (e.g., swabs, biopsy, fluid collection, resection, autopsy, etc.). In some situations, there may be more subjects than can be easily measured (e.g., a farm with millions of wheat plants). In these cases, the user may or may not elect to sample a subset of subjects in the population and create one or more virtual subjects (e.g., in a manner similar to the virtual clinical trial embodiment) to represent one or more of the unsampled population.
User context factors could be initialized for each user type in one or more of multiple ways, including user questionnaires, professional accounts, professional profile information, social media, online purchase history, etc. Following initialization, all of this data could be kept current by propagating changes to the subject data for a subject, additional survey questions, social media updates, coach-user interactions, etc.
After supplying one or more elements of subject/user data, multiple ways are subsequently described in which a user may use the system in this embodiment. A user may access their system account via one or more devices, including but not limited to a mobile device (e.g., smartphone, tablet, etc.), computer, laptop, network connection, wireless (Wi-Fi) connection, satellite link, etc.
The user may look through all of the subject predispositions to identify health risks, traits, etc. to generally assess animal or plant health, wellness, receive recommendations, track changes in predispositions across multiple time points (e.g., microbiome samples, changes in context factor, etc.), purchase products and to compare the animal and/or plant subjects to other populations (e.g., a total population, local geography, similar farms, similar fishing environments, etc.).
Some specific examples of ways in which the user might use the system include, but are not limited to:
If a user needed assistance (e.g., advice, more information, etc.), a user may benefit from accessing a coach such as a veterinarian, agricultural specialist, fishery specialist, etc. which the user may do through the coaching functionality. The user may also set one or more goals (e.g., improved dairy production, restoring a fishery population, improved crop yields, cost reduction, etc.). To help the user achieve this one or more goals, the system may make one or more recommendations using the user prediction engine and/or one or more coaches may be matched to assist the user to achieve these goals. As above, the coach may also receive recommendations based on user-coach interactions to help the coach be more effective in helping the user achieve their one or more goals.
The systems, apparatuses, devices, and methods disclosed herein are described in detail by way of examples and with reference to the figures. The examples discussed herein are examples only and are provided to assist in the explanation of the apparatuses, devices, systems, and methods described herein. None of the features or components shown in the drawings or discussed below should be taken as mandatory for any specific implementation of any of these the apparatuses, devices, systems, or methods unless specifically designated as mandatory. For ease of reading and clarity, certain components, modules, or methods may be described solely in connection with a specific figure. In this disclosure, any identification of specific techniques, arrangements, etc. are either related to a specific example presented or are merely a general description of such a technique, arrangement, etc. Identifications of specific details or examples are not intended to be, and should not be, construed as mandatory or limiting unless specifically designated as such. Any failure to specifically describe a combination or sub-combination of components should not be understood as an indication that any combination or sub-combination is not possible. It will be appreciated that modifications to disclosed and described examples, arrangements, configurations, components, elements, apparatuses, devices, systems, methods, etc. can be made and may be desired for a specific application. Also, for any methods described, regardless of whether the method is described in conjunction with a flow diagram, it should be understood that unless otherwise specified or required by context, any explicit or implicit ordering of steps performed in the execution of a method does not imply that those steps must be performed in the order presented but instead may be performed in a different order or in parallel.
Throughout this disclosure, references to components or modules generally refer to items that logically can be grouped together to perform a function or group of related functions. Like reference numerals are generally intended to refer to the same or similar components. Components and modules can be implemented in software, hardware, or a combination of software and hardware. The term “software” is used expansively to include not only executable code, for example machine-executable or machine-interpretable instructions, but also data structures, data stores and computing instructions stored in any suitable electronic format, including firmware, and embedded software. The terms “information” and “data” are used expansively and includes a wide variety of electronic information, including executable code; content such as text, video data, and audio data, among others; and various codes or flags. The terms “information,” “data,” and “content” are sometimes used interchangeably when permitted by context.
Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and/or associated data that is carried on or embodied in a type of machine-readable medium. “Storage” type media include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide non-transitory storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer of the mobile communication network into the computer platform of a server and/or from a server to the mobile device. Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links, or the like, also may be considered as media bearing the software. As used herein, unless restricted to non-transitory, tangible “storage” media, terms such as computer or machine “readable medium” refer to any medium that participates in providing instructions to a processor for execution.
While the disclosed methods, devices, and systems are described with exemplary reference to transmitting data, it should be appreciated that the disclosed embodiments may be applicable to any environment, such as a desktop or laptop computer, an automobile entertainment system, a home entertainment system, etc. Also, the disclosed embodiments may be applicable to any type of Internet protocol.
It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.
Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.
Thus, while certain embodiments have been described, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falling within the scope of the invention. For example, functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.
The above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other implementations, which fall within the true spirit and scope of the present disclosure. Thus, to the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description. While various implementations of the disclosure have been described, it will be apparent to those of ordinary skill in the art that many more implementations are possible within the scope of the disclosure. Accordingly, the disclosure is not to be restricted except in light of the attached claims and their equivalents.
This application claims priority to U.S. Application No. 63/490,181, filed on Mar. 14, 2023, entitled “SYSTEM AND METHOD FOR USING THE MICROBIOME TO IMPROVE HEALTHCARE,” which is incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63490181 | Mar 2023 | US |
