Barcoded medical test results reporting

Abstract

Systems and methods for detecting an analyte in a sample are disclosed. According to embodiments, the system may be operable to amplify the analyte and measure a signal related to the amount of the analyte. The system may be configured to display a dynamically generated barcode for communicating test results to a patient, a medical professional, or an institution for analyzing pathogen transmission within a population. The barcode may be a dynamically generated matrix code, such as a QR code (e.g., a QR code presented via an LCD or other suitable display that can be customized based on test results, etc.). The system may include a housing containing a well, a receiver, a light source, and a light sensor. Further, the housing may include a processor, an interface, and a display configured to display various test-related information, such as the dynamically generated barcode.

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of and priority to U.S. Provisional Application No. 63 / 484,447, filed February 10, 2023, the contents of which are expressly incorporated herein by reference in their entirety for any and all non-limiting purposes.

[0002] The embodiments described herein generally relate to systems and methods for reporting diagnostic test results using barcodes. Various embodiments described herein are suitable for reporting diagnostic tests that determine, for example, whether a sample taken from a patient contains a pathogen, such as severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) or influenza virus. [Background technology]

[0003] Numerous diagnostic and analytical technologies have been developed to detect the presence of protein, DNA, or other suitable biomarkers, for example, associated with SARS-CoV-2. Many such technologies are designed to amplify a target analyte for a predetermined period of time and then determine whether the amount of the target analyte is detectable and / or exceeds a predetermined threshold, indicating a "positive" result. In many situations, it may be desirable to report the results of the analysis, for example, to a remote and / or central authority. For example, information indicating a "positive" or "negative" result can be delivered to a medical professional, a patient, or an institution to determine the level of pathogen transmission within a population. Currently, test results may be entered manually through a computer interface. Alternatively, diagnostic testing devices may include network connectivity to automatically report such results. However, these technologies may not be suitable for "pop-up" clinics or testing facilities where the network infrastructure may be insufficient to support a large number of connected computers or diagnostic devices. Therefore, there is a need for systems and methods for reporting diagnostic test results and collecting information about these test results.

[0004] The systems and methods described herein are well suited for "rapid" testing and test result reporting, using the near-ubiquitous user's smartphone at will, without specialized apps or settings, which can contribute significantly to curbing the spread of pathogens such as COVID-19. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 illustrates an example of a diagnostic testing device for determining the presence of one or more of various types of pathogens in a test sample and reporting the test results via a barcode according to an embodiment. [Figure 2] FIG. 2 shows an example implementation of the device shown in FIG. [Figure 3A]FIG. 3A depicts an example of data records stored on a server, each data record associated with a corresponding device and used to authenticate the device according to an embodiment. [Figure 3B] FIG. 3B illustrates an example of data communication between various entities that may be established with a verification server according to an embodiment. [Figure 4A] FIG. 4A shows an example of a QR code. [Figure 4B] FIG. 4B shows an example of a QR code. [Figure 5A] FIG. 5A shows an exemplary plot of a data signal corresponding to a positive test result according to an embodiment. [Figure 5B] FIG. 5B shows an exemplary plot of a data signal corresponding to a negative test result according to an embodiment. [Figure 6A] FIG. 6A shows an example of a message that can be displayed by a diagnostic testing device according to an embodiment. [Figure 6B] FIG. 6B shows an example of a message that can be displayed by a diagnostic testing device according to an embodiment. [Figure 7] FIG. 7 illustrates an example of a web page that may be served after scanning a device-associated barcode according to an embodiment. [Figure 8A] FIG. 8A is an example of a web page that may be provided after scanning a test result-related barcode according to an embodiment. [Figure 8B] FIG. 8B illustrates an example of test result output on a web page provided after scanning a test result-related barcode according to an embodiment. [Figure 9] FIG. 9 illustrates an example process for performing a diagnostic test, encoding the data, and generating a barcode from the encoded data according to an embodiment. [Figure 10] FIG. 10 illustrates an example process for serving a website based on data in a barcode according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0006] <Definition> Unless otherwise defined herein, scientific and technical terms used in this application shall have the meanings commonly understood by those skilled in the art. Generally, the terms and techniques used in connection with chemistry, molecular biology, cell and cancer biology, immunology, microbiology, pharmacology, and protein and nucleic acid chemistry described herein are those well known and commonly used in the art.

[0007] As used herein, the following terms have the meanings ascribed to them unless specified otherwise.

[0008] The term "including" is used to mean "including but not limited to." "Including" and "including but not limited to" are used interchangeably.

[0009] The words "a" and "an" refer to one or more unless otherwise specified.

[0010] "About" means an amount, level, value, number, frequency, percentage, dimension, size, amount, weight, or length that varies by 30, 25, 20, 15, 10, 9, 8, 7, 6, 5, 4, 3, 2, or 1% relative to a reference amount, level, value, number, frequency, percentage, dimension, size, amount, weight, or length. In any embodiment discussed in connection with a numerical value used with the term "about," it is specifically contemplated that the term about can be omitted.

[0011] Unless the context requires otherwise, throughout this specification and claims, the word "comprise" and variations thereof, such as "comprises" and "comprising," are to be interpreted in their open, inclusive sense, i.e., "including but not limited to."

[0012] "Consisting of" means including and limited to what follows the phrase "consisting of." Thus, the phrase "consisting of" indicates that the listed elements are required or required, and that no other elements may be present.

[0013] "Consisting essentially of" means including any elements listed after the phrase, and may further include, but is not limited to, other elements that do not interfere with or contribute to the operation or function specified herein for the listed elements. Thus, the phrase "consisting essentially of" indicates that the listed elements are essential or required, but that other elements are optional and may or may not be present depending on whether they affect the operation or function of the listed elements.

[0014] References throughout this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the invention. Thus, the appearances of the phrase "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0015] As used herein, the term "sample" refers to a composition containing an analyte. A sample may be heterogeneous, containing a variety of components, or homogeneous, containing a single component. In some cases, a sample may be naturally occurring, biologically derived, and / or artificially produced. Furthermore, a sample may be in its native or denatured form.

[0016] In certain embodiments, the sample is a biological sample. In some cases, the sample may be a single cell (or the contents of a single cell) or multiple cells (or the contents of multiple cells), a saliva sample, a mucus sample, a blood sample, a tissue sample, a skin sample, a urine sample, a water sample, and / or a soil sample. In some cases, the sample may be from a living organism, such as a eukaryote, a prokaryote, a mammal, a human, yeast, and / or bacteria, or the sample may be from a virus. In some embodiments, the sample may be a food or beverage product. In some embodiments, the sample may be a swab of a surface, e.g., a swab of a food preparation surface or container. Biological samples include, but are not limited to, tissues, cells, and biological fluids obtained from a subject. For example, biological samples include, but are not limited to, blood and fractions or components of blood, including serum, plasma, or lymph, saliva, nasal fluid, etc. In certain embodiments, the biological sample is a blood sample, serum sample, saliva sample, mucus sample, tissue sample, skin sample, or urine sample. In one embodiment, the biological sample contains virus or protein molecules from a test subject. The biological sample may be a peripheral blood leukocyte sample isolated by conventional means from a subject. In certain embodiments, the biological sample is selected from the group consisting of serum, blood, salivary secretions (e.g., saliva), lacrimal secretions (e.g., tears), respiratory secretions (e.g., mucus), nasal fluid, nasal swabs, oral swabs, mucus samples, and intestinal secretions (e.g., mucus).

[0017] As used herein, the term "analyte" refers to any molecule or compound to be detected as described herein. Suitable analytes include, but are not limited to, small chemical molecules and / or biological molecules, such as environmental molecules, clinical molecules, chemicals, and pollutants. More specifically, such chemical molecules and / or biological molecules include, but are not limited to, pesticides, insecticides, toxins, therapeutic drugs and / or drugs of abuse, hormones, antibiotics, antibodies, organic materials, proteins (e.g., enzymes, immunoglobulins, and / or glycoproteins), nucleic acids (e.g., DNA and / or RNA), lipids, lectins, carbohydrates, whole cells (e.g., prokaryotic cells such as pathogenic bacteria and / or eukaryotic cells such as mammalian tumor cells), viruses, spores, polysaccharides, glycoproteins, metabolites, cofactors, nucleotides, polynucleotides, transition-state analogs, inhibitors, nutrients, electrolytes, growth factors, and other biological and / or non-biological molecules, as well as fragments and combinations thereof. Some analytes described herein may be proteins such as enzymes, drugs, cells, antibodies, antigens, cell membrane antigens, and / or receptors or their ligands (e.g., neuroreceptors or their ligands, hormone receptors or their ligands, nutrient receptors or their ligands, and / or cell surface receptors or their ligands). In certain embodiments, the analyte is an infectious or pathological agent, such as, for example, a bacterium, a virus, a yeast, or a fungus.

[0018] As used herein, the term "protein" refers to proteins, polypeptides, oligopeptides, peptides, and analogs, including proteins containing unnatural amino acids and amino acid analogs, and peptidomimetic structures. The term "protein" also refers to proteins, polypeptides, oligopeptides, peptides, and analogs.

[0019] <Detailed explanation> Epidemics, pandemics, and other periods of widespread infection throughout a population may prompt health agencies, government agencies, and other types of institutions and organizations to monitor infection rates. Diagnostic testing instruments may be available for rapid, mass testing throughout geographically dispersed populations. To provide accurate information about infection rates and make informed recommendations or decisions based on such information, entities must be confident that they receive authentic and reliable reports of test results. As such, collecting and compiling test results from such geographically dispersed laboratories poses technical considerations and challenges. For example, entities collecting and compiling test results from diagnostic testing instruments need a communication channel to convey information with sufficient indicators of authenticity and reliability.

[0020] Test results can be reported and received using publicly available communications infrastructure, such as the global Internet. However, enabling diagnostic testing devices to provide results over electronic communications networks, such as the Internet, can increase the cost and complexity of designing such devices due to the additional hardware (e.g., wired and wireless interfaces) and programming (e.g., network protocols) involved. Even if such additional hardware and programming are provided, other technical challenges may make wired or wireless communication means unsuitable for reporting test results in some scenarios. For example, a large fleet of diagnostic testing devices may be deployed in the same location for high-volume, high-throughput testing of patients. The use of wired technologies (e.g., Ethernet, etc.) may be undesirable or unfeasible given the lack or limited availability of access points to the communications network. The use of wireless technologies (e.g., cellular, Wi-Fi, Bluetooth, etc.) may be undesirable due to radio interference caused by devices being in close proximity to one another. Other technical requirements may make certain wireless technologies an undesirable solution for reporting test results from diagnostic testing devices in some scenarios. For example, some short-range communication standards, such as Bluetooth, may require a pairing process to be successfully completed before information can be exchanged between devices, which introduces additional complexity into the process of reporting test results (e.g., if the pairing process needs to be performed for each report transmission or if the pairing state needs to be maintained for multiple report transmissions).

