Laboratory instrument data manager

Abstract

A data manager for laboratory instruments can store a respective driver for different types of laboratory instruments. The driver for a given type of laboratory instrument can establish a connection with a laboratory instrument of one of the plurality of types, receive data from the laboratory instrument in a respective format, and convert the data from the respective format to a common laboratory information management system (LIMS) format. The data manager can upload the data in the common LIMS format to a LIMS.

Description

TDCC#86232-WO-PCTLABORATORY INSTRUMENT DATA MANAGERTechnical Field

[0001] The present disclosure relates to a laboratory instrument driver for data transfer to a laboratory information management system (LIMS). Such techniques can be particularly useful to simplify and streamline laboratory operations by automatically and efficiently transferring sample result data directly into the LIMS.Background

[0002] A LIMS is a software-based solution with features that support laboratory operations. Examples of such features include workflow and data tracking support, a flexible architecture, and data exchange interfaces. The features and uses of a LIMS have evolved over time from sample tracking to enterprise resource planning tools that manage multiple aspects of laboratory environments. Some LIMSs may include data management, data mining, data analysis, and electronic laboratory notebook integration. LIMS functionality can include reception and logging of a sample and associated customer data, assignment, scheduling, and tracking of the sample and associated workload, the processing and quality control associated with the sample and the utilized instruments and inventory, the storage of data associated with the sample, and the inspection, approval, and compilation of the sample data for reporting and / or further analysis.

[0003] Existing solutions for transfer of sample results to LIMS fall into three main categories: single-vendor solutions, multi-vendor solutions, and data integration tools. Singlevendor solutions enable data transfer and result extraction for a laboratory instrument manufactured by a single vendor. Multi-vendor solutions work with a variety of instruments manufactured by different vendors. Data integration tools include software systems that enable customization at each individual integration.Summary of the Disclosure

[0004] The present disclosure is directed to software for managing data transfer from laboratory instruments, referred to herein as a lab manger. The lab manager can automate entire lab data transfer while other solutions are limited to certain instruments or instrument-types. ForTDCC#86232-WO-PCT example, other solutions may only be able to process files and not read direct laboratory instrument data streams. In testing, at least one embodiment was found to save five minutes of manual work out of the fifteen minutes typically required per sample. Benefits include increases in lab technician efficiency, reductions in result entry errors, and faster result entry into LIMS. Lab manager applications can also provide a sample queue, which pre-populates with active samples, and a data review portal to ensure data integrity in manufacturing quality labs.

[0005] The above summary is not intended to describe each disclosed embodiment or every implementation. The description that follows more particularly exemplifies illustrative embodiments. In several places throughout the application, guidance is provided through lists of examples, which examples can be used in various combinations. In each instance, the recited list serves only as a representative group and should not be interpreted as an exclusive list.Brief Description of the Drawings

[0006] Figure l is a block diagram of a system including a laboratory instrument data manager.

[0007] Figure 2 is a block diagram of the lab manager architecture.

[0008] Figure 3 illustrates an example of a graphical user interface associated with a lab manager.

[0009] Figure 4 illustrates an example of a graphical user interface associated with a data portal associated with a lab manager.

[0010] Figure 5 is a flow diagram illustrating a method for laboratory instrument data management.

[0011] Figure 6 illustrates an example machine within which a set of instructions, for causing the machine to perform various methodologies discussed herein, can be executed.Detailed Description

[0012] Currently, a significant portion of quality sample result data from laboratory instruments that is used to support a product release is first manually transcribed to paper and then manually entered in the LIMS. Automation of this data transfer step, particularly in quality labs, not only streamlines the lab operations and reduces repetitive work for the lab team but itTDCC#86232-WO-PCT also dramatically reduces the likelihood of data transcription errors which can result in costly customer complaints. As an example, some laboratory sites may conduct more than 1.2 million analytical tests each year where the results are manually sorted, handled, and transferred from most laboratory instruments to LIMS.

[0013] Single-vendor solutions for transfer of sample results to LIMS often work out-of- the-box with known laboratory instruments, but are limited because they only work with a small subset of the laboratory instruments that are used in many labs. However, some labs have instruments manufactured by different vendors, which leads to having multiple different software applications in each lab resulting in a complex solution with each application having its own initial software and possibly recurring license costs. Although data can be transferred, these solutions often do not provide a fully customizable output that can work with existing LIMS interfaces.

[0014] Multi-vendor solutions are often much more expensive and are often customized. Another downside of multi-vendor solutions is that the software vendor may not keep up with latest hardware / firmware updates for all laboratory instruments and they may not offer integration options for all laboratory instruments that a company might use.

