Big data processing to facilitate coordinated treatment of individual multiple sclerosis subjects

Abstract

Systems and methods are disclosed for building and using a data platform to facilitate intelligent selection of treatments for multiple sclerosis and to identify indications for multiple sclerosis treatments. Various record snapshots of records associated with multiple sclerosis subjects facilitate efficient queries that can be used to explore heterogeneous, unstructured, and non-categorical datasets to generate specific general hypotheses and subject-specific treatment predictions.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of the filing date of European Patent Application No. 20179750.3, filed June 12, 2020, the disclosure of which is incorporated herein by reference in its entirety for all purposes.

[0002] Field The methods and systems disclosed herein generally relate to systems and methods for using a platform to store and process tagged data relevant to determining diagnostic and treatment strategies. Time-constrained processing can be used to predict temporally related data and generate predicted subject states based on time-series event chains. [Background technology]

[0003] background Multiple sclerosis (MS) is a common disease with heterogeneous presentation. For example, approximately 1 in 300 people in the United States has MS (based on Wallin et al., "The prevalence of MS in the United States," Neurology, 92(1), 2019).

[0004] The cause of the disease is still unknown, but various risk factors have been identified. The likelihood of being diagnosed with MS varies depending on (for example) whether a family member has been diagnosed with MS (or other autoimmune diseases), the latitude of the subject's residence, whether the subject lives near a coast, whether the subject is female, the subject's age, the subject's race, whether the subject is infected with certain viruses (e.g., Epstein-Barr virus), whether the subject smokes, and whether the subject is obese.

[0005] Because early disease symptoms, disease progression, and response to various treatments vary widely among subjects, some experts question whether MS is actually a spectrum of distinct diseases. The medical community has also defined medical tests that can be used to identify various disease subtypes and inform treatment decisions. Nevertheless, selected treatments are often ineffective.

[0006] Clinical trials are frequently conducted to determine the effectiveness of specific new treatments or treatment combinations. However, eligibility criteria are often restrictive, and therefore the subject population under test may not represent the patient population seeking treatment advice from a neurologist. Furthermore, the relatively small size of the subject population can limit the extent to which data scientists can discover factors that contribute to efficacy.

[0007] Fortunately, the number of treatment options for multiple sclerosis has exploded over the past decade. This is beneficial in that it reduces the likelihood that a patient will not respond to all treatment options. However, repeatedly trying each treatment is now increasingly impractical with the possibility of additional treatments. It often takes six months or more to determine whether a treatment is slowing progression. During that time, a patient's multiple sclerosis may progress more dramatically and irreversibly than if other treatments were used. Therefore, it would be advantageous to have a system or process available that can improve patient assessment and treatment selection.

[0008] As large amounts of medical data become digitally available, systems and methods for personalized medicine are on the rise. In one example, U.S. Patent Application Publication No. 2015 / 0324530 discloses personalized management and comparison of medical symptoms and outcomes based on patient profiles of a community of patients, and is described as useful for a variety of different medical conditions, including MS. However, the disclosed technology does not match patients based on previous MS treatments and when these treatments are applied to predictively identify proposed treatment courses that may be effective for a particular MS patient.

[0009] Other intelligent medical approaches have been explored, such as U.S. Patent Application Publication No. 2015 / 0161331, which describes a technique for analyzing, classifying, and matching large amounts of medical information from many sources and across different domains for a wide variety of medical conditions, including MS, using patient medical record data categorized into multiple subgroups according to the patient's clinical parameters, disease template, treatment, and outcome. When a new patient enters the system, the patient's parameters and disease template are matched with the closest subgroup to suggest treatments with potentially favorable outcomes. However, this application also does not describe matching patients based on previous MS treatments and when these treatments were applied to predictively identify proposed treatment courses that may be effective for a particular MS patient.

[0010] ALLAM et al.: "Patient Similarity Analysis with Longitudinal Health Data," ARXIV.ORG, May 14, 2020, XP081673418, provides a comprehensive overview of tools and methods used in patient similarity analysis with longitudinal data, discussing the potential of patient similarity analysis to improve clinical decision-making. However, the disclosed techniques do not match patients based on previous MS treatments and when those treatments are applied to predictively identify proposed treatment courses that may be effective for a particular MS patient. Summary of the Invention

[0011] overview In some embodiments, a computer-implemented method is provided. The method includes receiving, at a cloud-based application server, a query identifying a treatment for multiple sclerosis and querying a data store using an identifier for the treatment, the data store being stored at least in part based on input received from a distributed set of care provider entities. A first example method further includes receiving, in response to the query, a set of subject identifiers, each subject identifier in the set of subject identifiers indicating that a subject corresponding to the subject identifier received the treatment. For each subject identifier in the set of subject identifiers, the first example method further includes determining, based on data in the data store, a time at which the subject corresponding to the subject identifier began the treatment, and extracting, from one or more records associated with the subject identifier, one or more metrics indicative of an outcome of the treatment and one or more subject attributes. The extracting of the one or more metrics is based at least in part on the time the treatment began, and each of the one or more subject attributes reflects a characteristic or medical test result of the subject corresponding to the record. The first example method further includes generating a predicted responsiveness of other subjects to the treatment based on the extracted metrics and the extracted subject attributes, and outputting a result corresponding to the predicted responsiveness.

[0012] In some embodiments, a system is provided that includes one or more data processors and a non-transitory computer-readable storage medium containing instructions that, when executed on the one or more data processors, cause the one or more data processors to perform some or all of one or more of the methods disclosed herein.

[0013] In some embodiments, a computer program product tangibly embodied in a non-transitory machine-readable storage medium is provided that includes instructions configured to cause one or more data processors to perform some or all of one or more of the methods disclosed herein.

[0014] Some embodiments of the present disclosure include a system including one or more data processors. In some embodiments, the system includes a non-transitory computer-readable storage medium including instructions that, when executed on the one or more processors, cause the one or more processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein. Some embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium including instructions configured to cause one or more processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein.

[0015] The terms and expressions employed are used as terms of description and not of limitation, and there is no intention in the use of such terms and expressions to exclude any equivalents of the features shown and described or portions thereof, but it is recognized that various modifications are possible within the scope of the invention as claimed. Thus, while the claimed invention has been specifically disclosed by embodiments and optional features, it will be understood that modifications and variations of the concepts disclosed herein may be resorted to by those skilled in the art, and that such modifications and variations are deemed to be within the scope of the invention as defined by the appended claims. [Brief explanation of the drawings]

[0016] The present disclosure is described in conjunction with the accompanying drawings, in which:

[0017] [Figure 1]1 illustrates a network environment in which cloud-based applications are hosted, in accordance with some aspects of the present disclosure.

[0018] [Figure 2] 1 is a flowchart illustrating an example of a process performed by a cloud-based application to deliver abridged subject records to a user device in connection with a consultation broadcast requesting assistance with a subject's treatment, according to some aspects of the present disclosure.

[0019] [Figure 3] 10 is a flowchart illustrating an example process for monitoring user integration of a treatment plan definition (e.g., a decision tree or processing workflow) and automatically updating the treatment plan definition based on the results of the monitoring, according to some aspects of the present disclosure.

[0020] [Figure 4] 1 is a flowchart illustrating an example of a process for recommending a treatment for a subject, according to some aspects of the present disclosure.

[0021] [Figure 5] 1 is a flowchart illustrating an example of a process for obfuscating query results to comply with data privacy regulations in accordance with certain aspects of the present disclosure.

[0022] [Figure 6] 1 is a flowchart illustrating an example of a process for communicating with a user using a bot script, such as a chatbot, in accordance with some aspects of the present disclosure.

[0023] [Figures 7A-7B] 1 shows a flowchart illustrating an exemplary process for constructing and using a snapshot datastore representing dynamic and distributed source data to characterize subpopulations and generate subject-specific predictions.

[0024] [Figure 8] 10 shows a flowchart illustrating an exemplary process for generating high-level treatment response predictions and / or prescriptions using a snapshot data store.

[0025] [Figures 9A-9F] 1 illustrates an exemplary interface for receiving input for building a multiple sclerosis data store.

[0026] In the accompanying drawings, similar components and / or features may have the same reference label. Furthermore, various components of the same type may be distinguished by following the reference label with a dash and a second label that distinguishes between the similar components. When only a first reference label is used in this specification, the description is applicable to any of the similar components having the same first reference label, regardless of the second reference label. DETAILED DESCRIPTION OF THE INVENTION

[0027] Detailed Description I. Overview Multiple sclerosis is a heterogeneous disease with many different presentations, symptoms, and outcomes. This situation presents challenges for neurologists in selecting treatment strategies. However, the disappointingly high prevalence of the disease provides a tool whereby big data can be collected and analyzed to support multidimensional analysis to inform the selection of more effective treatment strategies.

[0028] Big data analysis of clinical data is complex because most clinical history and patient attributes correspond to complex non-binary, non-categorical, non-numeric data. Consequently, much of this data is represented in unstructured formats (e.g., physician notes or radiologist reports) that are difficult to query and aggregate. While there have been some efforts in the medical field to convert complex assessments into categorical or numeric variables, this can result in information loss and can be inconsistent between the parties performing the conversion.

[0029] Furthermore, the types of information frequently evaluated by neurologists span many data types. Thus, even when reviewing a single subject's files, they frequently open multiple files of different file types. Some files may contain large MRI data sets, often containing images of various virtual slices of the brain and / or spinal cord, often acquired repeatedly from different perspectives. Neurologists can compare information from a collection of files from recent time periods (or snapshots) with corresponding information from a collection of historical data corresponding to the subject, and then attempt to determine whether any changes are acceptable. Notably, most current treatment options have not been reported to completely halt the progression of MS; rather, they have been reported to slow its progression. Therefore, neurologists are left to hypothesize whether the observed changes would be more pronounced if a different treatment were provided.

[0030] Some systems and methods disclosed herein are configured to build and use MS big data sets to facilitate personalized medicine, in which treatments are selected for individuals based in part on quantitative multivariate analysis. In particular, a cloud-based application can provide an interface through which a user (e.g., a care provider, a radiologist, a laboratory, and / or a subject) can provide inputs characterizing the subject's condition. The interface can be configured to selectively receive inputs (e.g., for some or all types of information) corresponding to defined structures. Field data presented via the interface can identify the structures. For example, the interface can indicate that disability-related information should include scores along a particular scale (e.g., the Expanded Disability Status Scale) and / or that MRI information should include counts of particular types of lesions (e.g., enhanced / non-enhanced as detected in a particular type of scan).

[0031] In some examples, the interface may be further configured to receive less structured, semi-structured, or unstructured data. Unstructured data may include (for example) physician notes, subject textual self-assessment reports, etc. The unstructured data may be processed (e.g., using natural language processing and / or keyword detection) to identify corresponding structured data. In some examples, the unstructured data is used as supporting information and is maintained in an unstructured format. For example, in addition to receiving one or more quantitative MRI metrics, the interface may accept MRI images. The MRI images may conform to MRI standards, although the exact composition of the data may depend (for example) on the type of machine used and the scan selected.

[0032] The cloud-based application can be configured to provide multiple types of interfaces for multiple types of users. For example, a first interface can be utilized by a physician and can include one or more pages configured to receive input corresponding to a direct assessment, an in-house assessment, a prescription rationale, etc. One or more second interfaces can be utilized by a laboratory and / or imaging facility and can include one or more pages configured to receive medical test results (e.g., blood test results, MRI images, MRI statistics, etc.). A third interface can be utilized by a subject and can include one or more pages configured to receive self-assessment responses or self-evaluations. For example, a subject interface can be configured to pose health-related questions and receive corresponding answers. The cloud-based application can further detect roles and permissions for each user accessing the cloud-based application. Various permissions can enable a user to enter specific types of information (e.g., corresponding to specific fields), initiate or control specific types of actions (e.g., data processing), and / or view specific types of data (e.g., corresponding to specific fields and / or specific subjects).

[0033] In addition to collecting subject assessment data that facilitates big data querying, the cloud-based application can automatically collect or collect via input one or more contextual data points. For example, the cloud-based application can detect the jurisdiction in which the user computer is located and / or the jurisdiction corresponding to the subject's address (e.g., as input by the user). As another example, the cloud-based application can automatically detect or detect via input the assessment, medical test, or time period (e.g., date, time, date period, and / or time period) corresponding to the input.

[0034] The cloud-based application can further receive information about the particular subject. The information can include demographic information, medical history information, employment information, etc. The information can include what medications the subject was taking, during what period of time the medications were taken, any adverse effects experienced during that period, and potentially an indication as to why the subject stopped taking the medication. The particular subject information can be detected via input from a user, electronic medical records, automatic text recognition, etc.

[0035] In some examples, the cloud-based application processes the data to construct time series data for each subject that associates individual time periods with (for example) any medications the subject is receiving, disability levels / scores, MRI statistics or characteristics, well-being indices, symptom presentations, and / or adverse events. In some examples, an event chain can be generated based on data including a series of timestamps and associated clinical, biomarker, medical test, and / or self-assessment metrics. Thus, the event chain can identify which treatments the subject received, the periods during which they received various treatments, clinical assessments performed during the treatment periods, the results of one or more MRIs received during the treatment periods, subject reports or self-assessments during the treatment periods, etc.

[0036] A cloud-based application can use the subject's event chain to (for example) generate a prediction corresponding to the effectiveness of a given treatment, predict the effectiveness of a given treatment, predict a prognosis, and / or identify a recommended treatment. For example, the cloud-based application can use the subject's event chain to identify one or more corresponding filters to impose on a big data population, identify one or more subpopulation classes, and / or identify one or more nearest neighbors. In some examples, the event chain is input into one or more artificial intelligence models (e.g., one or more trained machine learning models) to generate one or more outputs that predict the effectiveness and / or outcome of using one or more treatments. For example, each of the one or more models can generate an output corresponding to a prediction that the subject will switch from their current treatment to another model-compatible treatment. The output can include (for example) a predicted absolute value or change in disability score, lesion burden, total number of enhancing lesions, etc. A treatment can then be selected based on the output.