[0021] Furthermore, when reporting test results using publicly available communication channels such as the Internet, a mechanism is needed to establish the authenticity of reported test results. In other words, a mechanism is needed to distinguish authentic results from noise (e.g., false reports, distorted reports, etc.). Furthermore, confidence in the underlying reports provided may depend on knowing that the diagnostic testing device is operating correctly (e.g., not providing false positives and / or false negatives). Therefore, confidence in the reliability of the data can be maintained by including in the reported test results information indicative of the device's operational status (e.g., information indicating the device's "health"). Such information may be useful in determining whether the diagnostic testing device is operating properly and, therefore, the reliability of test results received from that device. However, providing sufficient indicators of authenticity and reliability is not straightforward in all scenarios. Constraints associated with diagnostic testing instruments can pose technical challenges to presenting the test results in a manner that allows entities receiving the reported test results to distinguish and redact valid test reports from invalid ones. As an example, a given form factor (e.g., a preferred or required form factor) may result in a diagnostic testing device with a relatively small footprint and limited hardware and / or computational capabilities. As such, equipping the diagnostic testing device to use existing technological means, such as digital signatures or public key infrastructure, to enable authentication of reported test results may not be desirable or feasible given the preferred or required form factor, hardware, and / or computational constraints. Furthermore, including additional information about the operational status of the diagnostic testing device increases the size of the reporting payload. Therefore, a mechanism is needed that allows for efficient reporting of test results from a distributed population of testing stations with sufficient indicators of authenticity and reliability.

[0022] In consideration of the technical challenges discussed above, techniques are described herein for a visual means for providing test results from a geographically distributed population of diagnostic testing devices to a remotely located entity that collects and compiles those test results. The techniques described herein leverage the existing technological capabilities of computing devices to facilitate the transmission of test results from the diagnostic testing devices to those entities. The visual means for communicating test results includes dynamically generated barcodes, such as two-dimensional (2D) barcodes or matrix codes, that are configured, when scanned by a computing device, to cause the computing device to transmit information, including the test results, to the remotely located entity. The dynamically generated barcode configuration leverages the inherent capabilities of computing devices used to scan and process barcodes, facilitating the transmission of test results and additional information encoded in the barcode without requiring special programming by those computing devices.

[0023] However, using visual means to report test results with sufficient indications of authenticity poses additional technical challenges. As noted above, the form factor of a diagnostic testing device can constrain the device's ability to output visual information. For example, limited screen display size can constrain the amount of information that can be presented at any given time. As such, one technical challenge arising from using visual means to provide test results with sufficient indications of authenticity and reliability arises from the maximum size of a barcode (e.g., a matrix barcode) that can be presented on the screen display. In other words, the amount of information that can be stored in a barcode can depend on the size of the barcode used. The storage space available in the barcode can also depend on the level of error correction employed. A lower level of error correction may allow for a larger payload, but increases the likelihood of errors during scanning and / or decoding. A higher level of error correction may reduce the likelihood of errors, but also reduces the size of the payload due to more available storage space being used for error correction information. Additionally, the screen display may need to provide sufficient resolution (e.g., a minimum number of pixels per barcode unit) to successfully and properly read the barcode. For example, some matrix barcodes (e.g., QR Code®) consist of a grid of black and white squares (barcode units). Sufficient resolution may include a 4x4 pixel grid for each barcode unit / module (e.g., black or white square). Thus, an nxn (or nxm) pixel display screen limits the size of any presented barcode. These technical considerations represent a trade-off between the amount of information that can be stored in a barcode (e.g., a matrix code) and the size of the display screen, the number of display screen pixels used per barcode unit, and the level of error correction employed. These challenges can be exacerbated when the barcode shares a display with other information (e.g., instructions, messages, control options, etc.).Such additional information can further limit the size of the barcode for a given size screen display and the amount of information that may be stored in that barcode.

[0024] The techniques described herein address the above technical challenges, providing dynamically generated barcodes (e.g., matrix codes) with sufficient resolution and error correction to minimize errors in transmission and decoding, with sufficient indications of authenticity and authenticity. The techniques described below may be employed to maximize the amount of information that may be conveyed through visual means, taking into account constraints or limitations imposed by diagnostic testing devices that use visual means to present test results. As described below, such techniques include the structure of the payload containing the information to be reported, accompanying information used to authenticate the reported information, encoding schemes used to encode such information, and mechanisms used to trigger computing devices to facilitate the transmission of such information.

[0025] The technology described herein is particularly suited for efficiently communicating the results of diagnostic tests to determine whether a patient has a viral or bacterial infection (e.g., COVID-19, influenza, respiratory syncytial virus (RSV), SARS, etc.) to healthcare providers, patients, and / or government agencies to determine the level of pathogen transmission in a population. For example, as various tests (e.g., PCR, loop-mediated isothermal amplification, antigen tests, e.g., rapid antigen tests, etc.) become available to diagnose COVID-19 infection, it is desirable to disseminate information about the test results to various entities (e.g., government agencies, healthcare institutions, patients, patients' relatives, etc.) to determine various safety protocols and approaches to reducing pathogen transmission in a population. However, due to privacy concerns, test providers and government agencies often do not communicate personal patient-related information, such as the patient's name, address, age, phone number, and accompanying medical conditions. Accordingly, the present disclosure describes systems and methods for performing a diagnostic test using a diagnostic testing device, dynamically generating a barcode, and displaying the dynamically generated barcode to a testing service provider. Additionally, the present disclosure describes providing test results to patients and / or government or health agencies (e.g., where required by law to report test results). Additionally, test results may be provided with an indicator of authenticity, which may prevent third parties from altering test results or transmitting false test results. Additionally, in some cases, test results may only be provided to authorized entities.

[0026] In various embodiments described herein, the test results are performed by a fluorescence of loop primers during self-quenching loop-mediated isothermal amplification (FLOS-LAMP) device. The device may be configured to determine the test results, encode the test results, communicate the test results over a network, and / or provide device authentication information when communicating the test results. Additionally, the device may provide the test results in the form of a barcode (e.g., a matrix barcode such as a QR code) that, when scanned by a scanning device (e.g., a smartphone), allows a user (or testing service provider) to transmit the test results to a remotely located entity, such as a "test server" configured to store the test results in a data store (e.g., one or more databases) associated with the user, the diagnostic testing device that performed the test, and / or a particular testing facility. In some cases, the "test server" may be configured to disseminate information related to the test results to government agencies and / or health authorities (e.g., if required by law). The "test server" may also be configured to (e.g., automatically) generate a document indicating the results of the test and provide such a document to the patient as proof of a positive or negative result. Such documentation may be provided to the patient using electronic means, such as email or text message, and / or physical means, such as a hardcopy document sent by mail. Reports of diagnostic test results may also be provided to other health-related systems, such as electronic health record (EHR) systems to update the EHR.

[0027] In various embodiments, the test server may be configured to receive and accept test results only from known test devices. For example, the report payload may include the test results along with the serial number of the diagnostic test device that performed the test. The test server may compare the transmitted serial number to a database of serial numbers corresponding to various diagnostic test devices, and if the transmitted serial number matches one of the serial numbers in the database, the test server may accept the test result and process the test result as described herein. For example, the test server may store the test results and provide a web portal (e.g., via a website, web page, etc.) based on the received test results, and the test server may disseminate the test results to government agencies and / or health organizations, etc. In some cases, if the transmitted serial number (or other identifier) ​​does not match any of the serial numbers in the database and / or if the test server cannot identify / verify the test device, the test server may not accept (e.g., ignore, downplay, delete) the test result. In some cases, if the result is not accepted, the test server may send an error message to the user who submitted the test result to the test server by scanning a barcode provided by the diagnostic test device. The test server may also maintain information indicating the geographic locations (e.g., addresses, cities, states, regions, countries, etc.) where diagnostic testing devices are deployed. Thus, by associating reported test results with their corresponding diagnostic testing devices, an entity may identify geographic regions or specific locations with relatively high or low infection rates based on the test results reported by diagnostic testing devices deployed in those regions or locations. By associating reported test results with their corresponding diagnostic testing devices, an operator may also detect potentially malfunctioning diagnostic testing devices by identifying anomalies in the test reports provided by one testing device compared to other diagnostic testing devices deployed in the same geographic region or at the same location.

[0028] Furthermore, the test server may be configured to authorize various entities to access some (or all) of the test results based on the data access permissions of these entities. Various entities may have different authentication mechanisms, including secure passwords, tokens, codes, etc., for authenticating with the test server configured to receive the test results. For example, users and medical professionals may be authenticated with the test server and authorized to view test-related information and personal user-related information, while government agencies may be authenticated with the test server and authorized to receive only test-related information with personal user-related information removed. Furthermore, a testing service provider may be authenticated with the test server to send test results but may not be authorized by the test server to view or modify the test results or view personal user-related information.

[0029] FIG. 1 illustrates an example of a diagnostic testing device 100 (e.g., a FLOS-LAMP device) operable to amplify an analyte and measure a signal related to the amount of the analyte, according to an embodiment. The device 100 is further configured to dynamically generate and display a barcode (e.g., a matrix barcode, such as a QR code) for visually communicating test results to a patient, a medical professional, or an institution for analyzing pathogen transmission within a population. In some cases, the dynamically generated barcode may be a matrix barcode, such as a QR code. Other types of barcodes, 2D barcodes, or matrix barcodes may be employed and configured using the techniques described herein. Examples of other types of 2D and matrix barcodes include AR Code, Aztec Code, Data Matrix, DotCode, EZCode, high-volume color barcode, JAB Code, MaxiCode, PDF417, Qode, ShotCode, and SPARQCode. The dynamically generated barcode may be presented via an LCD or other display suitable for presenting dynamically generated barcodes. The device 100 includes a housing 102 containing a well 130, a receiver 120, a light source 152, and a light sensor 154. Additionally, the housing 102 includes a processor 140, an interface 160, and a display 170 configured to display various test-related information, such as a dynamically generated barcode 180 as described herein. Additionally, the housing 102 includes an optional static barcode 190 (e.g., a printed, engraved, or other immutable barcode) attached to a side of the housing 102 and uniquely associated with the device 100 (e.g., encoding a serial number, fixed device parameters, etc.). The static barcode 190 may also be a 2D barcode or matrix barcode, such as a QR code. The static barcode 190 may be scanned to verify possession of the diagnostic test device and / or to verify that the diagnostic test device is authentic (e.g., not a counterfeit or copy device).As such, static barcode 190 may be scanned to initiate an authentication procedure to verify that an entity (e.g., a particular user, a testing facility, and / or the like) is authorized to possess the device. Static barcode 190 may also be scanned to identify and record the geographic location of the diagnostic testing device. In some cases, information encoded in static barcode 190 (e.g., information identifying device 100) may also be encoded in dynamically generated barcode 180. Housing 102 of device 100 is configured to accept reaction tube 110 containing a sample including an analyte. Test-related information may include the type of test to be performed. In various embodiments, the username and / or user identification number may be verified by the testing service provider prior to running the test and / or during sample collection from the user.

[0030] In various embodiments, the well 130 may be located within a compartment of the housing 102 that can be closed via an optional cover 104 (also referred to herein as a lid 104). The cover 104 may be connected to the housing 102 via a connecting element 103, which may be a hinge, a living hinge, or any other suitable connecting element configured to connect the cover 104 to the housing 102, such that the cover 104 can close or open the compartment of the housing 102.

[0031] In various embodiments, the well 130 is configured to receive a reaction tube 110 containing a sample including an analyte. The well 130 may be any suitable opening for receiving at least a portion of the reaction tube 110. In exemplary embodiments, the well 130 may have a shape substantially similar to the shape of at least a portion of the reaction tube 110. In exemplary embodiments, the well 130 includes at least a tube holder and an opening through which the reaction tube 110 can be inserted. In exemplary embodiments, the well 130 includes an enclosure having walls, and the walls of the enclosure are configured to abut (at least partially) the walls of the reaction tube 110.

[0032] In an exemplary embodiment, reaction tube 110 forms an enclosure for containing a sample including an analyte, which may include, for example, a liquid. In an exemplary embodiment, well 130 may include one or more windows configured to transmit light from light-emitting source 152. Light source 152 is configured to emit light that, when transmitted through an analyte, excites analyte-emission light that can be detected by light sensor 154. Information regarding the detected analyte-emission light can be analyzed by processor 140 to determine whether the analyte contains a pathogen (e.g., a "positive" test result) or does not contain a pathogen (e.g., a "negative" test result).

[0033] The processor 140 is configured to be operatively coupled to the receiver 120, the light emitting source 152, and the light sensor 154. In various embodiments, the processor 140 is configured to exchange data with the receiver 120, the light source 152, and the light sensor 154. For example, the receiver 120 may send data 116 to the processor 140, which may be used by the processor 140 to determine operating parameters of the light source 152 and the light sensor 154. In various embodiments, the processor 140 may adjust various parameters of the emitted light (e.g., the light wavelength, the intensity of the light, the duration for which the pulses of light are emitted, the number of pulses of light emitted, or any other characteristic associated with the emitted light). Additionally, the processor 140 is configured to activate the light sensor 154 and receive data from the light sensor 154.

[0034] In various embodiments, processor 140 may be, for example, a general-purpose processor, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a digital signal processor (DSP), and / or the like. Processor 140 may be configured to retrieve data from and / or write data to memory. Memory may be, for example, random access memory (RAM), a memory buffer, a hard drive, a database, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), read-only memory (ROM), flash memory, a hard disk, a floppy disk, cloud storage, and / or the like.

