Patent Application
20250147056
The present application relates to software used for analyzing data from assays to measure the presence or absence of certain materials within a subject or within an area. Example assays may be used with environmental, human, animal, biological, or other materials.
Conventional assay analysis systems utilized in a biochemical and/or biomedical environment typically perform a single assay at a time. For example, a conventional assay analysis system may receive a test card on which a sample has been provided. The conventional assay analysis system utilizes various hardware components to analyze the sample based on the type of assay being performed. Once the assay is complete, the assay analysis system may perform a similar assay or a different assay on another test card onto which another sample has been provided.
In such cases with multiple analyses being performed on the same computer or device at roughly the same time, then the software performing the analysis should not be permitted to interfere with or affect the analysis of the other assays.
Accordingly, a need arises for a modularized assay-specific software interface.
Aspects of the disclosure relate to systems and methods for determining a final result associated with each of two or more assays. The system includes an analyzer capable of analyzing a first assay and a second assay and a control computer which itself comprises a processor and memory accessible by the processor for operating a host program, a first assay module instance, and a second assay module instance. Together the analyzer, the host program and the assay module instances perform operations. The host program initiates the first assay on the analyzer and the first assay module instance on the control computer. The host program initiates the second assay on the analyzer and the second assay module instance on the control computer. The analyzer performs the first assay and the second assay. The analyzer collects a first raw data associated with the first assay and a second raw data associated with the second assay. In an example, the collection of the first raw data associated with the first assay and the second raw data associated with the second assay occurs in parallel or substantially in parallel. The host program transfers the raw data from the analyzer to the associated assay module instance (i.e. the first raw data is transferred to the first assay module instance and the second raw data is transferred to the second assay module instance). Each of the first assay module instance and the second assay module instance calculates from the raw data an intermediate result and from the intermediate result determines a final result. Each assay module instance transmits to the host program its determined final result. The host program stores both final results and displays both final results on a results screen.
The system may further comprise a scanner such as a barcode scanner or a QR code scanner or an rf ID tag scanner for automatic inclusion of additional information related to the assay. The additional information may comprise a test start configuration, a test result configuration, and a hardware instrumentation configuration. Example assays comprise at least one of a polymerase chain reaction (PCR) test, lateral flow assay (LFA), an antibody test, a colorimetric test, a turbidity test, a viscosity test, a cytometry test, or a chemical test.
So that the manner in which the above recited features of the present application can be understood in detail, a more particular description of the application, briefly summarized above, may be had by reference to examples, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical examples of this application and the application may admit to other equally effective examples.
Other features will be apparent from the Detailed Description that follows.
In the following detailed description of the preferred examples, reference is made to the accompanying drawings, which form a part hereof, and within which are shown by way of illustration specific examples by which aspects of the application may be practiced. It is to be understood that other examples may be utilized and structural changes may be made without departing from the scope of the application. Electrical, mechanical, logical, and structural changes may be made to the examples without departing from the spirit and scope of the present teachings. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims and their equivalents.
As used herein, “in parallel” means that a time period in which one resource item is in use overlaps entirely with a time period in which the other resource item is in use. Additionally, when two of the two or more resource items are used “substantially in parallel”, this means that a time period in which one resource item is in use overlaps, at least partially, with a time period in which the other resource item is in use. When two of the two or more resource items are used “in series”, a time period in which one resource item is in use arises prior to or subsequent to a time period in which the other resource item is in use.
It is sometimes advantageous to perform multiple assays or the same assay multiple times simultaneously. In such occurrences multiple test cards may be used in multiple analyzers, all of which may be controlled by a single computer. In another example the test card may be appropriately designed for more than a single assay. In cases in which different assays are performed on the same card usually a single computer controls the processes. In order to assure the reproducibility of the tests, it is imperative that the software performing the analysis on each of the different assays not interfere with any of the other analysis being performed.
For example, conventional in vitro diagnostics (IVD) test platforms typically only perform one test modality. (In this contact, modality means a type of test. For example, a test platform may perform both a PCR test and an LFA. Each of these assays is considered a modality or operation.) Some diagnostics test platforms can perform a small number of different tests, but not at the same time. Other diagnostics test platforms can perform only a limited number of different tests at one time. Overall, testing capabilities of conventional diagnostic test platforms are limited by the time and space requirements for multiple diagnostic tests. This often results in limited diagnostic information and negative patient outcomes.
In a clinical setting, some test results from conventional platforms require a subsequent confirmation or reflex test before a diagnosis or clinical outcome is decided. These confirmation or reflex tests can be of a different modality than the initial test, for instance a PCR test after an LFA test, or a second PCR after a first PCR to make false positives or false negatives less probable. In other situations, a combination of tests is required to determine a diagnosis, a clinical outcome, or a conclusive result. These scenarios require managing multiple conventional POC platforms or testing services from centralized laboratories. As a result, total cost of diagnosis and time to result is greater than that attributed by an individual, conventional POC test.
The present disclosure relates to assays or tests with one or more modalities. In a single mode operation an assay card is inserted into an apparatus which performs an analysis. A computer program, when executed by a computing device, performs one or more operations. These operations may include, but are not limited to, opening valves, admitting reagents, heating a sample, cooling a sample, illuminating a sample, detecting illumination from a sample, and additional operations, to run the assay on a sample in the assay card. If the analyzing apparatus is capable of performing multiple assays, for instance a PCR assay and a cytometry assay, then both of these modes/modalities would be run on the analyzer apparatus, potentially at the same time. In order for each test to run without interference from the other test and, after the test itself has been locked down (not to be changed), for instance, after having been approved by regulators, then future instances of that test must be made immutable to preserve the reproducibility of the assay. In order to facilitate such non-interference with other tests running on the same apparatus at the same time, the software which interacts with the apparatus must also be isolated from other instances of the software running other tests.
In an example, a user interface (or host program) is created which allows a user to enter relevant information for all tests being run on an apparatus, for instance by a multi-modal assay card. Since two modes may be run, each mode of operation must be approved first by regulators. If the first modality is approved first, and the second modality is approved later after changes to the computer code have been enacted, then each mode must have its own instance of the computer program to run each of the tests independently on the immutable version of the computer program. Locking down, fixing, or making the computer code immutable ensures that the test produces reliable results for all subjects whose samples are being analyzed. Confirming that the computer code for a particular test is not altered nor the results changed requires that each of the testing modalities has its own instance of computer code running and that each of the instances cannot in any way interfere with the any other instance if computer code running a different test at the same time.
In an example, a sandbox environment may be used to isolate an instance of a program to, for instance, debug the program or to identify and debug malware. In the case of an assay apparatus with more than one mode of operation, it makes more sense to have a single user interface for the user and then to spin up or run individual computer program for each of the assay/testing modes being employed. Each of the individual instances being executed must be so designed as to be unable to access any of the memory accessible by the other instances. A separate program, the user interface, is given permission to read these memory locations.
In current solutions, most human intended in vitro diagnostic (IVD) instruments modularize their software such that releasing an additional assay on the platform does not require a patch of the underlying firmware of the instrument. This makes sense, as firmware patches can carry a risk to the patient, as well as high regulatory threshold. However, there are tradeoffs for this design.
The algorithm associated with the assay remains immutable. This limits or prevents optimization of algorithm performance on a per-assay basis. For example, if one assay's biological characteristics produce a signal differing from a previously released assay on the same instrument (or the original assay released with the instrument).
Analyzing data from a different diagnostic modality is not possible. Because different analyte interrogation methods produce fundamentally different signal types, an algorithm from one modality (e.g., PCR—amplification curve analysis), cannot analyze the results from another (e.g., image cytometry—cell counting).
The network 138 may include an external resource 140, such as a database of recipes for an analyzer apparatus 200 or remote storage of data such as configuration files, recipe files, and the like. Within the computer memory 110 are stored programs. The programs may include an operating system 120 as well as a host program (e.g., a user interface) 106 and instances of an assay module 102-1, 102-2, . . . 102-N. In some examples, for example when the analyzer 200 is configured to perform more than one assay, then there may be multiple instances of an assay module instance 102-1, 102-2, . . . 102-N being executed concurrently by the processor 134, as detailed elsewhere in this disclosure. In some examples, a single instance of the assay module may interact with an analyzer performing multiple assays, as detailed elsewhere in this disclosure. FIG. 1 depicts three such assay module instances: a first assay module instance 102-1, a second assay module instance 102-1, and an Nth assay module instance 102-N. Other programs 112 may also be stored in memory for execution by the processor 134.
The user interface for starting a test and the user interface for reporting results for different modalities are not compatible. The information required for the initiation of a PCR test is not identical to that required for the initiation of a cytometry test. Likewise, the reporting of results between the two aforementioned modalities are fundamentally different (a Ct value or viral load in the former, a count of the number and types of cells in the latter). This holds true for any two or more given modalities.
Along with the reasons noted above, combining modalities in a commercially released human-intended IVD instrument after-the-fact in current solutions is not possible. The configuration of tests the device can operate is unchangeable after regulatory approval.
A system may have several main components: the assay module package, a communication interface, a set of static configurations, and a virtual environment.
In an example, the assay module package is a software artifact which encapsulates the next three components. It can be of any format, such as zip, tar, etc.
A communication interface communicates into and out of the assay module instance from the host program or between the host program and the analyzer. By means of this communication interface, data is sent from the analyzer to the host program and from the host program into the assay module for analysis. Also by means of the communication interface, the results of analyses are transmitted out of the assay module to the host program, internal process statuses are reported, and configuration information regarding the assay being run is sent to the analyzer.
The set of configurations defines the following: User interface (UI) elements and interface logic, such as valid and invalid field values, for initiating the specific assay being run. The UI elements and interface logic such as printing options and display configurations, for reporting the results of the specific assay being run. The configuration also includes a recipe which defines the set of hardware control and measurement steps to run a specific assay.
The virtual environment may comprise two sub-programs: an algorithm and a set of business logic. The algorithm and the business logic may be written in a variety of programming languages or packages such as Python or Matlab. The algorithm may be packaged in a manner to eliminate any external dependencies. The algorithm carries out the analysis of raw data, and outputs extracted signal information or an intermediate result. The business logic may analyze the signal information or intermediate result and may supply the final result (e.g., cell count, positive/negative, etc.).
In an example, as illustrated in
In an example, illustrated in
When the first analyzer 200-1 finishes the test(s) and has the raw data ready, the host program 106 transfers the raw data to the first assay module instance 102-1. The first assay module instance 102-1 then processes the data, determines a final result and sends the final result to the host program 106 for display to a user. In an example, the first assay module instance 102-1 may store the final result in, for instance, a specific memory address or may write the final result to a specific location on a storage medium 130 (e.g., on a hard drive). The first assay module instance 102-1 may also write the raw data, the processed data, or the final result to a storage medium 130.
In the example of having multiple analyzers a user may insert each test card 202 into each test card receptacle 204 of each analyzer 200 and initiate an assay module instance 102 to receive the data, process the data, and provide a final result. In some examples, the assay module instance 102 may be initiated first and then the test card 202 may be inserted into the receptacle 204. In other examples, the test card 202 may be inserted into the receptacle 204 first and the assay module instance 102 started second. In an example, the host program 106 may be started first and information entered (e.g., patient name, number, test name, date, location, etc.) prior to starting an instance of the assay module 102. In an example, the test card 202 may comprise a bar code, a QR code, or other code, which may be scanned automatically so that the user interface 106 recognizes the test or tests associated with the scanned test card 202 and automatically starts the assay module instance 102 (or instances) with the proper information required to run the test (e.g., recipe information for the analyzer 200 to perform a PCR assay on the sample in the scanned and inserted test card 202). In an example, once the test or tests finish, the host program 106 may pull the raw data from the analyzer 200 and send the raw data to the associated assay module instance 102. The assay module instances 102 may calculate an intermediate result by processing the data and then may return a final result to the host program 106. The host program 106 may store the result and the raw data in a storage medium 130 and may display the results to a user. Since there are multiple tests being performed, the tests may be performed in parallel, partially in parallel, partially in series, or fully in series, as specified by a user or by the test recipes themselves. The assay module instances 102-1, 102-2, . . . 102-N may also operate in parallel, partially in parallel, partially in series, or fully in series, as desired by the user or by the host program. If the control computer 100 has multiple processors, the individual assay module instances 102 may operate fully in parallel. If the control computer 100 has a single processor 134 (or fewer processors than assay module instances), then two or more assay module instances 102-1, 102-2, etc. may operate concurrently on the same processor 134.
In another example, depicted in
In the example shown in
There is a significant benefit to having an assay module instance 102 operate independently of the user interface/host program 106 and also independently of other assay module instances. In order to be sure that no individual test interferes with any other test (or, indeed, that no other program on the computer 100, including malware, viruses, and the like interferes with operation of the assay or interferes with analysis of the data), each assay module instance 102 can be made immutable in the same way that the analyzer 200 has hardware 206 which cannot be modified without negatively impacting the reliability of the test results. Isolating the software which analyzes the raw data allows a user to be confident of the reliability of the tests. In some circumstances, it may not be possible to modify an analyzer, or its software, for instance, after it has been approved by a regulatory body.
In this manner, therefore, the assay module instances 102-1, 102-2, . . . 102-N may each be qualified at different times and each one is “locked down” or made immutable once it has been approved by regulators. If a new test is added to a card, and the new test achieves regulatory approval with, say, an updated version of software (e.g., a newly trained machine learning model using data collected after approval of the first test, or a new random number generator is used from an update in the operating system), then the old analysis may still operate since the old analysis may operate independently of the new analysis or the new test. As noted elsewhere in this disclosure the raw data is collected only at the analyzer, and the analysis, data processing, and production of the final results only occurs in a specific assay module instance.
In the example shown in
Achieving isolation of the assay module instances may require multiple steps during software development. External dependencies of each of the assay module instances must be eliminated. For example, an assay module instance may call upon an external code library with advanced processing options as part of the data analysis. Since such code libraries may be updated as newer or more efficient methods become available, an external library may change over time which may, in turn, alter the results. In an example, the specific sections of code in a library accessed by an assay module instance when it passed regulatory compliance, may be written to a specific location in the storage device which is not accessible to other programs so that the libraries accessible by the assay module instance are also made immutable. In other circumstances, when calling a library, the program may access an external server which has its libraries regularly updated or changed. If the second assay module instance requires a library which has been updated after the library required by the first assay module instance, then both of these libraries could be stored on the control computer storage, but each assay module instance would only be permitted to directly access the appropriate code library for itself and not to access any other such code libraries. In an example, two assay module instances may access the same general library for some components of the analysis. If both require the same components, then they could both access the same library or they could access different librarys. For example, two or more libraries are kept separate in order to decrease a risk of unintended effects (e.g., interdependencies between assay modules). However, in an example, if one assay module instance requires some specific components from a library, then that assay module instance may access these specific components independently of any other assay module instances.
In an example, it is possible to include all the code library components (or a subset of library components), in each assay module instance as it is instantiated. In another example, a set of core library components is included in, and accessible by, each assay module instance. If each assay module instance needs to use some of the core components of the library, then the computer may store one set of such core components in a library accessible by each assay module instance. In an alternative example, core components of a library used by more than one assay module instance may be accessed by each assay module instance as needed, but specific components needed by a single assay module instance may be accessible by that specific assay module instance only.
In an example, of accessing a function or component from a code library, if the code is accessed, then the second assay module instance which uses the component must be so designed so that if the first assay module instance uses the code snippet, then the second assay module instance's intermediate results are not affected. In an example, if a first assay module instance calls for a random number from, for example, a pseudo-random number generator from the operating system 120 then subsequent outputs of the pseudo-random number generator may be influenced by the first call. In this example, if any additional random numbers are called for by a second assay module instance, then they would be influenced by the first call for a random number by the first assay module instance. In such an example, each assay module instance must be so designed that they rely not on any single output of a pseudo-random number generator, but on an ensemble of many such outputs. For example, some machine learning methods start with a random assignment of certain inputs and then iterate until the outputs do not change to within a threshold amount. If an assay module instance uses such a method, then it must call the method many times to be reasonably certain that any single random assignment does not distort the output. Thus if a second assay module instance also uses a set of random assignments, the second assay module instance must also call upon a large enough set of such assignments that the output is reasonably unlikely to be distorted by a particular set of initial conditions. In some computers, the random number generator is a hardware random number generator, for which an additional software instance would not necessarily affect the output of the random number generator, but the same logic applies to the design of the different assay module instances that enough random assignments would be required to avoid any distortion of results based on a single random number or single random assignment.
Another factor in isolating different instances of the assay module is insuring that the memory allocated to each instance is not accessible by the other instances and, indeed, not accessible by any other program 112 running on the computer, with the exception, under certain circumstances, of the host program 106 or of the operating system 120. Since the same methods are used to prevent malware or malicious users from corrupting computer functions generally, analogous techniques and methods may be employed here. For example, general computer memory allocated to each instance may be assigned randomly in blocks to prevent other programs from finding the proper memory addresses to overwrite with alternative instructions. In another example, when a program accesses a memory address to which it does not have permission, an alarm may notify the user that there has been some contamination of the process or that another program attempted to read or write to a memory address allocated to the assay module instance.
In an example, the overall flow may follow the steps from Table 1.
The host program 106 sends the raw data 804 to the assay module instance 102 by an API. The assay module instance 102 performs the algorithm 412 on the raw data 804 to produce processed data or an intermediate result. The result logic 414 is applied to the processed data to produce a final result 806. The final result 806 is sent to or shared with the host program 106. The host program 106 then displays the final result 806 to a user on, for example, a results screen 820. In another example, the final result 806 may be transmitted to a user's personal electronic device rather than displayed on a results screen 820 on the interface computer 100. In another example, the host program 106 may write the final result 806 to storage 130. The storage 130 may be nearby or even inside the control computer 100 or the storage 130 may be remote from the control computer 100. For this reason, both the results screen 820 and the storage 130 are shown in a dotted line as being part of the control computer 100 since these items may be physically separated or remote from the control computer 100 and the analyzer 200.
Note that multiple assay module instances can be running at the same time, independent of each other (except for hardware resources such as RAM or CPU utilization). The host program 106 (e.g., Fluxergy Works) becomes a harness which spools up and shuts down assay module instances 102. The host program's 106 only functionality being that which reads data from an assay module, coordinates assay modules, and allows users to interact with test results. In an example, the assay module instance 102 may write the final result 806 to a hard drive or other storage medium 130 and then share with the host program 106 the location of the stored final result 806. In another example, the assay module instance 102 may store the final result 806 in memory 130 (e.g. RAM) and may send the memory address directly to the host program 106. In this example, the host program 106 may write the final result 806 to storage 130.
In this disclosure, each new assay and/or modality can be loaded, modified, and unloaded independently of any other. There are no dependences between assay modules of differing assays. Additionally, assay modules for a given assay do not share a runtime environment when operating. In this way, the instrument 200 and UI 106 do not require patches when a new assay is produced, even if the assay is of a different modality. This method of isolating each instance of an assay module 102 has regulatory benefits in that no patch is needed on the firmware or UI to analyze the raw data 804 and produce a final result 806. All regulatory risk can be isolated to the assay module 102, which is validated alongside the assay undergoing regulatory approval.
Additionally, the instrument can be guaranteed to operate in the same manner regardless of assay or modality, reducing patient risk when introducing new products to market.
Other benefits include evaluating the algorithm with in-silico analysis which matches the final product more closely, rather than a ported version of the algorithm contained on the instrument (which may be in a different programming language more suited for instrument control).
While the methods and systems described in this disclosure are not limited by the types of assays being performed by the analyzer, some example assays are shown in Table 2 below.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various examples. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or that carry out combinations of special purpose hardware and computer instructions.
Although specific examples have been described, it will be understood by those of skill in the art that there are other examples that are equivalent to the described examples. Accordingly, it is to be understood that the examples described are not to be limited by the specific illustrated examples, but only by the scope of the appended claims.
This application is a non-provisional application of, and claims priority to, U.S. Provisional Patent Application No. 63/597,255, entitled “Modularized Assay-Specific Software Interface”, filed on Nov. 8, 2023, the entire disclosure of which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63597255 | Nov 2023 | US |