[0015] Although data integration tools provide the highest level of custom integration, they also require much more in-house technical expertise to use and maintain. Additionally, the cost structure is often based on the number of unique integrations in addition to requiring the inhouse expertise to develop the integration solution.

[0016] At least one embodiment described herein addresses the above and other deficiencies by providing a unified system that can manage the data from the laboratory instruments and automatically report it to LIMS, in some cases, after an electronic review. The system is compatible with a large variety of laboratory instruments commonly found in labs, allows for the addition of new laboratory instruments as needed, is capable of flexible mapping of data to different tests in LIMS, can output data in a format that can be customized as needed (e g., so that an entity making use of the solution is not locked into a particular instance of a LIMS), and is relatively low-cost and maintainable by lab staff. Such a solution is estimated to generate an 18 to 25 percent increase in efficiency in laboratory operation.

[0017] At least one embodiment includes drivers for laboratory instruments that can convert the data from a native format associated with respective laboratory instruments to aTDCC#86232-WO-PCT common format associated with the LIMS. Some embodiments includes a suite of applications to address the limitations of currently existing solutions for automated transfer of analytical data to LIMS in manufacturing labs. Examples of such applications include the lab manager, which can convert direct laboratory instrument outputs into sample result fdes that are compatible with existing LIMS import interfaces (e g., a file format referred to as RESTXT). The data portal provides a user-friendly interface for one-click data reviews before the data is released to LIMS to streamline data review and maintain the highest data integrity possible in LIMS. The sample queue application can automatically query LIMS and push active sample identifiers (IDs) to the lab manager systems throughout the lab which increases data integrity by eliminating manual sample ID entry by the lab team.

[0018] The figures herein follow a numbering convention in which the first digit or digits correspond to the drawing figure number and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. For example, 104 may reference element “04” in Figure 1, and a similar element may be referenced as 304 in Figure 3. Analogous elements within a Figure may be referenced with a hyphen and extra numeral or letter. Such analogous elements may be generally referenced without the hyphen and extra numeral or letter. For example, elements 320- 1, 320-2, and 320-3 in Figure 3 may be collectively referenced as 320. As will be appreciated, elements shown in the various embodiments herein can be added, exchanged, and / or eliminated so as to provide a number of additional embodiments. In addition, as will be appreciated, the proportion and the relative scale of the elements provided in the figures are intended to illustrate certain embodiments of the present invention and should not be taken in a limiting sense.

[0019] Figure l is a block diagram of a system including a laboratory instrument data manager (“lab manager”) 104. Data can be received by the lab manager 104 from a sample queue 102 associated with laboratory instruments. The sample queue 102 is illustrated as a graphical user interface for a query sample manager for active samples in the lab.

[0020] The lab manager 104 is an application for enabling efficient data transfer in laboratory environments. The architecture of the lab manager 104 is split into features (like logging, data mapping, user interface, automatic backups), laboratory instrument drivers (which contain information on how to connect to and process data from a laboratory instrument), and configurations (which contain lab, business, and site specific settings for LIMS 108 integration).TDCC#86232-WO-PCTThe separation of these components in the lab manager 104 provides a highly flexible application that can be leveraged across different laboratories for an entity to enable and streamline digital data transfer in multiple discrete labs.

[0021] The lab manager 104 can be used to build and maintain flexibility in the entire system. This flexibility enables adding new laboratory instruments and new sample results, but also allows for different labs, sites, or businesses to use the same type of laboratory instrument in different ways. This flexibility is achieved by using abstract classes to define a specific interface for the laboratory instrument drivers, separating common functionality from the specific implementation of a laboratory instrument, and by providing customizable configuration items to control the behavior.

[0022] The data portal 106 is a graphical user interface that allows reviewing data after it has been processed by the lab manager 104, but before it goes into the LIMS 108. One click of a button allows for rejecting that data, which can optionally include archiving the data, or accepting and sending the data to the LIMS 108. Such embodiments are particularly useful for use with laboratory instruments that are file processors, which process data automatically to the LIMS 1018. In some embodiments, the data portal 106 can be bypassed and the data from the lab manager 104 can be sent directly to the LIMS 108 without first being handled by the data portal 106.

[0023] The data portal 106 includes a dashboard where data is displayed as processed by the lab manager 104 allowing the user to reject data or send to the LIMS 108. The lab manager 104 can process data from the laboratory instruments and the data portal 106 can display the data to an operator. Rather than setting the output folder of the lab manager 104 to the LIMS 108 drop folder, the lab manager 104 can transfer files into a file-share where the data portal 106 can monitor the data. After a user reviews the data on the data portal 106 and, for example, clicks send, the data can be transferred to the LIMS 108 drop folder.