[0035] The processor 140 and associated memory are communicatively coupled to the light source 152 and / or the detector 154 and are configured to control and perform diagnostic tests by operating various components of the device 100. The processor 140 and associated memory may be operable to receive, process, and / or record signals related to the concentrations of analytes and / or controls. The processor 140 and / or associated memory may be configured to determine whether the sample contained within the reaction tube 110 is “positive” or “negative” for one or more analytes. This is in accordance with various methods described in more detail in Provisional Patent Application No. 63 / 275,758, filed November 4, 2021, entitled “System and Method for Detecting the Presence of an Analyte in a Sample,” and Patent Application No. 17 / 666,338, filed February 7, 2022, entitled “System and Method for Detecting the Presence of an Analyte, Such as SARS-CoV-2, in a Sample,” both of which are incorporated herein by reference in their entireties. Provisional Patent Application No. 63 / 275,758 also provides further details of the device 100.

[0036] While FIG. 1 shows a block diagram of an example diagnostic testing device 100, FIG. 2 shows an example diagnostic testing device 200, which may be an exemplary implementation of device 100. Device 200 includes a housing 202 and a cover 204 configured to cover tube 210 during assay testing. Cover 204 may be attached to housing 202 via hinge element 203 (or any other suitable element). Device 200 further includes wells 230, a display 270, an interface element 260, a dynamically generated barcode 280 displayed on display 270, and a static barcode 290, typically affixed or imprinted on the side of housing 202. In the example shown in FIG. 2, dynamically generated barcode 280 is a matrix barcode, specifically a QR code. Similarly, in the example shown in FIG. 2, static barcode 290 is also a matrix barcode, specifically a QR code. In various embodiments, cover 204, hinge element 203, well 230, display 270, interface element 260, and barcodes 280 and 290 of device 200 correspond to the respective cover 104, connection element 103, well 130, display 170, interface 160, and barcodes 180 and 190 of each device 100. Additionally, as shown in FIG. 2, reaction tube 210 is shown inserted into well 230 and corresponds to reaction tube 110 shown in FIG. 1. As described herein, the form factor of device 200 and its display 170 may constrain the size of dynamically generated barcode 280, which in turn constrains the size of the payload encoded by barcode 280.

[0037] In various embodiments, as described above, device 100 is configured with an associated static barcode 190. Static barcode 190 may include information related to device 100. For example, static barcode 190 may include machine identification information, such as the device's serial number. In one implementation, the serial number may be encoded using 24 bits. The serial number associated with device 100 is assigned to the device at the time of manufacture and may include a combination of several decimal digits (e.g., 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 decimal digits, etc.) that uniquely identify the device. Additionally, static barcode 190 may indicate additional information related to device 100, such as the type of device 100, the version of device 100, and a reporting payload format associated with device 100 (e.g., an indication of the data content and / or structure of the data output by dynamic QR code 280). In some cases, static barcode 190 includes authentication information associated with device 100. For example, such authentication information may include an authentication message that can be used to generate a hash-based (or keyed-hash) machine authentication code (HMAC) for authenticating data associated with test results. The HMAC may be generated based on a secret, private key associated with device 100, as described further below in connection with FIG. 3A. The HMAC may be used to verify that data associated with test results was obtained by device 100. The HMAC value protects the integrity and authenticity of data generated by device 100 by allowing a verifier to authenticate the device. Typically, device 100 firmware may contain a private key known only to the entity that authenticates received test reports (e.g., the entity operating the test server). In some embodiments, bytes of a private key stored in the device firmware of a diagnostic test device may be concatenated with bytes of a device-specific identifier (e.g., device serial number) to obtain the key used to generate the HMAC. In some embodiments, the private key bytes may precede the device-specific identifier bytes when concatenated.In some embodiments, when concatenated, the unique identifier bytes may precede the secret key bytes. A cryptographic hash of the concatenated bytes may be obtained, for example, using a cryptographic hash function. Any suitable cryptographic hash algorithm may be employed, for example, a Secure Hash Algorithm (SHA) such as MD5, SHA-256, SHA-512, or any other cryptographic hash function. The result of the cryptographic hash algorithm may be used as a key for an HMAC generation algorithm. An HMAC may be generated over a payload (e.g., a message) containing information related to the diagnostic testing device, for example, its unique identifier (e.g., serial number), type, version, reporting format, etc. Any industry-standard algorithm suitable for hashing the payload may be employed. Generating the HMAC may result in a standard 32-byte HMAC. The HMAC may be truncated before being encoded for storage in the static barcode. The payload, along with the truncated HMAC, generates the actual content to be encoded into the QR code. On the server side (e.g., a testing server), the process may be repeated to authenticate and verify the diagnostic testing device. If the truncated HMAC calculated on the received payload excluding (i.e., not including) the truncated HMAC matches the transmitted truncated HMAC, the diagnostic testing device may be authenticated and verified at the server side. A similar process may be used to generate a truncated HMAC for the payload of a dynamically generated barcode 180, as described herein.

[0038] FIG. 3A shows an exemplary diagram for authenticating various diagnostic testing devices 300-1 through 300-N via testing server 320. For example, exemplary testing server 320 includes a processor for processing data received by testing server 320 (e.g., the processor may be configured to decode the data and compare the received data to data stored in a database associated with the processor). In an exemplary embodiment, testing server 320 may be associated with database 321 that includes data that may be stored as column entries 321-1 through 321-N. In this example, each column entry includes an associated authentication secret key, Secret Key 1 through Secret Key N. In various embodiments, secret keys Secret Key 1 through Secret Key N are used to generate an associated HMAC as described herein. In an exemplary embodiment, the HMAC may be generated based on the serial number of the device (e.g., device 300-1) and a secret key, Secret Key 1, associated with device 300-1. As shown in FIG. 3A, devices 300-1 through 300-N include respective secret keys Secret Key 1 through Secret Key N and device-associated serial numbers. Secret Key 1 through Secret Key N and their respective serial numbers can be used by these devices to generate HMAC 1 through HMAC N, which can be used for authentication purposes by test server 320. Rather than separately storing individual secret keys for each diagnostic test device, a global secret key may be employed as described herein. The global secret key may be stored in firmware for each diagnostic test device and known to a test server (e.g., test server 320) configured to authenticate the diagnostic test device. The diagnostic test devices and test server may use the global secret key to generate respective HMACs for each individual diagnostic test device 300-1 through 300-N, for example, using the serial numbers of the diagnostic test devices, as described herein.In this way, even if a global secret key is employed for all devices, the HMAC may be bound to a specific diagnostic testing device by using the device's serial number used to generate the key for the HMAC algorithm.