[0037] As another example, an event chain can be used to identify a set of similar subjects who received a given treatment. Similar subjects can be identified by calculating a distance metric between the multidimensional event chain of a given subject and each of a set of other subjects who received the given treatment, and identifying a subset of the set of other subjects associated with a distance metric below a certain threshold. A prediction of a given subject's responsiveness to a given treatment can be defined based on the responsiveness of a subset of subjects to the given treatment (e.g., mean or median disability progression within a certain period of time, mean or median relapse within a certain period of time, mean or median new lesions within a certain period of time, etc.).

[0038] The interface can be configured to receive input that identifies, for each treatment selection made in connection with a given subject, an identifier (e.g., name) of the treatment, the date or duration when the treatment began, any adverse events experienced by the subject in connection with the treatment (e.g., and when such adverse events were experienced), and / or the date or duration when the treatment ended. The subject's event chain can be updated to reflect some or all of the treatment information.

[0039] In some examples, data related to a given subject (e.g., the subject's event chain) can be used to identify one or more corresponding subjects. The corresponding subjects and the given subject may be similar and / or associated with one or more of the same or similar attributes. For example, each of the corresponding subjects may have received the same particular treatment that the subject is receiving, will receive, or is considering. The corresponding subjects and the given subject may be associated with similar or the same type of multiple sclerosis, similar or the same disability score, similar or the same treatment history, etc. Which attributes influence the definition of the corresponding subject set may be defined via user input, or may be predefined or learned by a model.

[0040] As an example, a user of the cloud-based application can begin a query by selecting a field constraint and identifying a subject (who has fully ambulatory relapsing-remitting multiple sclerosis and may have recently transitioned from interferon beta treatment to ocrelizumab treatment). The data store can be queried to identify other subjects who meet the field constraint of being fully ambulatory and diagnosed with relapsing-remitting multiple sclerosis at the time they also transitioned from interferon beta treatment to ocrelizumab treatment. In this illustrative example, the field constraints correspond to the subject's actual attributes, although in some circumstances, one or more constraints can correspond to potential attributes (e.g., treatments being considered for the subject). Notably, the query may look backward to identify subjects previously associated with various characteristics currently associated with a given subject.

[0041] To facilitate retrospective querying, the cloud-based application can generate and store snapshots for each subject at each treatment transition point (when treatment is initiated, changed, or terminated). The snapshots can include the most recently reported and / or calculated information. The snapshots can include fields and / or information described herein, such as the most recent treatment, one or more MRI statistics, one or more gait metrics (e.g., whether the subject uses a cane, whether the subject uses bilateral walking supports, whether the subject uses a walker, and / or whether the subject uses a wheelchair), type of multiple sclerosis, and other information. For example, if a subject changed medication in July 2017, information about many other areas may not have been provided at the same time. However, it can query previously received information to discover (for example) that the most recent treatment prescribed was in January 2016 and was fingolimod, that the most recent MRI administered in April 2017 corresponded to the relevant MRI statistic set, that data entry corresponding to a clinic visit in March 2017 indicated the subject was using a cane, and that the most recent diagnosis from September 2008 was relapsing-remitting multiple sclerosis. Thus, this information is essentially pulled into the July 2017 snapshot.

[0042] Thus, snapshots can facilitate performing retrospective multidimensional queries using constraints that do not require contemporaneous observations. For each corresponding subject, the date treatment began can be set as time 0. One or more data points associated with the corresponding subject and subsequent time points (e.g., up to and including the date the corresponding subject stopped using a particular treatment) can be collected. The subsequent data points can indicate (for example) mobility or ambulation level, disability level, one or more MRI metrics, adverse event indicators, and / or any treatment termination indicators. Aggregate statistics can then be generated based on the subsequent data points, potentially based on the snapshot data.

[0043] For example, the aggregate statistics may include a distribution of the time periods during which the corresponding subjects continued a particular treatment. As other examples, the aggregate statistics may include, for each time period, a statistic (e.g., median, mean, or mode) that characterizes the number of new lesions detected across the corresponding subjects, characterizes a number of new enhancing lesions, characterizes a change in the total volume of a particular type of lesion, characterizes a change in disability level, characterizes a change in ambulation level, characterizes a change in a well-being index, characterizes the presence, prevalence, or severity of adverse events, and / or characterizes the probability or number of recurrences. Which post-treatment information is tracked can be determined based on input corresponding to the query or based on a predetermined configuration.

[0044] In some examples, corresponding subjects can be divided into two or more groups, and aggregate statistics can be generated for each group. For example, a first group can include corresponding subjects who continued to receive treatment for at least a predetermined time (e.g., 18 months), and a second group can include corresponding subjects who stopped treatment before the predetermined time. As another example, a first group can include corresponding subjects who received treatment for at least a first period (e.g., at least 6 months) and whose Expanded Disability Status Scale (EDSS) scores remained the same or changed by less than 1.5 points over a second period (e.g., within 12 months), and a second group can include corresponding subjects who received treatment for at least the first period and whose EDSS scores changed by 1.5 points or more over the second period.

[0045] For each example, the generated aggregate statistics for each group can represent information at baseline (time 0) for the subjects in the group, such as demographic information (e.g., age distribution, gender distribution), medical history information (e.g., prevalence of comorbidities), baseline MRI statistics (e.g., lesion burden, total lesion count, enhanced lesion count), and / or disability metrics (e.g., EDSS score or ambulation level). Thus, the aggregate statistics can be used to predict which types of subject attributes and / or conditions predict treatment efficacy and / or a positive prognosis during treatment. A caregiver or subject can use the prediction and certain attributes of the subject to decide whether to select a treatment or continue using the treatment. In some examples, predictions of efficacy and / or prognosis can be generated for a subject for each of multiple treatment strategies (e.g., associated with different corresponding subject populations), and a treatment can be selected for the subject based on the prediction.

[0046] In some examples, after a given subject begins treatment, one or more data points can be tracked for the given subject and compared with aggregate statistics for corresponding subjects or one or more groups within the corresponding subject. For example, four months after treatment initiation, the change in T2 lesion burden, change in EDSS score, and number of enhancing lesions can be determined for a given subject. A model (e.g., a classifier) ​​or multivariate analysis can be used to predict whether a subject's specific data points align more strongly with a "responder" or "non-responder" population subgroup (e.g., if the responder subgroup is associated with longer use of treatment, less MRI-based progression, and less disability progression). Caregivers or subjects can use the predictions to decide whether to change or consider changing the subject's treatment strategy.

[0047] In some examples, a query can be executed that includes constraints corresponding to a symptom set, disability score, and / or test result set associated with a given subject. The symptom set, disability score, and / or test result may (but need not) be insufficient to support a diagnosis of multiple sclerosis. A population of other subjects with similar symptoms, disability scores, and / or test results can be identified. The query may also be executed to further impose negative constraints (e.g., indicating that one or more other symptoms are not experienced). The population can be subdivided based on the treatment approach used. For each group within the population, statistics can be generated that indicate (for example) the likelihood of transitioning to another subtype of multiple sclerosis or a diagnosis of multiple sclerosis (e.g., as a function of time or within a period of time), the change in disability score (e.g., the median change as a function or time, or the probability of a worse score occurring within a period of time), the probability of changing treatment as a function of time, etc. The care provider can then recommend treatments associated with a relatively low likelihood of transitioning to another subtype, a relatively small change (or no change) in disability score, and / or a relatively small probability of changing treatment.

[0048] The cloud-based application can operate to implement data privacy protocols that allow an entity to send and / or receive one or more data records or other information characterizing a subject (e.g., experiencing a medical condition and / or having a possible or confirmed diagnosis of a medical condition) with an external entity while satisfying constraints imposed by data privacy regulations across various jurisdictions. The cloud-based application can be configured to algorithmically evaluate data privacy violations and automatically omit, obfuscate, or modify data records to comply with data privacy regulations. For example, the cloud-based application may be configured to determine whether aggregate statistics generated based on data associated with a set of corresponding subjects risk revealing identifying information. Such information may be more likely to be revealed (for example) if the constraint for identifying the corresponding subjects is particularly narrow, if the size of the population of corresponding subjects (or subgroups therein) is particularly small, if the number of aggregate statistics obtained or presented is particularly large, etc. To illustrate, if a query includes a zip code constraint along with three other constraints and the resulting population of subjects includes only three subjects, even presentation of statistical data generated based on data from all three subjects risks revealing personally identifiable information.

[0049] If it is determined that responding to the query poses a risk of revealing personally identifiable information, the cloud-based application can determine whether the user is authorized to view information about the subjects represented in the data, and if not, the cloud-based application can reject the query or modify the query to be less restrictive.

[0050] Some embodiments of the present disclosure provide technical advantages over conventional systems by providing a cloud-based application configured to exchange subject information with external entities without violating data privacy regulations. Cloud-based applications facilitate the selective collection and processing of data to arrive at datasets that are relatively consistent in content and format across subjects and other users. Data representations can further facilitate data querying in that fields that can identify constraints can be identified. Queries about subject populations can then be performed utilizing logical operands and / or basic searches rather than performing natural language processing queries. Furthermore, converting subject records into an event stream and / or generating snapshots at specific significant events can facilitate performing queries when various data points are not aligned in time. The use of machine learning models (e.g., classifiers) and population data can facilitate the improvement of predictors that affect the efficacy and / or tolerability of treatments.

[0051] While the above disclosure describes a cloud-based application configured to perform intelligent functions with respect to facilitating the diagnosis and treatment of multiple sclerosis, the cloud-based application can be configured to consult with an external physician, determine a diagnosis, and identify a potential diagnosis or potential treatment for any disease, condition, area of ​​study, or disorder, including, but not limited to, oncology, including cancers of the lung, breast, colorectal, prostate, stomach, liver, cervical (cervix), esophagus, bladder, kidney, pancreas, endometrium, oral cavity, thyroid, brain, ovary, skin, and gallbladder, solid tumors such as sarcomas and carcinomas, cancers of the immune system including lymphomas (such as Hodgkin's lymphoma or non-Hodgkin's lymphoma), and cancers of the blood (hematological cancers) and bone marrow such as leukemias (such as acute lymphocytic leukemia (ALL) and acute myeloid leukemia (AML)), lymphomas, and myelomas. Further disorders include blood disorders such as anemia, bleeding disorders such as hemophilia, blood clots, ophthalmologic disorders including diabetic retinopathy, glaucoma, and macular degeneration, neurological disorders including Parkinson's disease, spinal muscular atrophy, Huntington's disease, amyotrophic lateral sclerosis (ALS), and Alzheimer's disease, multiple sclerosis, diabetes, systemic lupus erythematosus, myasthenia gravis, inflammatory bowel disease (IBD), psoriasis, Guillain-Barré syndrome, chronic inflammatory demyelinating polyneuropathy (CIDP), Graves' disease, Hashimoto's thyroiditis, eczema, vasculitis, allergies, and autoimmune disorders including asthma.

[0052] Other diseases and disorders include, but are not limited to, kidney disease, liver disease, heart disease, stroke, gastrointestinal disorders such as celiac disease, Crohn's disease, diverticular disease, irritable bowel syndrome (IBS), gastroesophageal reflux disease (GERD) and peptic ulcers, arthritis, sexually transmitted diseases, high blood pressure, bacterial and viral infections, parasitic infections, connective tissue diseases, celiac disease, osteoporosis, diabetes, lupus, diseases of the central and peripheral nervous system such as attention deficit / hyperactivity disorder (ADHD), catalepsy, encephalitis, epilepsy and seizures, peripheral neuropathy, meningitis, migraine, myelopathy, autism, bipolar disorder, and depression.

[0053] II. Overview of MS subtypes, diagnostic protocols, relevant medical tests, progression assessment and available treatments II.A. Types of Multiple Sclerosis The medical community defines several types of MS, which can influence treatment options and inform prognosis.

[0054] II.A.1. Relapsing-Remitting Multiple Sclerosis (RRMS) In 85–90% of cases, multiple sclerosis initially manifests as relapsing-remitting multiple sclerosis (RRMS). Patients with RRMS experience separate exacerbations (or “relapses”) in which new neurological symptoms appear or old symptoms worsen. A prominent mechanistic hypothesis is that exacerbations are the result of an autoimmune cascade in which autoreactive leukocytes cross the blood-brain barrier from the periphery and attack the protective myelin layer on neuronal processes in the central nervous system. The autoimmune cascade primarily involves T cells, but is also thought to involve some B cells (e.g., to recruit macrophages, activate the complement pathway, and / or produce costimulatory molecules that influence T cell differentiation). Another theory is that the attack is carried out by myelin-specific T cells with dysfunctional immune regulatory mechanisms.

[0055] Each exacerbation may result in one or more physiological symptoms. Physiological symptoms may be symptoms related to one of eight functional systems. The functional systems and associated symptoms include the pyramidal system (symptoms: muscle weakness or difficulty moving limbs), cerebellar system (balance impairment or tremor), brainstem system (difficulty speaking or swallowing), sensory system (numbness or tingling), bowel or bladder system (incontinence), visual system (blurred or blind), cerebral system (deficits in memory, multitasking, or thinking), and others. During exacerbations, symptoms may disappear partially or completely. Complete recovery from relapse is more likely if the relapse occurs closer to the date of diagnosis (compared to later periods). Early in the disease, relapses typically involve the pyramidal, cerebellar, sensory, or visual functional systems. Later in the disease, relapses often involve the brainstem, bowel or bladder, or cerebral functional systems.

[0056] II.A.2. Active or inactive secondary progressive multiple sclerosis (SPMS) If left untreated, approximately 90% of patients with RRMS will transition to secondary progressive multiple sclerosis (SPMS) within 25 years (approximately 50% will transition within 10 years). There is no general agreement in the medical community about what precise indicators indicate the transition from RRMS to SPMS.

[0057] SPMS patients who continue to experience symptomatic relapses and inflammation are considered to have active SPMS, while patients without relapses are characterized as having active SPMS. However, these patients typically experience a gradual and generally monotonous decline in function as a result of nerve damage or loss. In other words, it is generally understood that the decline observed in SPMS patients is primarily due to neurodegeneration and not due to other immunological insults.

[0058] II.A.3. Primary Progressive Multiple Sclerosis (PPMS) Some MS patients are never diagnosed with RRMS and are instead initially diagnosed with primary progressive multiple sclerosis (PPMS). Similar to SPMS, these patients typically experience a gradual and persistent worsening of symptoms and brain damage. For both SPMS and PPMS, the gradual loss of function can occur over a period of months to years, making it difficult to detect. Most people with PPMS initially present with motor symptoms (while sensory and / or optical symptoms are more common in RRMS). A notable criterion for a PPMS diagnosis is that functional system impairment occurs gradually and is unrelated to discrete relapses (so that the gradual worsening is not the result of any residual disability caused by relapses).

[0059] II.A.4. Progressive-relapsing multiple sclerosis Some people experience symptomatic relapses and / or worsening lesions after a diagnosis of MS. In these cases, the patient is diagnosed with progressive-relapsing MS because the initial diagnosis of progressive MS is not discarded.

[0060] II.A.5. Clinically Isolated Syndrome (CIS) Although clinically isolated syndrome (CIS) is considered a subtype of multiple sclerosis, CIS is actually distinct from multiple sclerosis. A diagnosis of CIS indicates that a subject has experienced their first neurological symptom over at least 24 hours, which is isolated in time and not due to another medical condition (e.g., stroke or Lyme disease). If the subject recalls one or more other previous neurological symptoms or if MRI identifies older (non-enhancing) lesions, the subject should be diagnosed with multiple sclerosis rather than CIS.

[0061] A subject with CIS may or may not subsequently experience further symptoms and receive a diagnosis of multiple sclerosis. CIS patients may receive selected multiple sclerosis medications, which may reduce the likelihood or prolong the time a subject is diagnosed with multiple sclerosis.

[0062] II.B. Diagnosis of Multiple Sclerosis The patient's report of symptoms to the caregiver and the functional assessment performed by the caregiver are highly relevant when determining whether to diagnose a patient with multiple sclerosis and / or when diagnosing a patient with a particular subtype of multiple sclerosis. However, the results of several other medical tests can be highly influential in the diagnosis.

[0063] II.B.1. Medical Tests That May Be Useful for Diagnosing Multiple Sclerosis II.B.1.a. Magnetic Resonance Imaging Magnetic resonance imaging (MRI) machines contain large magnets that generate strong magnetic fields. These fields align protons in the body with the field. A radio frequency (RF) field at a resonant frequency spins protons out of equilibrium with the magnetic field. When the RF field is turned off, the protons release energy as they realign with the magnetic field. MRI machines include receiver coils to measure this energy release. Different types of biological structures produce different energy release profiles (e.g., identifying the time elapsed to return to equilibrium). Two operating settings include repetition time and echo time. Repetition time is the time between successive RF pulses. A long repetition time allows all protons to realign with the magnetic field before the next pulse, while a short repetition time results in many protons only partially realigning. Echo time indicates when the signal generated by the protons is measured. The longer the echo time, the more likely protons in gray and white matter are out of phase, resulting in a longer signal. Fluids, on the other hand, are less sensitive in this regard, so their signals remain stronger.

[0064] MRI images can include T1-weighted images (T1 images), T2-weighted images (T2 images), or flare images. T1 images are generated in response to short echo times (e.g., 14 ms) and short repetition times (e.g., 500 ms). In T1 images, white matter (e.g., axons) are bright, gray matter (e.g., neuronal cell bodies and dendrites) are gray, the spinal cord is gray, cerebrospinal fluid (CSF) is dark, and inflammation is dark. Black holes appear as hypointense (dark) areas in T1 images. When a contrast agent (e.g., gadolinium) is administered to a subject, the contrast agent can only cross the blood-brain barrier if this barrier has recently been disrupted and can leak into recently formed lesions. The T1 image then depicts these lesions as bright areas.

[0065] T2 images are generated in response to long echo times (e.g., 90 ms) and long repetition times (e.g., 4000 ms). In T2 images, white matter is dark gray, gray matter is light gray, the spinal cord is light gray, CSF is bright, and inflammation is bright. Therefore, T2 images can be used to detect new and old lesions (which appear bright). Flare images are generated in response to even longer echo times (e.g., 114 ms) and even longer repetition times (e.g., 9000 ms). In flare images, white matter is dark gray, gray matter is light gray, the spinal cord is light gray, CSF is dark, and inflammation is bright. Flare images allow better visibility of lesions adjacent to CSF ​​compared to T2 images.

[0066] MRI imaging of the brain and / or spinal cord can be used to facilitate the diagnosis of multiple sclerosis, facilitate the diagnosis of specific types of multiple sclerosis, facilitate the characterization of the progression of multiple sclerosis in a subject, facilitate the characterization of the extent to which a treatment is effectively treating a subject, and / or facilitate the decision to modify a treatment strategy for a subject. The number, location, size, and shape of lesions can inform one or more of these decisions. For example, "Dawson's fingers" are common lesions that occur in patients with RRMS. Dawson's fingers are multiple, ovoid lesions located near the venous system (deep medullary veins) of the brain. While lesions can be present in any CNS white matter, multiple sclerosis lesions frequently occur in the periventricular white matter, cerebellum, brainstem, and spinal cord.

[0067] MRI analysis frequently involves determining whether an MRI image depicts contrast-enhancing lesions; such lesions typically indicate that a subject's multiple sclerosis has recently been active. T2-weighted lesions are also frequently used to measure total lesion volume. T2 disease burden metrics measured early in the disease process (e.g., in CIS or RRMS) can provide information about a subject's long-term disability and / or disease progression.

[0068] Additionally, MRI can be used to identify cross-sectional areas (e.g., of spinal cord segments) or volumes (e.g., of the brain), which can be used to estimate the degree of atrophy in a subject. Atrophy can be estimated by comparing area / volume metrics generated based on a subject's most recent MRI with those generated based on the subject's older MRI. Atrophy can further be estimated by comparing area / volume metrics generated based on a subject's most recent MRI with statistics generated based on comparable populations. Atrophy statistics can be used to inform decisions regarding MS diagnosis and / or treatment decisions.

[0069] As described further below, the presence of lesions in multiple anatomical regions and / or the temporally separated appearance of lesions is indicative of multiple sclerosis disease. The temporally separated appearance of lesions can be detected by comparing MRIs acquired at different time points or by detecting that at least one lesion is contrast-enhanced (indicating recent inflammation) and at least one lesion is not contrast-enhanced.

[0070] II.B.1.b. Cerebrospinal fluid analysis The cerebrospinal fluid (CSF) of most subjects with multiple sclerosis (and many with other inflammatory conditions) contains relatively high concentrations of immunoglobulin G (IgG) compared with the general population. Although IgG appears to be a secondary effect of multiple sclerosis, it still provides a useful biomarker.

[0071] Therefore, analysis of CSF is frequently performed during the diagnostic phase of multiple sclerosis. CSF is collected from subjects via spinal tap. One or more laboratory tests (e.g., protein electrophoresis, Western blot, or a combination of isoelectric focusing and silver staining) are performed to detect proteins in each CSF sample and potentially in serum samples (e.g., diluted serum samples).

[0072] Detection of IgG bands in CSF is consistent with a diagnosis of multiple sclerosis. Additionally or alternatively, detection of oligoclonal bands in CSF and serum, along with additional bands in CSF, is also consistent with a diagnosis of multiple sclerosis. Either of these detections further predicts whether a subject with CIS will convert to clinically definite MS.

[0073] The IgG CSF index is defined as the ratio of IgG to albumin in the CSF compared to the ratio of IgG to albumin in serum. A value greater than 1 indicates that the central nervous system is producing IgG. The IgG CSF index can also be used to generate the IgG synthesis rate.

[0074] II.B.1.c. Visual evoked potentials Myelination of axons increases the speed at which action potentials travel along axons. Therefore, if myelin coasting is attacked through an inflammatory multiple sclerosis attack, the conductance of nerve impulses can subsequently be slowed. One test that can be useful in diagnosing multiple sclerosis is the elicitation of action potentials and measurement of their conduction velocity. Typically, for this evaluation, potentials are evoked by presenting specific visual stimuli (e.g., a binary dynamic checkerboard), and brain signals (e.g., in the occipital cortex) are noninvasively recorded (e.g., by electroencephalography). However, auditory or somatosensory stimuli may also be used instead. The evoked potential contains two negative peaks and one positive peak (between the two negative peaks). The magnitude and / or duration of each of these peaks can provide diagnostic and / or prognostic information for multiple sclerosis. For example, a condition of multiple sclerosis called optic neuritis can result in the loss of the positive peak and / or a severely attenuated response.

[0075] II.B.2. Criteria Used in the Diagnosis of Multiple Sclerosis No single test or assessment will reliably determine whether a subject has multiple sclerosis. In some instances, a single test result (e.g., a set of MRI images) may be sufficient to diagnose multiple sclerosis, but the test result is not reliably deterministic across subjects and situations.

[0076] Many healthcare providers characterize the diagnosis of multiple sclerosis as a diagnosis of exclusion, in that the clinician is tasked with prescribing tests and performing analyses to rule out other potential causes of the observed abnormalities. For example, many neurological symptoms and / or MRI results can be attributed to infections (e.g., Lyme disease), spinal cord compression, and vitamin B 12 It may be explained by a deficiency or a non-MS inflammatory demyelinating disease (e.g., sarcoidosis, systemic lupus erythematosus, neuromyelitis optica, or acute disseminated encephalomyelitis). If no such alternative explanation can be identified, a diagnosis of multiple sclerosis is appropriate.

[0077] Unfortunately, a diagnosis of exclusion is not a rapid diagnosis. Multiple sclerosis may continue to progress while a patient waits for various tests, test results, and awaits evaluation by a care provider. Various protocols and disease characterizations have been developed to account for this situation. For example, most criteria for the diagnosis of multiple sclerosis do not rely on excluding all potential alternative causes (although some individuals may subsequently discover, years after their multiple sclerosis diagnosis, that they actually have a different condition). Furthermore, the establishment of clinically isolated syndrome (CIS) has allowed physicians to prescribe several multiple sclerosis medications that may slow progression, even though a definitive multiple sclerosis diagnosis has not yet been reached.

[0078] II.B.2.a. McDonald's Standards The McDonald criteria are a prominent criterion for diagnosing multiple sclerosis. The basis of these criteria is that physicians generally need evidence of spatial and temporal separation to diagnose a subject with multiple sclerosis. Spatial separation can correspond to symptoms affecting different parts of the body, or different functional systems or lesions present in different parts of the central nervous system. Temporal separation can correspond to symptoms and / or lesions appearing at different times, which can be detected by multiple assessments (e.g., multiple MRIs or multiple clinical / symptomatic assessments) performed at different times, or by detecting some contrast-enhancing lesions (e.g., indicating recent inflammation) and some non-contrast-enhancing lesions (e.g., indicating that they have not recently formed).

[0079] The McDonald criteria have emerged as a frequently used standard for diagnosing multiple sclerosis. Under these criteria, any of the following circumstances will result in a multiple sclerosis diagnosis; otherwise, no multiple sclerosis diagnosis will be made: Symptomatic clinical evidence of two or more recurrences and two or more lesions two or more relapses, clinical evidence of lesions in the central nervous system, and one or more lesions typical of multiple sclerosis; Two or more relapses, clinical evidence of lesions in the central nervous system, and other relapses indicating damage to other parts of the central nervous system; Single relapse, clinical evidence of two or more lesions (e.g., involvement of two or more functional systems or parts of the body), distinct immune system activity as evidenced by oligoclonal bands identified based on multiple, temporally separated spinal taps, one recurrence, clinical evidence of two or more lesions (e.g., disorders in two or more functional systems or two or more parts of the body), and MRI evidence of new lesions from a previous scan; one relapse, clinical evidence of two or more lesions (e.g., impairment in two or more functional systems or two or more parts of the body), further symptomatic relapse, one relapse, clinical evidence of one lesion, one or more MRI lesions typical of multiple sclerosis, One relapse, clinical evidence of one lesion, other relapses showing activity in different parts of the central nervous system as shown by oligoclonal bands, MRI showing new lesions or new relapses from a previous scan, One relapse, clinical evidence of one lesion, one or more MRI lesions typical of multiple sclerosis, or A slow progression of neurological symptoms typical of multiple sclerosis over a period of one year, plus any two of the following: at least one brain lesion, two or more spinal cord lesions, or oligoclonal bands in the spinal fluid that are typical of multiple sclerosis.

[0080] II.C. Assessment of Multiple Sclerosis Progression After a subject is diagnosed with multiple sclerosis, they typically schedule regular appointments with a neurologist to assess various functions and report current or recent symptoms. In some instances, these appointments are scheduled at regular intervals (e.g., every six months). In some instances, the subject requests one or more appointments to discuss new symptomatic exacerbations, side effects of medication, etc. Neurologists also often recommend that subjects undergo periodic MRIs. Again, MRIs may be scheduled periodically to generally assess progression, or MRIs may be performed to determine whether new potential or actual symptoms are likely to correspond to an exacerbation, or to determine whether current treatments have been effective in slowing or halting disease progression.

[0081] Thus, a physician can determine whether and / or the extent to which a subject's multiple sclerosis is progressing based on one or more of the following: frequency of new symptoms, severity of new symptoms, worsening of old symptoms, changes in some functional system in which symptoms are experienced, frequency of new lesions, changes in lesion burden, changes in atrophy, and / or the subject's self-assessment. To more objectively assess the progression of multiple sclerosis, various scales have been developed. Some scales are designed to assess a subject's well-being and are based on the subject's responses to a series of questions.

[0082] Some scales are based on a physician's assessment of the subject's functional ability. One such function-based scale is the Expanded Disability Status Scale. This scale relies heavily on the subject's ability to walk. The scale ranges from 0 to 10 and is discretized in increments of 0.5. Scores from 0 to 4.5 are differentiated based on the number of functional systems in which the subject experiences symptoms or impairments and the severity of the symptoms / impairments. Scores from 4.5 to 7.5 are differentiated based on how far the subject can move and whether and / or what type of walking aid is required for mobility. Scores from 7.5 to 9.5 are differentiated based on the degree to which the subject is bedbound and retains some function. A score of 10 indicates death from multiple sclerosis.

[0083] II.D. Multiple Sclerosis Treatment In recent years, many new multiple sclerosis treatments have been brought to the market. Treatments can be distinguished based on their mechanisms (many of which are only partially understood), their routes of administration, and whether the treatments are characterized as first-line or second- or third-line approaches.

[0084] Injectable medications include interferon beta and glatiramer acetate. Interferon beta is an immune modulator that reduces the reactivity of CD4+ and CD8+ T cells. Interferon beta is available under three trade names (Avonex, Benzyl Alcohol, and Benzyl Alcohol) that differ in dosage formulation, route of administration, and frequency of use. (R) , Betaseron (R) and Rebif (R) Glatiramer acetate is an immunomodulatory agent that mimics myelin, binds to the major histocompatibility complex, and reduces T cell binding to antigens.

[0085] Recently, more oral medications have become available, including teriflunomide, monomethyl fumarate, fingolimod, siponimod, cladribine, dimethyl fumarate, diroximel fumarate, laquinimod, and ozanimod. Teriflunomide inhibits the mitochondrial enzyme dihydroorotate dehydrogenase. Dimethyl fumarate, monomethyl fumarate, and diroximel fumarate act through mechanisms currently being investigated to induce lymphopenia. Fingolimod and siponimod modulate sphingosine 1-phosphate (S1P); siponimod and ozanimod are selective for S1P1 and S1P5, whereas fingolimod is a nonselective S1P modulator. Cladribine inhibits CD4 + and CD8 + Depletes lymphocytes. Laquinimod interferes with T cell migration to the central nervous system and reduces IL-17 levels.

[0086] Still other drugs are delivered intravenously, including ocrelizumab, ofatumumab, ublituximab, rituximab, natalizumab, alemtuzumab, and mitoxantrone. Ocrelizumab, ofatumumab, ublituximab, and rituximab inhibit CD20 through complement-dependent cytotoxicity. +Targets B cells. Natalizumab is a monoclonal antibody that targets lymphocytes expressing CD52. Alemtuzumab is a monoclonal antibody that binds to CD52 on T and B cells, priming them for destruction. Mitoxantrone is a type II topoisomerase inhibitor that suppresses immune cell proliferation, impairs antigen presentation, enhances T cell suppressor function, and inhibits B cells.

[0087] Yet another treatment approach is autologous hematopoietic stem cell therapy, which involves removing some of the patient's bone marrow stem cells (released into the blood in response to chemotherapy), administering a multi-day chemotherapy treatment (to deplete most or all of the subject's immune cells), and administering stored stem cells (to promote recovery).

