Methods, media, and systems for storing and retrieving chromatographic data

Abstract

Exemplary embodiments provide methods, media, and systems for providing services and systems for managing data in a chromatography data processing environment. The system can implement one or more autonomous services that read encoded data and decode the data for use by one or more applications. To communicate with the autonomous services, the autonomous services can expose endpoints that can be accessed by requesting applications. For example, the endpoints can apply decoders to read data streams generated by chromatography instruments. Each of the decoders can be configured to read differently configured data (e.g., to parse the stream in a manner based on how the instrument encoded the stream). Thus, collected data from many different instruments can be stored in a centralized repository and can be accessed by any authorized application through the endpoints. The data processing environment thus serves as a single access point for many different types of data.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 130,058, filed December 23, 2020. The entire disclosure of that application is incorporated herein by reference. Background Technology

[0003] Chromatography is a method of separating mixtures by passing them, in solution, suspension, or as vapor, through a medium in which the components of the mixture move at different rates. The components can then be analyzed to identify their presence, amount, concentration, or other properties. Chromatography includes many different techniques, such as mass spectrometry (MS), liquid chromatography-mass spectrometry (LCMS), and many others. Summary of the Invention

[0004] Exemplary embodiments relate to techniques for retrieving and processing chromatographic data in a data processing environment. Unless otherwise stated, these embodiments are contemplated to be used individually to achieve the described advantages, or in any combination to achieve synergistic effects.

[0005] According to the first embodiment, a chromatography data processing environment comprising one or more autonomous services can be provided. An autonomous service can be a computing service whose functionality is independent of other services. Although it can asynchronously provide information that can be consumed by other services (and asynchronously consume information from other services), an autonomous service avoids synchronously assisting other services through its behavior.

[0006] Each autonomous service may expose one or more endpoint interfaces. For example, these endpoints may be representation state transition (REST) ​​endpoints capable of receiving RESTful application programming interface (API) calls. Endpoint interfaces may receive requests for raw data acquired by the chromatography instrument. A data processing environment may expose multiple endpoint interfaces; for example, each autonomous service may be associated with at least one endpoint interface and may expose at least one endpoint interface.

[0007] A decoder can be associated with an endpoint interface. The decoder can be configured to interpret the raw data associated with the endpoint interface. For example, the endpoint interface can be associated with a specific type of raw data generated by a chromatography instrument in a specific acquisition mode. The instrument may output raw data streams, including, for example, binary data, information arrays, etc. The decoder can be programmed to parse the raw data streams generated by such instruments so that the data streams can be meaningfully interpreted.

[0008] An autonomous service (or another construct) can retrieve the requested raw data from a raw data repository, apply a decoder to the raw data to generate decoded data, and return the decoded data in response to the raw request. For example, the autonomous service can apply a decoder to the raw data and provide the decoded data to the requesting application, or the autonomous service can identify the decoder and provide it (or its accessible location) along with the raw data (or the location of the raw data) to the requesting application. In the latter case, the application can use the decoder to decode the data.

[0009] By presenting the endpoint interface in this way, applications can request data acquired by chromatographic instruments without needing to understand how to interpret the data. Therefore, when bringing new types of instruments online (potentially outputting data in different stream formats), it is not necessary to reprogram each application that might use the data. Because each application does not need to be programmed with the details of how to interpret every different type of data stream, more different types of data can be made available to the applications, allowing for more complex analyses. This configuration also allows multiple different types of data to be stored together in a common source structure, simplifying data retrieval and storage.

[0010] According to the second implementation scheme, the autonomous service can be a first autonomous service configured to interface with the original data repository. A second autonomous service can be provided, wherein the second autonomous service is configured to interface with a metadata catalog that stores metadata describing how the original data was collected.

[0011] In this configuration, multiple autonomous services serve incoming data requests. At least one of these autonomous services is specifically configured to respond to requests for metadata, while the remaining autonomous services respond to requests for different types of data. The autonomous service responding to metadata requests does not respond to data requests and therefore does not need to implement any functionality related to the decoder. Similarly, the autonomous service responding to data requests does not need to implement any functionality for querying the metadata catalog. When a new data type is added, a new autonomous service implementing a decoder for the new data type can be added, or existing autonomous services can be updated using the new functionality. Meanwhile, most autonomous services can remain unchanged. Similarly, if the metadata catalog API has ever changed, only the metadata processing autonomous service needs to be updated.

[0012] According to the third embodiment, the endpoint interface can be a first endpoint interface and is configured to receive requests for raw data. A second endpoint interface, separate from the first endpoint interface, can be provided, wherein the second endpoint interface can be configured to receive requests for metadata describing how the raw data was collected.

[0013] In this implementation, incoming requests are divided into metadata-specific requests and data-specific requests. Each is handled by a different type of endpoint. A third implementation can be combined with the second implementation, such that the metadata processing autonomous service implements the second endpoint interface, and the data processing autonomous service implements a copy of the first endpoint interface. This helps to isolate incoming requests and provide known endpoints to the requesting application for the appropriate type of request. This implementation can also be deployed independently, where a single autonomous service implements both the metadata-specific second endpoint interface and the data-specific first endpoint interface. Multiple copies of such an autonomous service can be provided, each implementing both the metadata endpoint interface and the data endpoint interface. Implementing both the metadata-specific endpoint and the data-specific endpoint on a single autonomous service is relatively simple, and this implementation allows for a simple scaling process (i.e., additional capacity can be achieved by providing additional copies of the autonomous service).

[0014] According to the fourth embodiment, a single decoder can be associated with multiple different endpoint interfaces. This allows the decoder to be recirculated to interpret data streams that may originate from different chromatographic device configurations but provide raw data formatted in the same way. Similarly, a single decoder can have multiple versions, each mapped to a different endpoint (similarly, if the acquisition mode can capture different types of data, different decoders can be used for the same acquisition mode).

[0015] According to the fifth embodiment, the raw data repository may include data from multiple different chromatographic devices and / or chromatographic devices operating in multiple different acquisition modes. In the fifth embodiment, the data processing environment acts as a single data source for applications, regardless of which device generates the data (or what mode the data is operated in). Calling to any application in the ecosystem ensures that any acquired data can be properly accessed and processed.

[0016] According to the sixth implementation scheme, the original data repository includes data of various different data types, and the autonomous service is one of several autonomous services. Collectively, the autonomous service can be configured to decode each of the various different data types. For example, the various different data types can be included in an interface specification that describes how to decode the various different types. The interface specification can be implemented at least partially by each of the autonomous services by implementing the corresponding endpoint interface and decoder. Different parts of the interface specification can be divided among the various autonomous services, such that each autonomous service implements a part of the interface specification, rather than all of it. Each part of the interface specification can be implemented by at least one autonomous service, such that the interface service group collectively implements the interface specification.