[0039] Reporting test results generated by a diagnostic test device (e.g., device 300-1) to test server 320 can be performed using the following process: First, device 300-1 performs a diagnostic test and obtains the test results. The diagnostic test device generates a payload containing the test results (e.g., including the device serial number) as described herein. The diagnostic test device calculates an HMAC (e.g., HMAC1) of the payload as described herein based on a secret key (e.g., Secret Key 1) and the device serial number. The diagnostic test device truncates the HMAC as needed based on the available storage space of the barcode (e.g., a matrix barcode such as a QR code). The diagnostic test device encodes the payload and the truncated HMAC using an appropriate encoding scheme as described herein to fit the encoded payload and the encoded truncated MAC into the available storage space of the barcode. The diagnostic test device generates a uniform resource locator (URL) using the encoded payload and the encoded truncated HMAC. The address of the URL is the address of the test server. The diagnostic testing device appends the encoded payload and the encoded truncated HMAC to the address of the testing server in a URL. The diagnostic testing device displays the dynamically generated barcode on its display screen. A computing device (e.g., a mobile phone) equipped with an appropriate scanning device (e.g., a camera) scans the displayed barcode. The computing device may be configured (e.g., programmed) to recognize that a barcode has been scanned and to decode the information in the barcode based on the scan. The computing device may also be configured (e.g., programmed) to automatically navigate to a URL decoded from the scanned barcode. Thus, when the computing device decodes the scanned barcode to find a URL, the computing device may automatically navigate to the address indicated in the URL by generating an HTTP request using the decoded URL.The HTTP request may include both the address of the inspection server and encoded information appended to the address of the URL. By appending the encoded information to the URL, the barcode is configured to cause (e.g., trigger) the scanning device to automatically provide (e.g., transmit, send, upload) an encoded payload containing the inspection results and an encoded truncated HMAC to an inspection server (e.g., inspection server 320) via an HTTP request generated based on (e.g., in response to) the scan. Upon receiving the HTTP request containing the URL, the inspection server can perform an authentication procedure to authenticate the reported inspection results. As described herein, the inspection server can generate a truncated HMAC for the encoded payload in the URL (e.g., using a private key and device serial number obtained from the encoded payload). The inspection server can compare the received truncated HMAC with the generated truncated HMAC. If the two HMACs match, the inspection server can determine that the received report is authentic and valid. If not, the inspection server can discard the received report and report an error via an appropriate interface (e.g., a web page, a smartphone application, etc.). The test server can store test results of received valid reports. The test server may also evaluate additional information accompanying the test results transmitted in the report to assess the operational status of the diagnostic testing device that performed the test to determine whether the received test results are reliable. For example, as described herein, the received report may include information indicating the operational status of the diagnostic testing device (e.g., various statistics about the test performed, error codes, etc.). Based on such information, the test server can determine whether the test results are reliable (e.g., true positive, true negative) or unreliable (e.g., false positive, false negative). In some embodiments, the test server may store test results determined to be reliable and discard (e.g., not store, delete, ignore) test results determined to be unreliable.In some embodiments, the test server may store test results determined to be reliable in one data store (e.g., one database) and tests determined to be unreliable in another data store (e.g., another database). In some embodiments, the test server may store the test results along with the determined measure of reliability. The test server may determine the measure of reliability of a received test result based on accompanying information indicative of the operational state of the diagnostic testing device (e.g., the current operational state during the current test and / or one or more past operational states of previously performed tests).

[0040] FIG. 3B shows a system 301 including a user 310, a testing service provider 330, a medical professional 340, and a government or health agency 350 interacting with a testing server 320. In an exemplary embodiment, the user 310 can register with the testing server 320 by providing user personal information 312, which may include the user's first and last name, address, phone, email, date of birth, race, ethnicity, medical history, place of birth, etc. In some cases, the user may select only login information when registering with the testing server 320 (e.g., a user ID, and / or user email, and / or user phone, and a password). Upon registration, the testing server 320 may provide the user 310 with an account number (or any other suitable user identification). Additionally, the user 310 may transmit at least a portion of personal user-related information 311 to the testing service provider 330. For example, the personal information 311 may include the user's first and last name, user phone, or user date of birth. In some cases, the individual user-related information 311 may be an account number associated with the user 310 (or any other user identification provided by the testing server 320). Communicating the user-related information 311 to the testing service provider 330 enables the testing service provider 330 to link the test result data with the user 310 (or user identifier), thereby enabling the testing server 320 to associate the test results with the user (or user identifier) ​​and facilitating access to the test results by the user 310.

[0041] When the user 310 performs a function for the testing service provider 330, or when the user 310 receives a barcode (e.g., a matrix code such as a QR code, such as the dynamically generated barcode 180 described above) from the testing service provider 330 generated after the performance of a diagnostic test, the user 310 can scan the barcode. The barcode may encode a link that can be automatically executed by the smartphone operating system (e.g., Android® or iOS®) as described herein and direct a web browser to a website 320 hosted by or associated with the testing server 320. The website can provide a web portal associated with the user 310 (e.g., the testing service provider 330). The web portal includes form fields, graphical user elements, etc. that facilitate the user 310 to provide user-related information 311 (e.g., testing service provider information, patient information, etc.).

[0042] Additionally, a user 310 (e.g., an individual being tested for an infectious disease) provides a test sample (e.g., a nasal swab, a throat swab, a blood sample, etc.) to a testing service provider 330. The testing service provider 330 can introduce the test sample into a reaction tube (e.g., reaction tube 110 shown in FIG. 1 ). The reaction tube 110 can contain reagents capable of amplifying an analyte if present in the test sample, and / or a dye or other suitable marker to aid in the detection of the analyte.

[0043] The testing service provider 330 may perform the test using a diagnostic device configured to display a dynamically generated barcode 380 (e.g., a matrix code such as a QR code) on a display screen (e.g., a barcode similar to or the same as the dynamically generated barcode 180 shown in FIG. 1 ). After the test is completed, the dynamically generated barcode 380 is scanned by the testing service provider 330 (or by the user 310, if the user 310 receives the dynamically generated barcode 380 from the testing service provider 330), for example, using a smartphone or other suitable device. As described herein, the barcode encodes a URL. The testing service provider 330 (or the user 310) may scan the dynamically generated barcode 380 to obtain the URL, and the smartphone operating system may automatically direct a browser application to the URL obtained from the dynamically generated barcode 380. As described herein, the URL address may be associated with a web page that provides a web portal (e.g., a reporting portal) associated with the testing service provider 330. 3B illustrates that the dynamically generated barcode 380 may optionally be displayed to the user 310 (as indicated by the dashed border around the dynamically generated barcode 380), and the user 310 may then scan the dynamically generated barcode 380, thereby transmitting data associated with the dynamically generated barcode to the testing server 320. When data associated with the dynamically generated barcode 380 is transmitted from the user 310 to the testing server 320, the data associated with the dynamically generated barcode 380 may not be communicated from the testing service provider 330 to the testing server 320. In some cases, when data associated with the dynamically generated barcode 380 is communicated to the testing server 320 by the testing service provider 330, the data associated with the dynamically generated barcode 380 may not be communicated by the user 310 to the testing server 320.

[0044] The dynamically generated barcode may encode a URL that includes parameters (also called arguments) that encode test data associated with the test performed by the diagnostic testing device, as described herein. In this manner, when a browser is directed to the URL, the server hosting the web page may receive the parameters, decode the test data, and store the information in one or more databases associated with the test server 320, thereby creating a test result data record. Additionally, a timestamp indicating the time the test result data record was created may be stored with the associated test result data record.

[0045] 3B further illustrates that user 310 may send user-related information 311 to medical professional 340, who may access the test results by authenticating with testing server 320. In an exemplary embodiment, medical professional 340 may be registered with testing server 320 and may retrieve test results for user 310 based on user-related information 311 received from user 310.

[0046] Further, as shown in FIG. 3B, a government agency 350 (or similar organization, such as a health organization, the World Health Organization, a charity, a nonprofit organization, a private organization, a group of individuals, or another individual) may be configured to query the testing server 320 for test results. The government agency 350 may also be registered with the testing server 320 and authorized to receive at least some information regarding one or more users' test results (e.g., if such authorization is granted or required by law). In one example, the government agency 350 may not have access to user personal information, but may receive information indicating individual positive / negative results and / or the overall test positivity rate within a population. For example, the government agency 350 may receive information on positive test results (or negative test results) in a given location (or within a given region) within a given time interval. For example, the government agency 350 may receive information on COVID-19 positive cases and COVID-19 negative cases in a specified city (e.g., New York City) for a given day, a given hour, or a given minute. In various embodiments, when a dynamically generated barcode (e.g., dynamically generated barcode 380) is scanned, test results associated with the dynamically generated barcode may be transmitted from the test server to a government agency (e.g., if such reporting is required by law). In this manner, the user's acquisition of test results and the reporting of test results to a government agency may be linked, reducing or eliminating reporting bias. It should be noted that if the same dynamically generated barcode 380 is scanned multiple times, the test results associated with the dynamically generated barcode 380 may not be processed multiple times. For example, if the dynamically generated barcode 380 was previously scanned and the test results associated with the dynamically generated barcode 380 were successfully processed, data obtained by scanning the dynamically generated barcode 380 again may not be processed by the test server 320 (e.g., if the dynamically generated barcode 380 is scanned a second, third, etc. time, the test server 320 may not transmit data to a government agency).However, if scanning the dynamically generated barcode 380 results in a failure of the testing server 320 to process the test results (an indication of the failure may be communicated to the user scanning the dynamically generated barcode 380 via an appropriate user interface associated with the scanning application employed by the user), the testing server 320 may be configured to accept new test results obtained by a subsequent scan of the dynamically generated barcode 380.

[0047] Returning to FIG. 1 , device 100 includes an interface 160 configured to interface with processor 140. The interface may include one or more buttons, a touchscreen, a touchpad, a joystick, or the like. For example, a particular implementation of interface 160 is illustrated in FIG. 2 by interface element 260, which may include several buttons. In one embodiment, interface 160 may allow a user to input various parameters related to a diagnostic test (e.g., interface 160 may allow a user to input the type of diagnostic test to be performed or other parameters related to the diagnostic test, such as the wavelength of light that may be emitted by light source 152 to illuminate the sample). Additionally, interface 160 may allow a user to open and close a cover of device 100, or to interact with device 100 in any other manner. For example, interface 160 may be used to select information to display via display screen 170.

[0048] In various embodiments, display screen 170 is configured to display any suitable information to the testing service provider. For example, prior to running a diagnostic test, display screen 170 may display information related to the type of diagnostic test to be run. For example, such information may be displayed to receive confirmation from the testing service provider and / or the user that the correct diagnostic test has been selected.

[0049] In various embodiments, as discussed above, the display screen 170 may further present the results of the diagnostic test encoded in a dynamically generated barcode 180 (e.g., a matrix code such as a QR code) that is not easily human-readable. In various embodiments, the dynamically generated barcode 180 may be scanned using any suitable electronic device, e.g., an electronic device including a camera, such as a smartphone. In some cases, other electronic devices including a camera or scanner may be used (e.g., a laptop, desktop, scanner, etc.). In some cases, a default camera and / or scanning app may be operable to transmit the encoded data to the test server 320 (e.g., by launching a default web browser, entering the encoded URL with arguments into the address bar, and directing the web browser to that URL). It should be noted that this may eliminate the need for special-purpose software, and the dynamically generated barcode 180 may be scanned in the same manner as any other barcode (e.g., the dynamically generated barcode 180 may be scanned using a code scanning application and / or functionality on a smartphone).