[0088] Medications can also be differentiated based on which subtype of multiple sclerosis they are approved to treat. Most approved multiple sclerosis medications are approved to treat RRMS. Medications approved to treat SPMS include mitoxantrone, cladribine, and siponimod. As of June 2020, the only medication approved in the United States and Europe to treat PPMS is ocrelizumab.

[0089] Many more treatments are available to treat the symptoms of multiple sclerosis (rather than the disease itself). For example, dalfampridine can be used to improve walking, tolterodine can be used to treat incontinence, or baclofen can be used to treat spasticity. Additionally, solumedrol (intravenous), prednisone (oral), and / or methylprednisolone (oral) are frequently used to treat multiple sclerosis relapses (e.g., to speed recovery from a relapse and / or increase the likelihood of complete recovery from a relapse).

[0090] Each treatment can be used as a first-line, second-line, or third-line treatment. Generally, a second-line treatment is administered after one or more first-line treatments have failed, are no longer effective, or cause intolerable adverse events. Similarly, a third-line treatment is administered after one or more second-line treatments have failed, are no longer effective, or cause intolerable adverse events. Different physicians may make different decisions regarding which treatments qualify as first-line treatments. These decisions may be based on adverse event profiles, as a higher risk of adverse effects and / or a more severe risk of adverse effects may be more acceptable if other treatment options have failed. According to the MS Foundation, treatments typically used as first-line treatments include teriflunomide, interferon beta, glatiramer acetate, ocrelizumab, pegylated interferon beta, and dimethyl fumarate. Treatments typically used as second or third line treatments include fingolimod, alemtuzumab, cladribine, siponimod, mitoxantrone and natalizumab.