[0017] Because each autonomous service is assigned the task of implementing only a portion of the interface specification, each autonomous service can be simpler (as it doesn't need to worry about providing decoders and endpoint interfaces for the parts of the interface specification it doesn't implement). New autonomous services can be easily added to handle new capabilities, and it's not necessary to shut down all autonomous services when a decoder needs updating.

[0018] According to the seventh embodiment, based on the sixth embodiment, multiple autonomous services may collectively include multiple endpoint interfaces, each characterized by a data type. When an application requests data, it can invoke the original data repository or metadata catalog to identify the data type; for example, the data can be tagged with a codec key stored with the data and / or stored in the metadata. Endpoint interfaces can be data type-based callable, so once the data type is known, the requesting application can identify the appropriate endpoint interface to decode the data and can formulate appropriate RESTful API calls to communicate with the interface. This provides applications with an efficient way to identify and invoke autonomous services capable of decoding data.

[0019] These implementation schemes will now be described in detail with reference to the accompanying drawings. Attached Figure Description

[0020] For ease of identification of any particular element or action, one or more of the most effective numbers in the reference numerals refer to the reference numeral that first introduced the element.

[0021] Figure 1 An example of a mass spectrometry system according to an exemplary implementation is shown.

[0022] Figure 2 An example of a workflow for manipulating collected data according to one implementation scheme is shown.

[0023] Figure 3A A first exemplary data processing ecosystem according to one implementation scheme is shown.

[0024] Figure 3B A second exemplary data processing ecosystem according to another implementation is shown.

[0025] Figure 4 This is a flowchart depicting exemplary logic for storing and retrieving chromatographic data according to an exemplary implementation.

[0026] Figure 5 An exemplary logic for adding a new decoder to a data processing environment, according to one implementation, is described.

[0027] Figure 6An exemplary computer system architecture is described that can be used to practice the exemplary implementations described herein. Detailed Implementation

[0028] Data acquired by chromatographic instruments can be highly complex. Different types of instruments, operating in different modes and performing different experiments, can generate data in many different formats. This data may then need to be analyzed for a variety of different purposes, resulting in a variety of different types of output data. In a typical solution, each raw data stream is stored in a raw data file, and each application that processes the data stores the processed data in its own application-specific format and location. In some cases, the input raw data may be assigned to many different locations, and the same input raw data may be unnecessarily duplicated. Furthermore, the user may need to know where the data is stored and may need to program each analysis program to be able to interpret the data. Because each application needs to be programmed to learn to recognize different types of input data, in many cases, the application is only configured to interpret a minimal subset of the data types. This can limit the types of analyses that can be performed.

[0029] The exemplary embodiments described herein address these and other problems by providing services and systems for managing data in a chromatography data processing environment.