[0024] Figure 2 is a block diagram of the lab manager architecture. The instrument drivers 210 can include a respective driver for each type of laboratory instrument (e.g., vendor and model class). The instrument drivers 210 contain information related to the connection type (e.g., RS-232, USB, ethernet, etc.), data format and / or file type (e.g., CSV, TXT, XML, etc.) along with specific settings such as standard fields and custom fields. An instrument driver 210TDCC#86232-WO-PCT also defines what information is possible to extract from the laboratory instrument and the code to parse the raw laboratory instrument data into the defined sample results.

[0025] The configuration 212 includes transfer options that can be modified to alter the behavior of the data transfer. The configuration 212 represents how the processed sample results from the instrument driver 210 are mapped into the LIMS server. For example, the configuration 212 can define which LIMS analysis (test) and component (result) correspond to the pH test done in a specific lab.

[0026] The framework 214 includes features that are shared across instrument drivers 210 for different types of laboratory instruments and provides a user interface for interaction with the system. The framework 214 contains the definition for the abstract drivers and how they are implemented within the system. An abstract driver is a driver that defines functionality for a laboratory instrument, regardless of type. The framework 214 is also responsible for running the drivers and processing and / or translating the instrument results into a format that can be transmitted to LIMS for processing, as illustrated at 216. The framework 214 contains functions for logging results and errors to enable advanced troubleshooting and to backup settings to our application server.

[0027] Instrument drivers 210 are split into two categories, one category for laboratory instruments that operate with an accompanying file processor and another category for laboratory instruments that operate without an accompanying file processor. Laboratory instruments that operate without an accompanying file processor run standalone or without a computer and the data export from the instrument to the lab manager computer uses a communication path such as a cable to transmit the data. These systems can use specific connection settings and listeners for incoming data. Laboratory instruments that operate without an accompanying file processor typically run from a computer (e.g., using vendor software) and the data export is a file that is saved on the computer. The file processors can be configured with the location of the output files. The output files can be processed at any time and in any order. Further, the sample ID, which is an identifier of the sample being operated on by the laboratory instrument, can be provided in the file for instances in which the samples are set up and run in the vendor software. For laboratory instruments that operate without an accompanying file processor, however, the sample ID may not be provided in the data stream because it was never entered into the laboratory instrument (e.g., for a pH meter or a balance). Because of the differences in the rawTDCC#86232-WO-PCT data format and the handling of the data and sample identification, the two different types of laboratory instruments can be handled differently in the framework 214.

[0028] Abstract classes, such as helper classes, configuration classes, an abstract file processor class, a file processor class, an abstract instrument class, and / or an instrument panel class, can be used to define a specific interface for the laboratory instrument drivers 210. Examples of the helper classes include a configuration class, an event arguments class, a logger class, a serial file-receive class, and an update-me class. The configuration class can manage interaction between the user interfaces and the configuration classes. The configuration class can include methods to create, read, update, and delete objects that represent configurations for various aspects of the framework 214. The event arguments class can include properties for events that can occur by the instrument-specific drivers and received by the framework 214 to manage and process sample result data. The Logger class can include status and data logging functionality, which can log updates and errors, write result data from laboratory instruments into a log file, and log the sample history (e.g., user login / logout, sample ID, data received, data sent) into a local database. The serial file-receive class can establish a connection with remote computers to receive files. The update-me class can enable automatic and / or on-demand updates to the framework 214 by checking for the latest version from an application server and prompting for updates.