[0091] III. Network Environment for Hosting Cloud-Based Applications Configured with Intelligent Capabilities 1 illustrates a network environment 100 in which an embodiment of a cloud-based application is hosted. Network environment 100 may include a cloud network 130 that includes a cloud server 135 and a data registry 140. Cloud server 135 may execute the source code underlying the cloud-based application. Data registry 140 may store data records captured from or identified using one or more user devices, such as computers 105, laptops 110, and mobile devices 115.

[0092] Data records stored in data registry 140 may be structured according to a skeletal structure of fixed portions (e.g., data fields). Computer 105, laptop 110, and mobile device 115 may each be operated by various users. For example, computer 105 may be operated by a physician, laptop 110 may be operated by an administrator of an entity, and mobile device 115 may be operated by a subject. Mobile device 115 may connect to cloud network 130 using gateway 120 and network 125. In some examples, computer 105, laptop 110, and mobile device 115 are associated with the same entity (e.g., the same hospital). In other examples, computer 105, laptop 110, and mobile device 115 are associated with different entities (e.g., different hospitals). User devices computer 105, laptop 110, and mobile device 115 are examples for illustrative purposes, and thus the present disclosure is not limited thereto. Network environment 100 may include any number or configuration of user devices of any device type.

[0093] In some embodiments, cloud server 135 can obtain data (e.g., subject records) for storage in data registry 140 by interacting with either computer 105, laptop 110, or mobile device 115. For example, computer 105 interacts with cloud server 135 by using an interface to select locally stored (e.g., stored on a network local to computer 105) subject records or other data records for inclusion in data registry 140. As another example, computer 105 interacts with an interface to provide cloud server 135 with the address (e.g., network location) of a database that stores subject records or other data records. Cloud server 135 then retrieves the data records from the database and incorporates the data records into data registry 140.

[0094] In some embodiments, computer 105, laptop 110, and mobile device 115 are associated with different entities (e.g., a medical center). Data records that cloud server 135 retrieves from computer 105, laptop 110, and mobile device 115 may be stored in different data registries. Data records from each of computer 105, laptop 110, and mobile device 115 may be stored within cloud network 130, but the data records may not be intermingled. For example, computer 105 cannot access data records retrieved from laptop 110 due to constraints imposed by data privacy regulations. However, cloud server 135 may be configured to automatically obfuscate, obscure, or mask portions of the data records when the data records are queried by different entities. Thus, data records captured from an entity may be released to different entities in an obfuscated, obscured, or masked format to comply with data privacy regulations. As an illustrative example, a doctor or other medical professional may input a subject's symptoms that may be related to multiple sclerosis. The symptoms may be stored in the cloud network 130 as part of the subject record associated with the subject.

[0095] Once the data records are collected from the computers 105, laptops 110, and mobile devices 115, the data records can be used as training data to train machine learning or artificial intelligence models to provide the intelligent analytic functions described herein. If a user device associated with an entity queries the data registry 140 and the query results include data records originating from different entities, the data records may be available for query by any entity, given that these data records may be provided or exposed to the user device in an obfuscated format that complies with data privacy regulations.

[0096] Cloud server 135 may be configured to perform intelligent functions to process the data records stored in data registry 140. For example, performing intelligent functions may include inputting at least a portion of the data records stored in data registry 140 into a trained machine learning or artificial intelligence model to generate an output for further analysis. In some embodiments, the output may be used to extract patterns within the data records or to predict values ​​or outcomes associated with data fields of the data records. Various embodiments of intelligent functions performed by cloud server 135 are described below.

[0097] In some embodiments, the cloud server 135 is configured to enable a user device (e.g., operated by a physician) to access a cloud-based application to send a consultation broadcast to a set of destination devices. The consultation broadcast can be a request for assistance or assistance regarding the treatment of a subject associated with the subject record. The destination device can be a user device operated by another user associated with another entity (e.g., a physician at another medical center). If the destination device accepts the request for assistance associated with the consultation broadcast, the cloud-based application can generate a condensed representation of the subject record that omits or hides certain data fields of the subject record. The condensed representation can comply with data privacy regulations, such that the condensed representation of the subject record cannot be used to uniquely identify the subject associated with the subject record. The cloud-based application can send the condensed representation of the subject record to the destination device that accepted the request for assistance. The user operating the destination device can evaluate the condensed representation and communicate with the user device using a communication channel to discuss options for treating the subject. As an illustrative example, a physician may be treating a subject with a possible, probable, or confirmed diagnosis of multiple sclerosis. A physician may seek further advancements or consultations on how to treat a subject with multiple sclerosis. The physician may have a broadcast consultation sent to a physician working at a different hospital. Various subject attributes of the subject record may be obfuscated and then transmitted to another physician. The two physicians may then communicate regarding the obfuscated multiple sclerosis record during a communication session, such as a chat room.

[0098] In some embodiments, the cloud server 135 is configured to provide a treatment plan definition interface to the user device. The treatment plan definition interface allows the user device to define a treatment plan for the condition. For example, the treatment plan can be a workflow for treating a subject for that condition. The workflow can include one or more criteria for defining a population of subjects as having the condition. The workflow can also include a specific type of treatment for the condition. The cloud server 135 receives and stores a treatment plan definition for a particular condition from each user device in the collection of user devices. A cloud-based application can distribute a treatment plan for a given condition to the set of user devices. Two or more user devices in the set of user devices may be associated with different entities. Each of the two or more user devices can include an option to integrate any portion or the entire treatment plan into a customer rule set. The cloud server 135 can monitor whether a user device integrates the entire shared treatment plan or a portion of the treatment plan. Interactions between the user device and the shared treatment plan can be used to determine whether to update the treatment plan or rules created based on the treatment plan.

[0099] In some embodiments, the cloud server 135 allows a user operating a user device to access a cloud-based application to determine a proposed treatment for a subject with a condition. The user device loads an interface associated with the cloud-based application. The interface allows the user operating the user device to select a subject record associated with a subject being treated by the user. The cloud-based application can evaluate other subject records to identify previously treated subjects similar to the subject being treated by the user. Similarity between subjects can be determined, for example, using an array representation of the subject records. The array representation can be any numerical and / or categorical representation of values ​​of data fields in the subject records. For example, the array representation of the subject records can be a vector representation of the subject records in a domain space, such as Euclidean space. In some examples, multiple values ​​in the array correspond to a single field. For example, the field value may be represented by multiple binary values ​​generated by one-hot encoding. The cloud-based application can generate an array representation of each subject record in a group of subject records. Similarity between two subject records can be represented by the distance between the array representations of the two subject records. Additionally, the cloud-based application can be configured to identify subjects that are closest to a subject record selected by the user device using the interface. The cloud-based application can identify treatments previously administered to the subjects that are closest. The cloud-based application can make the treatments previously administered to the closest neighbors available on the interface for evaluation by a user operating the user device.

[0100] In some embodiments, the cloud server 135 is configured to create a query that searches a database of previously treated subjects. The cloud server 135 can execute the query and retrieve subject records that satisfy the query constraints. However, when presenting the query results, the cloud-based application can present complete subject records only for subjects who have been or are being treated by the user creating the query. The cloud-based application masks or otherwise obfuscates portions of the subject records of subjects not treated by the user creating the query. Masking or obfuscating portions of the subject records included in the query results allows the user to comply with data privacy regulations. In some embodiments, the query results (whether or not the query results are obfuscated) can be automatically evaluated for patterns or common attributes within the subject records.

[0101] In some embodiments, the cloud server 135 embeds a chatbot in a cloud-based application. The chatbot is configured to automatically communicate with a user device. The chatbot can communicate with the user device in a communication session in which messages are exchanged between the user device and the chatbot. The chatbot can be configured to select an answer to a question received from the user device. The chatbot can select an answer from a knowledge base accessible to the cloud-based application. When a user device sends a question to the chatbot and the chatbot does not have an existing answer stored in the knowledge base, the chatbot can select a different phrase of the question for which there is an existing answer stored in the knowledge base. A user communicating with the chatbot can be prompted about the accuracy or usefulness of the answer provided by the chatbot.

[0102] III.A. Cloud-based applications allow user devices to broadcast consultation requests to other user devices and automatically condense subject records to comply with data privacy regulations 2 is a flowchart illustrating a process 200 performed by a cloud-based application to deliver a condensed subject record to a user device in connection with a consultation broadcast requesting assistance regarding the subject's treatment. Process 200 can be performed by cloud server 135 to enable user devices associated with different entities (e.g., hospitals) to collaborate or consult regarding a patient's treatment while complying with data privacy regulations.

[0103] Process 200 begins at block 210, where the cloud server 135 receives a set of attributes from a user device. Each attribute in the set of attributes can represent any characteristic of the subject (e.g., a patient). The set of attributes can be identified by a user using an interface provided by the cloud server 135. For example, the set of attributes identifies the subject's demographic information and recent symptoms experienced by the subject. Non-limiting examples of demographic information include age, gender, ethnicity, state or city of residence, income range, education level, or any other suitable information. Non-limiting examples of recent symptoms include subjects currently or recently (e.g., at last clinic visit, intake, within 24 hours, within one week) experiencing a particular symptom (e.g., shortness of breath, fever above a threshold temperature, blood pressure above a threshold blood pressure, etc.).

[0104] In block 220, the cloud server 135 generates a record for the subject. The record can be a data element including one or more data fields. The record indicates each of a set of attributes associated with the subject. The record can be stored in a central data store, such as the data registry 140 or any other cloud-based database. In block 230, the cloud server 135 receives a request submitted by a user using the interface. The request can be to initiate a consultation broadcast. For example, a user associated with an entity is a physician at a medical center treating a patient. The user can operate a user device to access a cloud-based application and broadcast a request to assist in the patient's treatment. The broadcast can be sent to a set of other user devices associated with different entities.

[0105] In block 240, the cloud server 135 queries the central data store using one or more recent symptoms included in the set of attributes associated with the subject. The query result includes a set of other records. Each record in the set of other records is associated with another subject. In block 250, the cloud server 135 identifies a set of destination addresses (e.g., other user devices associated with different entities). Each destination address in the set of destination addresses is associated with a care provider of another subject associated with one or more other records in the set of other records identified in block 240. In block 260, the cloud server 135 generates a condensed representation of the record for the subject. The condensed representation of the record omits, obfuscates, or obfuscates at least a portion of the record. The condensed representation of the record cannot be used to uniquely identify the subject associated with the record, so it can be exchanged between external systems without violating data privacy regulations. The cloud server 135 can perform any masking or obfuscation technique to generate the condensed representation of the record.