[0030] This system can implement one or more autonomous services that read and decode encoded data for use by one or more applications. To communicate with these autonomous services, they can expose endpoints accessible to requesting applications. For example, an endpoint could be a RESTful endpoint that uses a decoder to read data streams generated by a chromatography instrument. Each of these decoders can be configured to read data with different configurations (e.g., parsing the stream in a manner based on the instrument's encoding of the stream). Therefore, acquisition data from many different instruments can be stored in a centralized repository and accessed by any authorized application via endpoints. Thus, this data processing environment serves as a single access point for many different types of data.

[0031] The environment may include multiple autonomous services, each configured for a specific purpose. For example, one or more autonomous services may be configured to retrieve metadata associated with a particular raw data stream; the metadata may indicate the type of raw data, the decoder capable of decoding the raw data, and other information about the data acquisition (e.g., vial volume, sample component list, etc.). An application may invoke an endpoint associated with the metadata autonomous service to retrieve this information. Another set of autonomous services may be configured with decoders designed to parse the raw data (typically in stream form) and return a set of parsed data (e.g., a chromatographic sample set). In some implementations, multiple autonomous services may be provided to decode the data, with each autonomous service responsible for a relatively small number of data types (less than a subset of the entire set of data types). Therefore, each autonomous service requires only a relatively small number of endpoints and can be loaded into memory and run more efficiently.

[0032] These and other features will now be described in more detail with reference to the accompanying drawings.

[0033] For illustrative purposes, Figure 1 This is a schematic diagram of a system that can be used in conjunction with the techniques described in this article. Although Figure 1 A specific type of apparatus in a particular LCMS configuration has been described, but those skilled in the art will understand that different types of chromatographic apparatus (e.g., MS, tandem MS, etc.) may also be used in conjunction with this disclosure.

[0034] Sample 102 is injected into liquid chromatograph 104 via injector 106. Pump 108 can pump the sample through chromatographic column 110 to separate the mixture into component fractions based on the retention time through the column.

[0035] The output from the chromatographic column is fed into mass spectrometer 112 for analysis. Initially, the sample is desolvated and ionized by desolvation / ionization device 114. Desolvation can be any desolvation technique, including, for example, a heater, a gas, a heater combined with a gas, or other desolvation techniques. Ionization can be achieved using any ionization technique, including, for example, electrospray ionization (ESI), atmospheric pressure chemical ionization (APCI), matrix-assisted laser desorption / sorption ionization (MALDI), or other ionization techniques. Ions generated by ionization are fed into collision chamber 118 by a voltage gradient applied to ion guide 116. Collision chamber 118 can be used to transfer ions (low energy) or fragment ions (high energy).

[0036] Various techniques can be used (including those described in U.S. Patent 6,717,130 to Bateman et al., which is incorporated herein by reference), in which an alternating voltage can be applied to the collision chamber 118 to induce fragmentation. Spectra of the precursor (no collision) at low energy and the fragments (products of the collision) at high energy are collected.

[0037] The output of the collision chamber 118 is input to the mass analyzer 120. The mass analyzer 120 can be any mass analyzer, including quadrupole, time-of-flight (TOF), ion trap, sector magnetic field mass analyzer, and combinations thereof. A detector 122 detects ions emitted from the mass analyzer 120. The detector 122 can be integrated with the mass analyzer 120. For example, in the case of a TOF mass analyzer, the detector 122 can be a microchannel plate detector that counts ion intensity (i.e., counts the injected ions).

[0038] The raw data repository 124 provides permanent storage for ion counts used for analysis. For example, the raw data repository 124 can be an internal or external computer data storage device, such as a disk, flash-based storage device, etc. The acquisition device 126 analyzes the stored data. Data can also be analyzed in real time without needing to be stored in the raw data repository 124. In real-time analysis, the detector 122 transmits the data to be analyzed directly to the computer 126, rather than first storing it in a permanent storage device.

[0039] Collision chamber 118 performs fragmentation of precursor ions. Fragmentation can be used to determine the primary sequence of the peptide, and subsequently, the origin protein can be identified. Collision chamber 118 contains a gas, such as helium, argon, nitrogen, air, or methane. When a charged precursor interacts with gas atoms, the resulting collisions can fragment the precursor by breaking it down into fragment ions. This fragmentation can be achieved using the technique described in Bateman by switching the voltage in the collision chamber between a low voltage state (e.g., low energy, <5V) and a high voltage state (e.g., high energy or elevated energy, >15V), where the low voltage state is used to obtain the MS spectrum of the peptide precursor, and the high voltage state is used to obtain the MS spectrum of the collision-induced fragments of the precursor. The high and low voltages can be referred to as high energy and low energy, respectively, because high or low voltage is used to impart kinetic energy to the ions.

[0040] Various procedures can be used to determine when and how to switch the voltage used for this MS / MS acquisition. For example, conventional methods trigger the voltage in target or data correlation mode (data correlation analysis, or DDA). These methods also include gas-phase isolation (or pre-selection) coupled to the target precursor. Low-energy spectra are acquired and checked in real-time by software. When the desired mass reaches a specified intensity value in the low-energy spectrum, the voltage in the collision chamber switches to a high-energy state. High-energy spectra for the pre-selected precursor ions are then obtained. These spectra contain fragments of the precursor peptides seen at low energies. After sufficient high-energy spectra have been collected, data acquisition returns to a low-energy state to continue searching for precursor masses with suitable intensities for high-energy collision analysis.

[0041] Different suitable methods can be used in conjunction with systems such as those described herein to obtain ion information, such as combining information on precursor and product ions for mass spectrometry used to analyze samples. While conventional switching techniques can be employed, implementations can utilize the technique described in Bateman, which can be characterized as a fragmentation protocol that switches voltages in a simple alternating cycle. This switching is performed at a sufficiently high frequency to include multiple high-energy spectra and multiple low-energy spectra within a single chromatographic peak. Unlike conventional switching protocols, this cycle is independent of the content of the data. This switching technique described in Bateman provides efficient simultaneous mass analysis of both precursor and product ions. In Bateman, the use of high-energy and low-energy switching protocols can be applied as part of a single-injection LC / MS analysis of peptide mixtures. In data acquired from a single injection or experimental run, the low-energy spectra contain ions primarily from the unfragmented precursor, while the high-energy spectra contain ions primarily from the fragmented precursor. For example, a portion of the precursor ions can be fragmented to form product ions, and the precursor and product ions can be analyzed substantially simultaneously, or simultaneously, or, for example, using rapid succession, by applying rapidly switching or alternating voltages to the collision chamber of the MS module, switching between low voltages (e.g., predominantly generating precursors) and high or elevated voltages (e.g., predominantly generating fragments). MS operation employing rapid succession alternating between high (or elevated) energies and low energies, according to the Bateman technique described above, may also be referred to herein as the Bateman technique and the high-low procedure.

[0042] Data acquired using the high-low protocol allows for the accurate determination of retention times, mass-to-charge ratios, and intensities of all ions collected in both low-energy and high-energy modes. Generally, different ions are observed in the two different modes, and the spectra acquired in each mode can be further analyzed individually or in combination. Ions from a common precursor observed in one or both modes will share the same retention time (and therefore have substantially the same scan time) and peak shape. The high-low protocol allows for meaningful comparisons of the different characteristics of ions within a single mode and between modes. This comparison can then be used to group the ions observed in the low-energy and high-energy spectra.

[0043] In summary, when operating the system using Bateman technology, sample 102 is introduced into the LC / MS system. The LC / MS system generates two sets of spectra: a set of low-energy spectra and a set of high-energy spectra. The low-energy set primarily contains precursor-related ions. The high-energy set primarily contains fragment-related ions. These spectra are stored in the raw data repository 124. After data acquisition, these spectra can be extracted from the raw data repository 124 and displayed and processed using post-acquisition algorithms in the acquisition device 126.

[0044] Metadata describing various parameters related to data acquisition may be generated along with the raw data. This information may include the configuration of the liquid chromatograph 104 or mass spectrometer 112 (or other chromatographic equipment for acquiring data), which may define the data type. Identifiers (e.g., keys) of the codecs configured to decode the data may also be stored as part of the metadata and / or along with the raw data. The metadata may be stored in the metadata directory 130 in the document repository 128.

[0045] The acquisition device 126 can operate according to a workflow, providing data visualization to analysts at each workflow step and allowing analysts to generate output data by performing workflow-specific processing. Workflows can be generated and retrieved via a client browser 132. When the acquisition device 126 executes a workflow step, it can read raw data from a data stream located in the raw data repository 124. When the acquisition device 126 executes a workflow step, it can generate processed data stored in the metadata directory 130 in the document repository 128; alternatively or otherwise, the processed data can be stored in different locations specified by the user of the acquisition device 126. It can also generate audit records that can be stored in the audit log 134.

[0046] The exemplary implementation described herein can be executed in the client browser 132, the acquisition device 126, and other locations. Figure 6Examples of devices suitable for use as acquisition device 126 and / or client browser 132, as well as various data storage devices, are depicted.

[0047] Regarding the context, Figure 2 Depicting what can be made by Figure 1 This is a simplified example of the workflow 202 applied to the acquisition device 126. Workflow 202 is designed to acquire a set of inputs 204, apply multiple workflow steps or levels to the inputs to generate an output at each level, and continue processing the output at subsequent levels to generate experimental results. Note that workflow 202 is a specific example of a workflow and includes specific levels executed in a specific order. However, the invention is not limited to this. Figure 2 The specific workflow described in the document. Other suitable workflows may have more, fewer, or different levels executed in different orders.

[0048] The initial input set 204 may include a sample set 206, which comprises raw (unprocessed) data received from the chromatographic experimental apparatus. This may include measurements or readings, such as mass-to-charge ratios. Measurements initially present in sample set 206 may be measurements that have not yet been processed (e.g., to perform peak detection or other analytical techniques). Sample set 206 may include data in streaming form (e.g., a sequential list of data values ​​received from the experimental apparatus in a stable, continuous stream).

[0049] In the context of this application, sample set 206 may represent raw data stored in raw data repository 124 and returned by endpoint interface. Sample set 206 may be represented as a model of data flow (e.g., including data structures corresponding to data points collected by chromatographic equipment). Figure 3A and Figure 3B As shown, workflow 202 can be executed on sample set 206 data by an application running on acquisition device 126 and / or within data ecosystem 312.

[0050] The initial set of inputs 204 may also include a processing method 208, which may be a template method (as discussed above) applied to (and thus embedded in) workflow 202. The processing method 208 may include settings to be applied at various levels of workflow 202.

[0051] The initial input set 204 may also include a result set 210. When created, the result set 210 may include information from the sample set 206. In some cases, the sample set 206 may be processed in some initial manner when copied to the result set 210—for example, MS data may need to be extracted, smoothed, etc., before being provided to the workflow 202. The processing applied to the initial result set 210 may be determined on a case-by-case basis based on the workflow 202 in use. Once the raw data has been copied from the sample set 206 to create the result set 210, the result set 210 may be completely independent of the sample set 206 for the remainder of its lifecycle.

[0052] Workflow 202 can be divided into a group of levels. Each level can be associated with one or more level processors that perform the computations associated with that level. Each level processor can be associated with level settings that affect how the processor generates output from a given input.

[0053] Levels can be separated from each other by step boundaries 238. Step boundary 238 can represent a point where the output has been generated by the level and stored in the result set, at which point processing can proceed to the next level. Some level boundaries may require certain types of input to be crossed (for example, data generated at a given level may need to be reviewed by one or more reviewers who need to provide their authorization to cross step boundary 238 to the next level). Step boundary 238 can be applied in any direction at any time when a user moves from one level to a different level. For example, step boundary 238 exists when a user moves from initialization level 212 to channel processing level 214, but it also exists when a user attempts to move backward from quantitative level 222 back to integration level 216. The step boundary 238 can be ungated, meaning that once the user decides to move to the next level, no further input is required (or only coarse input is needed), or it can be gated, meaning that the user must provide some type of confirmation indicating that they wish to proceed to the selected level (possibly in response to a warning issued by the acquisition device 126), or a reason for moving to a certain level, or credentials authorizing the workflow 202 to proceed to the selected level.

[0054] In initialization stage 212, each of the stage processors can respond by clearing the results it generates. For example, the stage processor of channel processing stage 214 can clear all its derived channel and peak tables (see below). At any point in time, the clear stage setting can clear stage traces from the current stage and any subsequent stages. In this example, initialization stage 212 does not generate any output.

[0055] After crossing step boundary 238, processing can proceed to channel processing stage 214. As described above, the chromatographic detector can be associated with one or more channels on which data can be collected. At channel processing stage 214, acquisition device 126 can export a set of processed channels from the data present in result set 210, and can output a processed channel list 226. The processed channel list 226 can be stored in a versioned sub-document associated with channel processing stage 214, which can be included in result set 210.

[0056] After crossing step boundary 238, processing can proceed to integration level 216, which identifies peaks in the data in result set 210 based on the processed channel list 226. Integration level 216 can identify peaks using techniques specified in its settings, which can be defined in processing method 208. Integration level 216 can output a peak table 228 and store it in a versioned sub-document associated with integration level 216. This sub-document can be included in result set 210.

[0057] After crossing step boundary 238, processing can proceed to identification stage 218. At this stage, acquisition device 126 can identify components in the mixture analyzed by the chromatographic apparatus based on information in peak table 228. Identification stage 218 can output component table 230, which includes a list of components present in the mixture. Component table 230 can be stored in a versioned sub-document associated with identification stage 218. This sub-document can be included in results set 210.

[0058] After crossing step boundary 238, processing can proceed to calibration stage 220. During chromatographic experiments, calibration compounds can be injected into the chromatographic apparatus. This process allows analysts to account for subtle variations in electronics, surface cleanliness, laboratory environmental conditions, etc., throughout the experiment. In calibration stage 220, data obtained regarding these calibration compounds are analyzed and used to generate calibration table 232, which allows acquisition device 126 to correct the data to ensure its reliability and reproducibility. Calibration table 232 can be stored in a versioned sub-document associated with calibration stage 220. This sub-document can be included in results set 210.

[0059] After crossing step boundary 238, processing can proceed to quantification stage 222. Quantification refers to the process of determining the numerical value of the amount of analyte in a sample. Acquisition device 126 can use results from previous stages to quantify the components included in component table 230. Quantification stage 222 can update component table 230 stored in result set 210 with the quantification results 234. The updated component table 230 can be stored in a versioned sub-document associated with quantification stage 222. This sub-document can be included in result set 210.

[0060] After crossing step boundary 238, processing can proceed to summary level 224. In summary level 224, the results of each previous level can be analyzed and incorporated into summary result report 236. Summary result 236 can be stored in a versioned sub-document associated with summary level 224. This sub-document can be included in result set 210.

[0061] As used herein, steps may correspond to the levels described above. Alternatively, a single level may include multiple steps, or multiple levels may be organized into a single step. In any case, all activities performed in a given step should be available for performance by the same user or group of users, and each step should be associated with one or more pages describing a set of configuration options for that step (e.g., visualization options, review options, step configuration settings, etc.).

[0062] Transitions may exist at some or all step boundaries 238, but not every step boundary 238 requires a transition. A transition can represent a change in responsibility for the dataset from a first user or user group to a second different user or user group.

[0063] Figure 3A An exemplary data ecosystem for storing and retrieving chromatographic data is described 312.

[0064] The chromatographic acquisition device 326 (such as a spectrometer, chromatograph, or other device) can perform and output measurement results (e.g., as a stream of readings formatted according to the data type specific to the acquisition device 326 and / or the settings applied to the acquisition device 326). These measurement results can be stored in the raw data repository 124.

[0065] In one example, acquisition device 326 can use the acquisition controller service to acquire samples. The acquisition controller service can submit samples to the acquisition data receiver autonomous service via a RESTful API call. The acquisition data receiver autonomous service can create a sample set, which represents multiple samples fed into the instrument for analysis. In other words, the sample set is an organized sequence of several injections into the chromatography equipment.

[0066] The raw data repository 124 may include data from multiple different chromatographic devices and / or chromatographic devices operating in multiple different acquisition modes. Therefore, the data processing environment acts as a single data source for applications, regardless of which device generates the data (or what mode the data is operated in). Calling any application in the ecosystem ensures that any acquired data can be properly accessed and processed.

[0067] The sample set can be stored in the sample set model repository, while the sampled raw data blocks can be sent to a separate raw data block repository.

[0068] The acquisition device 326 can also generate metadata describing the configuration of the acquisition device 326, details of the experiment being performed, decoders configured to decode data generated for the experiment, etc. This metadata can be stored in the metadata directory 130. Similar to the raw data repository 124, the metadata directory 130 can store metadata associated with multiple different acquisition devices in various different configurations.

[0069] The raw data can be decoded by a set of decoders 304, each decoder being associated with a specific data type. For example, a decoder may be associated with a specific type of raw data generated by a chromatography instrument in a specific acquisition mode. The instrument may output raw data streams, including, for example, binary data, information arrays, etc. The decoders can be programmed to parse the raw data streams generated by such instruments, so that the data streams can be meaningfully interpreted.

[0070] In some implementations, a single decoder may be associated with multiple data types; in another implementation, multiple versions of the same decoder may each be associated with different data types. Decoder 304 may be embedded within data service 302, such as a self-contained service (e.g., via reflection).

[0071] Each autonomous service can expose one or more endpoint interfaces. A specific decoder can be associated with each endpoint interface. The decoder can be configured to interpret the raw data associated with the endpoint interface.

[0072] For example, these endpoints could be representational state transition (REST) ​​endpoints capable of receiving RESTful application programming interface (API) calls. The endpoint interface can receive requests for raw data acquired by the chromatography instrument. The data ecosystem 318 can exhibit multiple endpoint interfaces; for example, each autonomous service can be associated with and exhibit at least one endpoint interface. Applications 310a, 310c configured to process raw data can use API calls to invoke the endpoint interfaces to retrieve data.

[0073] An autonomous service (or another construct) can retrieve the requested raw data from a raw data repository, apply a decoder to the raw data to generate decoded data, and return the decoded data in response to the raw request. For example, the autonomous service can apply a decoder to the raw data and provide the decoded data to the requesting application, or the autonomous service can identify the decoder and provide it (or its accessible location) along with the raw data (or the location of the raw data) to the requesting application. In the latter case, the application can use the decoder to decode the data.

[0074] Returning to the example above, the autonomous service can retrieve sample set models from the sample set model repository and / or raw data blocks from the raw data block repository. Data can be decoded according to the decoder, and either version of the data (raw data block or sample set) can be provided to the application. The reason for providing either or both of the raw data blocks and sample set models is that, for performance reasons, the application can be adapted to use one or another representation of the data.

[0075] By presenting the endpoint interface in this way, applications 310a and 310c can request data acquired by the chromatography instrument without needing to understand how to interpret the data. Furthermore, applications 310a and 310c can store data along with metadata in a central repository in a known or generic format. The metadata indicates, for example, when the data was received by the application, when the data was processed by the decoder, the identity of the user who captured the data, the identity of the instrument that generated the data, and other information describing how and when the data was acquired. Therefore, when bringing new types of instruments online (potentially outputting data in different streaming formats), it is not necessary to reprogram each application 310a or 310c that might use the data. Because each application 310a or 310c does not need to be programmed with the details of how to interpret each different type of data stream, more different types of data can be made available to the applications, allowing for more complex analyses. This configuration also allows multiple different types of data to be stored together in a common source structure, simplifying data retrieval and storage.

[0076] In the depicted implementation, the endpoint interface has two types. The first type serves as directory endpoint 306, which is configured to receive requests for metadata. In response to receiving a request for metadata on directory endpoint 306, data service 302 can identify the corresponding metadata in metadata directory 130. Data service 302 can then return the requested metadata to the requesting application, or return the location of the metadata so that it can be retrieved by the application as needed.

[0077] Another type of endpoint interface can be used as a data endpoint 308. Typically, multiple data endpoints 308 exist within the data ecosystem 312, corresponding to multiple data types that the original data repository 124 can support. Each data endpoint 308 is characterized by a data type. When an application requests data, it can invoke the original data repository or metadata catalog to identify the data type; for example, the data can be tagged with a codec key stored with the data and / or stored in the metadata. Endpoint interfaces can be data type-based callable, so once the data type is known, the requesting application can identify the appropriate endpoint interface to decode the data and can formulate appropriate RESTful API calls to communicate with the interface. This provides applications with an efficient way to identify and invoke autonomous services capable of decoding data.

[0078] Therefore, incoming requests are divided into metadata-specific requests and data-specific requests. Each is handled by a different type of endpoint. This helps to isolate incoming requests and provide the requesting application with known endpoints for the appropriate type of request.

[0079] In this example, a single autonomous service handles requests for metadata and each different data type. While the implementation is simple, updating the entire autonomous service may be necessary whenever one of the data types changes or a new data type is added. This could lead to unnecessary downtime. Furthermore, the autonomous service needs access to both the metadata catalog 130 and the raw data repository 124. These issues can be mitigated by dividing the responsibilities of different tasks among the various autonomous services. The following will combine... Figure 3B Examples describing such environments.

[0080] Figure 3B An alternative configuration is shown, in which (1) all metadata requests are directed to a specific data service 314, which interfaces with the document repository 128 instead of the original data repository 124, and (2) data requests are submitted to any of a plurality of additional autonomous services, each having an embedded specific decoder or group of decoders and processing requests for data types specific to its embedded decoder.

[0081] In this configuration, multiple data services 320, 322, etc., serve incoming data requests. Additionally, at least one data service 314 is specifically configured to respond to requests for metadata. Data service 314, which responds to metadata requests, does not respond to requests for data and therefore does not need to implement any decoder-related functionality. Similarly, data services 320, 322, etc., that respond to data requests do not need to implement any functionality for querying the metadata catalog. When a new data type is added, a new autonomous service implementing a decoder for the new data type can be added, or existing autonomous services can be updated using the new functionality. Meanwhile, most autonomous services can remain unchanged. Similarly, if the metadata catalog API has been changed, only the metadata processing autonomous service needs to be updated.

[0082] The raw data repository 124 includes data of various different data types. Commonly, autonomous services can be configured to decode each of these different data types. For example, the various different data types can be included in an interface specification that describes how to decode the various different types. The interface specification can be implemented at least partially by each of the autonomous services by implementing the corresponding data endpoint 308 and decoders 316, 324. Each data service 320, 322 can be associated with a different group of decoders 316, 324, although there may be some overlap among decoders supported by different data services. However, no single data service implements all the decoders; therefore, the functionality for decoding different types of data is distributed across multiple data services. Thus, different parts of the interface specification can be partitioned among multiple different autonomous services, such that each autonomous service implements a part of the interface specification, rather than all of it. Each part of the interface specification can be implemented by at least one autonomous service, such that the interface service group collectively implements the interface specification.

[0083] Because each autonomous service is assigned the task of implementing only a portion of the interface specification, each autonomous service can be simpler (as it doesn't need to worry about providing decoders and endpoint interfaces for the parts of the interface specification it doesn't implement). New autonomous services can be easily added to handle new capabilities, and it's not necessary to shut down all autonomous services when a decoder needs updating.

[0084] Figure 4 An exemplary data retrieval logic 400 for storing data in a chromatography data processing environment and retrieving data from the chromatography data processing environment, according to an exemplary embodiment, is described. The data retrieval logic 400 may be embodied as a computer-implemented method or instructions stored on a non-transitory computer-readable storage medium, and may be configured to cause a processor to execute it. Figure 4 The logic blocks included. In some implementations, the data retrieval logic 400 may be configured to execute... Figure 4The computational system includes logical blocks to execute the calculations.

[0085] Processing begins at box 402. At box 404, the chromatographic apparatus can acquire data. For example, the apparatus can perform an experiment and output data as a measurement result stream. The apparatus can store the measurement results in the raw data repository. At box 406, the apparatus can generate experiment-related metadata and can store the metadata in a metadata directory different from the raw data repository.

[0086] At box 408, requests for metadata can be received at the metadata endpoint interface. The metadata endpoint interface can communicate directly with and associate with the autonomous service. The metadata endpoint interface can expose an API and can receive requests via RESTful API calls. This request can be received from an application configured to process raw chromatographic data.

[0087] At box 410, the autonomous service associated with the metadata endpoint interface that received the request can identify the location of the requested metadata. For example, the autonomous service can query metadata catalog 130 based on the request to identify where the metadata is stored within metadata catalog 130. At box 412, the system can return the metadata or the location of the metadata to the requesting application.

[0088] At box 414, requests for data can be received at the data endpoint interface. The data endpoint interface can communicate directly with and be associated with an autonomous service. The autonomous service may or may not be the same autonomous service associated with the metadata endpoint interface. The data endpoint interface can expose an API and can receive requests via RESTful API calls. This request can be received from an application configured to process raw chromatographic data and can be the same application that sent the request at box 408. The data endpoint interface can be associated with a specific type of data, and the application can generate RESTful API calls based on the data type to be retrieved. The data endpoint interface can be associated with a decoder in the autonomous service capable of decoding the requested data.

[0089] At box 416, the autonomous service can identify the location of the requested data. For example, the autonomous service can query the original data repository 124 based on the request to identify where the requested data (which may be in the form of a stream) is located in the original data repository 124.

[0090] The data endpoint interface that receives a request for data can be associated with a decoder in the autonomous service that is capable of decoding the requested data. At box 418, the decoder associated with the data endpoint interface can be identified and its location can be determined (e.g., a hyperlink to the location of the decoder can be generated).

[0091] At decision box 420, the autonomous service determines whether it is configured to decode the data. In some implementations, the autonomous service is configured to apply the decoder identified at box 418 to parse the data stream identified at box 416. In other implementations, the autonomous service simply identifies the location of the raw data and the decoder, and provides those locations to the application (which can then decode the data itself).

[0092] If the decision at decision box 420 is "yes", processing proceeds to box 422 and the autonomous service application uses its identified decoder to decode the identified raw data. This generates a streaming model, which is provided as output to the requesting application at box 424. Processing then proceeds to completion box 426 and terminates.

[0093] If the decision at decision box 420 is "No" (i.e., the autonomous service is not configured to decode the data), then at box 428, the autonomous service returns the location of the data identified at box 416 and the location of the decoder identified at box 418. Processing can then proceed to completion box 430 and terminate.

[0094] Figure 5 It describes the addition of the new decoder 304 to, for example Figure 3A and Figure 3B The flowchart illustrates the exemplary logic of the data processing environment depicted in the document.

[0095] At box 502, a new decoder for a data processing environment may be received. The decoder may be received along with new types of data that become supportable by the data processing environment. Receiving the decoder may include, for example, receiving a location from which the decoder can be retrieved, or receiving computer-executable code for the decoder.

[0096] A decoder may include logic for decoding (e.g., parsing) data streams from an MS instrument. A decoder may be associated with an identifier, and the identifier may contain metadata sufficient to identify the decoder's data source, data format, data type, decoder type, or decoder parameters (such as file type extensions, data descriptions, header information, etc.).

[0097] At box 504, the interface specification of the data processing environment (e.g., a document describing the data types supported by the environment and / or the structure of data services that can be used to decode the data) can be updated based on the information received at box 502. As previously described, in some implementations, each data service implements the entire interface specification; in others, each data service implements a portion of the interface specification, such that the interface specification is fully implemented across all available data services.

[0098] Depending on the implementation being used, at box 506, the system may identify one or more existing data services to implement the decoder, or it may create new data services for the decoder. When each data service implements all decoders, all data services are identified at box 506. If only one data service or a subset of data services will implement the decoder, one or more new data services may be created (and / or one or more existing data services may be identified to support the new decoder). In some implementations, the decoder can be loaded into a data service via reflection to embed the decoder within the data service.

[0099] At box 508, one or more new data endpoints corresponding to the decoder can be created on the data service identified or created at box 506. This may involve creating a new interface for the data service that can receive API calls. In some implementations, a new RESTful endpoint may be created.

[0100] At box 510, the system may optionally update the specification of the API displayed by the data service and publish it to end users. The API specification can be updated to describe how to invoke the new decoder via the endpoint created at box 508, such as by providing the method name or path used to invoke the endpoint. In some implementations, it is not necessary to advertise the API specification, as API calls can be patterned based on the data type of the decoder associated with the endpoint. Therefore, the application may be able to derive or infer the appropriate API to be invoked based on the type of data being requested.

[0101] Figure 6 An example of a system architecture and data processing apparatus that can be used to implement one or more exemplary aspects described herein in a standalone and / or networked environment is shown. Various network nodes, such as data server 610, web server 606, computer 604, and laptop computer 602, can be interconnected via a wide area network 608 (WAN), such as the Internet. Other networks may also be used, including private intranets, corporate networks, LANs, metropolitan area networks (MANs), wireless networks, personal networks (PANs), etc. Network 608 is for illustrative purposes and may be replaced by fewer or more computer networks. A local area network (LAN) can have one or more topologies of any known LAN topology and can use one or more protocols of a variety of different protocols, such as Ethernet. The data server 610, web server 606, computer 604, laptop computer 602, and other devices (not shown) can be connected to one or more networks via twisted-pair cables, coaxial cables, fiber optic cables, radio waves, or other communication media.

[0102] Computer software, hardware, and networks can be used in a variety of different system environments, including standalone, networked, remote access (also known as remote desktop), virtualized, and / or cloud-based environments, etc.

[0103] The term "network" as used herein and depicted in the accompanying drawings refers not only to a system in which remote storage devices are coupled together via one or more communication paths, but also to individual devices that can be coupled from time to time to such systems having storage capabilities. Therefore, the term "network" includes not only a "physical network" but also a "content network" consisting of data residing on all physical networks and attributable to a single entity.

[0104] Components may include a data server 610, a web server 606, a client computer 604, and a laptop computer 602. The data server 610 provides overall access, control, and management of the database and control software for performing one or more exemplary aspects described herein. The data server 610 may connect to the web server 606, through which users interact with and obtain requested data. Alternatively, the data server 610 may itself act as a web server and be directly connected to the Internet. The data server 610 may connect to the web server 606 via a network 608 (e.g., the Internet), via a direct or indirect connection, or via some other network. Users may interact with the data server 610 using a remote computer 604 or laptop computer 602, for example, by using a web browser to connect to the data server 610 via one or more externally public websites hosted by the web server 606. The client computer 604 or laptop computer 602 may be used with the data server 610 to access data stored therein, or may be used for other purposes. For example, from client computer 604, a user can access web server 606 using an internet browser (as known in the art) or by executing a software application that communicates with web server 606 and / or data server 610 via a computer network (such as the Internet).

[0105] Servers and applications can be combined on the same physical machine and retain separate virtual or logical addresses, or they can reside on separate physical machines. Figure 6 Only one example of a network architecture that can be used is shown, and those skilled in the art will understand that the specific network architecture and data processing apparatus used may vary and are secondary to the functionality they provide, as further described herein. For example, the services provided by web server 606 and data server 610 may be combined on a single server.

[0106] Each component, including data server 610, web server 606, computer 604, and laptop computer 602, can be any type of known computer, server, or data processing device. Data server 610 may include, for example, a processor 612 that controls the overall operation of data server 610. Data server 610 may also include RAM 616, ROM 618, network interface 614, input / output interface 620 (e.g., keyboard, mouse, monitor, printer, etc.), and memory 622. Input / output interface 620 may include various interface units and drivers for reading, writing, displaying, and / or printing data or files. Memory 622 may also store operating system software 624 for controlling the overall operation of data server 610, control logic component 626 for instructing data server 610 to perform the aspects described herein, and other application software 628 for providing auxiliary, support, and / or other functions that may be used in conjunction with or without the aspects described herein. The control logic component may also be referred to herein as data server software control logic component 626. The functionality of data server software can refer to a combination of operations or decisions made automatically based on rules encoded in the control logic components, operations or decisions made manually by users who provide input to the system, and / or automated processing based on user input (e.g., queries, data updates, etc.).

[0107] The memory 1122 may also store data for performing one or more aspects described herein, including a first database 632 and a second database 630. In some embodiments, the first database may include the second database (e.g., as a separate table, report, etc.). That is, information may be stored in a single database or divided into different logical, virtual, or physical databases, depending on the system design. The web server 606, computer 604, and laptop computer 602 may have similar or different architectures as described with respect to the data server 610. Those skilled in the art will understand that the functionality of the data server 610 (or web server 606, computer 604, laptop computer 602) as described herein can be distributed across multiple data processing devices, for example, to distribute the processing load across multiple computers, or to separate transactions based on geographic location, user access level, quality of service (QoS), etc.

[0108] One or more aspects may be embodied in computer-usable or readable data and / or computer-executable instructions, such as in one or more program modules executed by one or more computers or other devices as described herein. Typically, program modules include routines, programs, objects, components, data structures, etc., which perform a specific task or implement a specific abstract data type when executed by a processor in a computer or other device. These modules may be written in source code programming languages, which are subsequently compiled for execution, or they may be written in scripting languages ​​such as (but not limited to) HTML or XML. Computer-executable instructions may be stored on a computer-readable medium such as a non-volatile storage device. Any suitable computer-readable storage medium may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and / or any combination thereof. Furthermore, various transmission (non-storage) media representing data or events as described herein may be transmitted between a source and a destination in the form of electromagnetic waves propagating through signal conduction media such as metal wires, optical fibers, and / or wireless transmission media. The aspects described herein may be embodied in a method, a data processing system, or a computer program product. Therefore, various functionalities can be embodied, in whole or in part, in software, firmware, and / or hardware or hardware equivalents (such as integrated circuits, field-programmable gate arrays (FPGAs), etc.). Specific data structures can be used to more efficiently implement one or more aspects described herein, and such data structures are envisioned to be within the scope of the computer-executable instructions and computer-available data described herein.

[0109] The components and features of the devices described above can be implemented using any combination of discrete circuit systems, application-specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Furthermore, where appropriate, the features of these devices can be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination thereof. It should be noted that hardware, firmware, and / or software elements may be collectively referred to herein or individually as “logic components” or “circuits.”

[0110] It should be understood that the exemplary apparatus shown in the above block diagrams may represent a functionally descriptive example of many possible specific implementations. Therefore, the division, omission, or inclusion of block functions depicted in the figures does not necessarily mean that the hardware components, circuits, software, and / or elements used to implement these functions will be divided, omitted, or included in the implementation.

[0111] At least one computer-readable storage medium may include instructions that, when executed, cause a system to perform any of the computer-implemented methods described herein.

[0112] The expressions “one embodiment” or “implementation” and their derivatives may be used to describe several embodiments. These terms mean that a particular feature, structure, or characteristic described in conjunction with an embodiment is included in at least one embodiment. The phrase “in one embodiment” appearing in different places in the specification does not necessarily refer to the same embodiment. Furthermore, unless otherwise stated, the foregoing features are considered to be used in any combination. Thus, any feature discussed individually may be used in combination with each other unless it is indicated that these features are incompatible with each other.

[0113] Referring generally to the notation and naming used herein, the detailed description herein can be presented as a program procedure executed on a computer or computer network. Those skilled in the art use these program descriptions and representations to most effectively communicate the substance of their work to others skilled in the art.

[0114] The process here is generally considered to be a self-consistent sequence of operations that yields the desired result. These operations are those that require physical manipulation of physical quantities. While not strictly necessary, these quantities are typically in the form of electrical, magnetic, or optical signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has proven convenient, primarily for general reasons, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all these and similar terms are associated with the appropriate physical quantities and are merely convenient notations applied to them.

[0115] Furthermore, the manipulations performed are often referred to by terms such as addition or comparison, which are generally associated with mental operations performed by a human operator. In any of the operations described herein that form part of one or more embodiments, this ability of a human operator is not necessary or desired in most cases. Instead, these operations are machine operations. Useful machines for performing the operations of the various embodiments include general-purpose digital computers or similar devices.

[0116] The terms “coupled” and “connected”, as well as their derivatives, may be used to describe some implementations. These terms are not necessarily intended to be synonymous with each other. For example, the terms “connected” and / or “coupled” may be used to describe some implementations to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term “coupled” may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0117] Various implementations also relate to devices or systems for performing these operations. The device may be specifically constructed for the desired purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. The processes presented herein are not inherently related to any particular computer or other device. Various general-purpose machines may be used with programs written in accordance with the teachings of this document, or it may prove convenient to construct more specialized devices to perform the required method steps. The desired structures of various such machines will appear in the given description.