[0050] The dynamically generated barcode 180 may be any suitable barcode for encoding test-related information, including, for example, matrix codes such as QR codes and other types of 2D barcodes. For example, the dynamically generated barcode 180 may be a Model 1 or Model 2 QR code. For example, the dynamically generated barcode 180 may be a Version 1 through Version 40 QR code. For example, a Version 1 QR code has a data matrix with a size of 21 x 21 elements, a Version 2 QR code has a data matrix with a size of 25 x 25 elements, a Version 3 QR code has a data matrix with a size of 29 x 29 elements, a Version 4 QR code has a data matrix with a size of 33 x 33 elements, etc. In some cases, a Version 4 QR code may be sufficient to represent all necessary data related to the test results. Alternatively, in some cases, a Version 40 QR code may be used (a Version 40 QR code has a data matrix with a size of 177 x 177 elements). The dynamic QR code 180 can be any suitable level L (low), M (medium), Q (quartile), or H (high). For example, level L allows for 7% of the data to be recovered if the dynamic QR code 180 is damaged (or poorly scanned or captured), and level H allows for up to 30% of the data to be recovered if the dynamic QR code 180 is damaged (or poorly scanned or captured). In various embodiments, the highest level of error correction available (level H) may be used to tolerate errors in capturing the dynamic QR code 180 via an auxiliary device (e.g., a smartphone camera). The highest error correction (level H) may be selected to provide maximum robustness. As described herein, the display screen size of the diagnostic testing device and / or the resolution used for each barcode unit / module may limit the size of the barcode that may be presented on the display screen.For example, a display screen size of 150x150 pixels and a resolution of 4x4 pixels per barcode unit / module may constrain the size of any QR code to 37x37 elements or less (i.e., a 33x33 Version 4 QR code), resulting in a displayed QR code having a size of 132x132 pixels (150 pixels divided by 4 pixels per barcode unit / module equals 132 pixels). Also, as described herein, the size of the barcode (e.g., QR code) used in conjunction with a selected level of error correction may limit the amount of information that can be contained in the barcode (e.g., barcode payload). It will be understood that various display screen sizes, pixel resolutions, barcode sizes, etc. may be employed depending on a variety of factors, including, for example, the form factor (e.g., footprint) of the diagnostic testing device, cost, aesthetics, and other desired or required design considerations that affect the visual presentation capabilities of a given diagnostic testing device. As described herein, various techniques may be employed to maximize the amount of information that can be stored in dynamically generated barcodes within the constraints of a given implementation.

[0051] The selected encoding scheme may be an example of a technique that helps maximize the amount of information contained in a dynamically generated barcode (e.g., a matrix code such as a QR code). In various embodiments, the dynamically generated barcode (e.g., the dynamically generated QR code 180) may include numeric-only encoding, alphanumeric encoding, binary encoding, or kanji / kana encoding, as known in the art. In one example implementation, the dynamically generated barcode 180 may include alphanumeric encoding. As described herein, alphanumeric encoding may provide a trade-off between information density and a sufficient number of characters to represent a URL that can be used to provide test information in a visual manner with sufficient indications of authenticity and reliability. As described herein, pixel resolution (e.g., 4x4 pixels per barcode unit / module / "dot") may serve as a trade-off between the size of the diagnostic testing device's display screen and reserving sufficient space on the display screen for additional visual elements, such as borders and supporting instruction text. In some embodiments, the display screen may present only the dynamically generated barcode to maximize the size of the presented barcode. In some embodiments, the display screen may simultaneously display the dynamically generated barcode with one or more additional elements (e.g., decoration such as borders, instructions, control options, etc.), in which case the maximum size of the dynamically generated barcode is constrained by both the size of the display screen and any additional elements simultaneously presented. As described herein, barcode configurations and display screens may include various other configurations and sizes and arrangements known and used in the art.

[0052] 4A and 4B show possible examples of dynamically generated barcodes (e.g., barcode 190 or barcode 180). The example dynamically generated barcodes shown in FIGS. 4A and 4B are matrix barcodes, specifically QR codes. For example, FIG. 4A shows an example of display screen 170 including QR code 411 and additional text 413 adjacent to QR code 411. As shown, QR code 411 is a version 4 QR code. In some cases, as shown in FIG. 4B, QR code 415 may be a version 40 QR code, which may contain more information than a version 4 QR code.

[0053] A URL encoded by a dynamically generated barcode (e.g., a matrix code such as a QR code) may be generated in a manner that maximizes the size of the payload added to the URL's address (e.g., a hostname). In various embodiments, the URL includes a prefix (HTTPS: / / ) followed by a website address domain. The web address (e.g., a domain name and / or a fully qualified domain name) maximizes the size of the payload in the URL. In exemplary embodiments, a minimum number of characters may be employed for the website domain and / or top-level domain (e.g., 3 characters, 4 characters, 5 characters, 6 characters, 7 characters, 8 characters, 9 characters, 10 characters, etc.). For example, a top-level domain (i.e., a domain suffix) containing two characters may be employed. Such a domain may correspond to a country code domain (e.g., ".to", ".tw", ".uk", ".us", etc.). Similarly, a two-character domain name may be employed, resulting in a fully qualified domain name of only five characters (e.g., xx.xx) and a URL of only 13 characters (e.g., https: / / xx.xx). A payload containing the encoded test results and associated information may be appended to this URL. A single forward slash (" / ") may be used as the separator between the address and the payload in a URL, although other separators may also be used.

[0054] In some embodiments, the payload appended to the address in the URL may include information used to assist in decoding the payload received via the URL. Such information may be indicated using one or more characters. For example, a single selected character (e.g., “A” or “B” or “C” or “D”) may indicate one or more of the following: the role of the scanned barcode (e.g., whether the barcode is a dynamically generated barcode used to provide test results or whether the barcode is a static barcode used to provide information about a diagnostic testing device); the encoding character set used to encode the test results, collateral data, HMAC, etc., as described herein; an indication of the version of the scanned barcode (e.g., which QR code version); or any other information associated with the scanned barcode (e.g., the level of the barcode, etc.). Any suitable encoding character set may be employed to encode the test results, collateral data, HMAC, etc. The encoding character set may be an alphanumeric set corresponding to a particular base-n encoding. For example, for base 10 encoding, numeric characters (0-9) are used, and for base 16, hexadecimal characters such as (af) are used, corresponding to letters (0-9) and numbers (10-15), respectively. Furthermore, base 32 encoding (using all letters of the alphabet and numbers 2-7) or any other suitable base encoding (e.g., base 41 encoding, base 43 encoding, base 48 encoding, base 64 encoding, etc.) can be used. In various embodiments, for base 43 encoding, characters (0-9, A-Z, $, *, +, -, ., / , :) may be used, and for base 41 encoding, characters (0-9, A-Z, $, *, +, -, .) may be used. The encoding scheme used to encode the inspection results, accompanying data, HMAC, etc. may be selected to minimize the size of the payload added to the address in the URL.For example, if a matrix barcode (e.g., a version 4 QR code) is used to visually present test results with sufficient indication of authenticity and reliability, base 43 or base 41 encoding may be used to minimize the size of the payload.

[0055] To obtain the URL's encoded payload, the selected encoding scheme is used to encode a bit string corresponding to the test result report. The bit string, sometimes referred to as a Bit Packed Data Structure (BPDS), may be the result of a concatenation of various bit strings corresponding to the report, e.g., the test results themselves, associated information about the diagnostic tester, an HMAC, etc. This concatenated bit string, the BPDS, may represent a very large integer and is then encoded using the selected encoding scheme, thereby reducing the size of the data from a relatively long string of 1s and 0s to a relatively short string of characters in the selected encoding scheme. The BPDS may include a "core" containing the test results, information about the test run (e.g., run number, type), information about the diagnostic tester (e.g., operational status, error codes), and other information described herein.

[0056] For example, the BPDS core may include (1) a reporting payload format or version (encoded using only a few bits, e.g., 1, 2, 3, 4, 5, 6, 7, 8, 9, or 10 bits). To minimize the size of the BPDS core, only 1 or 2 bits may be used to indicate the reporting payload format or version. The reporting payload format format or version may be associated with the selected encoding scheme employed. In some embodiments, to minimize the size of the BPDS core, a minimum number of bits may be used to indicate the reporting payload format or version. In other embodiments, more bits may be used.

[0057] The BPDS Core may also include (2) an indication of the type of diagnostic testing equipment (e.g., product identifier) ​​used to perform the diagnostic test (which may also be encoded using only a few bits, e.g., 1, 2, 3, 4, 5, 6, 7, 8, 9, or 10 bits). To minimize the size of the BPDS Core, a minimal number of bits may be used to indicate the type of diagnostic testing equipment.

[0058] The BPDS core may also include (3) the serial number of the diagnostic testing device that performed the diagnostic test (which may be encoded using a few bits to a few dozen bits, e.g., 10-48 bits). In some embodiments, to minimize the size of the BPDS core, a minimal number of bits may be used to represent the serial number of the diagnostic testing device. In other embodiments, more bits may be used.

[0059] The BPDS core may include (4) a test run number that identifies the cumulative number of diagnostic tests performed by the diagnostic tester. The test run number may be persistently stored in memory of the diagnostic tester (e.g., diagnostic tester 100) and may monotonically increase each time a new sample is inserted and a new analysis is performed (i.e., each time a diagnostic test is performed). The test run number may be encoded using a few bits to several tens of bits (e.g., 10-36 bits). In some embodiments, to minimize the size of the BPDS core, a minimum number of bits may be used to represent the test run number. In other embodiments, more bits may be used.

[0060] The BPDS core may include (5) an indication of the type of test performed by the diagnostic tester. For example, the test type may be a COVID test, an influenza test, a combination COVID and influenza test, or any other suitable test (e.g., an RSV test or a strep test) that can be performed by the diagnostic tester (e.g., diagnostic tester 100). The test type indication may be encoded using a few bits (e.g., 1, 2, 3, 4, 5, 6, 7, 8, 9, or 10 bits). In some embodiments, to minimize the size of the BPDS core, a minimal number of bits may be used to indicate the test type indication. In other embodiments, more bits may be used.

[0061] In some cases, the same type of test (e.g., a COVID test) may have different subtypes (e.g., versions), and the diagnostic testing device (e.g., diagnostic testing device 100) may be configured to adjust test parameters depending on the particular version of a particular type (e.g., a particular version of a COVID test). For example, for a first type of COVID test, a first wavelength, intensity, or duration of illumination of light from light source 152 may be selected, and for a second type of COVID test, a second wavelength, intensity, or duration of illumination of light may be selected. In some cases, any other suitable parameters may be adjusted for different versions of the same type of test. For example, if device 100 includes a heating element for heating the analyte, the heating temperature of the heating element may vary depending on the version of the test being run. In some cases, the version of the test being run may be distinguished from other versions of the test based on the type of kit used for the test (e.g., the amount of analyte, the type of analyte, the type of reaction tube 110, the transparency of the walls of the reaction tube 110, etc.). In various embodiments, the data regarding the type of test being run may include information regarding the test subtype for the particular type of test being run. The check type and check version may be encoded by a few bits (e.g., 1, 2, 3, 4, 5, 6, 7, 8, 9, or 10 bits). In some embodiments, to minimize the size of the BPDS core, a minimum number of bits may be used to indicate the check type and check version (subtype). In other embodiments, more bits may be used.