[0029] The configuration classes can include a file processor configuration class, a filereceive configuration class, an import export class, an instrument configuration class, a method configuration class, a sample structure class, a system configuration class, a system preferences class, and / or a usage data class. The file processor configuration class can include settings (e.g., instrument alias and ID, folder to monitor for files, folders for archiving files and moving error files, and where to send the data to LIMS) and data mappings (e.g., information used to route incoming data from the laboratory instrument to the desired location in LIMS) for file processors. The file-receive configuration class can include settings (e.g., name, receiving COM port, folder locations) for file receivers to send files between computers that are not on the enterprise network. The import-export class can include a combined set of instrument configurations, instrument method configurations, and file processor configurations used to import and export settings between systems or to clone laboratory instruments on the same computer if duplicate instruments are being used. The instrument configuration class can includeTDCC 86232-WO-PCT settings for laboratory instruments such as alias and ID, instrument-specific settings corresponding to configured controls, automation options for skipping data review or panel reset, and how and where to send data to the LIMS. The method configuration class can include the data mapping for instrument methods to route incoming data from the laboratory instrument to the desired location in the LIMS. The sample structure class can include the structure of the sample queue for the sample queue 102 illustrated in Figure 1, which can include multiple samples with sample ID and list of analyses including a name, replicate number, and components. The sample structure can match the LIMS configuration where tests include components and are added to samples based on templates. The system configuration class can include information used to trace the computer and associated settings in the lab manager application server, such as location, description, and version number. The system preferences class can include configuration items for the framework 214 such as default LIMS location, archive and error folder paths, output file types and extensions, settings for sample reports, and settings for sample queue integration. The usage data class can include the structure for how usage data is stored. The system can keep track of the numbers of data transfer events and data points transferred for each laboratory instrument, which can be beneficial for monitoring the health of the system.

[0030] The abstract file processor is the parent class of the file processors in the framework 214. This class defines the properties and functions that each file processor implements and contains functions that the child file processors can use to simplify common actions, like sending processed sample results and error messages. The class contains a function that runs to process files in the file drop folder.

[0031] After object instantiation, the file processor ID is set by the file processor class. When the load settings function is called, the file processor ID is used to load the saved file processor settings from the file processor configuration file. After the settings are loaded and the object is configured, a call to process files will attempt to process files in the file drop folder. First, this function checks the drop folder for files. For each file in the folder, it first compares the file extension to see if the file is valid. If the extension is invalid, the file is moved to the errored folder with a message about the file type being incorrect. If the file extension is correct, the file processor attempts to process the file using the child functionality. If an error occurs, theTDCC#86232-WO-PCT file is moved to the error folder along with an error message based on the exception. If the file is processed successfully, the file is either moved to the archive folder or deleted.

[0032] The abstract file processor class defines three custom events: on-data-received, on-error, and on-request-stop-processing. The on-data-received event is used to pass sample results from the child file processor implementation to the file processor class for processing. The on-error event is used to pass error messages encountered during processing to the file processor class for more detailed error logging. The on-request-stop-processing event is used to interrupt file processing when requested from the user interface. This event allows processing a batch of files to be stopped in the middle after the processing has already been requested.

[0033] The functions that are provided for the child file processor implementations allow for various methods to pass sample result data for processing into LIMS. If the available data fields are defined, only the sample ID and the actual data values need to be provided. If the available data fields depend on the instrument method (e g., with a titrator or chromatography system), custom data fields can be used to increase the flexibility of the instrument drivers. In these cases, the data field names, data values, and data field units can be provided along with the sample ID. Some other parameters include the measurement date and time and a method name that can be used for advanced data mapping into LIMS. Each of the different functions has an implementation for processing files where the data is sent to LIMS or processing a file in test mode to simply report a result back to the user.

[0034] The file processor class is a wrapper that combines the instrument-specific abstract file processor implementation, the file processor configuration which includes the LIMS data mapping, and the connection to the other services required for receiving, processing, and logging data. This wrapper also exposes some of the settings and counters to the user interface to enhance the user experience, such as by showing the number of processed and errored files or to navigate to specific folders.

[0035] The file processor object is created and the ID is provided therewith. On creation, the object creates references to the logging services and loads the file processor configuration. Based on the configuration, the correct implementation of the abstract file processor class is created using the abstract interface. The new object is configured and the event handlers are attached to the events.TDCC#86232-WO-PCT

[0036] The process files function is called from the main form to initiate processing of files by the abstract file processor implementation. The resulting data is handled by the on-data- received event handler. This event handler first writes the received data from the file processor into the data log and updates the sample history. Next, the received data from the event is mapped against the file processor data mapping grid to correctly assign values to certain LIMS analysis and component pairs. Finally, the mapped data is exported by the configs class based on the configured settings and the file processor usage is incremented. If an error occurs during processing, the on-error event handler simply writes the error message into the log for troubleshooting.

[0037] The test process file function is used to test the data processing for a single file. This is useful during initial configuration to ensure the file export settings from the laboratory instrument or vendor software are configured correctly and to make sure that the data mapping method is properly set up. After verifying the requested file has the correct file extension, this function calls the test process file function of the abstract file processor implementation which returns the data object instead of throwing the event to the on-data-received event handler. The data object is then used to generate a message to the user which either contains an error message about why the data processing failed or contains the processed data mapped to the LIMS analysis and components. It also specifically calls out any missing data fields if applicable.