[0106] At block 270, the cloud server 135 utilizes a condensed representation of the record with a connection input component for each destination address in the set of destination addresses. The connection input component may be a selectable element presented at each destination address. Non-limiting examples of a connection input component include a button, a link, an input element, and other suitable selectable elements. At block 280, the cloud server 135 receives a communication from a destination device associated with the destination address. The communication includes an indication that a user operating the destination device has selected a connection input component associated with the condensed representation of the record. At block 290, the cloud server 135 facilitates establishment of a communication channel between the user device for which the connection input component was selected and the destination device. The communication channel enables a user operating the user device (e.g., a physician treating the subject) to exchange messages or other data (e.g., a video feed) with a destination device (e.g., a physician at another hospital who has agreed to assist in the subject's treatment) associated with the destination address for which the connection input component was selected.

[0107] In some embodiments, the cloud server 135 is configured to automatically determine the location of the user device and the location of the destination device for which the connection input component was selected. The cloud server 135 can also compare the locations to determine whether to generate a condensed representation of the recording. For example, in block 260, the cloud server 135 can generate a condensed representation of the recording because the cloud server 135 determines that each destination address in the set of destination addresses is not co-located with the user device that initiated the consultation broadcast. In this case, the cloud server 135 can automatically determine to generate a condensed representation of the recording to comply with data privacy regulations. As another example, if the set of destination addresses are associated with the same entity as the user device that initiated the consultation broadcast, the cloud server 135 can transmit the recording in its entirety (e.g., without obfuscating any portion of the recording) to the destination device associated with the destination address while complying with data privacy regulations.

[0108] In some embodiments, the cloud server 135 generates a plurality of other condensed record representations. Each of the plurality of other condensed record representations is associated with a different subject. The cloud server 135 transmits the plurality of other condensed record representations to a user device and receives a communication from the user device identifying a selection of a subset of the plurality of other condensed record representations. Each of the set of destination addresses is represented by one of the condensed record representations. For example, generating the condensed record representation includes determining the jurisdiction of the other subject associated with the condensed record representation, determining data privacy rules governing the exchange of subject records within the jurisdiction, and generating the condensed record representation to comply with the data privacy rules. A first other condensed record representation of the plurality of other condensed record representations may include a particular type of data. A second other condensed record representation of the plurality of other condensed record representations may omit or obscure the particular type of data. For example, the particular type of data may be contact information, identifying information such as a name, a social security number, or other appropriate information that can be used to uniquely identify the other subject.

[0109] In some embodiments, querying the central data store using the one or more recent symptoms includes determining a score for each other record of the plurality of other records. The score may characterize a similarity between at least a portion of the other records and at least a portion of the subject's records. The querying may further include defining the set of other records to be a subset of the plurality of other records associated with scores above a threshold. The querying of the central data store may include identifying the set of other records using at least a portion of the demographic information. For example, one of the other records may include data fields containing items of demographic information such as age, gender, ethnicity, etc. In some embodiments, the user device and the other device (e.g., a destination device associated with the destination address) are associated with different medical institutions.

[0110] III.B. Sharable Treatment Plan Definition Updates Based on Aggregate User Integration FIG. 3 is a flowchart illustrating a process 300 for monitoring a user's integration of a treatment plan definition (e.g., a decision tree or processing workflow) and automatically updating the treatment plan definition based on the monitoring results. Process 300 can be executed by cloud server 135 to enable a user device to define a treatment plan for treating a population of symptomatic subjects. The user device may distribute the treatment plan definition to user devices connected to an internal or external network. A user device receiving the treatment plan definition can decide whether to integrate the treatment plan definition into a custom rule base. Integration into the custom rule base can be monitored and used to automatically modify the treatment plan definition.

[0111] In block 310, the cloud server 135 stores interface data that causes a treatment plan definition interface to be displayed when a user device loads the interface data. The treatment plan definition interface is provided to each user device of the set of user devices when the user device accesses the cloud server 135 to navigate to the treatment plan definition interface. In some embodiments, the treatment plan definition interface allows a user to define a treatment plan for treating a population of subjects with a condition (e.g., lymphoma).

[0112] In block 320, the cloud server 135 receives a set of communications. Each communication in the set of communications is received from a user device of the set of user devices and generated in response to an interaction between the user device and the treatment plan definition interface. In some embodiments, the communications include, for example, one or more criteria for defining a population of subject records. Each criterion may be represented by a variable type. The criteria may be filter conditions for filtering a pool of subject records. For example, criteria for defining a population of subject records associated with subjects who may develop lymphoma may include the filter conditions "abnormal in anaplastic lymphoma kinase (ALK)" and "age 60 or older." The communications may also include a particular type of treatment for the symptoms. The particular type of treatment may be associated with a suggested action (e.g., undergo surgery) or inaction (e.g., reduce salt intake) to treat the symptoms associated with the subjects represented by the population of subject records.

[0113] In block 330, the cloud server 135 stores the set of rules in a central data store, such as the data registry 140 or any other centralized server in the cloud network 130. Each rule in the set of rules includes one or more criteria and a specific treatment type to be included in a communication from a user device. As an illustrative example, the rule represents a treatment workflow for treating lymphoma in a subject. The rule includes the following criteria (e.g., a condition following an "IF" statement) and a next action (e.g., a specific treatment type defined or selected by the user following a "THEN" statement): "IF "lymph node biopsy indicates the presence of lymphoma cells" AND "blood test indicates the presence of lymphoma cells", THEN "treat with chemotherapy" AND "active surveillance". Further, each rule in the set of rules is stored in association with an identifier corresponding to the user device from which the communication was received.

[0114] In block 340, the cloud server 135 identifies a subset of the set of rules that are available to entities via the treatment plan definition interface. The subset of rules may include a subset of the set of rules associated with symptoms and distributed to external systems, such as other medical centers, for evaluation. For example, rules may be selected for inclusion in the subset of rules by evaluating rule characteristics or identifiers associated with the rules. Rule characteristics may include a code or flag stored or attached to a stored rule. The code or flag indicates that the rule is publicly available to external systems (e.g., provided to the entities).

[0115] In block 350, for each rule in the subset of rules identified in block 340, the cloud server 135 monitors interactions with the rule. The interactions may include an external entity (e.g., outside the entity associated with the user who defined the treatment plan associated with the rule) integrating the rule into a custom rule base. For example, a user device associated with the external entity (e.g., another hospital) evaluates rules available to the external entity. The evaluation includes determining whether the rule is suitable for integration into a rule set defined by the external entity. A rule may be suitable if a user device associated with the external entity indicates that a treatment workflow defined using the rule is suitable for treating the condition corresponding to the rule. Continuing with the illustrative example above, a rule for treating lymphoma may be available to an external medical center. A user associated with the external medical center determines that the rule for treating lymphoma is suitable for integration into the rule set defined by the external medical center. Thus, after the rule is integrated into the custom rule base defined by the external medical center, other users associated with the external medical center can execute the integrated rule by selecting the integrated rule from the custom rule base. Additionally, the cloud server 135 monitors the integration of available rules by detecting a signal that is generated or caused to be generated when the treatment plan definition interface receives input corresponding to the integration of a rule into the custom rule base from a user device associated with an external entity.

[0116] As another illustrative example, a user device associated with an external entity uses a treatment plan definition to integrate an interaction-specified modified version of a rule into a custom rule base. The interaction-specified modified version of a rule is a portion of a rule selected for integration into the custom rule base. Selecting a portion of a rule for integration includes selecting fewer criteria than all of the criteria included in the rule for integration into the custom rule base. Continuing with the illustrative example above, a user device associated with an external entity selects the criterion "IF 'lymph node biopsy indicates the presence of lymphoma cells'" for integration into the custom rule base, but the user device does not select the criterion "blood test reveals the presence of lymphoma cells" for integration into the custom rule base. Thus, the interaction-specific modified version of the rule integrated into the custom rule base is "IF 'lymph node biopsy indicates the presence of lymphoma cells', THEN 'treat with chemotherapy' and 'active surveillance'." The criterion "blood test reveals the presence of lymphoma cells" is removed from the rule to create an interaction-specified modified version and incorporated into the custom rule base.

[0117] In block 360, the cloud server 135 may detect that a modified version of the interaction-specified rule has been integrated into a custom rule base defined by the external entity. Upon detection, the cloud server 135 may update the rule stored in a central data store of the cloud network 130. The rule may be updated based on the monitored interaction. The term "base" in this example corresponds to "after evaluating" or "using the results of the evaluation" of the monitored interaction. For example, the cloud server 135 detects that a user device associated with the external entity has integrated a modified version of the interaction-specified rule. In response to detecting the modified version of the interaction-specified rule, the cloud server 135 may update the rule stored in the central data store from the existing rule to the modified version of the interaction-specified rule.

[0118] In some embodiments, the cloud server 135 updates the rules by generating an updated version that is utilized across external entities. Other original versions may remain unupdated and are provided to users associated with user devices that received one or more communications identifying the criteria and particular types of treatment. For example, the cloud server 135 updates rules stored in the central data store, but the cloud server 135 does not update other rules in the set of rules stored in the central data store.

[0119] In some embodiments, the cloud server 135 can update a rule when an update condition is met. The update condition may be a threshold value. For example, the threshold value may be the number or percentage of external entities that have integrated modified versions of a rule into their custom rule base. As another example, the update condition may be determined using the output of a trained machine learning model. Illustratively, the cloud server 135 can input detection signals received from external entities into a multi-armed bandit model that automatically determines whether and when to employ a rule and / or whether and when to employ an updated version of a rule. The detected signals indicate whether the external entity has integrated a rule into its custom rule base or whether the external entity has integrated a modified version of an interaction-specified rule.

[0120] In some embodiments, the cloud server 135 identifies multiple rules in a rule set that include criteria corresponding to the same variable type and identify the same or similar types of treatments. The variable type may be a value or variable used as a condition for the criteria. The variable type of a rule's criteria may also be any value for a condition that constrains a population of subjects into subgroups. For example, the variable type of a rule that defines a population of pregnant women is "IF 'subject is pregnant'." The cloud server 135 determines a new rule that is a contraction of the multiple rules if the new rule is publicly available across entities.

[0121] In some embodiments, the cloud server 135 provides another interface configured to receive the set of subject attributes. For example, a user operating a user device accesses the other interface and uses the other interface to select a subject record that includes the set of attributes. The selection of the subject record can cause the cloud server 135 to receive the set of subject attributes. The cloud server 135 identifies (e.g., determines) a particular rule whose criteria are met based on the set of subject attributes. For example, the cloud server 135 evaluates the set of attributes of the subject record against the criteria of a rule stored in a central data store. Illustratively, if the set of attributes includes a data field that includes a value of "pregnant" and the rule includes a single criterion of "IF 'subject is pregnant'," the cloud server 135 identifies the rule. The cloud server 135 updates the other interface to present the particular rule and each particular type of action associated with the particular rule.

[0122] In some embodiments, the rule criteria are variable types associated with specific demographic variables and / or specific symptom-type variables. Non-limiting examples of demographic variables include information on any item that characterizes the subject's demographics, such as age, sex, ethnicity, race, income level, education level, location, and other suitable items of demographic information. Non-limiting examples of symptom-type variables indicate whether the subject is currently or recently (e.g., at the last visit, at intake, within 24 hours, within one week) experiencing a specific symptom (e.g., shortness of breath, loss of consciousness, fever above a threshold temperature, blood pressure above a threshold blood pressure, etc.).

[0123] In some embodiments, cloud server 135 monitors data in a registry of subject records, such as subject records stored in data registry 140. Cloud server 135 monitors data in the registry of subject records for each rule in the subset of rules (identified in block 340). Cloud server 135 identifies a set of subjects for which the criteria of the rule are met and a particular treatment has been previously prescribed for the subject. For each of the set of subjects, cloud server 135 identifies the subject's reported status as indicated from or using an assessment or test. For example, the reported status is any information that characterizes the subject's status in aspects such as whether the subject has been discharged from the hospital, whether the subject is alive, the subject's blood pressure measurement, the number of times the subject has awakened during a sleep stage, and other suitable status. Cloud server 135 determines an estimated responsiveness metric for the set of subjects to a particular treatment based on the reported status. For example, if a particular treatment in a rule is to prescribe medication, the estimated responsiveness metric is a representation of the extent to which the medication addressed the symptoms or condition experienced by the subject. As a non-limiting example, the estimated responsiveness metric for the set of subjects can be an average, weighted average, or any sum of the scores assigned to each subject in the set of subjects. The score can represent or measure the effectiveness of the subject's responsiveness to the treatment. The cloud server 135 can cause the subset of the set of rules and the estimated responsiveness metric for the set of subjects to be displayed or presented in the treatment plan definition interface.

[0124] III.C. Presenting Treatment Recommendations with Associated Efficacy Using Treatments Prescribed to Similar Subjects 4 is a flowchart illustrating a process 400 for recommending a treatment for a subject. Process 400 can be performed by cloud server 135 to display recommended treatments for a patient and the effectiveness of each recommended treatment on a user device associated with a medical entity. The recommended treatments can be identified using results of evaluating the effectiveness of treatments previously prescribed for similar subjects.

[0125] In block 410, the cloud server 135 receives input corresponding to a subject record characterizing an aspect of a subject. The input is received from a user device associated with the entity. Additionally, the input is received in response to the user device selecting or identifying the subject record using an interface associated with an instance of a platform configured to manage a registry of subject records. The user device can access the interface by loading interface data stored on a web server (not shown) connected within the cloud network 130. The web server may be included in the cloud server 135 or may run on the cloud server.

[0126] In block 420, the cloud server 135 extracts a set of subject attributes from the subject record received in block 410. The subject attributes characterize aspects of the subject. Non-limiting examples of subject attributes include any information found in an electronic health record, any demographic information, age, sex, ethnicity, recent or past symptoms, conditions, severity of conditions, and any other suitable information that characterizes the subject.

[0127] In block 430, the cloud server 135 generates an array representation of the subject record using the set of subject attributes. For example, the array representation is a vector representation of the values ​​contained in the subject record. The vector representation may be a vector in a domain space, such as Euclidean space. However, the array representation may be any numerical representation of the values ​​of the data fields of the subject record. In some embodiments, the cloud server 135 may perform a feature decomposition technique, such as singular value decomposition (SVD), to generate values ​​that represent the set of subject attributes of the array representation of the subject record.

[0128] In block 440, the cloud server 135 accesses a set of other sequence representations characterizing a plurality of other subjects. The sequence representations in the set of other sequence representations may be vector representations of subject records characterizing the other subject (e.g., one of the plurality of other subjects).

[0129] In block 450, the cloud server 135 determines a similarity score representing the similarity between the sequence representation representing the subject and each of the sequence representations of other subjects. For example, the similarity score is calculated using a function of the distance (in domain space) between the sequence representation representing the subject and the sequence representations representing the other subjects. As an illustrative and non-limiting example, the similarity score can be calculated using a range from "0" to "1," with "0" representing a distance above a defined threshold and "1" representing the sequence representations having no distance between them.

[0130] At block 460, the cloud server 135 identifies a first subset of the plurality of other subjects. A subject may be included in the first subset if the similarity score associated with the subject exceeds a predetermined absolute or relative threshold. Similarly, at block 470, the cloud server identifies a second subset of the plurality of other subjects. However, a subject may be included in the second subset if the subject's similarity score is within a predetermined range.

[0131] In block 480, the cloud server 135 obtains record data for each subject in the first and second subsets of the plurality of other subjects. The record data includes attributes included in the record that characterize the subject. For example, the record data identifies a treatment the subject received and the subject's responsiveness to the treatment. Responsiveness to the treatment can be represented by text (e.g., "The subject responded positively to the treatment") or a score indicating the degree to which the subject responded positively or negatively to the treatment (e.g., a score from "0" to "1," with "0" indicating a negative response and "1" indicating a positive response).

[0132] At block 490, the cloud server 135 generates output that is presented to an interface on the user device. The output may indicate, for example, treatments received by other subjects in the first and second subsets, treatment responsiveness of subjects in the first and second subsets, and differences between subject attributes of subjects in the second subset and subject attributes of subjects.

[0133] In some embodiments, the cloud server 135 determines that the subject and one of the subjects from the first or second subset are being or have been treated by the same medical entity. The cloud server 135 determines that the subject and the other subject from the first or second subset are being or have been treated by different medical entities. The cloud server 135 can utilize different obfuscated versions of the subject's records via an interface. As a technical advantage, the cloud-based application can automatically provide different obfuscated versions of the records to entities based on various constraints on data sharing imposed by data privacy regulations in different jurisdictions. In some embodiments, the cloud server 135 identifies the first and second subsets using nearest neighbor learning techniques.

[0134] III.D. Automatic Obfuscation of Query Results from External Entities 5 is a flowchart illustrating a process 500 for obfuscating query results to comply with data privacy regulations. Process 500 can be executed by cloud server 135 as an execution rule to ensure that data sharing of subject records with external entities complies with data privacy regulations. A cloud-based application can enable a user device to query data registry 140 for subject records that meet query constraints. However, the query results may include data records originating from external entities. Thus, process 500 enables cloud server 135 to provide additional information about treatment from external entities to a user device while complying with data privacy regulations.

[0135] In block 510, the cloud server 135 receives a query from a user device associated with a first entity. For example, the first entity may be a medical center associated with a first set of subject records. The query may include a set of symptoms related to a medical condition or any other information that constrains the query search of the data registry 140.

[0136] At block 520, the cloud server 135 queries the database using the query received from the user device. At block 530, the cloud server 135 generates a dataset of query results corresponding to the set of symptoms and associated with the medical condition. For example, the user device submits a query for subject records of subjects diagnosed with lymphoma. The query results include at least one subject record from a first set of subject records (originating from or created at a first entity) and at least one subject record from a second set of subject records associated with a second entity (e.g., a medical center different from the first entity). Each of the subject records from the first set of subject records and the second set of subject records can include a set of subject attributes. The subject attributes can characterize any aspect of the subject.

[0137] At block 540, the cloud server 135 presents (e.g., utilizes, or otherwise makes available) the entire subject attribute set to the user device for the subject records included in the first subject record set because those records originate from the first entity. Presenting the subject records in their entirety includes making the set of attributes included in the subject record available to the user device for evaluation or interaction using an interface. At block 550, the cloud server 135 also, or alternatively, makes available to the user device an incomplete subset of the subject attribute set for each subject record included in the second subject record set. Providing the incomplete subset of the set of subject attributes provides anonymity to the subject because the incomplete subset of the subject attributes cannot be used to uniquely identify the subject. For example, providing the incomplete subset may include available four of ten subject attributes to anonymize the subject associated with ten subject attributes. In some embodiments, at block 550, the cloud server 135 utilizes an obfuscated set of subject attributes for each subject record included in the second set. Obfuscating the set of attributes includes reducing the granularity of the information provided. For example, instead of utilizing the subject attribute of the subject's address, the obfuscated attribute may be a zip code or the state the subject lives in. Regardless of whether an incomplete subject or obfuscated subset is available, the cloud server 135 anonymizes the subject associated with the subject record.

[0138] III.E. Chatbot Integration with Self-Learning Knowledge Bases 6 is a flowchart illustrating a process 600 for communicating with a user using a bot script, such as a chatbot. Process 600 can be performed by the cloud server 135 to automatically link new questions provided by a user to existing questions in a knowledge base to provide answers to the new questions. The chatbot can be configured to provide answers to questions related to symptoms.

[0139] In block 605, the cloud server 135 defines a knowledge base including a set of answers. The knowledge base may be a data structure stored in memory. The data structure stores text representing a set of answers to defined questions. Each answer may be selectable by the chatbot in response to a question received from the user device during a communication session. The knowledge base may be automatically defined (e.g., by retrieving text from a data source and parsing the text using natural language processing techniques) or user-defined (e.g., by a researcher or physician).

[0140] In block 610, the cloud server 135 receives a communication from a particular user device. The communication corresponds to a request to initiate a communication session with a particular chatbot. For example, a doctor or a subject may operate the user device to communicate with the chatbot in a chat session. The cloud server 135 (or a module stored within the cloud server 135) may manage or facilitate the establishment of the communication session between the user device and the chatbot. In block 615, the cloud server 135 receives a particular question from the particular user device during the communication session. The question may be a string of characters that is processed using natural language processing techniques.

[0141] In block 620, the cloud server 135 queries the knowledge base using at least some words extracted from the specific question. The words may be extracted from the string representing the specific question using natural language processing techniques. In block 625, the cloud server 135 determines that the knowledge base does not contain a representation of the specific question. In this case, the received question may be newly submitted to the chatbot. In block 630, the cloud server 135 identifies other question representations from the knowledge base. The cloud server 135 can identify other question representations by comparing the question received from the user device with other question representations stored in the knowledge base. For example, if similarity is determined based on an analysis of the question representation using natural language processing techniques, the cloud server 135 identifies other question representations.

[0142] At block 635, the cloud server 135 retrieves an answer from a set of answers associated with other question representations in the knowledge base. At block 640, the answer retrieved at block 635 is sent to the particular user device as an answer to the received question, even if the knowledge base did not contain the received question representation. At block 645, the cloud server 135 receives an indication from the particular user device. For example, the indication may be received in response to the user device indicating that the answer provided by the chatbot responded to the particular question.

[0143] In block 650, the cloud server 135 updates the knowledge base to include the particular question representation or a different representation of the particular question. For example, storing the question representation includes storing keywords included in the question in a data structure. The cloud server 135 can also associate the same or different representation of the particular question with more answers sent to the particular user device.

[0144] In some embodiments, the cloud server 135 accesses a subject record associated with a particular user device. The cloud server 135 determines multiple answers to a particular question. The cloud server 135 then selects an answer from the set of answers. However, the selection of the answer is based at least in part on one or more values ​​included in the subject record associated with the particular user device. For example, the values ​​included in the subject record can represent symptoms recently experienced by the subject. The chatbot may select an answer that corresponds to the symptoms recently experienced by the subject.

[0145] III.F. Module for predicting response to multiple sclerosis treatment and monitoring multiple sclerosis progression 7A and 7B show flowcharts illustrating exemplary processes 700a and 700b for constructing and using snapshot data stores representing dynamic and distributed source data to characterize subpopulations and generate subject-specific predictions. Process 700a (shown in FIG. 7A) begins at blocks 705a-705e with receiving input identifying information regarding subjects with possible, probable, or confirmed multiple sclerosis. The inputs received at various blocks may be received at different times from different computing systems and in association with different users. The inputs may be received via an interface (e.g., a web-based or app-based interface) generated and / or managed by a cloud-based application system.

[0146] At block 705a, input is received identifying one or more symptoms experienced by the subject and / or a clinical assessment of the subject. The symptoms may include one or more multiple sclerosis symptoms identified herein, one or more neurological symptoms, and / or one or more symptoms related to one or more functional systems. The clinical assessment may include assessing (for example) the subject's mobility, the subject's disability (e.g., according to a defined disability measure such as the EDSS), an identification of the time required to perform a given task (e.g., walking a specific distance, performing a peg test, etc.), an identification of the accuracy of task performance (e.g., a memory task, a cognitive task, etc.), etc. The input received at block 705a may be from (for example) a care provider, a physician, a neurologist, a nurse, a doctor's office, a hospital, and / or the subject.

[0147] At block 705b, input is received identifying one or more test results associated with the subject. The test results may include results of one or more tests used to diagnose and / or evaluate multiple sclerosis, such as the tests identified in Section II (e.g., MRI, CSF analysis, visual evoked potential testing, and / or blood tests). The input received at block 705b may be from (for example) a technologist, radiologist, laboratory, and / or imaging center.

[0148] At block 705c, input is received identifying a possible, probable, or confirmed diagnosis for the subject. The diagnosis may include a neurological disease, multiple sclerosis, or a subtype of multiple sclerosis (e.g., those identified in Section II). The input received at block 705c may be from (for example) a neurologist, physician, nurse, nurse practitioner, doctor's office, or hospital.

[0149] At optional block 705d, input is received identifying a treatment for the subject. The treatment may be a treatment that has been or is being prescribed for the subject, or a treatment that is being considered for the subject. The treatment may include a multiple sclerosis treatment, such as a treatment described herein (e.g., Section II).

[0150] At optional block 705e, input is received identifying a subject's self-assessment. The subject's self-assessment may correspond to well-being, symptom presentation, mental state, activity level, social engagement, treatment goals, etc. In some examples, at least a portion of the input received at block 705e is in response to a quality of life survey, such as the Multiple Sclerosis Quality of Life-54 questionnaire.

[0151] It will be appreciated that input received at a given box may be received multiple times, for example, the symptom identification information at box 705a may be reported multiple times (e.g., reflecting the current state of the symptom).

[0152] The inputs are used to create and / or update records for particular subjects in block 710 using a cloud-based application. In some examples, to enter an input, a user must first find an existing record or create a new record. In some examples, the input is automatically accepted, and the cloud system determines whether the subject identification information sufficiently matches a record (if not, a new record can be created). The data carried by each input can be associated with a timestamp and source. In some examples, the data is processed (e.g., to facilitate storage of the data in a more structured and / or standard form). For example, certain numbers can be converted to ranges, MRI images can be processed by image processing to generate statistics, etc.

[0153] At optional block 715, a record snapshot is generated. The record snapshot can be generated at a defined time or interval, or in response to a specific type of input. For example, a new snapshot can be generated upon detecting a new diagnosis, treatment, symptom, and / or MRI results. The snapshot can include values ​​for each of a set of fields. The set of fields can characterize the corresponding subject (e.g., via demographic information, medical history, and / or behavioral patterns), diagnosis, diagnosis history, current treatment, treatment history (e.g., which treatments received and for what duration), current symptoms, symptom history, and / or recent self-assessment. Values ​​for all of these fields may not be provided at the same time. Therefore, the cloud-based application can identify the most recent value of a field not provided in the snapshot trigger input. In some examples, if the most recent value is sufficiently old, it may be omitted from the snapshot or flagged within the snapshot.

[0154] In block 720, the data store is queried for other records containing historical data corresponding to the particular treatment. The particular treatment may be a treatment the subject is receiving or a treatment being considered for the subject. In some examples, the query includes a temporal constraint, such as requiring that the particular treatment be initiated at least one year ago (so that subsequent data is more likely to be available). In some examples, the query further includes one or more attributes of the subject (e.g., age, geography, disease type, length of time since initial multiple sclerosis diagnosis, disability, etc.). In these examples, the query can be performed to identify records indicating that the subject had those attributes at a particular time (or period) relative to when the particular treatment was initiated. For example, the attribute can be an attribute associated with the subject at or just before the time the particular treatment was initiated. As another example, the particular time can be the length of time a given subject (for which input was provided in blocks 705a-705e) was receiving a particular treatment. Thus, the query may be performed using snapshots to facilitate time-dependent constraints.

[0155] In particular, a query may be performed with a first time constraint (e.g., to search for records and / or snapshots that associate a particular attribute with the time a particular treatment was initiated), but the data returned by the query may be associated with a different time period (e.g., approximately one year after treatment initiation, the first two years of use of a particular treatment, the time between the start of a particular treatment and the end of a particular treatment). Thus, for example, a query constraint may indicate that a subject had fewer than five lesions when they initiated treatment, and the query results may indicate how the number of lesions changed over the period that the treatment was used.

[0156] In block 725, the records provided in response to the query are divided into two or more subgroups. Each subgroup can correspond to a different type of response to treatment. For example, the subgroups can differ with respect to the length of time the subject received treatment (e.g., longer duration indicates greater efficacy), with respect to MRI progression, with respect to disability progression, with respect to symptom onset, with respect to progression across MS subtypes (e.g., from relapsing-remitting to secondary progression) and / or combinations thereof. This subgroup division can be determinable based on data points collected from the records within a time window corresponding to treatment duration (e.g., from the start of treatment or within a specified period between the start of treatment and the use of another treatment).

[0157] At block 730, a classifier is used to assign the subject to one of the subgroups based on the subject's characteristics. The classifier may include (for example) a clustering classifier, a neural network (e.g., perceptron, decision tree, random forest, logistic regression, linear regression, nearest neighbor, naive Bayes), a component analysis classifier, etc. The classifier can be trained to identify one or more features associated with each subgroup and generate a similarity metric that assesses how similar a subject's profile is to a given class (e.g., relative to one or more other subgroups). The classification can indicate a prediction as to whether and / or how well the subject will respond to treatment.

[0158] At block 735, an output corresponding to a treatment prediction or recommendation is generated based on the classification generated in block 730. For example, the output may identify a binary prediction as to whether the subject will respond to treatment, the probability that the subject will respond to treatment, the subject's predicted progression to treatment over time, the subject's predicted change in MRI statistics over time, the probability of progression to another disease subtype, etc. The output may be presented at and / or transmitted to (for example) a care provider, neurologist, physician, or a device associated with the subject. In some examples, process 700a may be repeated for each of multiple treatment options, thereby identifying the treatment option associated with the most favorable predicted outcome for the subject.

[0159] In some examples, some or all of blocks 740-755 are performed automatically. For example, the query in block 720 may be performed at regular time intervals in response to receiving a particular type of input about the subject (e.g., identification of an MRI or disability progression, identification of a new treatment being used or being considered for the subject, or identification of a new diagnosis of an MS subtype for the subject). The query can be configured to include constraints that identify the particular treatment being used or being considered for the subject as reflected in the subject's record. The query can request particular predetermined field values ​​(e.g., corresponding to MRI results, relapse detection, disability assessment, adverse events, subsequent changes in treatment, subject demographics, diagnosis, and / or previous medications used) of records that satisfy the constraints. The requested particular predetermined field values ​​may be associated with a predetermined time period relative to the initiation of a particular treatment (e.g., the first year of treatment, the first two years of treatment, or the duration of treatment).

[0160] As another example, automated techniques or predetermined criteria may be used to segment the records in block 725. Automated techniques may include (for example) clustering algorithms applied to MRI change data, lesion change data, or treatment length usage data. The predetermined criteria may separate records based on (for example) a threshold number of new lesions detected during the treatment period, a change in lesion score detected during the treatment period, and / or a number of relapses detected during the treatment period.

[0161] One advantage of automated processing is that record data can be shielded from users receiving the output generated in block 735. That is, users or user devices can lack access to certain values ​​from records retrieved by query in block 720. This can facilitate data privacy while continuing to leverage big data.

[0162] In some examples, some or all of blocks 720-735 are executed in response to input (e.g., from the same or a different user than the user who provided the input received in any of blocks 705a-705e). For example, user input can select fields whose record values ​​should be retrieved via a query upon detecting constraint satisfaction (at block 720), and / or user input can identify criteria for separating query result records into subgroups (at block 725). When a user has more active control over blocks 720-725, the presentation and / or visualization of the data can be abstracted, obfuscated, and / or generalized to protect data privacy. For example, rather than presenting specific field values, distributions and / or statistics of values ​​for various fields (e.g., representing records retrieved by a query) can be presented. Distributions and / or statistics may be presented for individual fields rather than presenting multivariate distributions and / or statistics, again to shift away from presenting identifying or personal information.

[0163] Process 700b shown in FIG. 7B illustrates another technique for using subject records to inform treatment predictions or recommendations. Blocks 705a-705e, 710, and 715 shown in FIG. 7B may correspond to similarly numbered blocks shown in FIG. 7A. In block 740, a data store is queried for corresponding records containing historical data corresponding to the subject records. For example, the query may identify one or more symptoms, test results, diagnoses (e.g., of multiple sclerosis subtype), treatments, and / or self-assessments associated with the subject for whom input was received in blocks 705a-705e. In some examples, the query includes one or more values ​​received via input in blocks 705a-705e, or processed versions thereof. For example, the input in block 705a may identify a given subject, age 27, residing at a particular address in Des Moines, Iowa, with eight T2 scan MRI lesions, while a query constraint may specify that the snapshot of interest should be associated with subjects between the ages of 21 and 30, residing in the United States, with six to ten T2 lesions.

[0164] In some examples, for each of the set of other subject snapshots, a similarity score is generated based on at least a portion of the other subject snapshots using at least a portion of the snapshots or records associated with the given subject for which input was received in blocks 705a-705e. To generate the score, different fields can be associated with different weights. Block 740 can then include identifying other subject snapshots whose scores exceed a predetermined threshold (e.g., in the top percentile or above a particular value).

[0165] 7A, block 720, the query performed in block 740 of FIG. 7B may be performed with a first time constraint (e.g., to search for records and / or snapshots that associate a particular attribute with the time a particular treatment was initiated), but the data returned by the query may be associated with a different time period (e.g., approximately one year after treatment initiation, the first two years of use of a particular treatment, the time between the start of a particular treatment and the end of a particular treatment). Thus, in some examples, query constraints may be applied to individual snapshots (e.g., such that an individual snapshot satisfies all constraints), but the record information retrieved may correspond to other snapshots and / or other portions of records (associated with the same subject for which the constraints were met).

[0166] In block 745, the query result records are divided into subgroups based on treatment. For example, each query result can correspond to a portion of the corresponding record that identifies data points corresponding to the time a given treatment was initiated, used, and / or terminated. Thus, potentially, for a given subject, multiple query results are identified, each corresponding to a different treatment. The subdivision in block 745 can include identifying unique MS treatments and dividing the query results accordingly. In some examples, multiple treatments are associated with individual groups (e.g., when multiple treatments are related to the same or similar mechanism of action). For example, interferon beta and glatiramer acetate can be grouped together. As another example, dimethyl fumarate, monomethyl fumarate, and diroxymethyl fumarate can be grouped together. As another example, ocrelizumab, ofatumumab, brituximab, and rituximab can be grouped together.

[0167] At block 750, one or more response statistics are generated for each subgroup. The response statistics can be generated based on (for example) clinical, MRI, symptomatic treatment, treatment decision, health indicators, adverse events, and / or relapse data associated with the treatment period. The response statistics can reflect absolute values ​​(e.g., absolute lesion burden and / or absolute disability score) and / or change in values ​​over the treatment period (e.g., change in lesion burden since treatment initiation and / or change in disability score since treatment initiation). The response statistics can be based on (for example) the number of T2 lesions, the number of enhancing lesions, the cumulative number of enhancing lesions, lesion burden, atrophy metric, number of relapses, disability score, health index, the length of time the subject has continued treatment, and / or one or more other MS-related variables disclosed herein. In some examples, the response statistics are based on multiple metrics. For example, the response statistics can include a binary value indicating whether the subject experienced any new lesions, any relapses, or any disability progression over a period of time. Response statistics can include (for example) univariate distributions, multivariate distributions, mean, median, mode, skew, range, maximum, minimum, and / or standard deviation. Response statistics can include the percentage of subjects in which a particular type of response (e.g., corresponding to not getting worse) is observed.

[0168] In block 755, an output is generated corresponding to one or more predictions regarding how a subject associated with the record generated / updated in block 710 will respond to each of one or more treatments and / or identify a recommended treatment. The prediction regarding how a subject will respond to a treatment may include response statistics generated for the corresponding subgroup. For example, the prediction may identify a 44% chance that lesion burden and disability will remain stable for at least two years if a given medication is taken over that period. The recommended treatment may be associated with one or more most favorable response statistics compared to statistics associated with other treatments. The output may be transmitted to a user device and / or presented locally (e.g., to a care provider, physician, neurologist, or subject). The output may include one, more, or all of the response statistics generated in block 750, which may be associated with a corresponding treatment.

[0169] Similar to FIG. 7A, some or all of the query and subsequent processing may be performed automatically or in response to user input. For example, predefined rules may identify which subject attributes should be used in the query (e.g., and how they should be generalized), or user input, similar information. As another example, a predefined protocol may indicate what type of statistics should be generated in block 750. As yet another example, the interface may present distributions (e.g., as overlaid lines or separate graphs) for each of the subgroups for one or more types of response variables (e.g., number of new lesions, number of new relapses, disability progression, number of adverse events). The user can then select the response variable of interest and define one or more statistics to be generated for each treatment type.

[0170] 7A and 7B, respectively, can facilitate the use of big data processing to identify a treatment. It will be appreciated that a similar approach can be used to generate a predicted prognosis (e.g., associated with the use of a given treatment or independent of a particular treatment).

[0171] In some examples, the data store can be used to generate more general treatment predictions and / or indications (e.g., not necessarily tied to an individual subject). FIG. 8 shows a flowchart illustrating an exemplary process 800 for generating high-level treatment response predictions and / or indications using a snapshot data store. Process 800 begins at block 805, where the data store is queried for records containing an indication that the subject received a particular treatment. The query may specify that the particular treatment should have been initiated by at least a particular date (e.g., more than one year ago, more than two years ago, more than five years ago). In some examples, the query further specifies one or more other constraints, such as the multiple sclerosis subtype the subject would have had when the particular treatment was initiated. The data store queried in block 805 can include a data store generated based on one or more input types and / or variables disclosed herein. In some examples, the data store includes a set of snapshots associated with an individual subject to reflect estimated time-synchronized data points.

[0172] In block 810, a period of interest is identified for each query response record. The period of interest begins at the start of a particular treatment and can correspond to the period over which one or more response metrics are evaluated. In some examples, the period of interest is the same across query response records (e.g., 1 year, 2 years, 5 years). In some examples, the period of interest is defined as the period over which a particular treatment was used. In some examples, the period of interest is the shorter of the period of use of a particular treatment and a particular time.

[0173] At block 815, the query result records are divided into treatment response subgroups. The records can be divided according to one or more techniques described with respect to block 725 in process 700a (as shown in FIG. 7A) and / or based on one or more variables. In some examples, the records are divided into two subgroups (corresponding to progression, no progression, new lesions and no new lesions, new symptoms and no new symptoms, moderate-to-severe adverse events and no or mild adverse events, treatment use for at least a threshold time and treatment use for less than a threshold time). In some examples, the subgroup assignment depends on two or more variables. In some examples, there are three or more subgroups.

[0174] The variable values ​​used for record segmentation may be extracted from record entries associated with the period of interest identified in block 810. For example, if the period of interest is identified as one year, then for each query result record, the records may be searched for entries representing treatment response (e.g., MRI data, clinical assessments, medication status) and associated with a timestamp approximately one year after treatment initiation. As another example, if the period of interest is identified as the treatment period, then all snapshots associated with timestamps after treatment initiation and extending through snapshots showing medication changes may be identified. Thus, if a subject began treatment in April 2013 and completed treatment in May 2016, the subject's lesion count or disability in October 2017 may be irrelevant for record segmentation (determining the period of interest).

[0175] At block 820, one or more aggregate attribute statistics are generated for each subgroup. The aggregate statistics may characterize attributes of the subjects in the subgroup at the time the subjects began receiving a particular treatment. The aggregate attribute statistics may correspond (for example) to the subject's age, sex, latitude, residential status, country of residence, MS subtype, medication history, lesion count, lesion burden, disability score, mobility index, use of walking aids, co-morbid conditions, functional systems affected by symptoms, and / or time since first MS diagnosis (again, all considered at the time treatment began). The aggregate attribute statistics may include mean, median, mode, range, minimum, maximum, outliers, distribution, skew, etc.

[0176] At block 825, an output corresponding to a treatment prescription and / or prediction is generated. For example, the output may identify attribute characteristics (e.g., via one or more attribute statistics) associated with subgroups in which a particular treatment was effective and may identify attribute characteristics associated with other subgroups in which a particular treatment was not effective. In some examples, characteristics of only a subset of the set of attributes evaluated are represented in the output. For example, at block 820, for each of the set of attributes, a p-value (or other significance indicator) may be generated to indicate the extent to which the attribute is distinguishable across subgroups. The output generated at block 825 may then include subgroup-specific statistics for each attribute associated with a p-value (or other significance indicator indicating significant subgroup distinction) below a threshold. In some examples, a multivariate analysis is performed to identify attributes that are most predictive of subgroup assignment, and the output characterizes the values ​​of those attributes in one, multiple, or all subgroups.

[0177] In some examples, block 825 includes generating new treatment instructions. For example, the attribute statistics may indicate that a particular treatment is particularly well-suited (e.g., as determined based on duration of use) when used by RRMS MS patients who are under 50 years old and have an EDSS score of less than 3.5. As another example, the attribute statistics may indicate that a particular treatment is correlated with a particular rapid progression when used by RRMS MS patients who have an EDSS score of greater than 6.0. Subsequent analyses can then be performed to assess whether there is a significant difference between one of these subject populations when the particular treatment is administered compared to when one or more other treatments (or no treatment) are administered. If so, the treatment strategy can be used to determine whether to recommend or use a particular treatment for a given subject by determining whether the given subject's attributes correspond to one of the populations.

[0178] In some examples, rather than dividing query result records into subgroups to evaluate how subject attributes correlate with treatment response, treatment response can be identified as a non-binary number. For example, treatment response can include the number of weeks a subject continued treatment, the number of new lesions detected over two years while continuing treatment, the change in a numerical well-being index over the first year of treatment, etc. A model can then be trained to predict treatment response based on the subject's attributes. For example, a regression model or a feedforward neural network may be used. The trained model can then process an input dataset representing other subject attributes to predict how the subject will respond to treatment. The learned parameters can also be evaluated to determine which subject attributes are associated with a high weight (e.g., indicating relative influence in generating the output prediction).

[0179] IV. Examples 9A-9F illustrate an exemplary interface configured to receive input for building a multiple sclerosis record data store. FIG. 9A illustrates an interface including multiple editable sections identifying information corresponding to a particular subject with possible, probable, or confirmed multiple sclerosis. The "Person" section 905 includes the subject's multiple identifiers (identifier number and name), current place of residence, place of birth, contact information (phone number, email address), insurance information, and current status (indicating alive or deceased). The Person section 905 further identifies the date the subject signed informed consent, thereby enabling one or more caregivers to upload information about the subject to the computing system providing the interface and for the uploaded information to be used in a specified manner. A copy of the signed informed consent itself can be uploaded via another page of the interface so that the consent can be reviewed. The Person section 905 also identifies the subject's age, which can be automatically updated in time.

[0180] The "Demographics, Medical History" section 910 includes indicators of whether the subject has any of a range of other diseases, whether the subject has a family history of multiple sclerosis or other autoimmune diseases, smoking history, characteristics of alcohol intake, employment and marital status, education level, and ethnicity.

[0181] The "Symptom Occurrence" section 915 may identify the MS subtype with which the subject was diagnosed, the date the subject's multiple sclerosis is estimated to have manifested itself, and the disability score. Symptom characterization may be further identified by interaction with the symptom occurrence section 915.

[0182] The measurements section 920 may include results from clinical, laboratory, or imaging evaluations.

[0183] The treatment section 925 may identify each MS treatment, symptomatic and non-pharmacological, received by the subject, and the dates corresponding to each treatment. The treatment section 925 may further identify one or more adverse events experienced by the subject in response to the treatment.

[0184] Interacting with the treatment section 925 allows the user to select one or more MS treatments (e.g., alemtizumab, azathioprine, copaxone, deaclizumab, dimethyl fumarate, methotrexate, mitoxantrone, natalizumab, interferon, ocrelizumab, fingolimod, rituximab, teriflunomide, other, or no treatment), indicate any adverse event information (e.g., pathogen: bacterial / fungal / viral / parasitic / if unknown, adverse event onset / resolution dates, whether the adverse event required hospitalization, CTCAE toxicity grade (1-5) and / or outcome). The interface may allow the user to identify one or more MS and / or symptom treatments (e.g., prednisone, cortisone, dexamethasone, hydrocortisone, methylprednisolone, prednisone). For each MS and / or symptom treatment, the interface may be further configured to receive the dose, units, duration, route (subcutaneous, intramuscular, intravenous, oral, etc.), start / end dates, and / or reason for terminating the treatment. The user may further identify one or more non-pharmacological treatments (e.g., physical therapy, yoga, vaccinations, etc.) being used by the subject.

[0185] FIG. 9B illustrates an exemplary interface configured to receive results from an MRI evaluation. Data entered through this interface is then accessible via the measurements section 920 of the interface shown in FIG. 9A. As shown, the interface of FIG. 9B is configured to accept inputs identifying the date of the examination, which central nervous system region was imaged, whether T1 images were acquired, an indication (via the "T1 Type" field) of whether the T1 images were normal, typical for MS, or abnormal and atypical for MS, the number of lesions detectable in the T1 images, whether gadolinium was administered, whether the T1 images acquired after gadolinium administration were normal, typical for MS, or abnormal and atypical for MS, and a count of the number of contrast-enhancing lesions. The interface is further configured to accept inputs indicating whether T2 images were acquired, an indication (via the "T2 Type" field) of whether the T2 images were normal, typical for MS, or abnormal and atypical for MS, and the number of lesions detectable in the T2 images. The interface is further configured to accept input indicating the number of each of several types of lesions highly characteristic of MS (subtentorial, paracortical, periventricular, and adjacent), and to accept the number of detected black holes.

[0186] Other interfaces (not shown) capable of receiving data corresponding to measurement section 920 may be configured to receive hematological data. The hematological data may include metrics corresponding to red blood cell count, hemoglobin count, platelet count, white blood cell count, lymphocyte count, T cell count, CD4 T cell count, CD8 T cell count, CD19 B cell count, NK cell count, neutrophil count, monocyte count, eosinophil count, and / or basophil count.

[0187] One or more other interfaces (not shown) capable of receiving data corresponding to the measurement section 920 can be configured to receive blood chemistry data, thyroid function data, serology data, and / or autoantibody test data. The blood chemistry data can characterize total protein count, albumin count, SGOT / AST count, SGPT / ALT count, gamma-GT count, bilirubin count, alkaline phosphate count, calcium count, urea count, uric acid count, creatine count, amylase count, lipase count, and / or vitamin D levels. The thyroid function data can characterize levels of T3, T4, TSH, anti-microsomal antibodies, and / or anti-thromboglobulin antibodies. The serology data can indicate the presence of anti-JC virus, the presence of JC virus DNA in the subject's urine, the presence of HBV antigen, the presence of anti-HCV, the presence of anti-HIV, the presence of anti-varicella, quantitative gold test results, Mantoux test results, the presence of neutralizing anti-IFN, the presence of neuroleptic anti-natalizumab, and / or pregnancy test results. Autoantibody data can indicate the presence or absence of NMO-IgG, anti-MOG, ANA, anti-mitochondrial, anti-parietal cell, ASMA, anti-Ro, La, Sm, RNP, Sci-70, Jo1, anti-DNA, ANCA, anti-LKM, anti-cardiolipin, LAC, and / or anti-transglutaminase.

[0188] Figure 9C illustrates an exemplary interface configured to receive results from an MRI evaluation. Data entered through this interface is then accessible via a measurements section 920 of the interface shown in Figure 9A. As shown, the interface of Figure 9C is configured to accept input identifying the date the cerebrospinal fluid was collected from the subject, whether the CSF was determined to correspond to a normal sample, a sample typical for MS, an abnormal sample also atypical for MS, or a sample corresponding to trauma, whether oligoclonal bands were detected in the CSF, the amount of oligoclonal bands detected, whether JC virus DNA was detected in the CSF, and the IgG index.

[0189] FIG. 9D illustrates an exemplary interface configured to receive results from evoked potentials. The evoked potentials may include sensory evoked potentials generated in response to somatosensory stimulation (SSEPs), auditory evoked potentials (BAEPs), visual evoked potentials (VEPs), or motor evoked potentials (MEPs). The potentials may be detected in corresponding cortical regions on the right or left side of the body. The interface illustrated in FIG. 9D is configured to identify whether each of multiple types of evoked potentials was normal, abnormal, or unknown.

[0190] Each interface identified in Figures 9A-9D is accessible to a caregiver. Other interfaces are also available for subjects diagnosed with MS. Figure 9E shows a subject-side interface that includes selection details regarding the types of data available in the subject's record. Figure 9F shows exemplary survey questions that are also accessible to the subject. Various questions may be presented to the subject at different times, and notifications may be presented indicating that new questions are available. The questions may correspond to health-oriented questions that can be used to determine the subject's health index.

[0191] While this example provides exemplary interface configurations and contemplated data, other interface configurations and data variables are also contemplated. For example, the interface can be configured to receive any type of disease characterization disclosed herein, any type of symptom characterization disclosed herein, any type of treatment characterization, any type of subject attribute disclosed herein, any type of clinical assessment disclosed herein, any type of medical test or imaging results disclosed herein, etc.

[0192] 9A-9F thus illustrate interfaces through which a user can provide information characterizing a subject's demographics, diagnosis, treatment, and other information. This information can be used to support big data analytics to evaluate the effectiveness of specific treatments generally or in specific situations. This information can also or alternatively be used to generate queries that use other records and / or define operations to be performed to generate predictions for individual subjects associated with the record regarding treatment response.

[0193] V. Further Considerations Some embodiments of the present disclosure include a system including one or more data processors. In some embodiments, the system includes a non-transitory computer-readable storage medium containing instructions that, when executed on the one or more data processors, cause the one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein. Some embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium containing instructions configured to cause one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein.

[0194] The terms and expressions which have been employed are used as terms of description rather than of limitation, and there is no intention in the use of such terms and expressions to exclude equivalents of the features shown and described or portions thereof, but it is recognized that various modifications are possible within the scope of the invention as claimed. Thus, although the claimed invention has been specifically disclosed by embodiments and optional features, it will be understood that modifications and variations of the concepts disclosed herein may be resorted to by those skilled in the art, and that such modifications and variations are deemed to be within the scope of the invention as defined by the appended claims.

[0195] This description provides only preferred exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, this description of preferred exemplary embodiments provides those skilled in the art with an enabling description for implementing various embodiments. It will be understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope of the appended claims.

[0196] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood that the embodiments can be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order to avoid obscuring the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0197] VI. Further Examples A first example includes a method including receiving, at a cloud-based application server, a query identifying a treatment for multiple sclerosis and querying a data store using an identifier for the treatment, the data store being stored at least in part based on input received from a distributed set of care provider entities. The first example method further includes receiving, in response to the query, a set of subject identifiers, each subject identifier in the set of subject identifiers indicating that the subject corresponding to the subject identifier received the treatment. The first example method further includes, for each subject identifier in the set of subject identifiers, determining, based on data in the data store, a time at which the subject corresponding to the subject identifier began the treatment, and extracting, from one or more records associated with the subject identifier, one or more metrics indicative of an outcome of the treatment and one or more subject attributes. The extracting of the one or more metrics is based at least in part on the time the treatment began, and each of the one or more subject attributes reflects a characteristic or medical test result of the subject corresponding to the record. The first example method further includes generating a predicted responsiveness of other subjects to the treatment based on the extracted metrics and the extracted subject attributes, and outputting a result corresponding to the predicted responsiveness.

