Patent Application
20220412974
Infectious diseases pose an ever present threat to global and public health in many countries and cities. Diagnostic strategies can include biosensors to detect pathogens and/or biomolecules associated with a particular pathogen. A biosensor is an analytical device which can include a sensing bioreceptor, a transducer, and a detector with a digital output. Generally, a target analyte interacts with the bioreceptor, and a detecting component of the bioreceptor recognizes the analyte through a reaction, specific adsorption, frequency response, or another process such as physical/chemical interaction. The transducer translates such interactions to a quantifiable signal measured by the detector and provided as digital output. Depending on the particular design, biosensors may provide multiple capabilities, including high performance, user-friendly operation, rapid response, high sensitivity and specificity, portability, relatively compact size, and real-time analysis.
A system for detecting a pathogen can include a sensor array having a plurality of sensors to detect a pathogen. The plurality of sensors can include virus sensors, which directly detect a whole virus, and at least one of a biomarker sensor, an antibody sensor, a saturated oxygen sensor, a temperature sensor, and a heart rate sensor. The system can receive sensor output from at least a portion of sensors included in the sensor array, where the sensor output from a sensor can represent a response signature linked to the pathogen. The system can assign weights to the sensor output of the individual sensors based in part on characteristics of the individual sensors to detect the response signature associated with the pathogen. Characteristics of the individual sensors can include sensor type or function, and/or performance variations in the individual sensors. The system can determine whether the pathogen has been detected based on the weights assigned to the sensor output of the individual sensors, and the system can output whether the pathogen has been detected.
There has thus been outlined, rather broadly, the more important features of one or more embodiments so that the detailed description thereof that follows may be better understood, and so that the present contribution to the art may be better appreciated. Other features of the present invention will become clearer from the following detailed description of the invention, taken with the accompanying drawings and claims, or may be learned by the practice of the invention.
These drawings are provided to illustrate various aspects of the invention and are not intended to be limiting of the scope in terms of dimensions, materials, configurations, arrangements or proportions unless otherwise limited by the claims.
While these exemplary embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, it should be understood that other embodiments may be realized and that various changes to the invention may be made without departing from the spirit and scope of the present invention. Thus, the following more detailed description of the embodiments of the present invention is not intended to limit the scope of the invention, as claimed, but is presented for purposes of illustration only and not limitation to describe the features and characteristics of the present invention, to set forth the best mode of operation of the invention, and to sufficiently enable one skilled in the art to practice the invention. Accordingly, the scope of the present invention is to be defined solely by the appended claims.
In describing and claiming the present invention, the following terminology will be used.
The singular forms “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a particle” includes reference to one or more of such materials and reference to “subjecting” refers to one or more such steps.
As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary.
As used herein, the term “at least one of” is intended to be synonymous with “one or more of” For example, “at least one of A, B and C” explicitly includes only A, only B, only C, and combinations of each.
Concentrations, amounts, and other numerical data may be presented herein in a range format. It is to be understood that such range format is used merely for convenience and brevity and should be interpreted flexibly to include not only the numerical values explicitly recited as the limits of the range, but also to include all the individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly recited. For example, a numerical range of about 1 to about 4.5 should be interpreted to include not only the explicitly recited limits of 1 to about 4.5, but also to include individual numerals such as 2, 3, 4, and sub-ranges such as 1 to 3, 2 to 4, etc. The same principle applies to ranges reciting only one numerical value, such as “less than about 4.5,” which should be interpreted to include all of the above-recited values and ranges. Further, such an interpretation should apply regardless of the breadth of the range or the characteristic being described.
Any steps recited in any method or process claims may be executed in any order and are not limited to the order presented in the claims. Means-plus-function or step-plus-function limitations will only be employed where for a specific claim limitation all of the following conditions are present in that limitation: a) “means for” or “step for” is expressly recited; and b) a corresponding function is expressly recited. The structure, material or acts that support the means-plus function are expressly recited in the description herein. Accordingly, the scope of the invention should be determined solely by the appended claims and their legal equivalents, rather than by the descriptions and examples given herein.
Technologies
Technologies are described for evaluating sensor output of sensors included in an array of sensors to: (i) determine whether a subject is currently infected with a virus, (ii) determine an estimated prognosis of the virus, or (iii) determine whether the subject has had a past infection of the virus. In one example configuration, a device (e.g., a pathogen detection device, a mobile device, or another type of device) containing a sensor array can be used to test a biological sample (e.g., saliva, mucus, blood, etc.) for the presence of a virus. The sensor structure and aptamer/molecular recognition mechanisms can be designed to detect pathogens, cells, biomarkers, antibodies and antigens. The sensor array can include a plurality of virus sensors, which directly detect a whole virus, and at least one of: a biomarker sensor, an antibody sensor, a saturated oxygen sensor, a temperature sensor, and a heart rate sensor. Sensor output of the individual sensors in the sensor array can be evaluated to identify a response signature associated with the virus and assign weights to the sensor output of the individual sensors based in part on characteristics of the individual sensors (e.g., sensor types and/or performance variations of the individual sensors).
As described in more detail later, a machine learning model can be trained to evaluate and weight the sensor output of the individual sensors and determine a probability whether the pathogen has been detected based on the weights assigned to the sensor output. It is contemplated that the device can be an easy-to-use, point-of-care, and self-administered multimodal sensor device to accurately diagnose and assess a stage of infection in an individual. The device, in one example can be a stand-alone device configured to output a probability whether the virus has been detected, along with an estimated prognosis of the virus; or the device, in another example, can be used with a second device (e.g., a mobile device) and/or cloud service, to provide the probability of infection and estimated prognosis of the virus to a subject and/or health care practitioner for customized treatment.
An outbreak of a virus can result in high mortality rates due to unexpected volumes of subjects in critical condition. Healthcare systems may be overwhelmed when hospitals are not prepared for the number of individuals that need intensive care. These types of outbreaks call for the crucial need for point-of-care diagnostic platforms that not only detect viral infection, but also simultaneously identify subjects that may be at greater risk of developing major complications and may need special care protocols. Assessing health risks for subjects can help in hospital coordination of supplies and equipment while preventing sudden overwhelming situations for intensive care facilities by reserving assets for the most high risk individuals. Experience shows that during peak infection volume, large numbers of subjects need to be tested and diagnosed at high rates. Prior to the present technologies, a point-of-care technology that diagnoses an infection and simultaneously assesses the risk of complications or death from the infection was not available. The present technologies described herein can provide rapid and accurate test results which are easy to interpret and can minimize the risk of infectious exposure to healthcare personnel.
To further describe the present technology, examples are now provided with reference to the figures.
In one example, the sensor array 118 can comprise an integrated circuit (chip) containing an N×N array of sensors 112/114a-n. The array can have any number of sensor based on desired size, number of data points, variations of sensors, etc. However, as a general rule N can be an integer from 4 to 100 and in some cases 5 to 50. As an example, referring to
Returning to
One advantage of using sensor arrays is that they can be used to quantify different independent variables that affect the sensor output. For example, if a virus sensor responds to a particular virus (Cv1), temperature (T), humidity (H), pressure (P), and 12 other viruses or pathogens (Cv3-Cv14), 16 independent measurements can uniquely determine each of these measurands. Instead of using the same sensor 16 different times, 16 sensors can be used simultaneously. Assume that in a 4×4 sensor array with sensors Sij (i=1 to 4 and j=1 to 4) the output of each sensor can be given by:
S
ij
=a
ij
C
v1
+b
ij
T+c
ij
H+d
ij
P+e
ij
C
v2+
where Cv1 is the concentration of virus 1, T is the temperature, H is the humidity, P is the pressure, and Cv2 to Cv14 are the concentration of the other 12 viruses. In a well-designed sensor, aij can be much larger than the other coefficients. The sensors in the array can be designed to be identical but will vary because of the fabrication imperfections and non-uniformities. In this case, the coefficients aij will be nearly equal with small differences. Even then, having 16 sensor output simultaneously, can enable finding the 16 independent variables Cv1, T, H, P, Cv2, . . . CV14 in one simultaneous array measurement. These sensor outputs can be viewed as independent measurements because the coefficients will be slightly different. For this approach to work, the coefficients aij's, bij's etc. need to be known beforehand. Therefore, machine learning can be used to find and tabulate these coefficients.
In another approach, the sensors can be designed to selectively detect different viruses. In this case, aij's and eij's can all be different. Our sensor arrays can be used with both these approaches. To enable different sensors in the array to detect different viruses, different “selective” functionalization technique ranging for photolithography, shadow masking, and liquid-phase selective molecular layer deposition can be used.
The virus sensors 112 included in the sensor array 118 can directly detect a whole intact biological virus, a biomarker associated with the biological virus, and/or antibodies produced in response to an infection of the biological virus in a subject. Specific types of virus sensors 112 are discussed later in more detail. Sensor output generated by the virus sensors 112 can be evaluated to determine a probability that a virus has been detected in a biological sample input 116, or a probability of a past infection of the virus. In one example configuration, the pathogen detection device 102 can include a diagnosis and prognosis module 110 that determines a probability of a current or past infection of a virus, and an estimated prognosis of the virus infection based on features associated with the virus infection. The diagnosis and prognosis module 110 can evaluate sensor data 108 of each individual sensor 112/114a-n in the sensor array 118 and determine a probability of infection based on weights assigned to the sensor data 108 of each of the individual sensors 112/114a-n in the sensor array 118. The weights assigned to sensor data 108 can be based in part on one or more characteristics of an individual sensor 112/114a-n to detect a response signature of the virus.
A response signature of a virus can be defined by a number of factors that when considered together indicate a current or past infection of the virus, as well as a stage of infection of the virus. The factors can include: whether the whole virus, biomarkers of the virus, and/or antibodies associated with the virus have been detected, and whether symptoms associated with an infection of the virus (e.g., fever, low blood oxygen level, increased heart rate, etc.) are present. A combination of sensor data 108 from various sensor types can be used to determine whether these factors that define the response signature of the virus are present in the sensor data 108, thereby indicating that a current or past infection of the virus has been detected in a subject, and indicating a stage of infection of the virus. Illustratively, a response signature of a virus may include sensor data 108 that indicates the detection of a whole virus and/or biomarker of the virus, an oxygen saturation level below 80%, a body temperature above 104°, and an elevated resting heart rate. Characteristics of the sensors 112/114a-n associated with detecting a response signature of a virus can include (i) a type or function of a sensor 112/114a-n and/or (ii) learned performance variations of the individual sensors 112/114a-n to generate sensor output. Some of these sensor characteristics are described below.
Individual Sensor Characteristics—Sensor Type or Function
In one aspect of the technology, the diagnosis and prognosis module 110 can assign a weight to sensor output of an individual sensor 112/114a-n based on a type or function characteristic of the sensor 112/114a-n to detect a response signature of a virus. Types of sensors 112/114a-n that perform defined functions can include, but is not limited to, virus sensors, biomarker sensors, antibody sensors, a pulse oximeter sensor, a temperature sensor, or a heart rate sensor. A sensor type or function associated with sensor output of an individual sensor 112/114a-n can be identified, and a weight that corresponds to the sensor type or function can be assigned to the sensor output. As an example, using a sensor identifier, the diagnosis and prognosis module 110 may determine whether sensor output is associated with a virus sensor, a biomarker sensor, an antibody sensor, a pulse oximeter sensor, a temperature sensor, or a heart rate sensor, and the diagnosis and prognosis module 110 can assign a weight to the sensor output that corresponds to the type or function of the identified sensor 112/114a-n. The weights assigned to the sensor output of the sensor 112/114a-n correspond to the significance of the sensor output to indicate an infection of the virus. As a non-limiting example, sensor output of a virus sensor 112 can be weighted more heavily than sensor output from a temperature sensor based on the presumption that detecting the presence of a whole virus in a biological sample is a better indicator of an infection as compared to a body temperature that is above normal. The diagnosis and prognosis module 110 can use the weights assigned to the sensor output to generate a probability 124 that the virus has been detected.
In one example configuration, the diagnosis and prognosis module 110 can use machine learning to evaluate sensor data 108 and assign weights to sensor data 108 of individual sensors 112/114a-n based in part on a type or function of the individual sensors 112/114a-n. The machine learning model can then generate a probability that a response signature of the virus has been detected based on the weights assigned to the sensor data 108. As an illustration, in response to receiving sensor output from the sensors 112/114a-n in the sensor array 118, the diagnosis and prognosis module 110 can create a sensor dataset that links sensor output to a sensor 112/114a-n that generated the sensor output. For example, the sensor dataset can include a sensor identifier for a sensor 112/114a-n that links the sensor 112/114a-n to the sensor output. The diagnosis and prognosis module 110 can input the sensor dataset to the machine learning model, and the machine learning model can evaluate the sensor output of the individual sensors 112/114a-n and assign weights to the sensor output based on a type or function of the individual sensors 112/114a-n. The machine learning model can use the weights to generate a probability that a response signature associated with a virus has been detected, and if detected, the machine learning model can generate an estimated prognosis of the virus. For example, the machine learning model can evaluate the sensor output of the individual sensors 112/114a-n to generate a probability of a stage of infection of the pathogen in a subject.
A virus infection in different subjects can take widely different paths. In some subjects, a virus infection can be asymptomatic, while in other subjects the virus infection can be symptomatic with different degrees of severity. In addition to detecting a virus, the diagnosis and prognosis module 110 can generate an estimated prognosis of the virus infection pathway. The prognosis can indicate an estimated stage of infection of the virus in a subject, such as a first stage of infection, advanced state of infection, critical stage of infection, a recovery stage of infection, or a recovered stage (past infection). In one example, the diagnosis and prognosis module 110 can evaluate the sensor output of the individual sensors 112/114a-n in the sensor array 118 and identify patterns in the sensor data 108 that correlate to stages of infection of a virus. For example, various patterns of virus detection data, antibody detection data, and vital sign data (e.g., body temperature, heart rate, blood oxygen level, etc.) in the sensor data 108 can correlate to stages of a viral infection. The diagnosis and prognosis module 110 can analyze the sensor data 108 for these patterns and output an estimated prognosis that correlates to an identified pattern. It is contemplated that a prognosis algorithm can be used to analyze the sensor data 108 and generate an estimated prognosis.
In one aspect of the technology, baseline health data 120 for a subject can be an additional feature included in a sensor dataset which can be evaluated by diagnosis and prognosis module 110 to generate an estimated prognosis of the virus. For example, a machine learning model can be trained using the baseline health data 120 to allow for more personalized predictions of a virus infection. The baseline health data 120 can be generated using past and current health metrics for the subject, and the baseline health data 120 can include, but is not limited to, baseline body temperature, baseline heart rate, and/or baseline blood oxygen level. The baseline health data 120, in one example, can be obtained from a subject's health records, which can include habits and conditions that affect the physical health of the subject (e.g., exercise, smoking, alcohol, drugs, psychological condition, etc.), and the baseline health data 120 can be used to train the machine learning model. After training, the pathogen detection device 102 can be configured to periodically (e.g., weekly, monthly, etc.) send a request for a subject's baseline health data 120 to a remote health data repository which stores the baseline health data 120 on behalf of the subject, and the updated baseline health data 120 can be used to generate a probability of virus infection in the subject. In one example, sensors 114a-n contained in the pathogen detection device 102 can collect health metrics for a subject over a period of days, weeks, and/or months, and the health metrics can be used to calculate and update the baseline health data 120 for the subject. In one example, the machine learning model can be trained using model-agnostic meta-learning and a labeled training dataset that includes data associated with multiple subjects, and a gradient descent update can be performed using a labeled dataset and baseline health data 120 for a subject to personalize the machine learning model to the subject.
In one example configuration, a meta-learning approach can be used to personalize a machine learning model to a subject using a limited labeled dataset. For example, model-agnostic meta-learning (MAML) is a meta-learning framework that generates a meta-model from a set of tasks with limited data to allow the meta-model to be quickly adapted to handle new tasks. Specifically, consider some given tasks {(i)}i=1K that are drawn from an underlying task distribution p(
). Each task
(i) has a train dataset
train(i) and a test dataset
(i), both of which have few sam les. MAML aims to learn a meta-model θ that can be quickly adapted to the test dataset of each task after performing one gradient descent update on the corresponding train dataset. Once the meta-model is learned, the machine learning model can be readily personalized to a specific subject by performing one gradient descent update using the subject's own data and
Although a meta-model can be quickly adapted to new tasks, solving the MAML problem involves heavy computation.
Individual Sensor Characteristics—Learned Sensor Performance Variations
As described earlier, another sensor characteristic associated with detecting a response signature of a virus can include learned performance variations in virus sensors 112 included in a sensor array 118. By way of background, virus sensors 112 can include electrodes that are separated by a tunneling gap that is tuned to match the size of a virus and/or virus molecules. The virus sensors 112 can be functionalized with different aptamers to bind with different viruses, biomarkers, and/or virus antibodies. In these types of biosensors, small physical variations between the biosensors 112 can result in differences in sensor output. As such, sensor output from biosensors 112 included in a sensor array 118 may not always agree. For example, small, nearly atomic-scale variations in a gap of a biosensor 112 may result in changes in a virus sensor's current-voltage characteristics (I-Vs), while the main features of the I-Vs related to a specific biomolecule or analyte in the device gap remain the same. In one example, the biosensor can be a whole virus sensor 112. Changes that can occur in a virus sensor 112 can include: structural changes in the virus sensor 112 itself, such as a rearrangement of atoms on an electrode, changes in contact between the electrodes and the virus/biomolecules, changes in the virus/biomolecule properties because of the virus sensor's small volume/quantity in the device gap, and changes due to repeated oxidation/reduction in the presence of nearby metal electrodes. For example, an electrode-analyte contact can change because of electrochemical reactions as well as by electromigration of metal atoms, and by dehydration, possible heating, and oxidation of analytes and biomolecules. These structural changes can result in an effective change in the gap size of a virus sensor 112. Other differences such as inherent manufacturing variations, debris, and/or damage can similarly effect sensor output signals.
The performance characteristics of virus sensors 112 in a sensor array 118 can be learned by analyzing I-V output of the virus sensors 112. Referring to
Returning to
After learning performance characteristics of virus sensors 112 in a sensor array 118, sensor output of the virus sensors 112 can be weighted based on the learned performance characteristics. For example, sensor output of a virus sensor 112 that has been identified as being less accurate in detecting a virus (e.g., a whole virus, biomarker, or antibody) may be assigned a lower weight as compared to a weight assigned to sensor output of a virus sensor 112 that has been identified as being more accurate in detecting the virus. Accordingly, the diagnosis and prognosis module 110 can be configured to evaluate sensor output (i.e., sensor data 108) of individual virus sensors 112 (whole virus sensors, biomarker sensors, and/or antibody sensors) and assign weights to the sensor output based in part on the learned performance variations of the individual virus sensors 112 to generate the sensor output, and the diagnosis and prognosis module 110 can generate a probability that a virus has been detected based on the weights assigned to the sensor output of the individual virus sensors 112.
It is contemplated that the pathogen testing device 304 can be a peripheral device of the mobile computing device 302 and includes the sensor array 118 to detect a virus and a network device 306 (e.g., System on a Chip (SoC) network module) to send sensor output (i.e., sensor data 108) to the mobile computing device 302. Accordingly, the pathogen testing device 304 can be paired with the mobile computing device 302 to test for a virus. In one aspect, the testing device 304 can be paired with the mobile computing device 302 using a wireless network protocol, including, but not limited to, WI-FI, WI-FI DIRECT, Zigbee, Z-Wave, BLUETOOTH, BLUETOOTH Low Energy (BLE), NFC (Near Field Communication), cellular, and the like. In another aspect, the testing device 304 can be paired with the mobile computing device 302 using computer hardware port (e.g., USB-C port) or wired connection (e.g., network cable).
In one example configuration, a network library (e.g., BLE library) can provide a network interface for each sensor 112/114a-n in the sensor array 118 used to send sensor output to the mobile computing device 302. A network interface for a sensor 112/114a-n may allow the diagnosis and prognosis application 312 to request sensor data 108 from a sensor 112/114a-n, which can be temporarily stored in computer memory on the mobile computing device 302, and the diagnosis and prognosis application 312 can evaluate and assign a weight to the sensor data 108 as part of generating a probable diagnosis and prognosis of a virus.
The diagnosis and prognosis application 312 can output a probability that a virus has been detected along with an estimated prognosis of the virus to a display of the mobile computing device 302 (e.g., a mobile device screen), allowing a subject and/or a health care provider to view the diagnosis and prognosis. The diagnosis and prognosis application 312, in one example, can also send a diagnosis (and prognosis), via a network 310 (e.g., the Internet), to a health care provider to enable tele-health monitoring of a symptomatic subject who chooses to treat their infection at home or who is in remote and resource-limited area. Also, the diagnosis and prognosis application 312 can be configured to send a diagnosis and prognosis, via a network 310, to a health care information system 308 associated with a health care provider of the subject to store diagnosis (and prognosis) information in the health care information system 308. It is contemplated that the diagnosis and prognosis application 312 can identify subject-care instructions associated with the prognosis and a health risk status of a subject (e.g., low risk or high risk as determined via subject health records), and the subject-care instructions can be output to the display of the mobile computing device 302 to allow the subject to view the subject-care instructions. Illustratively, the subject-care instructions may be obtained from a private or public information system, and/or the subject-care instructions may be stored locally on the mobile computing device 302.
In one example, the device 402 can be a mobile device, such as a smartphone, tablet, laptop, or the like that receives sensor data from a peripheral pathogen testing device (e.g., the pathogen testing device 304 shown in
In another example, the device 402 can be a dedicated pathogen detection device (e.g., the pathogen testing device 304 shown in
In response to receiving sensor data 108 from the device 402, the diagnosis and prognosis service 408 can analyze the sensor data 108 to determine a probability that a virus has been detected and generate an estimated prognosis of the virus. The diagnosis and prognosis can be returned to the device 402, which can provide the diagnosis and prognosis to the subject (e.g., via a device display or another appropriate output). It is contemplated that the diagnosis and prognosis service 408 hosted in the service provider environment 406 can use machine learning, as described earlier, to generate a probable diagnosis and prognosis of a virus.
The computing service environment 400 may include a number of servers that are arranged, for example, in one or more server banks or computer banks or other arrangements. The servers may support the service provider environment 400 using hypervisors, virtual machine monitors (VMMs) and other virtualization software. The various processes and/or other functionality hosted in the service provider environment 400 may be executed on one or more processors that are in communication with one or more memory modules.
The computing service environment 400 may include a number of data stores used to store sensor data 108 and other data related to a subject and a virus. A data store may refer to any device or combination of devices capable of storing, accessing, organizing and/or retrieving data, which may include any combination and number of data servers, relational databases, object oriented databases, cluster storage systems, data storage devices, data warehouses, flat files and data storage configuration in any centralized, distributed, or clustered environment. The storage system components of the data store may include storage systems such as a SAN (Storage Area Network), cloud storage network, volatile or non-volatile RAM, optical media, or hard-drive type media.
API calls, procedure calls, or other network commands that may be made in relation to the diagnosis and prognosis service 408 and other services included in the service provider environment 406 and may be implemented according to different technologies, including, but not limited to, Representational state transfer (REST) technology or Simple Object Access Protocol (SOAP) technology. REST is an architectural style for distributed hypermedia systems. A RESTful API (which may also be referred to as a RESTful web service) is a web service API implemented using HTTP and REST technology. SOAP is a protocol for exchanging information in the context of Web-based services.
Networks used by the computing service environment 400 may include any useful computing network, including an intranet, the Internet, a local area network, a wide area network, a wireless data network, or any other such network or combination thereof. Components utilized for such a system may depend at least in part upon the type of network and/or environment selected. Communication over the network may be enabled by wired or wireless connections and combinations thereof. While
As in block 1020, weights can be assigned to the sensor output of individual sensors in the sensor array based in part on characteristics of the individual sensors to detect the response signature associated with the pathogen. In one example, a sensor dataset can be created that includes the sensor output linked to sensor identifiers for the sensors in the sensor array, and the sensor dataset can be input to a machine learning model trained to: (i) evaluate the sensor output of the individual sensors, (ii) assign weights to the sensor output based in part on type or function characteristics of the individual sensors to detect the response signature associated with the virus, and (iii) generate a probability whether the virus has been detected based on the weights assigned to the sensor output.
In one example, the machine learning model can further evaluate the sensor output of the individual sensors to generate a probability of a stage of infection of the virus in a subject, which can include a probability of a past infection of the pathogen in the subject. In one example, baseline health data can be obtained for a subject (e.g., by sending a request for the baseline health data to a remote health data repository which stores the baseline health data for the subject) and the baseline health data can be used as an additional feature in a sensor dataset evaluated by the machine learning model to generate an estimated prognosis of the pathogen.
Alternatively, or in addition to, the machine learning model can be trained in part to evaluate the sensor output of individual virus sensors identified by the sensor identifiers and assign weights to the sensor output based in part on learned performance variations of the individual virus sensors to generate the sensor output, and generate a probability whether the pathogen has been detected based on the weights assigned to the sensor output of the individual virus sensors. The learned performance variations of the individual virus sensors can be variations of current-voltage characteristics (I-Vs) among the individual virus sensors.
As in block 1030, a determination can be made whether the virus has been detected based on the weights assigned to the sensor output of the individual sensors, and as in block 1040, an indication whether the virus has been detected can be output to an output device (e.g., a display device, an LED indicator, and the like). Also, in one example, an estimated prognosis of the virus can be output to a device display to allow a subject to view the prognosis, and/or the estimated prognosis can be sent to a health care information system associated with a health care physician of the subject. In some examples, patient-care instructions associated with the prognosis of the pathogen and the baseline health data for the subject can be identified, and the patient-care instructions can be output to the device display to allow the subject to view the patient-care instructions.
The memory device 1120 may contain modules 1124 that are executable by the processor(s) 1112 and data for the modules 1124. In one example, the memory device 1120 can include a diagnosis and prognosis module, and other modules, as can be appreciated. The modules 1124 may execute the functions described earlier. A data store 1122 may also be located in the memory device 1120 for storing data related to the modules 1124 and other applications along with an operating system that is executable by the processor(s) 1112.
Other applications may also be stored in the memory device 1120 and may be executable by the processor(s) 1112. Components or modules discussed in this description may be implemented in the form of software using high-level programming languages that are compiled, interpreted or executed using a hybrid of the methods.
The computing device 1110 may also have access to I/O (input/output) devices 1114 that are usable by the computing device 1110. For example, the computing device 111 can include a display screen 1130. Networking devices 1116 and similar communication devices may be included in the computing device 1110. The networking devices 1116 may be wired or wireless networking devices that connect to the internet, a LAN, WAN, or other computing network.
The components or modules that are shown as being stored in the memory device 1120 may be executed by the processor(s) 1112. The term “executable” may mean a program file that is in a form that may be executed by a processor 1112. For example, a program in a higher level language may be compiled into machine code in a format that may be loaded into a random access portion of the memory device 1120 and executed by the processor 1112, or source code may be loaded by another executable program and interpreted to generate instructions in a random access portion of the memory to be executed by a processor. The executable program may be stored in any portion or component of the memory device 1120. For example, the memory device 1120 may be random access memory (RAM), read only memory (ROM), flash memory, a solid-state drive, memory card, a hard drive, optical disk, floppy disk, magnetic tape, or any other memory components.
The processor 1112 may represent multiple processors and the memory device 1120 may represent multiple memory units that operate in parallel to the processing circuits. This may provide parallel processing channels for the processes and data in the system. The local communication interface 1118 may be used as a network to facilitate communication between any of the multiple processors and multiple memories. The local communication interface 1118 may use additional systems designed for coordinating communication such as load balancing, bulk data transfer and similar systems.
While the flowcharts presented for this technology may imply a specific order of execution, the order of execution may differ from what is illustrated. For example, the order of two more blocks may be rearranged relative to the order shown. Further, two or more blocks shown in succession may be executed in parallel or with partial parallelization. In some configurations, one or more blocks shown in the flow chart may be omitted or skipped. Any number of counters, state variables, warning semaphores, or messages might be added to the logical flow for purposes of enhanced utility, accounting, performance, measurement, troubleshooting or for similar reasons.
Some of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more blocks of computer instructions, which may be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which comprise the module and achieve the stated purpose for the module when joined logically together.
Indeed, a module of executable code may be a single instruction, or many instructions and may even be distributed over several different code segments, among different programs and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices. The modules may be passive or active, including agents operable to perform desired functions.
The technology described here may also be stored on a computer readable storage medium that includes volatile and non-volatile, removable and non-removable media implemented with any technology for the storage of information such as computer readable instructions, data structures, program modules, or other data. Computer readable storage media include, but is not limited to, a non-transitory machine readable storage medium, such as RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other computer storage medium which may be used to store the desired information and described technology.
The devices described herein may also contain communication connections or networking apparatus and networking connections that allow the devices to communicate with other devices. Communication connections are an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules and other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. A “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example and not limitation, communication media includes wired media such as a wired network or direct-wired connection and wireless media such as acoustic, radio frequency, infrared and other wireless media. The term computer readable media as used herein includes communication media.
Reference was made to the examples illustrated in the drawings and specific language was used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the technology is thereby intended. Alterations and further modifications of the features illustrated herein and additional applications of the examples as illustrated herein are to be considered within the scope of the description.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more examples. In the preceding description, numerous specific details were provided, such as examples of various configurations to provide a thorough understanding of examples of the described technology. It will be recognized, however, that the technology may be practiced without one or more of the specific details, or with other methods, components, devices, etc. In other instances, well-known structures or operations are not shown or described in detail to avoid obscuring aspects of the technology.
Although the subject matter has been described in language specific to structural features and/or operations, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features and operations described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. Numerous modifications and alternative arrangements may be devised without departing from the spirit and scope of the described technology.
This application claims priority to U.S. Provisional Application No. 62/926,376 filed Oct. 25, 2019 and U.S. Provisional Application No. 63/021,605 filed May 7, 2020, which are each incorporated herein by reference.
This invention was made with government support under grant no. 1931100 awarded by the National Science Foundation. The government has certain rights in the invention.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US20/57384 | 10/26/2020 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 62926376 | Oct 2019 | US | |
| 63021605 | May 2020 | US |