[0118] It should be emphasized that an abstract of this disclosure is provided to allow readers to quickly determine the essence of the technical disclosure. It should be understood that the submitted abstract will not be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the foregoing detailed description, various features may be grouped together in a single embodiment for the purpose of simplifying this disclosure. This method of disclosure should not be construed as reflecting an intention to claim more features than are expressly stated in each claim. Rather, as reflected in the following claims, the subject matter of the invention has fewer features than all of the individual disclosed embodiments. Therefore, the following claims are incorporated herein by reference to the detailed description, wherein each claim exists independently as a separate embodiment. In the appended claims, the terms “including” and “in which” are used as common English equivalents of the corresponding terms “comprising” and “wherein,” respectively. Furthermore, the terms “first,” “second,” “third,” etc., are used only as labels and are not intended to impose numerical requirements on their objects.

[0119] The foregoing description includes examples of the disclosed architecture. It is certainly impossible to describe every conceivable combination of components and / or methods, but those skilled in the art will recognize that many further combinations and substitutions are possible. Therefore, this novel architecture is intended to cover all such changes, modifications, and variations that fall within the substance and scope of the appended claims.

Claims

1. A method for retrieving and processing chromatographic data, comprising: At the endpoint interface of the autonomous service in the chromatography data processing environment, requests for raw data acquired by the chromatography instrument are received from the application, wherein the environment demonstrates multiple endpoint interfaces. Identify the decoder configured to interpret the raw data associated with the endpoint interface; Retrieve the requested raw data from the raw data repository; as well as In response to the request, the following is returned: Decoded data is generated by applying the decoder to the original data. The retrieved raw data and the decoder or the location of the decoder, or The location of the retrieved raw data and the location of the decoder; The autonomous service and the decoder are different parts of the chromatography data processing environment, and the application uses the decoder to decode the raw data; When a decoder needs to be updated, it is not necessary to shut down all autonomous services.