[0198] A second example includes the method of the first example, wherein, for each subject identifier in the set of subject identifiers, the data store includes a set of subject-associated snapshots (each of the set of subject-associated snapshots corresponds to a particular time and a subject corresponds to the subject identifier), each snapshot in the subset of the set of subject-associated snapshots is associated with a treatment, and one or more metrics are extracted from the subset of the set of subject-associated snapshots.

[0199] A third example includes the method of the second example, wherein, when it is determined that for at least some of the set of subject-related snapshots, the data store does not contain other metric values ​​for the subject associated with a time after a different time prior to the particular time but not exceeding the particular time corresponding to the snapshot, at least one of the one or more metrics is defined to be a metric value from the different time.

[0200] A fourth example includes the method of any one of the first to third examples, wherein the one or more metrics indicative of treatment outcome include one or more absolute or relative statistics based on the MRI results.

[0201] A fifth example includes the method of any one of the first through fourth examples, wherein the one or more metrics indicative of treatment outcome include one or more absolute or relative statistics based on recurrence reports.

[0202] A sixth example includes the method of any one of the first to fifth examples, wherein the one or more metrics indicative of treatment outcome include one or more absolute or relative statistics based on the progress assessment.

[0203] A seventh example includes the method of any one of the first through sixth examples, wherein the one or more metrics indicative of treatment outcome include one or more absolute or relative statistics based on the impairment assessment.