[0038] The abstract instrument is a form that is the parent class of the instruments in the framework 214. Similar to the abstract file processor class, this class defines the required properties and functions that each child instrument implements and contains other useful functions that simplify the creation of new instrument drivers.

[0039] The abstract instrument class defines four functions that each child instrument implementation overrides: sub-load-form, sub-connect, sub-get-data (if enabled), and subdisconnect. These four functions provide the context on how the instrument-specific controls are populated and how the instrument connection is established and prepared to receive incoming data. The sub-load-form function populates the instrument-specific settings form controls with values loaded from the instrument configuration. The sub-connect function creates the connection to the instrument and start to monitor for incoming data. The sub-get-data function sends a command to the instrument to request data. The sub-disconnect function cleanly disconnects from the instrument.TDCC#86232-WO-PCT

[0040] The abstract instrument class defines three custom events: on-data-received, on- connected-changed, and on-instrument-error. The on-data-received event is used to pass sample results from the child instrument implementation to the instrument panel class for processing. The on-connected-changed event is used to notify the user interface if the connection to the instrument is established or lost. The on-instrument-error event is used to pass error messages encountered during data processing to the instrument panel class for more detailed error logging.

[0041] The functions that are provided for the child instrument implementations allow various methods to pass sample result data for processing into LIMS. Like the functions in the abstract file processor class, these functions provide a wide variety of possible inputs based on the specific situation for each instrument. Unlike the functions in the file processor class, there are no test functions. Testing for the instrument drivers is performed using the lab manager computer connected to virtual COM ports where data is streamed from the lab manager for simulating various connected instruments.

[0042] The instrument panel control is a wrapper that combines the instrument-specific abstract instrument implementation, the instrument and method configurations which include the LIMS data mapping, and the connection to the other services required for receiving, processing, and logging data. This wrapper also contains a queue of active samples that allows for more complex handling of incoming data. The wrapper is a custom control that provides a user interface for the laboratory instrument.

[0043] Figure 3 illustrates an example of a graphical user interface (GUI) associated with a lab manager 304. The GUI displays three different instrument panels 320-1, 320-2, 320-3 for three different instruments (Instrument 1, Instrument 2, Instrument 3) with the instruments tab 324 having been selected on top of the GUL The instruments tab 324 can display the connected instruments in the instrument panels 320.

[0044] Each instrument panel 320 includes the laboratory instrument alias (e.g., “pH” for Instrument 1, which can be a pH meter, for example), the sample queue grid, sample queue grid controls on the right, and the laboratory instrument controls along the bottom. The Connect / Disconnect button is used to connect to and disconnect from the laboratory instrument. The Get Data button is enabled if the instrument can retrieve data on command. When pressed, this would send a command to the instrument requesting data. The Settings button is used to show the instrument-specific settings form that contains controls which configure the instrumentTDCC#86232-WO-PCT connection. These settings may include the COM port or IP address along with any required baud rate or other connection settings. The sample queue controls (from the top) let the user move a sample up in the list, move a sample down in the list, delete a sample from the queue, or add a new sample to the queue.

[0045] When the instrument panel 320 object is created a respective ID is provided therewith. On creation, the object creates references to the logging services and loads the instrument configuration and the configurations for available methods. Based on the configuration, the correct implementation of the abstract instrument class is created using the abstract interface. The new object is configured, and the event handlers are attached to the events. A new sample queue list is created to hold pending and active samples.

[0046] The sample queue list is a list of a custom sample queue object class which holds the sample ID, the current method ID, the instrument method data mapping grid, and the data event object once it is received from the laboratory instrument. This list is bound to the data grid with certain exposed properties populating the grid shown in the user interface. This sample queue list enables the lab users to set up and run a batch of samples without intervention between each sample which increases the flexibility to integrate the lab manager 304 into existing lab work processes. When data is received from the laboratory instrument, it is placed into the first entry in the sample queue that has not received data. If there are no pending samples without data, a new entry is added. Once the sample ID and data have been received, the object attempts to map the received data based on the selected instrument method. If successful, the data can be reviewed and sent to LIMS. If the data mapping is not successful, it can prompt the user to check the method to ensure the correct instrument method is being used to map the data into LIMS. If a different method is selected, the data mapping is retried.

[0047] The status fields shown in the instrument panel 320 for each sample in the grid can be color coded based on the progress. For example, red means the sample either needs the sample ID or has not yet received data. Yellow means the sample data is ready to be reviewed. Green means the sample data was reviewed and sent to LIMS. Based on the data automation preferences, the sample will automatically progress through the stages. For example, if the autosend data option is enabled, as soon as the sample ID is entered and the data is received, it will attempt to map the data and send it to LIMS. If the auto-reset instrument panel option is enabled, as soon as the data is sent to LIMS, the sample line is removed from the list.TDCC#86232-WO-PCT