2. The method of claim 1, wherein the autonomous service is a first autonomous service configured to interface with the raw data repository, and the method further comprises a second autonomous service configured to interface with a metadata directory storing metadata describing how the raw data is collected.

3. The method of claim 1, wherein the endpoint interface is a first endpoint interface and configured to receive requests for raw data, and the method further comprises a second endpoint interface configured to receive requests for metadata describing how the raw data was collected.

4. The method of claim 1, wherein the decoder is associated with a plurality of different endpoint interfaces.

5. The method of claim 1, wherein the original data repository comprises data derived from at least one of the following: Multiple different chromatographic devices, or Chromatographic equipment that operates in a variety of different acquisition modes.

6. The method according to claim 1, wherein: The original data repository includes data of various different data types. The autonomous service is one of several autonomous services; and The multiple autonomous services are collectively configured to use the decoder to decode the various different data types.

7. The method of claim 6, wherein the plurality of autonomous services collectively include a plurality of endpoint interfaces, each endpoint interface being characterized by a data type.

8. A non-transitory computer-readable storage medium, the computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to perform the following operations: At the endpoint interface of the autonomous service in the chromatography data processing environment, requests for raw data acquired by the chromatography instrument are received from the application, wherein the environment demonstrates multiple endpoint interfaces. Identify the decoder configured to interpret the raw data associated with the endpoint interface; Retrieve the requested raw data from the raw data repository; as well as In response to the request, the following is returned: Decoded data is generated by applying the decoder to the original data. The retrieved raw data and the decoder or the location of the decoder, or The location of the retrieved raw data and the location of the decoder; The autonomous service and the decoder are different parts of the chromatography data processing environment, and the application uses the decoder to decode the raw data; When a decoder needs to be updated, it is not necessary to shut down all autonomous services.