[0204] An eighth example includes the method of any one of the first to seventh examples, further including training a machine learning model using the extracted metrics and the extracted subject attributes, and wherein the predicted responsiveness is generated using the trained machine learning model.

[0205] A ninth example includes the method of any one of the first through eighth examples, further including separating the set of subject identifiers into two or more groups using the metric; and assigning other subjects to groups of the two or more groups based on other subject metrics associated with the other subjects, wherein predicted responsiveness is generated based on the group assignment.

[0206] A tenth example includes the method of any one of the first through ninth examples, wherein each of the one or more subject attributes includes a subject attribute associated with a time at which the subject began treatment.

[0207] An eleventh example includes the method of any one of the first through tenth examples, wherein the received query further includes one or more particular attributes of the other subjects, and the query is performed based on the one or more particular attributes.

[0208] A twelfth example includes the method of any one of the first through eleventh examples, wherein the one or more particular attributes include identification of other treatments previously received by other subjects.

[0209] A thirteenth example includes the method of any one of the first through twelfth examples, further including predicting, based on the results, that the treatment will effectively treat multiple sclerosis in another subject; and treating the other subject with the treatment.

Claims

1. 1. A method comprising: receiving, at a cloud-based application server, a query identifying a treatment for multiple sclerosis; querying a data store using the treatment identifier, the data store being populated at least in part based on input received from a distributed set of care provider entities; receiving, in response to the query, a set of subject identifiers, each subject identifier in the set of subject identifiers indicating that a subject corresponding to the subject identifier received the treatment; For each subject identifier in the set of subject identifiers: determining, based on the data in the data store, a time when the subject corresponding to the subject identifier began the treatment; from one or more records associated with the subject identifier; one or more metrics indicative of the outcome of said treatment; and extracting one or more subject attributes, wherein the extracting of the one or more metrics is based at least in part on the time the treatment was initiated, and each of the one or more subject attributes reflects a characteristic of a record-corresponding subject or a result of a medical test; generating a predicted response of other subjects to the treatment based on the extracted metrics and the extracted subject attributes; and outputting a result corresponding to the predicted responsiveness.