[0062] The BPDS core may also include (6) an indication of the result of the test. Results may include "positive," "negative," "indeterminate," "fault" results, etc. In some cases, the result may be characterized by a probability of positive or negative. In some cases, the result may be a numeric value (e.g., glucose level, cholesterol level in a blood sample, etc.). The result of the test may be encoded by a few bits (e.g., 1, 2, 3, 4, 5, 6, 7, 8, 9, or 10 bits). In some embodiments, to minimize the size of the BPDS core, a minimum number of bits may be used to indicate the result of the test. In other embodiments, more bits may be used.

[0063] The BPDS may also include one or more statistics indicative of the current and / or past operational status of the diagnostic testing device. For example, the BPDS may include an indication of past results of diagnostic tests performed by the diagnostic testing device (e.g., diagnostic testing device 100). For example, the BPDS may indicate the number of positive results, the number of negative results, the number of indeterminate results, the number of canceled tests, and / or the number of malfunctions based on previously performed diagnostic tests (e.g., based on tests previously performed during a time interval, such as during the past week). In an exemplary implementation, the diagnostic testing device may use separate individual bit strings to indicate the number of positive results, negative results, indeterminate results, canceled tests, and / or malfunctions. Such bit strings may include a few bits or tens of bits (e.g., 5-20 bits). In some cases, 9 or 10 bits may be sufficient to provide an indication of such test statistics associated with the diagnostic testing device. In some embodiments, a minimum number of bits may be used to indicate individual test statistics to minimize the size of the BPDS core. In other embodiments, more bits may be used (e.g., to avoid bit overrun). Depending on the size of the bit string used to store a given test statistic, bit overruns may occur (e.g., if 9 bits are used to store the number of negative test results, the bit string will roll over after 512 negative results, roll over at the 513th negative result, etc.), however, bit overruns may be detected by comparing the test run number with the reported test statistics.

[0064] In some cases, when multiple tests are performed simultaneously (e.g., when both COVID and influenza tests are performed simultaneously or sequentially), the results of the tests may be expressed as a pair of results. For example, for COVID and influenza tests (herein, such tests are referred to as COVID-influenza binary tests, and the COVID and influenza tests are referred to as subtests), the results may be {COVID, influenza} = {positive, positive}, {COVID, influenza} = {positive, negative}, etc. In addition to binary tests, ternary tests, i.e., tests with three subtests, quaternary tests, i.e., tests with four subtests, or tests with more than four subtests, can be performed. Thus, for at least some tests, more information may be encoded in the QR code. In one example implementation, a data record may be used to indicate that both results occur simultaneously. Additionally, another data record may be used to indicate that a COVID-influenza binary test (or any other binary test) was performed. For each subtest, the dynamic QR code 180 may assign a data record indicating the results of that subtest and statistics related to the results of that subtest.

[0065] In some cases, the dynamic QR code 180 may encode data indicating subtest statistics when multiple subtests are performed. For example, if a COVID-influenza binary test is performed on a given sample, the QR code may encode as a first statistic (s1) the number of positive COVID results when the COVID-influenza binary test is performed. Additionally, the number of positive COVID results when only the COVID test is performed may be encoded in the QR code as a second statistic (s2) that is different from the first statistic (s1). Furthermore, if a COVID-influenza binary test is performed, each data record of the associated subtest may be encoded with a number of data bits sufficient to communicate the subtest-related information.

[0066] In some embodiments, the bit string is a sequence of bits representing multiple targets (t1 to t n ) may be employed to indicate a positive result for each of the n targets detectable by the diagnostic test performed. For example, a positive test result in a BPDS core may include a bit string of n bits indicating each of the n targets detectable by the diagnostic test performed. Each bit in the bit string may correspond to one of the targets, where, for example, one ("1") indicates a positive result for that target and zero ("0") indicates a negative result for that target. In some embodiments, if none of the n targets are detected but a control signal, such as an internal amplification control (IAC), is detected, the test result may be indicated as negative. In some embodiments, if none of the n targets are detected and the IAC is not detected, the test result may be indicated as indeterminate.

[0067] The BPDS core may also include an indication of the amount of time (e.g., seconds) that elapsed before detecting an internal amplification control (IAC) signal. In some embodiments, the BPDS core may include an indication of the number of seconds before detecting an IAC signal, based on obtaining a positive result or a negative test result. IACs are non-target DNA sequences present in the analyte that are co-amplified simultaneously with the target sequence. In diagnostic tests without IACs (e.g., PCR, loop-mediated isothermal amplification, antigen tests, etc.), a negative response (no band or signal) may mean that the target sequence was not present in the reaction. However, it may also mean that the reaction was inhibited (e.g., due to a thermal cycler malfunction when using PCR tests, an incorrect reagent mixture, reduced DNA polymerase activity when using PCR tests, or the presence of inhibitors in the sample matrix). On the other hand, in diagnostic tests with IACs, a control signal is expected even when the target sequence is not present. This can reveal failure of the diagnostic test if a control signal is not generated. If a control signal is not observed when an IAC is present, the elapsed time may be evaluated as zero. The indication of elapsed time can be encoded using a small number of data bits (e.g., 10, 12, 14, 16 data bits, etc.). In some embodiments, to minimize the size of the BPDS core, a minimum number of bits may be used to indicate the elapsed time. In other embodiments, more bits may be used.

[0068] 5A and 5B show exemplary SARS and IAC signals for a positive SARS-CoV-2 test 511 and a negative SARS test 513. If the SARS test 511 is positive, the SARS signal may be significantly higher than the IAC signal, and if the SARS test 513 is negative, the SARS signal may be lower than the IAC signal.

[0069] As described herein, the BPDS core may include an indication of the amount of time that has elapsed before detecting one of the specific results, such as a positive, negative, malfunction, inconclusive, or canceled result. Such an indication may also be encoded using a small number of data bits (e.g., 10, 12, 14, 16 data bits, etc.). In some embodiments, to minimize the size of the BPDS core, a minimal number of bits may be used to indicate the elapsed time. In other embodiments, more bits may be used.

[0070] If the test result indicates a "malfunction," the BPDS may also include a data code indicating the reason for the malfunction. The number of bits used to indicate the error code may be based on the number of possible reasons for the malfunction. In some embodiments, to minimize the size of the BPDS core, a minimum number of bits may be used to indicate the error code. In other embodiments, more bits may be used. The listed causes may include the parameters summarized in Table 1 below.

[0071] [Table 1] Table 1: Possible causes of malfunction

[0072] When an ASSERT failure occurs, the ASSERT failure may be due to an assertion error in software executed by the diagnostic tester's processor. In such cases, the ASSERT failure may indicate information that allows the assertion error to be identified. For example, an assertion error may be identified if the line number of the software where the assertion error occurred is identified and the first few characters of the file where the assertion error occurred are further identified to identify the file with the assertion error. When an ASSERT failure occurs, the BPDS may include an indication of the line number where the ASSERT occurred and an indication of the file where the assertion occurred (e.g., the first n characters). In an exemplary embodiment, the line number may be encoded using, for example, 16 bits of data, and the first few characters of the file (e.g., the first 3, 4, 5, 6 characters, etc.) may be encoded using 32 bits of data. In some embodiments, to minimize the size of the BPDS core, a minimum number of bits may be used to indicate the line number and character of the file. In other embodiments, more bits may be used.

[0073] In various embodiments, in the case of an indeterminate result, the BPDS core may not include additional information, e.g., to minimize the size of the BPDS core. In other embodiments, the BPDS core may include additional information along with an indication of an indeterminate result.

[0074] The BPDS core may include zero padding to achieve byte alignment.

[0075] In some embodiments, the BPDS may include both a BPDS core as described herein and an HMAC of the BPDS core obtained using a secret key associated with the diagnostic testing device, as described above. In some embodiments, the diagnostic testing device may lack (i.e., not include) an internal clock, e.g., to minimize device complexity, device cost, device form factor, etc. In other embodiments, the diagnostic testing device may optionally include a clock. The BPDS core may include one or more timestamps provided by any clock included in the diagnostic testing device.

[0076] In various embodiments, the HMAC may be truncated to fit within the available space of the dynamically generated barcode. While a truncated HMAC may be relatively less secure than an untruncated HMAC, the truncated HMAC may still provide sufficient cryptographic strength. In some cases, the HMAC may be truncated to less than 32 bytes. For example, in some cases, the HMAC may be truncated to 11 bytes. In some cases, the BPDS core may contain a total of 21 bytes, which, when concatenated with the 11 bytes of the HMAC, produces a BPDS having 32 bytes that are encoded for a URL.

[0077] In various embodiments, a static barcode (e.g., static barcode 190 attached to the device housing) may include 4 bytes, resulting in a BPDS with a total of 15 bytes if the BPDS includes static barcode information (the BPDS includes the HMAC truncated to 11 bytes and the 4 bytes of the static barcode). In various embodiments, having an HMAC (e.g., a truncated HMAC) provides assurance that the barcode in question is associated with an authentic device 100.

[0078] Additionally, in some implementations, the barcode may further include additional encoded data. For example, the additional encoded data may include the amount of time (e.g., seconds or minutes) the barcode remained on the screen before being refreshed or updated. Barcode updates may occur periodically. Combining such information with information regarding the time the scan was received by the portal server (e.g., test server 320 shown in FIGS. 3A and 3B) can provide an indication of when the test began in real time. As described herein, in some cases, device 100 may optionally include an internal clock, and a timestamp associated with the internal clock may also be encoded in the QR code.

[0079] As also described herein, in some embodiments, a diagnostic testing device may lack (i.e., not include) a wireless communication interface (e.g., radio, transmitter, receiver, transceiver, antenna, etc.) used to report test results and associated information. Excluding network interfaces (e.g., wired and wireless network interfaces) means that there are no available network vectors to attack the diagnostic testing device. In some embodiments, a diagnostic testing device may include a physical (e.g., wired) communication interface (e.g., Ethernet, USB, serial, telephone, etc.) or a wireless communication interface (e.g., cellular, Wi-Fi, Bluetooth, etc.) for other purposes, such as receiving over-the-air firmware updates, control signals (e.g., factory reset signals, shutdown / disable signals), etc. A diagnostic testing device may lack (i.e., not include) a wired communication interface (e.g., Ethernet, USB, serial, telephone, etc.) or a wireless communication interface (e.g., radio, transmitter, receiver, transceiver, antenna, etc.) to, for example, minimize device complexity, device cost, device form factor, etc.