[0048] The configuration tab 322 of the GUI can be selected to access system information, system preferences, serial file transfer setup, instrument configuration, method configuration, set active instruments, file processor configuration, and configure user management. Examples of configurable settings include output file format, LIMS integration settings (e.g., appropriate drop folder in LIMS), local test folder for saving files before sending to LIMS, etc. Setting active instruments allows the user to select which laboratory instruments are displayed in the instrument panels 320 of the lab manager 304.

[0049] The file processors tab 326 of the GUI can be selected to access controls for the file processors, such as start and stop, display configured file processors and a status thereof, display the number of processed samples and the number of errored files, etc. When enabled and running, the file processors check for new files to process periodically (e.g., every ten seconds). The user can select a test file and attempt to process the file, which will provide a message to the user, either with the extracted data if successful or with an error message about why it was unable to process the file if unsuccessful. This can help the user determine if the file export settings from the vendor software are set up correctly.

[0050] Although not specifically illustrated, the sample queue can include a table showing the sample ID and sampling point for each of the open samples in the lab. The sampling point can be an alpha-numeric descriptor of the sample that may be more meaningful to a user than the sample ID. Information about tests to be run for the currently selected sample can be displayed. Information about the currently selected sample including sample ID, sampling point, analysis, and component data can be stored and / or displayed. The sample queue can bind to these objects and receive notifications when they are updated. The sample queue can use a service for retrieving samples from LIMS, a service for publishing the sample queue, and access to the application settings.

[0051] Samples can be manually added to the table by typing in the sample ID in the text box of the display and clicking a button, such as “Add”, or by scanning a sample barcode with a barcode scanner configured as a USB peripheral device. Open samples can also be automatically added to the table when group ID polling is enabled for the lab. A sample can be deleted from the table in response to the user clicking on the sample and pressing delete on the keyboard. When the user selects a sample in the table, information about the tests for that sample are loaded, including LIMS analysis and component names for each test and completion status. TheTDCC 86232-WO-PCT additional information is displayed on the sample queue. The sample queue can automatically remove a sample from the table once the associated tests are complete for that sample.

[0052] The GUI associated with the sample queue can include a settings tab for configuration of the sample queue for a specific lab. The database server and name for the LIMS instance associated with the lab can be set in the LIMS section of the settings tab. A user can click a button in the settings tab (e.g., “Test”) to verify that the entered database server and name are correct. A network folder can be displayed in the settings tab to specify where the sample queue will be published. If the lab has an associated group ID, then that can be added in a group ID polling section of the settings tab to automatically retrieve a list of open samples from LIMS tagged with that group ID. The settings tab can include a refresh rate selection to determine how often the sample queue completion status is refreshed as well as the polling rate for group ID polling. The refresh rate can also determine how often the sample queue is published to the network folder.

[0053] Figure 4 illustrates an example of a GUI associated with a data portal 406. The data portal 406 is a software tool used to review data after it has been processed by the data manager, but before it goes into the LIMS. It allows human intervention in the data manager processing of data, which may be particularly useful for use with file processors that run in the background.

[0054] The data portal 406 includes a dashboard where data is displayed as processed by the data manager, allowing the user to reject 442 data or send 440 data to the LIMS. The data manager software processes data from the laboratory instruments, where it is picked up by the data portal 406 and displayed to a user. Rather than setting the output folder of the data manger to the LIMS drop folder, the data manager can transfer files into a file-share where the data portal 406 can monitor the data. After a user reviews the data on the data portal 406 dashboard and clicks send 440, the file is transferred to the LIMS drop folder.

[0055] The graphs 444 on the right of the data portal 406 window track the usage of the data that goes through the data portal 406 over a given period of time (e.g., a year). If there are multiple data portals 406 in one lab, each data portal 406 can have its own statistics / graphs 444. The top plot gives the total number of data points that go through the system, while the bottom plot has the breakdown of the processed data by analysis for a specified period. The buttonsTDCC#86232-WO-PCT below the graph allow the user to filter by more refined periods of time (e.g., day, week, or month).