2. For each subject identifier in the set of subject identifiers: the data store includes a set of subject-associated snapshots, each of the set of subject-associated snapshots corresponding to a particular time, the subject corresponding to the subject identifier; each snapshot in the subset of the set of subject-related snapshots is associated with the treatment; The method of claim 1 , wherein the one or more metrics are extracted from the subset of the set of subject-related snapshots.

3. 3. The method of claim 2, wherein, when it is determined that for at least some of the set of subject-related snapshots, the data store does not contain other metric values ​​for the subject associated with times after a different time prior to the particular time and not later than the particular time corresponding to the snapshot, at least one of the one or more metrics is defined to be a metric value from the different time.

4. The method of any one of claims 1 to 3, wherein the one or more metrics indicative of the outcome of the treatment comprise one or more absolute or relative statistics based on MRI results.

5. 5. The method of claim 1, wherein the one or more metrics indicative of the outcome of the treatment comprise one or more absolute or relative statistics based on recurrence reports.

6. 6. The method of any one of claims 1 to 5, wherein the one or more metrics indicative of the outcome of the treatment comprise one or more absolute or relative statistics based on a progress assessment.

7. The method of any one of claims 1 to 6, wherein the one or more metrics indicative of the outcome of the treatment comprise one or more absolute or relative statistics based on impairment assessment.

8. 8. The method of claim 1, further comprising training a machine learning model using the extracted metrics and the extracted subject attributes, wherein the predicted responses are generated using the trained machine learning model.

9. Separating the set of subject identifiers into two or more groups using the metric; 9. The method of claim 1, further comprising: assigning the other subjects to one of the two or more groups based on other subject metrics associated with the other subjects, wherein the predicted response is generated based on the group assignment.

10. 10. The method of claim 1, wherein each of the one or more subject attributes comprises an attribute of the subject associated with a time at which the subject began the treatment.

11. 11. The method of claim 1, wherein the received query further comprises one or more specific attributes of the other subjects, and wherein the query is performed based on the one or more specific attributes.

12. The method of claim 11 , wherein the one or more particular attributes include identification of other treatments previously received by the other subjects.

13. predicting, based on the results, that the treatment will effectively treat multiple sclerosis in the other subject; and The method of any one of claims 1 to 12, further comprising treating said other subject with said treatment.

Images