[0080] 6A and 6B show examples of information that may be displayed on the display 170 of the device 100. For example, FIG. 6A shows an example display reporting a positive test result. (Note: In some cases, particularly when sample analysis is performed remotely, such as in a lab, the testing service provider may not have access to the results of the test results; in other cases, for example, when the test is performed in the patient's presence, the testing service provider may be able to observe the results of the test results on the device's display.) FIG. 6B shows an example display prompting the testing service provider to interact with the interface 160 (e.g., pressing a button similar to the interface element button 260 shown in FIG. 2), which causes a barcode 180 (e.g., a matrix code such as a QR code) to be dynamically generated. Once the dynamically generated barcode 180 is generated, the testing service provider and / or user can use a barcode scanning device (e.g., a smartphone) to scan and transmit the data encoded in the dynamically generated barcode 180 to a testing server (e.g., testing server 320 shown in FIGS. 3A and 3B), which can then store the data in a data store and / or database associated with the user account.

[0081] In various embodiments, upon scanning a static barcode (e.g., static barcode 190) using an appropriate electronic device (e.g., a smartphone, laptop, etc.), the testing service provider (or user) may be directed to a webpage based on the URL obtained from static barcode 190. An exemplary URL constructed from static barcode 190 associated with diagnostic testing device 100 may be, for example, HTTPS: / / XX.XX / B00001Q:C1PCUBD$O9B6E126, which may direct the testing service provider (or user) to a website associated with device 100 for the user to log in, create an account, and / or provide personal information. In this manner, test result data may be associated with (and later retrieved from) the user associated with the account and / or personal information. In an exemplary embodiment, the website may display the device serial number based on information obtained from static barcode 190. In some cases, the website may display the device serial number once the user logs into the website. Additionally, the website may display any other information related to the device manufacturer (e.g., the device manufacturer's name). In some cases, the website may display various links that may be accessed by the user. 7 shows an exemplary website 700, including a login header 711, a message 713 indicating that the device's QR code has been scanned, a section 715 containing possible links, and an area for logging in 717. Area 717 may contain any suitable message (e.g., a message that data has been encoded and may be transmitted to a government agency, such as a local state agency). The static barcode 190 allows a user to verify physical presence at the device's installation location and physical possession of a device with a particular serial number without first performing an inspection. This static QR code may facilitate management of device ownership on the detector portal website.

[0082] An exemplary URL constructed from a dynamically generated barcode associated with device 100 (e.g., dynamic QR code 180 shown in FIG. 1) is: HTTPS: / / XX.XX / A008D1M::E583CTOKZ46J7LJ3R7.+Q1$D * 3F8LTQ / QQZNLM+U. "HTTPS: / / XX.XX" may direct a device that scans the URL to website 800 shown in Figure 8A.

[0083] The payload, "A008D1M::E583CTOKZ46J7LJ3R7.+Q1$D *The "3F8LTQ / QQZNLM+U" may include encoded information related to the device, test results, test behavior, and / or personal information, as described herein. In some cases, if the testing service provider has access to user-related information (e.g., if the testing service provider is the user), the testing service provider or user can log in to an associated account via website 800, enter user-related information on website 800, or create a user account. Website 800 may include a text message 811 informing the testing service provider / user that the information is encrypted and may be collected by relevant federal, state, and local health authorities. Additionally, website 800 may include user information 813, such as the user's first and last name, date of birth, ethnicity, race, and gender, as well as the user's email, address, and phone number. Upon entering the user-related information, the testing service provider can submit the test via a submit test button (or any appropriate test submission graphical user element). Upon submitting the test results, the test results may be reported to government authorities and / or stored in a database associated with the user. It should be noted that user-related information (e.g., user-identifying information such as username, email, address, and phone number) may be removed when transmitting test-related information to relevant federal, state, and local health authorities. In some cases, website 800 may automatically pass test-related information to relevant health authorities (e.g., if required by law) regardless of whether personal information is transmitted. In some embodiments, website 800 is configured to display test results, for example, as shown in FIG. 8B. The test results may include the name of the device manufacturer, the result of the test (e.g., COVID-19 negative), the serial number of device 100 (e.g., serial number SN1), and the time and date the test results were uploaded to the server (e.g., Time1 and Data1).

[0084] 9 shows an exemplary process 910 for performing a diagnostic test and displaying diagnostic test information for transmission to a server. The steps of process 910 may be performed by device 100. In optional step 911, process 910 includes receiving user-related information from a user (e.g., the user-related information may be entered through an interface of device 100). For example, the user-related information may be any suitable unique user identification, such as a user account number, that may be scanned or manually entered into device 100. In one implementation, a sample may be collected from a patient at a medical facility by a medical service provider. For example, a swab sample from the patient may be placed into a reaction tube by the medical service provider.

[0085] At step 913, device 100 is configured to receive a test sample in a reaction tube. The test sample may be any suitable fluid from a user. For example, the test sample may be extracted from a nasal swab, throat swab, etc., taken from the user. At step 915, device 100 is configured to perform a test analysis using any suitable method previously referenced, and at step 917, device 100 is configured to encode data related to the test result and data related to the device serial number. At step 921, device 100 may be configured to dynamically generate a barcode based on the encoded data, and at step 923, device 100 is configured to display the dynamically generated barcode on a display associated with device 100.

[0086] FIG. 10 illustrates an exemplary process 1001 for running a test and displaying a web page related to the results of the test. In various embodiments, the steps of process 1001 can be performed by a system of devices, which can include a test device, a scanning device, and a server for providing a web page related to the results of the test. In an exemplary embodiment, step 1010 includes running a diagnostic test and displaying a dynamically generated barcode (e.g., a matrix code, such as a QR code, may be displayed on the display of the test device). Step 1010 may be the same as process 910 (e.g., step 1010 may include steps 911-923 of process 910). In various embodiments, step 1010 is performed by the test device (e.g., device 100). Additionally, process 1001 includes step 1020 of scanning an image of the dynamically generated barcode displayed by device 100 using any suitable scanning device (e.g., a smartphone camera, or any other suitable device). In an exemplary embodiment, the smartphone may be configured to include an application for scanning barcodes. In step 1030, the application for scanning the barcode may be configured to transmit the barcode data encoded in the barcode to the testing server. Upon receiving the barcode data, in step 1040, the testing server is configured to provide a web portal based on the transmitted data (e.g., a web portal associated with the testing service provider). In various cases, when providing the web portal based on the transmitted data, the transmitted data may be decoded. Further, after completion of step 1040, in step 1050, the application for scanning the barcode may be configured to display a web page of a website in a web browser, and the website or web page may be displayed based on the transmitted data.In various embodiments, the data in the QR code may represent a URL with various parameters relating to information related to the test, as discussed above (e.g., the URL HTTPS: / / XX.XX / A008D1M::E583CTOKZ46J7LJ3R7.+Q1$D discussed above). * 3F8LTQ / QQZNLM+U).

[0087] While various embodiments have been described above, they should be understood as being presented by way of example only and not limitation. While the schematic diagrams and / or embodiments described above show particular components arranged in particular orientations or positions, the arrangement of the components may be changed. While embodiments have been specifically shown and described, it will be understood that various changes in form and detail may be made. While various embodiments have been described as having particular features and / or combinations of components, other embodiments are possible that have any combination of features and / or components from any of the embodiments discussed above.

[0088] For example, while the device 100 described herein is generally associated with FLOS-LAMP analysis and is particularly suited for SARS-CoV-2 detection, it should be understood that the device 100 is applicable to many other analytes that can be selectively amplified or concentrated, for example, through LAMP, polymerase chain reaction (PCR), chemical synthesis, electrochemistry, biological production, chromatography, electrophoresis, isoelectric focusing, gravimetric separation, etc. Although the embodiments described herein generally describe a fluorescent signal that can be associated with or correlated to the amount or concentration of the analyte, the analyte may be detected by any suitable means, such as, for example, a pH-driven colorimetric signal from real-time loop-mediated isothermal amplification (RT-LAMP), or any other suitable colorimetric, electrical, electrochemical, optical absorbance, etc. signal.

[0089] In certain embodiments, the device 100 may be used to determine the presence or absence of an analyte by detecting and / or measuring a signal generated through isothermal nucleic acid amplification. Isothermal amplification of nucleic acids is an alternative to polymerase chain reaction (PCR). The advantage of these methods is that nucleic acid amplification can be performed at a constant temperature, unlike PCR, which requires cyclic temperature changes. In certain embodiments, isothermal nucleic acid amplification is performed using, for example, loop-mediated isothermal amplification (LAMP), nucleic acid sequence-based amplification (NASBA), helicase-dependent amplification (HDA), exponential amplification of nucleic acids (EXPAR), strand displacement amplification (SDA), recombinase polymerase amplification (RPA), or rolling circle amplification (RCA), as described, for example, in O.L. Bodulevl and I. Yu. Sakharov, Biochemistry (Moscow), 2020, Vol. 85, No. 2, pp. 147166, and references cited therein, which are incorporated herein by reference in their entirety.

[0090] In some embodiments, the test sample for the diagnostic test is a biological sample collected from a subject diagnosed with an infectious disease or believed to have or be at risk of developing an infectious disease. In other embodiments, the sample is a food or beverage product. In some embodiments, the sample is collected from a surface, such as a food preparation surface, a food or beverage packaging surface, or a surface in a home, rental property, or hotel, including, but not limited to, a kitchen counter surface, a bathroom counter surface, a toilet, a shower or bathtub surface, or a table or dresser surface.

[0091] In certain embodiments, the analyte is a virus or a component thereof. In some embodiments, the test sample is a biological sample collected from a subject diagnosed with, suspected of, or at risk of infection with a virus. For example, the test sample may be a nasal swab, a throat swab, or the like. In certain embodiments, the virus is norovirus, rotavirus, adenovirus, astrovirus, influenza virus, coronavirus, parainfluenza virus, respiratory syncytial virus, human immunodeficiency virus (HIV), human T-lymphotropic virus (HTLV), rhinovirus, hepatitis A virus, hepatitis B virus, Epstein-Barr virus, or West Nile virus. In certain embodiments, the virus is SARS-CoV-2.