[0056] Figure 5 is a flow diagram illustrating a method for laboratory instrument data management. At block 550, the method can include storing a respective driver for each of a plurality of types of laboratory instruments (e.g., one driver for each type of laboratory instrument). The respective driver can be executed (e.g., in association with the data manager) to perform various functions. As such, at block 552, the method can include establishing a connection with a laboratory instrument of one of the plurality of types. At block 554, the method can include receiving data from the laboratory instrument in a respective format. At block 556, the method can include converting the data from the respective format to a common LIMS format. At block 558, the method can include uploading the data in the common LIMS format to a LIMS.

[0057] Although not specifically illustrated in Figure 5, the method can further include storing an abstract instrument driver (e.g., in association with the data manager) that defines various functions for a laboratory instrument, regardless of type. Examples of the functions include a first function to populate settings of the laboratory instrument from stored values, a second function to establish a connection with the laboratory instrument and monitor the connection, and / or a third function to disable the connection. Respective modifications to the abstract instrument driver can be received for each type of laboratory instrument. The respective modifications can be made to the abstract instrument driver to create the respective driver for each of a plurality of types of laboratory instruments that is stored in association with the data manager. The abstract instrument driver beneficially allows for the integration of many different types of instruments, possibly in many different physical labs, with a common LIMS for an enterprise, thereby saving time, effort and / or cost that would otherwise be used according to some previous approaches to integrating lab equipment described herein.

[0058] For a particular one of the laboratory instruments that operates with an accompanying file processor, the method can include receiving a modification to an abstract file processor driver to be stored as the respective driver. The abstract file processor driver can be stored by the data manager and can be modified for different laboratory instruments. The abstract file processor driver can define various functions, such as a first function to process the respective data and a second function to transmit the respective data after processing.TDCC#86232-WO-PCT

[0059] The method can further include storing configuration settings (e.g., in association with the data manager) for use of laboratory instruments of a same type in different laboratories, businesses, or sites that have different LIMS integration requirements.

[0060] For a particular one of the laboratory instruments that operates without an accompanying file processor, the respective driver can include information related to a physical connection type of the particular laboratory instrument, definitions of data field names, values, and units for the respective data, and instructions to append a sample identifier to the respective data. This information beneficially allows the data manager to connect to standalone laboratory instruments of various types.

[0061] For a particular one of the laboratory instruments that operates with an accompanying file processor, the driver can include information related to a file type of the file processor, definitions of data field names, values, and units for the respective data, and instructions to append a sample identifier from the file processor to the respective data. This information beneficially allows the data manager to connect to additional laboratory instruments of various types.

[0062] The method can further include storing configuration settings including a definition of test methods supported by each type of laboratory instrument. Each type of laboratory instrument can be correlated (e.g., by the data manager) with the test methods supported thereby. Results of the test methods can be mapped to a desired location in the LIMS. The method can further include displaying the data in the common LIMS format prior to the upload of the data to the LIMS. A user can be prompted for approval of the data and it can be uploaded to the LIMS in response to receipt of approval from the user.

[0063] The method can further include querying the LIMS for a respective description of each test to be run on a sample. The respective description can include a sample ID and a test method requirement of a laboratory instrument on which a respective test is to be run. The respective description can be compared with the test methods supported by the laboratory instruments. The sample ID can be added to a queue associated with the particular laboratory instrument in response to the particular laboratory instrument supporting the test requirement. The method can further include adding the respective description to the queue and displaying the queue on a monitor in physical proximity to the particular laboratory instrument to facilitate efficient operation within the lab.TDCC#86232-WO-PCT

[0064] The method illustrated in Figure 5 can be performed by processing logic that can include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In some embodiments, the method is performed by or using the system shown in Figure 6. Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, the illustrated embodiments should be understood only as examples, and the illustrated processes can be performed in a different order, and some processes can be performed in parallel.Additionally, one or more processes can be omitted in various embodiments. Thus, not all processes are required in every embodiment. Other process flows are possible.

[0065] Figure 6 is an example machine 690 within which a set of instructions 699, for causing the machine 690 to perform various methodologies discussed herein, can be executed. The machine 690 can be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine 690 can operate in the capacity of a server or a client machine in client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

[0066] The machine 690 can be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine 690 is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0067] The example machine 690 includes a processing device 691, a main memory 692 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 693 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 694, which communicate with each other via a bus 695.

[0068] The processing device 691 represents one or more general-purpose processing devices such as a microprocessor, a central processing unit (CPU), or the like. More particularly,TDCC#86232-WO-PCT the processing device 691 can be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets, or processors implementing a combination of instruction sets. The processing device 691 can also be one or more specialpurpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 691 is configured to execute instructions 699 for performing the operations and steps discussed herein. The machine 690 can further include a network interface device 696 to communicate over the network 697.