9. The computer-readable storage medium of claim 8, wherein the autonomous service is a first autonomous service and configured to interface with the raw data repository, and wherein the instructions also configure the computer as a second autonomous service, the second autonomous service being configured to interface with a metadata directory storing metadata describing how the raw data is collected.

10. The computer-readable storage medium of claim 8, wherein the endpoint interface is a first endpoint interface and configured to receive a request for raw data, and wherein the instructions also configure the computer as a second endpoint interface, the second endpoint interface being configured to receive a request for metadata describing how the raw data was acquired.

11. The computer-readable storage medium of claim 8, wherein the decoder is associated with a plurality of different endpoint interfaces.

12. The computer-readable storage medium of claim 8, wherein the original data repository comprises data derived from at least one of the following: Multiple different chromatographic devices, or Chromatographic equipment that operates in a variety of different acquisition modes.

13. The computer-readable storage medium according to claim 8, wherein: The original data repository includes data of various different data types. The autonomous service is one of several autonomous services; and The multiple autonomous services are collectively configured to use the decoder to decode the various different data types.

14. The computer-readable storage medium of claim 13, wherein the plurality of autonomous services collectively include a plurality of endpoint interfaces, each endpoint interface being characterized by a data type.

15. A computing device, comprising: processor; and The memory stores instructions that, when executed by the processor, configure the device to: At the endpoint interface of the autonomous service in the chromatography data processing environment, requests for raw data acquired by the chromatography instrument are received from the application, wherein the environment demonstrates multiple endpoint interfaces. Identify the decoder configured to interpret the raw data associated with the endpoint interface; Retrieve the requested raw data from the raw data repository; as well as In response to the request, the following is returned: Decoded data is generated by applying the decoder to the original data. The retrieved raw data and the decoder or the location of the decoder, or The location of the retrieved raw data and the location of the decoder; The autonomous service and the decoder are different parts of the chromatography data processing environment, and the application uses the decoder to decode the raw data; When a decoder needs to be updated, it is not necessary to shut down all autonomous services.

16. The computing device of claim 15, wherein the autonomous service is a first autonomous service and configured to interface with the raw data repository, and wherein the instructions also configure the device as a second autonomous service, the second autonomous service being configured to interface with a metadata directory storing metadata describing how the raw data is collected.

17. The computing device of claim 15, wherein the endpoint interface is a first endpoint interface and configured to receive requests for raw data, and wherein the instructions also configure the device as a second endpoint interface, the second endpoint interface being configured to receive requests for metadata describing how the raw data is acquired.

18. The computing device of claim 15, wherein the decoder is associated with a plurality of different endpoint interfaces.

19. The computing device of claim 15, wherein the raw data repository comprises data derived from at least one of: Multiple different chromatographic devices, or Chromatographic equipment that operates in a variety of different acquisition modes.

20. The computing device according to claim 15, wherein: The original data repository includes data of various different data types. The autonomous service is one of several autonomous services; and The multiple autonomous services are collectively configured to use the decoder to decode the various different data types.

21. The computing device of claim 20, wherein the plurality of autonomous services collectively include a plurality of endpoint interfaces, each endpoint interface being characterized by a data type.

Images