[0092] Additionally, some methods described herein describe terminating the sample run when the target or control indicates (optionally after a waiting period). However, it should be understood that in other embodiments, the sample may be run (e.g., the target analyte may be selectively amplified) for up to a maximum duration (e.g., 60 minutes, 90 minutes, etc.). In such embodiments, if the target indicates within that time (by accepting an indication during an optional excluded initial period), an indication of a positive result may be transmitted. If the control indicates within that time, an indication of a negative result may be transmitted. In other cases, a signal may be transmitted indicating that the test failed or is indeterminate.

[0093] Where the methods and / or events described above indicate certain events and / or procedures occurring in a particular order, the order of the certain events and / or procedures may be changed. Furthermore, certain events and / or procedures may be performed simultaneously in a parallel process where possible, as well as sequentially as described above.

[0094] One or more aspects discussed herein may be embodied in computer-usable or readable data and / or computer-executable instructions (e.g., one or more program modules executed by one or more computers or other devices), as described herein. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor of a computer or other device. Modules may be written in source code programming languages ​​and then compiled for execution, or may be written in scripting languages, such as, but not limited to, HTML or XML. The computer-executable instructions may be stored on a computer-readable medium (e.g., a non-transitory computer-readable storage medium), such as a hard disk, optical disk, removable storage media, solid-state memory, RAM, etc. As will be appreciated by those skilled in the art, the functionality of the program modules may be combined or distributed as desired in various embodiments. Furthermore, the functionality may be embodied, in whole or in part, in firmware or hardware equivalents, such as integrated circuits, field programmable gate arrays (FPGAs), etc. Particular data structures may be used to more efficiently implement one or more aspects discussed herein. And such data structures are contemplated within the scope of the computer-executable instructions and computer-usable data described herein. Various aspects discussed herein may be embodied as methods, computing devices, systems, and / or computer program products.

[0095] [Note] Item 1. An apparatus comprising: a well configured to receive a reaction tube containing a test sample and an analyte; a light emitting source configured to emit excitation light at a wavelength for illuminating the analyte in the reaction tube; an optical detector configured to receive emitted light in response to illumination of the analyte by the excitation light; a processor operably coupled to the optical emission source and the optical detector; and a display configured to display a dynamic QR code; The processor: analyzing the emitted light to determine the results of a diagnostic test to determine whether the patient has a viral or bacterial infection; Encodes data related to the results of a diagnostic test; and configured to generate a dynamic QR code using the encoded data; The dynamic QR code includes data related to the results of a diagnostic test and is configured to be scanned using an electronic device. Item 2. Further, the device is provided with a static QR code associated therewith; Item 10. The device of item 1, wherein the processor receives a static QR code and encodes data from both the results of the diagnostic test and data associated with the static QR code. Item 3. The device of item 1, further comprising a receiver configured to receive test-related data wirelessly transmitted from a chip coupled to the reaction tube. Item 4. The apparatus of item 3, wherein the test-related data includes the type of test performed. Item 6. The device of Item 3 further comprising: a hinged cover configured to be movable over the top of the reaction tube; Receiver located within a hinged cover. Item 7. The device of item 1, wherein the dynamic QR code includes an encoding string including one or more encoding characters used to encode data related to the results of a diagnostic test. Item 8. The device of item 7, wherein the encoding characters used to encode information in the dynamic QR code are arranged in a bit-packed data structure (BPDS). Item 9. The device of item 8, wherein the BPDS includes a timestamp including the length of time it took to detect a particular result (e.g., one or more of positive, negative, malfunction, inconclusive, or canceled). Item 10. The device of item 1, wherein the light emitting source comprises one or more light emitting diodes. Item 11. The device of item 1, wherein the device is a fluorescence of loop primer during self-quenching loop-mediated isothermal amplification (FLOS-LAMP) device operable to amplify an analyte and measure a signal related to the amount of the analyte. Item 12. The device of item 1, wherein the test sample is a biological sample, and the biological sample is selected from the group consisting of serum, blood, salivary secretions, tear secretions, respiratory secretions, nasal fluid, mucus samples, and intestinal secretions. Item 13. The device of item 1, wherein the processor is configured to communicate the results of the diagnostic test to the patient in the form of one of a dynamic QR code or data from the results of the diagnostic test. Item 14. The device of item 1, wherein the processor is configured to communicate the results of the diagnostic test to a medical professional in the form of one of a dynamic QR code or data from the results of the diagnostic test. Item 15. The device of item 1, wherein the processor is configured to communicate the results of the diagnostic test to an institution for analyzing pathogen transmission within a population in the form of one of a dynamic QR code or data from the results of the diagnostic test. Item 16. A kit for use with the device according to Item 1, A kit containing a set of instructions, nasal swabs, buffer tubes, transfer pipettes, and reaction tubes. Item 17. A method comprising: receiving the test sample present in a reaction tube containing the test sample and an analyte; performing laboratory analysis of test samples and analytes; encoding data relating to the results of the diagnostic test and another data relating to the serial number of the device; Generating a dynamic QR code using the encoded data; and Displaying dynamic QR codes; The method, wherein the laboratory analysis comprises the results of a diagnostic test to determine whether a patient has a viral or bacterial infection. Item 18. The method according to Item 17 further comprising: Scanning the dynamic QR code with an application for scanning QR codes on a scanning device; transmitting, by the application and the scanning device, data relating to the results of the diagnostic test to the testing server; Creating, by the test server, a website containing data related to the results of the diagnostic tests; and Displaying websites based on data related to the results of diagnostic tests through applications and scanning devices. Item 19. The method according to Item 17 further comprising: emitting, by a light emitting source, excitation light to illuminate the analyte in the reaction tube; receiving, with an optical detector, emitted light in response to illuminating the analyte with the excitation light; and and determining, by a processor operably coupled to the light emitting source and the optical detector, at least one of the amount or concentration of the analyte by illuminating the analyte with the light emitting source and receiving and processing the emitted light. Item 20. A system including an apparatus and a plurality of reaction tubes, The device comprises: a housing defining a well, the housing configured to receive at least one reaction tube from a plurality of reaction tubes, the at least one reaction tube containing a test sample and an analyte; a receiver configured to receive any one of a plurality of near-field communication signals from the at least one reaction tube, each near-field communication signal from the plurality of near-field communication signals including a plurality of parameters for performing an assay on a test sample contained in the at least one reaction tube; a light emitting source configured to emit excitation light to illuminate the sample in the reaction tube; an optical detector configured to receive an emission signal in response to illumination of the sample by the excitation light; a processor operably coupled to the receiver, the optical emission source, and the optical detector; and a display configured to display a dynamic QR code; Equipped with the processor is configured to analyze the emitted light to determine a result of a diagnostic test to determine whether the patient has a viral or bacterial infection, encode data related to the result of the diagnostic test, and generate a dynamic QR code using the encoded data; 1. A device, comprising: a dynamic QR code containing data related to a result of a diagnostic test and configured to be scanned using an electronic device; and, each reaction tube from the plurality of reaction tubes is configured to be inserted into a well; a first reaction tube from the plurality of reaction tubes includes a first near-field communication chip configured to transmit a first signal including a first plurality of parameters for performing a first assay; a second reaction tube from the plurality of reaction tubes includes a second near-field communications chip configured to transmit a second signal including a second plurality of parameters for performing a second assay; The second assay differs from the first assay by at least one of the second plurality of parameters differing from at least one of the first plurality of parameters.

Claims

1. 1. A method for visually indicating the result of a diagnostic test, comprising: - performing a diagnostic test using the diagnostic test device by analyzing, using a light emitting source and an optical detector, at least the emitted light from the analyte combined with the test sample in the reaction tube present in the well of the detector; - obtaining one or more test results based on said analysis that indicate whether the patient who provided said test sample has a viral or bacterial infection; generating a barcode based on a size of a display screen of the diagnostic testing device, the barcode being configured to be scanned by a scanning device of a computing device, causing the computing device to automatically transmit the one or more acquired test results to a remote data store; and presenting on the display screen of the diagnostic test device; said generating said barcode further comprising: generating a bit-packed data structure (BPDS) containing a string of bits indicative of the one or more test results obtained; - obtaining an encoded BPDS by encoding the BDPS based on the storage capacity of the barcode; - generating a URL containing the encoded BPDS based on the storage capacity of the barcode; and encoding the generated URL into the barcode.

2. the core of the BPDS includes the bit string indicative of the one or more test results obtained; The generating of the barcode further comprises: generating a keyed hash message authentication code (HMAC) based on a key stored in the diagnostic tester's firmware and based on the serial number of the diagnostic tester; and - obtaining a truncated HMAC by truncating said HMAC; The method of claim 1 , wherein the generating the BPDS comprises adding the truncated HMAC to a core of the BPDS.

3. 10. The method of claim 1, wherein the BPDS further comprises at least one of the following: - A bit string indicating the type of the core of the BPDS; - a bit string indicating a product type associated with the diagnostic test device; a bit string indicating the serial number of the diagnostic test device; a bit string indicating the test run number of the diagnostic test; - a bit string indicating the type of diagnostic test; a bit string indicating statistics related to previous diagnostic tests performed by the diagnostic testing device, the statistics indicating one of the following: - the number of test results showing positive infection; - the number of test results showing negative infection; - the number of test results that were determined to be indeterminate; - the number of diagnostic tests that malfunctioned, or - number of diagnostic tests cancelled; - the time elapsed between the initiation of said diagnostic test and the detection of the target infection; the time elapsed between the initiation of the diagnostic test and the detection of a control signal; or ・Error code.

4. 10. The method of claim 1, wherein the barcode comprises at least one of the following: - Two-dimensional (2D) barcodes, - Matrix barcode, or -Quick response (QR) code.

5. The method of claim 1 , wherein the encoding of the BPDS comprises encoding the BPDS using an encoding scheme that minimizes the size of the encoded BPDS.

6. The method of claim 1 , wherein generating the URL includes using a fully qualified domain name to minimize the size of the URL.

7. 10. The method of claim 1, wherein the diagnostic testing device does not include a wired or wireless network interface used to provide the one or more obtained test results.

8. 1. A diagnostic testing device configured to visually indicate the results of a diagnostic test, comprising: a well configured to receive a reaction tube containing a test sample and analyte provided by a patient; a light source configured to illuminate the analyte in the reaction tube with excitation light; an optical detector configured to receive emission light from the analyte upon illumination of the analyte with the excitation light; ・Display screen; a processor in signal communication with the display screen, the light source, and the optical detector; and A diagnostic testing apparatus comprising a memory storing instructions which, when executed by the processor, cause the diagnostic testing apparatus to carry out a method according to any one of claims 1 to 7.

9. 10. A non-transitory computer readable medium storing instructions that, when executed by a processor of a diagnostic testing device, cause the diagnostic testing device to perform at least the method of any one of claims 1 to 7, thereby visually displaying results of the diagnostic test.

Images