[0069] The data storage system 694 can include a machine-readable storage medium 698 (also known as a computer-readable medium) on which is stored one or more sets of instructions 699 or software embodying any one or more of the methodologies or functions described herein. The instructions 699 can also reside, completely or at least partially, within the main memory 692 and / or within the processing device 691 during execution thereof by the machine 690, the main memory 692 and the processing device 691 also constituting machine-readable storage media.

[0070] In one embodiment, the instructions 699 include instructions to implement functionality corresponding to the lab manager described herein. While the machine-readable storage medium 698 is shown in an example embodiment to be a single medium, the term “machine-readable storage medium” should be taken to include a single medium or multiple media that store the one or more sets of instructions. The term “machine-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media, whether provided in a local or distributed manner (e.g., cloud storage).

[0071] As used herein, the singular forms “a”, “an”, and “the” include singular and plural referents unless the content clearly dictates otherwise. Furthermore, the word “may” is used throughout this application in a permissive sense (i.e., having the potential to, being able to), not in a mandatory sense (i.e., must). The term “include,” and derivations thereof, mean “including,TDCC 86232-WO-PCT but not limited to.” The term “coupled” means directly or indirectly connected and, unless stated otherwise, can include a wireless connection.

[0072] Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.

[0073] The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Various advantages of the present disclosure have been described herein, but embodiments may provide some, all, or none of such advantages, or may provide other advantages.

[0074] In the foregoing Detailed Description, some features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the disclosed embodiments have to use more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.

Claims

TDCC 86232-WO-PCTClaimsWhat is claimed is:

1. A non-transitory machine readable medium storing instructions executable by a processor to: store a respective driver for each of a plurality of types of laboratory instruments, wherein the respective driver is executable to: establish a connection with a laboratory instrument of one of the plurality of types; receive data from the laboratory instrument in a respective format; and convert the data from the respective format to a common laboratory information management system (LIMS) format; and upload the data in the common LIMS format to a LIMS.

2. The medium of claim 1, further comprising instructions to: store an abstract instrument driver that defines for a laboratory instrument, regardless of type: a first function to populate settings of the laboratory instrument from stored values; a second function to establish a connection with the laboratory instrument and monitor the connection; and a third function to disable the connection; and receive a respective modification to the abstract instrument driver for each of the plurality of types of laboratory instruments, wherein the respective driver comprises the abstract instrument driver with the respective modification.

3. The medium of claim 1, wherein for a particular one of the plurality of laboratory instruments that operates with an accompanying file processor, the medium further comprises instructions to receive a modification to an abstract file processor driver to be stored as the respective driver, wherein the abstract file processor driver defines:TDCC 86232-WO-PCT a first function to process the respective data; and a second function to transmit the respective data after processing.

4. The medium of claim 1, further comprising instructions to store configuration settings for use of laboratory instruments of a same type in different laboratories, businesses, or sites that have different LIMS integration requirements.

5. The medium of claim 1 or claim 2, wherein for a particular one of the plurality of laboratory instruments that operates without an accompanying file processor, the respective driver includes: information related to a physical connection type of the particular laboratory instrument; definitions of data field names, values, and units for the respective data; and instructions to append a sample identifier to the respective data.

6. The medium of claim 1 or claim 3, wherein for a particular one of the plurality of laboratory instruments that operates with an accompanying file processor, the respective driver includes: information related to a file type of the file processor; definitions of data field names, values, and units for the respective data; and instructions to append a sample identifier from the file processor to the respective data.

7. The medium of any one of claims 1 to 6, further comprising instructions to: store configuration settings including a definition of test methods supported by each type of laboratory instrument; correlate each type of laboratory instrument with the test methods supported thereby; and map results of the test methods to a desired location in the LIMS.

8. The medium of claim 7, further comprising instructions to: query the LIMS for a respective description of each of a plurality of tests to be run on a sample;TDCC 86232-WO-PCT wherein the respective description includes a sample identifier and a test method requirement of a laboratory instrument on which a respective test is to be run; compare the respective description with the test methods supported by the plurality of laboratory instruments; and add the sample identifier to a queue associated with the particular laboratory instrument in response to the particular laboratory instrument supporting the test method requirement.

9. The medium of claim 8, further comprising instructions to: add the respective description to the queue; and display the queue on a monitor in physical proximity to the particular laboratory instrument.

10. The medium of claim 7, further comprising instructions to: display the data in the common LIMS format prior to the upload of the data; prompt a user for approval of the data; and upload the respective data to the LIMS in response to receipt of approval from the user.

Images