Method and system for controlling the processing of biological materials

Abstract

A method for controlling the processing of a biological material, including: receiving at least one input parameter associated with a biological material: retrieving, by a data retrieving module, a first data set from a data store based on the at least one input parameter; selecting, by an algorithm selecting module, from a plurality of candidate machine learning algorithms, a first machine learning algorithm for processing the at least one input parameter, wherein the first machine learning algorithm is selected based on the at least one input parameter or the first data set; training the first machine learning algorithm using at least part of the first data set; applying the trained first machine learning algorithm to the at least one input parameter to determine a first processing parameter for subsequent processing of the biological material; and outputting the first processing parameter for subsequent processing of the biological material.

Description

[0001] METHOD AND SYSTEM FOR CONTROLLING THE PROCESSING OF BIOLOGICAL MATERIALS

[0002] TECHNICAL FIELD

[0003]

[0001] This disclosure relates to a method and a system for controlling the processing of biological materials.

[0004] BACKGROUND

[0005]

[0002] Biological material is collected for a range of purposes including, but not limited to, medical treatments, procedures, diagnoses and research. Depending on the purpose for which the material is collected, it may undergo a number of handling steps, which may include, amongst other things, transporting, processing and preserving the biological material.

[0006]

[0003] For example, in the field of personalised and precision medicine such as cell and gene therapies, biological material may be collected from a patient or donor and transported to a processing facility at which it is processed to generate a therapeutic product, before being again transported and administered to a patient.

[0007]

[0004] These handling steps often involve making a series of choices and decisions to obtain a desired processing result. For example, when packaging and shipping a biological material, the type of packaging may be selected from a number of packaging options, so that the biological material is packaged in a manner that will facilitate preservation of the biological material and facilitate subsequent processing (including transport and storage).

[0008]

[0005] As another example, when chilling or cryopreserving biological materials, it is necessary to set the operating conditions of the cooling equipment, which may involve setting a number of parameters which may include, for example, cooling temperature and cooling time.

[0006] In the past, these choices / decisions were made by human experts and / or operating staff. Necessarily, those choices and decisions were based on the experiential data available to the relevant operators, or based on fixed operating procedures, making it difficult to ensure that the decisions or the selected parameters (including machine operating parameters) were optimised to ensure that the quality of the biological material was sufficiently or optimally maintained during its processing. Where choices or decisions are made in accordance with a fixed procedure, or otherwise limited by the experience of the operating staff, misjudgements or errors are also hard to avoid. These may undesirably affect the outcome of the processing, e.g., the quality of the biological material being processed.

[0009]

[0007] It is desired to address or ameliorate one or more disadvantages or limitations associated with the prior art, or to at least provide a useful alternative. SUMMARY

[0010]

[0008] In accordance with at least a first aspect of the present invention, there is provided a method for biological material processing, including: receiving at least one input parameter associated with a biological material: retrieving, by a data retrieving module, a first data set from a data store based on the at least one input parameter; selecting, by an algorithm selecting module, from a plurality of candidate machine learning algorithms, a first machine learning algorithm for processing the at least one input parameter, wherein the first machine learning algorithm is selected based on the at least one input parameter or the first data set; training the first machine learning algorithm using at least part of the first data set; applying the trained first machine learning algorithm to the at least one input parameter to determine a first processing parameter for subsequent processing of the biological material; and outputting the first processing parameter for subsequent processing of the biological material.

[0011]

[0009] In accordance with at least a second aspect of the present invention, there is provided a method for biological material processing, including: receiving at least one input parameter associated with a biological material: selecting, by an algorithm selecting module, from a plurality of candidate machine learning algorithms, a first machine learning algorithm for processing the at least one input parameter, wherein the first machine learning algorithm is selected based on the input parameter; retrieving a first data set from a data store based on the first machine learning algorithm; training the first machine learning algorithm using at least part of the first data set; applying the trained first machine learning algorithm to the at least one input parameter to determine a first processing parameter for subsequent processing of the biological material; and outputting the first processing parameter for subsequent processing of the biological material.

[0010] In accordance with at least a third aspect of the present invention, there is provided a system for controlling the processing of a biological material, the system including: at least one processor; and a memory storing computer program instructions, which when executed by the at least one processor cause the system to perform a method of the first or the second aspect of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0012]

[0011] Some embodiments of the present invention are hereinafter described, by way of nonlimiting example only, with reference to the accompanying drawings, in which:

[0013]

[0012] FIG. 1 is a schematic diagram depicting an exemplary embodiment of a system for controlling the processing of a biological material according to at least some embodiments of the present disclosure;

[0014]

[0013] FIG. 2 is a schematic diagram showing a more detailed example of the control system and the orchestration module of FIG. 1 ;

[0015]

[0014] FIG. 3 is a flowchart depicting an exemplary workflow executed by the orchestration module of FIG. 1 for controlling the processing of a biological material;

[0016]

[0015] FIG. 4 is a schematic diagram showing a more detailed example of the processing flow executed by the control system and the orchestration module of FIG. 1 ;

[0017]

[0016] FIG. 5A - FIG.5C are schematic diagrams showing further example of the processing flow executed by the control system and the orchestration module of FIG. 1 ;

[0018]

[0017] FIG. 6 is an exemplary flowchart showing more details of the training and execution of the specific algorithm(s) of FIG. 1 ;

[0019]

[0018] FIG. 7 is a schematic diagram showing an exemplary architecture of a system for controlling sperm processing;

[0020]

[0019] FIG. 8A - FIG. 8E are schematic diagrams showing exemplary user interfaces of the system according to FIG. 7;

[0021]

[0020] FIG. 9 is a flowchart depicting an exemplary workflow executed by a Data Query Engine of the system;

[0022]

[0021] FIG. 10 is a flowchart depicting an exemplary workflow executed by an Algorithm Query Engine of the system;

[0023]

[0022] FIG. 11 is a flowchart depicting an exemplary workflow of the execution of a specific algorithm;

[0024]

[0023] FIG. 12 is a schematic diagram showing examples of machine learning models that may be used in the specific algorithms;

[0025]

[0024] FIG. 13 is a schematic diagram showing an exemplary architecture of a system for controlling sperm processing integrated with a distributed ledger;

[0026]

[0025] FIG. 14 is a schematic diagram showing a more detailed example of the smart contract logic submodule and the Al submodule of FIG. 13;

[0027]

[0026] FIG. 15 is a schematic diagram showing a further example of the control system with Al Logic Pre-processing and Al Logic Post-processing;

[0028]

[0027] FIG. 16 is a schematic diagram showing a further example of the control system in which the model data set is retrieved after the selection of the specific algorithm;

[0028] FIG. 17 is a schematic diagram showing an example a system for controlling the handling of a biological material by a plurality of biological material handling apparatuses;

[0029] FIG. 18 is a schematic diagram showing components of an exemplary biological material handling apparatus of the system of FIG. 17; and

[0029]

[0030] FIG. 19 is a schematic diagram showing components of an exemplary packaging device of the system of FIG. 17.

[0030] DETAILED DESCRIPTION

[0031]

[0031] While machine learning and artificial intelligence have been used in some areas of automatic control, they have not been widely used in the field of biomaterial processing. This is partly due to the unique nature of biological materials, e.g., their tendency to change over time, and for their characteristics to be particularly sensitive to small changes in processing parameters. Furthermore, the models used by existing machine learning methods are highly general in nature, and are applied equally to a variety of biological material samples, which in turn causes them to not only become out of date, but also be unable to optimise processing parameters for an individual biological sample based on the characteristics of that sample.

[0032] Furthermore, existing machine learning-based control systems often use fixed algorithms, which limits the scalability and flexibility of these systems, and makes it difficult to update their algorithms or introduce new machine learning models. This also affects the ability of systems to be improved over time, with many systems adopting a “set and forget” approach. These aspects of existing systems may result in compromising the quality of the handling / processing of biological materials, as the algorithms and / or data used are often not the ones that can deliver the best result.

[0032] Overview

[0033]

[0033] In at least some embodiments, the present disclosure provides a method and a system for controlling the processing of a biological material.

[0034]

[0034] The biological material may include (but is not limited to) one or more of the following: a) whole blood; b) blood components, such as blood platelets, red blood cells, white blood cells, plasma and other blood products; c) stem cells, such as haematopoietic stems cells, mesenchymal stem cells and embryonic stem cells; d) modified cells; e) engineered cells; f) gametes, such as egg cells and sperm; g) blastocytes h) oocytes; i) organs, including parts thereof; and j) tissue.

[0035]

[0035] It should be appreciated that the examples of biological materials identified herein are not intended to be an exhaustive list, and the methods and systems described herein may also be used for processing other biological materials.

[0036]

[0036] The methods and systems described herein may be used to calculate various parameters and / or conditions controlling the storage, transportation and manipulation of biological materials. For example, the described method and system may be used for selecting packaging device(s) and / or condition(s) for storing / transporting a biological material, controlling the temperature or temperature change(s) during refrigeration, freezing, thawing and / or other cryopreservation of the biological material, or determining the type and / or amount of cryoprotectant or other additive added during those processes. The processing of the biological material may also include one or more of the following: assay development, sample collection, cell diagnostics, bioreactor-based processing, and expansion of biomaterials.

[0037]

[0037] The described methods and systems may be used to control the processing of a biological material for various purposes. For example, they may be used to control the handling of biological material to be used in therapeutic treatments, such as cellular therapies.

[0038] System Architecture

[0039]

[0038] FIG. 1 is a schematic diagram depicting an exemplary embodiment of a system for controlling the processing of a biological material (referred to below as the "control system" or "system").

[0040]

[0039] In this example, the control system 102 includes an orchestration module 104, which is configured to receive input from and send output to an external system / device, or other module(s) of the system that is not shown in FIG. 1 . In some embodiments, the orchestration module 104 may also receive input as part of the execution of a smart contract, and its outputs may be used for processing the smart contract. That is, execution of a smart contract may involve passing input to the orchestration module 104, receiving the output of the orchestration module 104, and subsequently processing that output. The orchestration module 104 has access to a plurality of specific machine learning algorithms (106A, 106B, ... , 106N), and preferably can coordinate the execution of those algorithms, for example by chaining or linking those algorithms together so that they may be executed in sequence. The orchestration module 104 also has access to retrieve data stored in a data store 108, and preferably can also deliver data to the data store 108 to be stored therein.

[0040] The data store 108 stores data related to biological material processing, which may include data acquired from previous processing of biological materials, e.g., sample data (such as data relating to the characteristics of the biological material sample before and / or after processing) or processing condition data (such as data relating to the conditions under which the sample was processed, or the parameters which were applied when processing the biological material sample). The data stored in the data store 108 may be updated from time to time. In at least some embodiments, the data store 108 may also receive data uploaded from one or more biological processing devices. The data upload may be performed regularly or in real time or near real time.

[0041]

[0041] Through the orchestration module 104, the data stored in the data store 108 can be retrieved and utilised for training the specific machine learning algorithms (106A, 106B, ... , 106N).

[0042]

[0042] FIG. 2 is a schematic diagram showing a more detailed example of the control system 102 and the orchestration module 104. In this example and the description hereinafter, the orchestration module 104 may also be referred to as the "Algorithm Backbone / Platform".

[0043]

[0043] In this example, the data store 108 takes the form of a data lake 208. A data lake is a large and centralized repository that can store vast amounts of raw, unstructured, semistructured, and structured data in its native format. Unlike traditional data warehouses that require data to be structured and processed before storage, a data lake allows data to be ingested without any pre-processing or transformation, and provides a scalable and costefficient way to store and process large amounts of data from different sources. Although in this example the data store 108 takes the form of the data lake 208, in other implementations it may take other forms, such as a SQL database, a flat file structure, or any other known data storage mechanisms or structures in which data may be stored and subsequently retrieved with an appropriate data query.

[0044]

[0044] According to at least some embodiments, the data lake 208 stores historical data from previous processing of biological material. Preferably, the data stored in the data lake 208 includes data uploaded from at least one biological material processing device, e.g., device data indicating a device configuration or one or more operating conditions of a device, and / or sample data associated with the biological material being processed by the biological material processing device. In at least some embodiments, the data stored in the data lake 208 may include processing parameters that have been used by the biological material processing device to process biological material. This allows real-world data to be automatically stored in the data lake 208, so that it can be used for future training of machine learning models or algorithms. When more processing devices are connected to the system, more data can be collected and stored in the data lake 208, therefore significantly improving the effectiveness of future training of the machine learning algorithms. The biological material processing device may be (or include or connect to) a device that is configured to perform data communication with the data lake 208, through wired, wireless or mixed communication channels. For example, the biological material processing device may be an Internet of Things (loT) device, or an Internet of Medical Things (loMT) device, that is configured to upload device data, sample data and / or processing parameter data to the data lake 208 intermittently or continuously. In some embodiments, the data may be uploaded from the biological material processing device to the data lake 208 in real-time or near real-time, e.g., the upload of device, sample or processing parameter data may be commenced as soon as an appropriate data channel is available after that data is generated. This ensures that the latest data can be sent to and stored in the data lake 208 in a timely manner, thereby enabling the training of machine learning algorithms using up-to-date data and enhancing the accuracy of the trained machine learning model and its output result, which in turn improves the quality of the biological material processed in accordance with this embodiment.

[0045]

[0045] The orchestration module 104 includes a data retrieving module 202, an algorithm selecting module 204, and an algorithm execution module 210.

[0046]

[0046] FIG. 3 is a flowchart depicting an exemplary workflow executed by the orchestration module 104 for controlling the processing of a biological material. Although this workflow is described as being executed by the orchestration module 104, these steps may be undertaken by any appropriate code module or software and / or hardware component(s), such as a processor executing a smart contract.

[0047]

[0047] At Step 302, the orchestration module 104 receives at least one input parameter associated with a biological material.

[0048]

[0048] At Step 304, the data retrieving module 202 (which may be part of the orchestration module 104 as illustrated in Figure 2, or may otherwise simply be in data communication with the orchestration module 104) retrieves a first data set from a data store based on the at least one input parameter.

[0049]

[0049] At Step 306, the algorithm selecting module 204 (which may be part of the orchestration module 104 as illustrated in Figure 2, or may otherwise simply be in data communication with orchestration module 104) selects, from a plurality of candidate machine learning algorithms stored in an algorithm library 206, a first machine learning algorithm for processing the at least one input parameter, wherein the first machine learning algorithm is selected based on the at least one input parameter and / or the first data set.

[0050]

[0050] At Step 308, the orchestration module 104 trains the first machine learning algorithm using at least part of the first data set. In other embodiments, another component (such as the algorithm selecting module 204, or a processor executing a smart contract) may be responsible for training the first machine learning algorithm.

[0051] At Step 310, the algorithm execution module 210 applies the trained first machine learning algorithm to the at least one input parameter to determine a first processing parameter for subsequent processing of the biological material.

[0051]

[0052] At Step 312, the orchestration module 104 outputs the first processing parameter for subsequent processing of the biological material.

[0052]

[0053] Such a process allows the machine learning algorithms to be trained using the latest data from the data store (such as data lake 208) immediately before the execution of the machine learning algorithm, which enables the machine learning algorithm to be optimised and therefore provide improved processing parameters for use in processing the biological material. This, in turn, enables a biological material processing apparatus to process the biological material using the improved processing parameters, which results in improved quality of the processed biological material.

[0053]

[0054] Furthermore, this highly modular system architecture enables the orchestration module 104 to function as a coordination point that can dynamically facilitate two key steps in the machine learning processing, namely retrieving the required model data set for training (and optionally testing, as further described below) the machine learning algorithm, and selecting a specific machine learning algorithm.

[0054]

[0055] Preferably, the retrieved model data set is separated into a training data set and a testing data set. The training data set is used for training the machine learning model used in the specific machine learning algorithm, and the testing data set is then used for evaluating the performance of the trained model, e.g., in the form of an estimated accuracy. This may be an iterative process, involving fine-tuning the machine learning model to deliver an optimised outcome. Preferably, the ratio of this separation into a training data set and a testing data set is dependent on the algorithm requirements, and / or the size of the retrieved model data set, to provide a more accurate training result while maintaining testing performance.

[0055]

[0056] According to at least some embodiments, the control system 102 is implemented by: at least one processor; and a memory storing computer program instructions, which when executed by the at least one processor cause the control system 102, and the orchestration module 104 included therein, to perform the above-described functions. In other embodiments, the at least one processor executing a smart contract performs the functions described above.

[0056]

[0057] According to at least some embodiments, the control system 102 is integrated with a distributed ledger (e.g., a blockchain) through the execution of a smart contract.

[0057]

[0058] FIG. 4 is a schematic diagram showing a more detailed example of the processing flow executed by the control system 102 and the orchestration module 104.

[0058]

[0059] A subprocess x of the control system 102 sends input parameters to the orchestration module 104. The subprocess x may be, for example, a subprocess executed to achieve a milestone of a smart contract being executed by the control system 102. The input parameters may include input data (e.g., variables / metadata) associated with a biological material, as well as configuration data (including, for example, one or more input data categories and one or more target output categories).

[0059]

[0060] The orchestration module 104 processes the input data and the configuration data to determine an associated data set. This data set may be referred to hereinafter as the "dynamic model data set" or "model data set". The dynamic model data set is retrieved by the data retrieving module, which in this example takes the form of a Data Query Engine 402. The Data Query Engine 402 processes the input data along with the configuration data, and transforms them into a data query which is executed to retrieve data from the data lake 208.

[0060]

[0061] Each of the input data and the configuration data may include a plurality of data types, each of which is associated with a corresponding data value. When retrieving the model data set, the data query may include one or more corresponding data types and / or data values from the input data. For example, where the input data is associated with a sperm sample, the input data may include the following data types and associated values:

[0061] • motility percentage: a value (number) indicating the percentage of actively moving sperm in the total sample;

[0062] • motility category: a value (string) indicating a categorised motility level of the sperm in the sample (e.g., Fast Progressive Motility, Slowly Progressive Motility Non-Progressive Motility, Non-Motile);

[0063] • concentration: a value (number) indicating the concentration of the sperm sample;

[0064] • volume: a value (number) indicating the volume of the sperm sample; and

[0065] • location: a value (string) indicating where the sperm sample is located.

[0066]

[0062] The data query may further include the input data category / type and / or the target output category / type indicated by the configuration data. For example, the category of the input data may be "human sperm", and the category of the target output may be "packaging recommendation".

[0067]

[0063] In at least one embodiment, the data query is executed by the data lake 208. In this embodiment, the data lake 208 receives the data query from the Data Query Engine 402 and processes it to produce a just-in-time (JIT) model data set. This model data set is returned to the orchestration module 104 for further processing. Once received by the orchestration module 104, it preferably goes through a data validation process prior to it, or a subset of it, being sent to the algorithm selecting module 204 (which in this example takes the form of an Algorithm Query Engine 404).

[0068]

[0064] The orchestration module 104 then determines the algorithm to be selected from the algorithm library 206 based on the input data, the configuration data and the model data set received from the data lake 208. This is achieved using the Algorithm Query Engine 404. The Algorithm Query Engine 404 processes the input data, configuration data and the model data set to produce an algorithm query which is used to select and / or retrieve an appropriate algorithm from the algorithm library 206.

[0069]

[0065] In some embodiments, the algorithm library 206 executes the algorithm query. In such embodiments, the algorithm library 206 receives the algorithm query from the Algorithm Query Engine and processes it to select a specific algorithm to be used to process the input data.

[0066] The input data, the configuration data and the model data set are then used to train and execute the selected specific algorithm. At least a part of the model data set is used for training the selected algorithm. Once the algorithm has been trained using at least a part of the model data set, the algorithm is executed on the input data to generate the output. The output preferably goes through a validation process. The validated output from the specific algorithm execution is either returned to the subprocess x (e.g., part of a smart contract executed by the control system 102), or is used as an input for one or more further specific algorithms selected from the algorithm library 206 if further processing is required. Whether or not the further processing is required is determined, in some embodiments, by the orchestration module 104. According to at least some embodiments, this is determined based on one or more requirements indicated by the subprocess x (e.g., a part of a smart contract). If the requirements are not met, the orchestration module 104 then selects a further specific algorithm using the Algorithm Query Engine 404. This further specific algorithm is then trained (by using a different model data set retrieved from the data lake 208) and executed on the input data to generate a further output, which will again be validated against the set of requirements received from the subprocess x (e.g., part of the smart contract), to determine if further iteration is required. As another example, multiple specific algorithms may be selected and executed in sequence to allow generation of different types of output.

[0070]

[0067] At the conclusion of each iteration, the results of the processing by the specific algorithm, along with the initial input data may be sent to the data lake 208 to be used in future execution cycles. In some embodiments, the processed results and initial input data are only sent to the data lake 208 after they have been validated.

[0071]

[0068] When the orchestration module 104 determines that all required algorithm processing is completed, it will send all processed results back to the subprocess x (e.g., part of the smart contract) that requested it. Where it is the control system 102 executing a smart contract that determines whether all required algorithm processing is completed, the processed results are used in subsequent sub-processes of, or to meet subsequent milestones in, the smart contract.

[0069] Preferably, the input data and the processed results are stored in the data lake 208, so that they can be used for future training (and testing) of relevant machine learning algorithms. In this way, the data lake 208 can be updated with the latest data, which makes it possible for the model data set used for training the machine learning algorithms to include the latest data available. This further enhances the accuracy of the trained machine learning algorithm, and improves the accuracy and effectiveness of the output results. As a result, the quality of the biological material processing can be better maintained or further improved. Furthermore, the quality of the output / processed biological material can be maintained or increased.

[0072]

[0070] In addition, the control method executed by the control system 102 as described herein may be performed by other devices for controlling biological material processing. For example, some biological material processing devices may be configured to utilise the control method described herein to generate processing parameter(s) based on data input they receive (which, in some cases, may be data collected by that device, e.g., sample data acquired by sensor(s) of that device). The input data and the resulting processing parameter(s) obtained by such devices when executing the described control method may also be uploaded to the data lake 208. This further improves the scale and recency of the data in the data lake 208, and accordingly the accuracy of the trained machine learning algorithm and its output. As a result, the quality of the biological material processing can be further improved, and the quality of the output / processed biological material can be maintained or improved.

[0073]

[0071] Preferably, the machine learning algorithm also returns a confidence level associated with the processed result, which indicates an estimation of the accuracy of the output result. Only when the confidence level is above a predetermined threshold is the output result taken to be valid. In some embodiments, the output result and the corresponding input data may only be stored back in the data lake 208 when the output result is valid. This ensures the reliability and accuracy of the data used for future training of the machine learning algorithm, and therefore further improves the accuracy of the trained machine learning algorithm and the output results from the present control method. As a result, the quality of the biological material processing can be better maintained or further improved. In some alternative embodiments, the validity of the output result may be determined by other methods, e.g., by comparing the output result with a predetermined range of values defined as acceptable.

[0074]

[0072] In addition, in the exemplary process described above, the Algorithm Query Engine 404 produces the algorithm query based on the input parameters (including the input data and the configuration data) and the model data set. Alternatively, in at least some embodiments, the machine learning algorithm may be selected based on the input parameters alone, or the model data set alone.

[0075]

[0073] Furthermore, while FIG. 4 shows that the process may be iterated until a valid result is obtained, in some embodiments, there may only be a single algorithm being selected and executed. Such an example is shown in FIG. 5A, where a dynamic model data set 1 is retrieved, and a corresponding specific algorithm 1 is selected to be trained and executed.

[0074] FIG. 5B shows another example where a different specific algorithm is selected, but with a different path. In this example, a different dynamic model data set 2 is retrieved, and a specific algorithm 2 is selected, trained and executed.

[0076]

[0075] FIG. 5C shows an example in which multiple algorithms are chained / linked together for serial execution.

[0077]

[0076] Preferably, the result of the first iteration using model data set 1 and specific algorithm 1 may be used as an input for the next execution cycle, where a different model data set 2 is retrieved, and a different specific algorithm 2 is selected, trained and executed for generating further result(s). All the results are then returned to the subprocess x, or used in the subsequent processing of the smart contract (if algorithm execution is part of smart contract processing). In this way, multiple machine learning algorithms can be utilised to calculate multiple output processing parameters. This enhances not only the system operation efficiency, but also the efficiency of biological material processing.

[0078]

[0077] Alternatively, at least some of the algorithms may generate the same type of output result, but using different machine learning models, and / or require different input data and different data set for training. As a result, their output results may be different. The orchestration module 104 may be configured to select, from these output results, a result with a higher confidence level.

[0079]

[0078] Alternatively, in some embodiments, the orchestration module 104 may select, train and execute a first specific algorithm to generate an output result, and determine if further iteration is needed based on the confidence level associated with the result. If the output confidence level is below a predetermined threshold, the orchestration module 104 may initiate another iteration, i.e., selecting, training and executing another specific algorithm to generate a further output result of the same type. The confidence level associated with the result output from this further specific algorithm is then compared with the predetermined threshold to determine if further iteration is needed.

[0080]

[0079] In some embodiments, the subprocess x may have a predetermined set of rules defining the range(s) / threshold(s) of acceptable output data. The orchestration module 104 may be configured to compare the output from a specific algorithm with these predetermined set of rules, to determine whether further iteration is needed. For example, if the result from a specific algorithm does not fall into the valid data range defined by subprocess x, the orchestration module 104 may continue to search for other available algorithms, and identify another specific algorithm that provides the same type of output. This other specific algorithm is then trained by using a data set retrieved for this other algorithm, and executed on the input data. If the output from this other specific algorithm meets the requirements defined in the subprocess x, the orchestration module 104 then outputs the result. Otherwise, the orchestration module 104 may keep searching for alternative algorithms that can generate the required type of output, until no alternative available algorithms can be identified.

[0081]

[0080] Some examples of the input and outputs that may be used in the processes illustrated in FIG. 5A to FIG. 5C are described as follows.

[0082] Example 1

[0083]

[0081] In this example, the biological material to be processed is sperm, and the processing of the biological material involves transportation and cryopreservation of the sperm. The input parameters may include one or more of the following:

[0084] • Input 1 - Manually entered by a medical practitioner o Category: Human Sperm o Motility Percentage - 50% o Motility category - slowly progressive motility o Concentration - 50% o Volume - 5ml o Cryoprotectant - 50% o Viscosity - Moderate o Application - Storage o Location - Austin, Texas o T reatment state - Storage

[0085] • Input 2 - Automatically uploaded from an biological material processing device o Sample temperature o Sample volume (split) - 50microlitres o Package data:

[0086] - Units 7 (3 per pack)

[0087] - Type

[0088] - Volume

[0089] - Material

[0090]

[0082] Output from the specific algorithms may include one or more of the following results:

[0091] - Required Heat Transfer Rates for cryopreservation of sample

[0092] - Time countdown for cryopreservation

[0093] - Sample quality retention

[0094] - Holding temperature through logistics

[0095]

[0083] The data set for training a relevant specific algorithm may include one or more of the following:

[0096] Relating to Input 1 o Motility o Concentration o Cryoprotectant o Application o Treatment state

[0097] • Relating to Input 2 o Sample temperature o Sample volume (split) - 50microlitres o Package data o Location

[0098]

[0084] The data in each data set may include data related solely to Input 1 , data related solely to Input 2, or data related to both Input 1 and Input 2.

[0099] Example 2

[0100]

[0085] In another example, the biological material to be processed is sperm, and the processing of the biological material involves cryopreservation of the sperm. The input parameters may include one or more of the following:

[0101] • Input 1 - Automatically uploaded from a biological material freezer device o Machine Conditions:

[0102] ■ High Temperature Compressor Temperature

[0103] ■ High Temperature Compressor Pressure

[0104] ■ Low Temperature Compressor Temperature

[0105] ■ Low Temperature Compressor Pressure

[0106] ■ Pump Duty - 40%

[0107] ■ AX Valve - 20% open

[0108] ■ Heat Transfer Fluid Temperature 30°C

[0109] ■ Location - Austin, Texas

[0110] • Input 2 - Passed in from subprocess x of the system o Heat Transfer Speed Requirements (100 degrees per minute) o Human Sperm Characteristics Data o Packaging Replicates

[0111]

[0086] Output from the specific algorithms may include one or more of the following results:

[0112] - Machine Operating Conditions for cryopreservation of sample

[0113] - Sample quality retention

[0114]

[0087] The data set for training a specific algorithm may include one or more of the following:

[0115] • Relating to Input 1 o Machine Conditions: ■ Machine Conditions:

[0116] ■ High Temperature Compressor Pressure

[0117] ■ Low Temperature Compressor Pressure

[0118] ■ Pump Duty

[0119] ■ Location - Austin, Texas

[0120] • Relating to Input 2 o Heat Transfer Speed Requirements (100 degrees per minute) o Human Sperm Characteristics Data o Packaging Replicates

[0121]

[0088] Similar to the previous example, the data in each data set may include data related solely to Input 1 , data related solely to Input 2, or data related to both Input 1 and Input 2.

[0122]

[0089] In this example, two of the specific algorithms may be used to generate the same type of output result, e.g., both being using for determining machine operating conditions for cryopreservation of a biological material. However, the two specific algorithms may use different machine learning models, and / or require different data sets for training. As a result, their output results may be different.

[0123]

[0090] For example, the machine operating conditions for cryopreservation of the sample determined by one specific algorithm may be:

[0124] -50°C, 60 Litres per minute pump, 240 seconds.

[0125]

[0091] The machine operating conditions for cryopreservation of the sample determined by another specific algorithm may be:

[0126] -30°C, 20 Litres per minute pump, 180 seconds.

[0127]

[0092] Each of these two results may be associated with a confidence level indicating an estimation of the accuracy of the output result. The orchestration module 104 may be configured to select, from the two output results, a result with a higher confidence level.

[0128] Example 3

[0129]

[0093] In a further example, the biological material to be processed is CAR-T cells for CAR-T therapy, and the processing of the biological material involves expansion of the cells. The input parameters may include one or more of the following:

[0130] • Input 1 - Manually entered by a medical practitioner o Cell Type - Engineered T-Cells (CAR-T) o Viability - 50% o Starting Cell count - 1.0 x 106o Target Cell count - 5.0 x 106o Patient Weight - 46kgs o Volume - 2ml o Cryoprotectant - 10% DMSO removed o Application - CAR T-Cell o Location - Melbourne, Australia o T reatment state - Thawed

[0131] • Input 2 - Automatically uploaded from a biological material package device o Sample temperature o Sample volume (split) - 50microlitres o Package data:

[0132] - Units 1

[0133] • Input 3 - Automatically uploaded from a bioreactor media feeding device o Volume of media (30 litres) o Type of media used o Nutrient density and type o Biologies License Application (BLA) approved uses

[0134]

[0094] Output from the specific algorithms may include one or more of the following results: o Duration of expansion o Nutrient media feed rates for expansion

[0135]

[0095] The data set for training a specific algorithm may include one or more of the following:

[0136] • Relating to Input 1 o Cell Type - Engineered T-Cells (CAR-T) o Viability - 50% o Starting Cell count - 1.0 x 106o Target Cell count - 5.0 x 106o Patient Weight - 46kgs o Location - Melbourne, Australia o Biologies License Application (BLA) Approved Protocol requirements

[0137] • Relating to Input 2 o Sample temperature o Location

[0138] • Relating to Input 3 o Volume of media (30 litres) o Type of media used o Nutrient density and type o Biologies License Application (BLA) approved uses

[0139]

[0096] The data in each data set may include data related to one or more of Input 1 , Input 2 and Input 3. Example 4

[0140]

[0097] In another example, the biological material to be processed is sperm, and the processing of the biological material involves thawing of the sperm. The input parameters may include one or more of the following:

[0141] • Input 1 - Manually entered by a medical practitioner o Category - Human Sperm o Motility Percentage - 50% o Motility category - slowly progressive motility o Concentration - 50% o Volume - 5ml o Cryoprotectant - 50% o Viscosity - Moderate o Application - Storage o Location - Austin, Texas o T reatment state - Storage o Packaging Type - MicroSperm o Packaging Replicates

[0142] • Input 2 - Automatically uploaded from a biological material processing package device o Sample temperature - Storage Temperature o Storage Duration o Storage temperature variations

[0143]

[0098] As shown in FIG. 5C, a first iteration may select specific algorithm 1 , which outputs a set of thawing device machine operating conditions: o +47 degrees Celsius; o 30 litres per minute pump speed; o 18 seconds.

[0144]

[0099] The orchestration module 104 may validate these results against any appropriate set of requirements that define a valid or acceptable result. In some embodiments, those requirements can be passed to the orchestration module 104 from an external source, and in an exemplary embodiment they are passed in from subprocess x. In such an example, they may be passed in as part of a request from subprocess x, and form part of the input parameters referred to above associated with the biological material. The requirements may depend on the nature of the biological material processing being undertaken. For example, where the biological material processing involves the thawing of a biological material sample, the requirements may include a range of acceptable cryoprotectant toxicity levels. The orchestration module 104 may determine that the output result from specific algorithm 1 does not meet the cryoprotectant toxicity requirement, as the cryoprotectant toxicity levels of the output result are not within the acceptable range. As a result, the orchestration module 104 continues to search for available algorithms that output thawing device machine operating conditions, and identifies specific algorithm 2. The second iteration of FIG. 5C is performed to retrieve the data set required for specific algorithm 2, and to train and execute specific algorithm 2.

[0145]

[0100] The trained specific algorithm 2 outputs a different set of thawing device machine operating conditions: o +30 degrees Celsius; o 60 litres per minute pump speed; o 6 seconds.

[0146]

[0101] The orchestration module 104 then validates these results against the cryoprotectant toxicity requirement, and determines that it meets the requirement. As a result, the orchestration module 104 returns the result from specific algorithm 2 to the subprocess x.

[0147]

[0102] As described above, the architecture of the system according to embodiments of the present invention allows utilization of an orchestration module 104 to provide a coordination point that can dynamically facilitate and coordinate the two key steps in machine learning processing, namely retrieving required model data set for training (and testing) the machine learning algorithm, and selecting a specific machine learning algorithm.

[0148]

[0103] The architecture of the system also allows the linking / chaining of different specific algorithms, each trained on their own model data sets immediately prior to execution. This allows for processed outputs from a specific algorithm to form at least part of the inputs into a further specific algorithm. The orchestration module 104 may be configured to coordinate this process, by sending the output from one specific algorithm to a subsequent specific algorithm, or to the Data Query Engine 402 for retrieving the model data set required for training the subsequent algorithm.

[0149]

[0104] By using this approach, the system may achieve a high level of machine learning complexity and capability in a modular fashion and use a more easily maintainable structure. This may also accelerate software development.

[0150]

[0105] The architecture of the system also allows for scalability because specific algorithms can be created / updated independently and added to a library of selectable algorithms (e.g., the algorithm library 206).

[0151]

[0106] In addition, retrieving model data from a data repository (e.g., the data lake 208), training a selected algorithm shortly before algorithm execution, and storing the algorithm outputs into the data repository for use in subsequent algorithm training allows for a real-time continuous feedback data loop. This approach ensures that the latest available model data is always utilized for training (and testing) a specific algorithm at the time of processing.

[0152]

[0107] FIG. 6 is an exemplary flowchart showing more details of the training and execution of the specific algorithm(s).

[0153]

[0108] At Step 6.1 , the specific algorithm receives input data as well as the retrieved model data set.

[0154]

[0109] At Step 6.2, the machine learning algorithm checks if there are any required machine learning and data analysis libraries, and imports (i.e., loads into memory) the required libraries. These libraries may be any suitable libraries, and can include open-source libraries such as TensorFlow, PyTorch, and scikit-learn.

[0155]

[0110] At Step 6.3, the model data set from the data lake is imported (loaded into memory).

[0156]

[0111] At Step 6.4, the model data set is separated into a training data set and a testing data set. As described in further detail hereinafter, the ratio of this separation may be dependent on the algorithm requirements, and / or the size of the model data set.

[0157]

[0112] At Step 6.5, any required feature scaling is applied to the training and testing data sets. This is done to standardize the independent features present in the data into a fixed range. This is dependent on the specific algorithm requirements, and any suitable feature scaling approach may be adopted.

[0158]

[0113] At Step 6.6, the machine learning algorithm is trained using the training data set, and tested using the testing data set.

[0159]

[0114] At Step 6.7, with the machine learning algorithm training completed, the input data is passed into the algorithm to allow it to produce its processed results.

[0160]

[0115] Finally, at Step 6.8, the machine learning algorithm returns the results and an associated confidence level, indicating the accuracy of the results in a manner further described below.

[0161] Specific Algorithm variables / metadata details

[0162]

[0116] As described above, a number of variables (possibly together with their associated respective metadata) are passed from the orchestration module 104 into each specific algorithm. Some examples of these variables / metadata and their usage are described as follows. a) Input Data o This is passed in as an object containing a series of values. The input data is the data used by the machine learning algorithm(s) to create a result (e.g., a prediction), which is returned along with a confidence level (e.g., a prediction probability) indicating its accuracy / confidence. The input data is received by the orchestration module 104 from either a subprocess x executed by the control system 102 (which may include user / machine input) or from a preceding specific algorithm if it is part of a sequence (specific algorithms chained / linked together), and passed into each specific algorithm. In some embodiments, the subprocess x from which the input data is received may be part of a smart contract executed by the control system 102. b) Model Data Set (from data a data repository such as data lake 208) o This data is passed in as a data set (e.g., in an "object" data type). This data set is the data that is retrieved from the data repository to train the related specific machine learning algorithm. c) Machine Learning Training / Test split ratio o This is passed in as a ratio (e.g., in a "float" data type). This ratio is used to split the model data set retrieved from the data lake into a training data set and a testing data set. Different specific algorithms may use a different split ratio, preferably an optimal split ratio that achieves the highest accuracy / confidence (e.g., prediction probability) for the corresponding algorithm, o Preferably, the split ratio may be determined further based on the size of the model data set. For example, an 80:20 train / test split may be used as a baseline ratio. When the size of the data set is large (e.g., millions of observations), a higher split ratio (e.g., 90:10 or even 99:1) may be used to produce a more accurate trained machine learning model. For data sets consisting of a low level of observations (< 10,000), a lower split ratio (e.g., 70:30 or lower) may be used to provide a more accurate result. This flexibility further enhances the accuracy of machine learning algorithm training, thereby enhancing the accuracy and effectiveness of the output results, and consequently the quality of the processed biological material. d) Feature Scaling o This is passed in as a value (e.g., in a "string" data type) that represents the required feature scaling, which is a process of normalising or standardising the ranges of the independent variables used in the model data sets (training data set and testing data set). Different machine learning models may require specific feature scaling to optimise their accuracy. e) Confidence threshold o This is passed in as a percentage (e.g., in a "float" data type). Each specific algorithm produces a result (e.g., prediction) as well as its accuracy / confidence (e.g., prediction probability). A confidence threshold is a percentage value that the confidence value is checked against to determine if it is a valid result. Depending on the specific algorithm, this threshold can be set to a level that is considered acceptable. In the event of a result not meeting its related confidence threshold, it will be flagged as a bad / below threshold result. These flagged results are prevented from being added back into the data repository as they may adversely affect the data used for further machine learning model training. f) Geographic information o The data passed to the algorithm may also include geographic information, which may be passed in as a value (e.g., in a "string" data type). This value may be used to ensure a specific algorithm adheres to specific restrictions associated with a geographic area. (Specific geographic areas may impose restrictions on the processing of biological material which may have an effect on the selection of appropriate algorithms.)

[0163]

[0117] In addition, according to at least some embodiments, the machine learning model used in a specific algorithm can also be dynamically loaded into the algorithm, e.g., from a machine learning model library. The machine learning model may be one of existing machine learning models, e.g., a logistic regression model, an artificial neural network, or a random forest model. Alternatively, it may be a custom-developed model.

[0164]

[0118] Table I below compares how some of the variables / metadata in the embodiments of the present disclosure are generated and used compared with some other machine learning processes.

[0165]

[0166]

[0119] As shown in Table I, other machine learning processes use an existing data set loaded from an external file. By contrast, embodiments of the present disclosure allow the utilisation of a dynamically generated data set to train the machine learning algorithm, the data set being retrieved from a data repository such as the data lake 208 immediately before the machine learning algorithm is trained. This arrangement allows the utilisation of the latest data to train the machine learning model.

[0167]

[0120] In addition, in contrast to other machine learning processes where the training / test data split ratio is statically configured inside the machine learning algorithm, embodiments of the present disclosure allow utilisation of a configurable split ratio, which improves the accuracy of machine learning algorithm training, thereby enhancing the accuracy and effectiveness of the output results.

[0168]

[0121] Furthermore, other machine learning processes use feature scaling parameters configured inside the algorithm, whereas embodiments of the present disclosure allow utilisation of dynamic feature scaling, which improves the accuracy of machine learning algorithm training, thereby further enhancing the accuracy and effectiveness of the output results.

[0169]

[0122] In addition, embodiments of the present disclosure allow the utilisation of dynamic confidence thresholds to flag results (e.g., predictions) having confidence levels that are below the set / required threshold, which further improves the reliability and accuracy of the output results and the quality of the data in the data repository used in subsequent algorithm executions.

[0170]

[0123] Furthermore, at least some embodiments of the present disclosure are configured such that a machine learning model is dynamically loaded into the specific algorithm (e.g., from an internal or external machine learning model library), which allows utilisation of the most recently updated machine learning models, thereby further enhancing the accuracy and effectiveness of the output results compared to other machine learning processes, which use machine learning model(s) statically configured inside an algorithm.

[0171] Example: A system for controlling the processing of sperm

[0172]

[0124] A more detailed example of the system according to embodiments of the present disclosure is described hereinafter. In this example, the biological material to be processed is sperm.

[0173]

[0125] FIG. 7 is a schematic diagram showing the architecture of the system according to this example. In this example and the description hereinafter, the orchestration module 104 is also referred to as the "Algorithm Backbone / Platform".

[0174]

[0126] In this example, three machine learning algorithms are selected to be executed in sequence:

[0175] 1) Packaging Selection Algorithm: This algorithm selects packaging device(s) based on sample quality. The sample quality is indicated by parameters such as motility, grading, or concentration of the sample sperm. The algorithm selects packaging device(s) (e.g., straw, microsperm, vial, etc.) most suited to that sample and which can best retain cellular integrity or sample quality during cryopreservation, storage and / or thawing.

[0176] 2) Machine Operating Conditions Algorithm: This algorithm determines machine operating conditions (protocol) for sperm sample processing. The algorithm analyses the selected packaging dimensions, volumes, and thermal conductivity, to determine the most suitable heat transfer requirements that will retain cellular integrity or sample quality during cryopreservation. The determined heat transfer requirements are then converted into machine operating conditions (protocol), including temperature, flow rate, velocities, and time for sample processing.

[0177] 3) Cryopreservation Algorithm: This algorithm uses the package selection recommendation and optimal machine operating conditions data output from the previous algorithms to determine which machine is suitable and should be used for the cryopreservation process, as well as the machine protocol, required configuration and scheduling.

[0178]

[0127] Although not depicted in FIG. 7, data reaches the Algorithm Backbone / Platform via the previous module(s) in the control system 102, e.g., a subprocess such as part of a smart contract executed by the control system 102.

[0179]

[0128] In this exemplary scenario, sperm quality data has come from a medical practitioner entering this data through an application (e.g., through a web page or other user interface), which sends the data to the control system 102. The data may go through a series of preprocessing steps before reaching the Algorithm Backbone / Platform.

[0180]

[0129] As shown in FIG. 7, at Step 701 , the Algorithm Backbone / Platform receives the sperm quality data, and determines that the Package Selection Algorithm is required to process this data. Prior to or after the selection of the Package Selection Algorithm, the Algorithm Backbone / Platform retrieves the required model data set from the data lake 208. The Algorithm Backbone / Platform then sends the sperm quality data and related model data set to the Package Selection Algorithm for training and processing.

[0181]

[0130] At Step 702, the Package Selection Algorithm uses the related model data set to train (and in some embodiments, test) its machine learning model, and then uses the supplied sperm data to perform the required calculations using the trained model to determine and return a sperm packaging recommendation. This recommendation is returned with its corresponding confidence level (based on the testing of the machine learning model) to the Algorithm Backbone / Platform.

[0182]

[0131] Upon receiving the returned data from the Package Selection Algorithm, the Algorithm Backbone / Platform will then confirm that machine operating conditions are to be determined by using the Machine Operating Conditions Algorithm.

[0183]

[0132] At Step 703, the Algorithm Backbone / Platform retrieves the model data set required for the Machine Operating Conditions Algorithm from the data lake 208, and sends the packaging recommendation data returned from the Package Selection Algorithm and the related model data set to the Machine Operating Conditions Algorithm for training and processing.

[0184]

[0133] At Step 704, The Machine Operating Conditions Algorithm uses the model data set to train (and in some embodiments, test) the relevant machine learning model, and applies the trained model to the supplied package selection recommendation to determine and return a set of optimal machine operating conditions. This set of optimal machine operating conditions (together with its corresponding confidence level) are returned to the Algorithm Backbone / Platform.

[0134] Upon receiving the returned data from the Machine Operating Conditions Algorithm, the Algorithm Backbone / Platform will then select the Cryopreservation Algorithm for subsequent execution.

[0185]

[0135] At Step 705, the Algorithm Backbone / Platform retrieves the required algorithm model data set required for the Cryopreservation Algorithm from the data lake 208, and sends both the package selection recommendation and optimal machine operating conditions, together with the just-retrieved model data set, to the Cryopreservation Algorithm for training and processing.

[0186]

[0136] At Step 706, the Cryopreservation Algorithm uses the received model data set to train (and in some embodiments, test) its machine learning model, and applies the trained machine learning model to the received package selection recommendation and optimal machine operating conditions data to determine which machine is suitable and will be used for the cryopreservation process. It also determines the machine protocol, required configuration and scheduling. In at least some embodiments, the Cryopreservation Algorithm may be configured to communicate to the selected machine, to set up the machine with the machine learning conditions determined in Step 704, and to initiate and control the cryopreservation process.

[0187]

[0137] With the architecture shown in FIG. 7, different specific algorithms can be developed and used for specific steps / tasks during the processing of biological material.

[0188]

[0138] Repeatable core aspects of the process described above can be incorporated into the Algorithm Backbone / Platform which will be used to coordinate the linking / chaining of different specific algorithms as well as to facilitate specific algorithm connections to the required model data set in the data lake 208.

[0189]

[0139] In this way, the Algorithm Backbone / Platform functions as a central coordination point for specific tasks involving machine learning based processing (which may also be referred to as "Al processing" in the present disclosure). This is particularly advantageous compared to existing system architectures, where the specific algorithms are pre-determined and pre-trained and are linked / chained together in a fixed manner. Even though those systems may achieve similar functions as the systems described herein, with a fixed architecture, and without the use of an Algorithm Backbone / Platform, the complexity of developing such a system is significantly higher, and the algorithms used in such systems are difficult to maintain, update / replace or extend in functionality. In at least some embodiments, the functions of the Algorithm Backbone / Platform here may be performed by processor executing an overall coordination template, such as a smart contract containing one or more milestones.

[0190]

[0140] In addition, the architecture of the system in the present disclosure also allows the system to be used for processing different biological materials. For example, the same system as that described above may be used for processing whole blood. In another example, the system may be used for biological material(s) for CAR-T therapy, e.g., CAR-T cells. The same or similar algorithms ("Packaging Selection Algorithm", "Machine Operating Conditions Algorithm", "Cryopreservation Algorithm" and the like) can be used for determining the various parameters required for processing whole blood and / or CAR-T biomaterials, without changing the architecture of the system. In this way, the need to develop fixed, bespoke systems for each type of biological material may be obviated.

[0191]

[0141] Further, while the system architecture remains the same, each specific algorithm may require different input data for different biological materials. For example, for sperm, the packaging may be selected based on one or more of motility, grading and concentration, while for whole blood, the packaging may be selected on volume and intended use. Accordingly, different model data sets are retrieved for training the machine learning model for different biological materials, which will result in a trained machine learning model suitable for a specific biological material, and subsequently applied to the specific input for that material. In this way, the system can cater for different biological materials, with the same algorithms (while the trained machine learning models are different) and the same system architecture.

[0192]

[0142] FIG. 8A - FIG. 8D show exemplary user interfaces ("Ul") of the system for controlling sperm processing described above with reference to FIG. 7.

[0193]

[0143] As shown in FIG. 8A, machine learning based packaging selection is performed by training and executing the Package Selection Algorithm, with sperm pre-freeze concentration and pre-freeze motility as the input (e.g., input by a user). In this example, in response to the sperm pre-freeze concentration being 98.95 and pre-freeze motility being 13.34%, "Micro Packaging" is selected, with associated confidence being 98.31%.

[0194]

[0144] The selected packaging type and the input sample quality (i.e., sperm pre-freeze concentration and pre-freeze motility) are then used by the Machine Operating Conditions Algorithm to determine optimal heat transfer requirements of the sample for retaining cellular integrity / sample quality during cryopreservation. The heat transfer requirements are then converted into machine operating conditions (protocol), e.g., temperature, flow rate, and time, for sample processing. As shown in FIG. 8B, the determined machine working conditions (protocol) are displayed on the Ul, preferably with a manual approval required to progress (the "confirm" button).

[0195]

[0145] Next, the Cryopreservation Algorithm uses the package selection recommendation and optimal machine operating conditions data to determine which machine is suitable and will be used for the cryopreservation process, as well as the machine protocol, required configuration and scheduling. These are then displayed on the Ul as shown in FIG. 8C. Once determined, the selected machine is setup and initiated. Real time adjustments can be coordinated by the Cryopreservation Algorithm to automatically adjust machine scheduling and operations to function at optimal levels (that is, in accordance with protocol, configuration and scheduling determined using the process disclosed herein and above) to give the highest sample quality outcome. The determined processing conditions may be displayed on the Ul, as shown in FIG. 8D. A graph showing the simulated Time-Temperature curve(s) for one or more samples in the machine may also be displayed, as shown in FIG. 8E.

[0196] Algorithm Library

[0197]

[0146] The specific algorithms described above may be stored in an algorithm library (e.g., the algorithm library 206 shown in FIG. 2). The algorithm library contains a set of specific algorithms that the Algorithm Backbone / Platform 104 can select to execute with the use of the Algorithm Selecting Module 204 (also referred to as the Algorithm Query Engine (or "AQE")).

[0198]

[0147] The specific machine learning algorithms contained in the algorithm library may include algorithms which use various machine learning models, e.g., Supervised Learning, Unsupervised Learning, Semi-Supervised Learning or Reinforcement Learning. FIG. 12 shows further examples of machine learning models that may be used in the specific algorithms.

[0199]

[0148] By storing the specific algorithms in an algorithm library, and using the Algorithm Query Engine to retrieve the selected specific algorithm in response to the input parameters and / or the dynamic data set, maintenance of the specific algorithms can be decoupled from maintenance of other components of the system. Individual algorithms can be added to, deleted from, or updated in the algorithm library, without affecting the other components of the system. This provides a more flexible system architecture, and improves system modularity, scalability, and the speed of development / iteration. This arrangement also allows the individual algorithms to be replaced with, or updated to, a more suitable machine learning algorithm for a particular task, e.g., an algorithm with a machine learning model that provides a more accurate result, or an algorithm that can be trained or executed faster than the existing candidate algorithm. This further increases the accuracy of the output result, and therefore improves or maintains the quality of the processed biological material.

[0200]

[0149] Two specific examples of the algorithms stored in the algorithm library are described in further detail as follows.

[0201] 1. Human Sperm Packaging Algorithm (Logistic Regression)

[0202]

[0150] An exemplary Human Sperm Packaging Algorithm is a custom machine learning algorithm that utilises a logistic regression model, and is categorised as a Classification form of a Supervised Learning Algorithm.

[0203]

[0151] This specific algorithm uses a logistic regression approach for predicting a categorical dependent variable (human sperm packaging) using a given set of independent variables (input data).

[0204]

[0152] The packaging prediction is achieved by supplying this specific algorithm with input data and relevant historical data retrieved from a data repository (e.g. data lake 208). Using this historical data, a machine learning model is constructed and trained. This trained model then uses the input data to return a packaging prediction.

[0205] 2. Machine Operating Conditions Algorithm (Multiple Linear Regression)

[0206]

[0153] An exemplary Machine Operating Conditions Algorithm is a custom machine learning algorithm that utilises a Multiple Linear Regression model, and is categorised as a Regression form of a Supervised Learning Algorithm.

[0207]

[0154] This specific algorithm uses a Multiple Linear Regression approach for predicting a continuous dependent variable (the machine operating conditions may include: heat exchange conditions and process time) using a given set of independent variables (input data).

[0208]

[0155] This machine operating conditions prediction is achieved by supplying this specific algorithm with input data and relevant historical data retrieved from the data lake. Using this historical data, a machine learning model is trained and preferably tested. This trained model then uses the input data to return a prediction, in this instance optimised machine operating conditions.

[0209] Data Query Engine (data retrieving module)

[0210]

[0156] Further details of the data retrieving module 202 (referred to in this example as the Data Query Engine), is described below with reference to the human sperm packaging use case examples.

[0211]

[0157] As described above, the Data Query Engine is a software module that is designed to take dynamic input data types and values and use this input data to generate a dynamic query used to retrieve a JIT (just in time) dynamic data set from the data repository (such as data lake 208). This is achieved with the Data Query Engine by it first processing and analysing the input data. Once processed (for example, tagged and / or categorised) the input data is aligned with all available related tagged / categorised structured and unstructured data stored in the data lake 208. Using this alignment process the Data Query Engine is then able to generate a dynamic query that will fetch all aligned data from the data lake 208.

[0212]

[0158] FIG. 9 shows an exemplary workflow executed by the Data Query Engine.

[0213]

[0159] At Step 901 , the Algorithm Backbone / Platform 104 sends the received Input Data Payload to the Data Query Engine via an API.

[0214]

[0160] An example of the API call to Data Query Engine is as follows:

[0215] URI: https : / / < intern al URI> / DataQueryEngine

[0216] METHOD: POST

[0217] BODY: Request Payload JSON (JavaScript Object Notation) { "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" ,

[0218] "subprocesslD":"0a5684bb-257b-48c7-8707-44b0e98b29c4",

[0219] "engine":"data query engine",

[0220] "config": {

[0221] "category":"human sperm",

[0222] "resultTarget":"packaging recommendation"

[0223] },

[0224] "data":[

[0225] {

[0226] "type":"manual",

[0227] "typeDescription":"doctor",

[0228] "inputs":{

[0229] "motiliyPercent":47,

[0230] "motilityCategory":"slowly progressive motility",

[0231] "concentration":25.9,

[0232] "volumemMI":5,

[0233] "location":{

[0234] "country":"united states",

[0235] "state":"texas",

[0236] "city":"austin"

[0237] }

[0238] }

[0239] }

[0240] ]

[0241] }

[0242]

[0161] At Step 902, Data Query Engine receives Input Data via the API data payload.

[0243]

[0162] At Step 903, Input Data Payload is processed and analysed to determine all data types and values in received data payload, for example:

[0244] • API Body (Request Payload (JSON)) is processed and analysed;

[0245] • "engine" value is checked to determine schema;

[0246] • "config" values are checked against related schema; and

[0247] • "data" values are checked against related schema.

[0248]

[0163] At Step 904, the received data types and values are checked against available data types and values in the data lake to determine alignment, which may involve: • the processed API Body (Request Payload) being split into separate objects for further processing;

[0249] • each "data" section being processed individually to determine data alignment with data in the data lake;

[0250] • the dynamic alignment query being constructed via specific parsing process determined by "engine", "category" and "resultTarget" and each data sections being defined "type"; and

[0251] • the dynamic alignment query being sent to the data lake via an API.

[0252]

[0164] An example of the API dynamic alignment call being sent to the data lake is as follows:

[0253] URI: https : / / < intern al URI> / DataLake / Alignment

[0254] METHOD: POST

[0255] BODY: Request Payload JSON (JavaScript Object Notation)

[0256] {

[0257] "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" ,

[0258] "config": {

[0259] "category":"human sperm",

[0260] "resultTarget":"packaging recommendation"

[0261] },

[0262] "data": {

[0263] "motilityPercent":25.9,

[0264] "motilityCategory":"slowly progressive motility",

[0265] "concentration":47,

[0266] "volumemMI":5

[0267] },

[0268] "filters": [

[0269] {

[0270] "category":"human sperm"

[0271] },

[0272] {

[0273] "country":"united states"

[0274] },

[0275] {

[0276] "state" :"texas"

[0277] }

[0278] ]

[0279] }

[0165] An example of the API response from the data lake is as follows:

[0280] {

[0281] "alignment":"success",

[0282] "dataMatch": [

[0283] "motilityPercent",

[0284] "motilityCategory",

[0285] "concentration",

[0286] "volumemMI",

[0287] "Packaging"

[0288] ],

[0289] "filterMatch": [

[0290] {

[0291] "category":"human sperm"

[0292] },

[0293] {

[0294] "country":"united states"

[0295] },

[0296] {

[0297] "state" :"texas"

[0298] }

[0299] ],

[0300] "rows": 11346,

[0301] "dataLocation":"ARTDataLakeDatabase",

[0302] "dataStructure": "SQL"

[0303] }

[0304]

[0166] At Step 905, using input / data lake alignment results, a query is constructed that is designed to fetch all available data that is related (aligns to received input data), which may involve:

[0305] • the API response from data lake being processed and analysed;

[0306] • the "alignment" value being checked to confirm alignment status;

[0307] • all returned values being checked against schema; and

[0308] • parsing data lake response to construct a dynamic query.

[0309]

[0167] An example of the API dynamic query call to the data lake is as follows:

[0310] URI: https : / / < intern al URI> / DataLake / Query METHOD: POST

[0311] BODY: Request Payload JSON (JavaScript Object Notation)

[0312] {

[0313] "dataLocation":"ARTDataLakeDatabase",

[0314] "dataStructure": "SQL",

[0315] "dataFetch": [

[0316] "motilityPercent",

[0317] "motilityCategory",

[0318] "concentration",

[0319] "volumemMI",

[0320] "packaging"

[0321] ],

[0322] "applyFilter": {

[0323] "category":"human sperm",

[0324] "country":"united states",

[0325] "state":"texas"

[0326] }

[0327] }

[0328]

[0168] At Step 906, the dynamically created query is sent to the data lake for execution via an internal API (the query forming the API data payload), which may involve:

[0329] • the data lake receiving a dynamic data query API Request;

[0330] • the data lake processing and analysing the request against related schema;

[0331] • the data lake transforming the API request payload into required "dataStructure" (in this example "SQL"); and

[0332] • SQL query being executed and results being returned to the DQE (Data Query engine) as JSON

[0333] An example of a programmatic JSON to SQL transformation is as follows:

[0334] JSON from received dynamic query API call

[0335] {

[0336] "dataLocation":"ARTDataLakeDatabase",

[0337] "dataStructure": "SQL",

[0338] "dataFetch": [ motilityPercent", motilityCategory", 'concentration",

[0339] 'volumemMI",

[0340] 'packaging"

[0341] ],

[0342] "applyFilter": {

[0343] "category":"human sperm",

[0344] "country":"united states",

[0345] "state":"texas"

[0346] }

[0347] }

[0348] An example of an SQL statement programmatically generated from JSON using related schema from a received dynamic query API call is as follows:

[0349] USE ARTDataLakeDatabase;

[0350] SELECT

[0351] ID, motilityPercent, motilityCategory, concentration, volumemMI,

[0352] Packaging

[0353] FROM

[0354] HumanSperm

[0355] WHERE country = 'US' and state = 'texas';

[0356]

[0169] The SQL query is executed and results returned to the DQE (Data Query engine) as JSON. An example of the API response from the data lake may be as follows:

[0357] {

[0358] "dataLocation": "ARTDataLakeDatabase", "rows":

[0359] 11346,

[0360] "query": {

[0361] "dataFetch": [ "motilityPercent",

[0362] "motilityCategory", "concentration",

[0363] "volumemMI", "packaging" ],

[0364] "apply Filter" : {

[0365] "category": "human sperm", "country": "united states", "state" :"texas"

[0366] }

[0367] },

[0368] "data Result": [{ "ID": 1 ,

[0369] "motilityPercent": 40,

[0370] "motilityCategory": "slowly progressive motility", "concentration":

[0371] 56.14,

[0372] "volumemMI": 5,

[0373] "packaging": "macro packaging"

[0374] }, {

[0375] ... all other 11345 rows ...

[0376] }]

[0377] }

[0378]

[0170] At Step 907, the results of the dynamic query sent to the Data Lake are returned to the Data Query Engine.

[0379]

[0171] At Step 908, the dynamic data set is returned to Algorithm Backbone / Platform 104.

[0380] Algorithm Query Engine (algorithm selecting module), Algorithm Library, Algorithm Execution and Validation

[0381]

[0172] Further details of the Algorithm Query Engine (algorithm selecting module 204) and the execution and validation of the selected algorithm are described below with reference to the human sperm packaging use case examples, and the exemplary workflow shown in FIG.

[0382] 10.

[0383] Step 1002 - Input Data and Dynamic Data Set Sent to Algorithm Query Engine

[0384] The Algorithm Backbone / Platform 104 sends Input Data and Dynamic Data Set payload to the Algorithm Query Engine via API, as set out below:

[0385] • The Algorithm Backbone / Platform 104 sends the dynamic data set (dataSet) it retrieved from the data lake via the Data Query Engine to the Algorithm Query Engine. Before it sends the dynamic data set it adds the requestID, subprocessID, config and data (input data).

[0386] • Example API call to Algorithm Query Engine:

[0387] URI: https : / / < intern al URI> / / AlgorithmQueryEngine

[0388] METHOD: POST

[0389] BODY: Request Payload JSON (JavaScript Object Notation)

[0390] {

[0391] "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" ,

[0392] "subprocesslD":"0a5684bb-257b-48c7-8707-44b0e98b29c4",

[0393] "engine":"algorithm query engine",

[0394] "config": {

[0395] "category":"human sperm",

[0396] "resultTarget":"packaging recommendation"

[0397] },

[0398] "data": {

[0399] "motilityPercent":25.9,

[0400] "motilityCategory":"slowly progressive motility",

[0401] "concentration":47,

[0402] "volumemMI":5 "dataSet": {

[0403] "dataLocation":"ARTDataLakeDatabase",

[0404] "rows":11346,

[0405] "dataResult": [{

[0406] "ID": 1 ,

[0407] "motilityPercent":40,

[0408] "motilityCategory":"slowly progressive motility",

[0409] "concentration":56.14,

[0410] "volumemMI":5,

[0411] "packaging":"macro packaging"

[0412] }, {

[0413] ... all other 11345 rows ...

[0414] }]

[0415] }

[0416] }

[0417] Step 1004 - Input Data and Dynamic Data Set Received

[0418] Algorithm Query Engine receives Input Data and Dynamic Data Set via API data payload.

[0419] Step 1006 - Input Data and Dynamic Data Set Processed and Analysed

[0420] Input Data and Dynamic Data Set payload are processed and analysed, and a summary of data payload is sent to the Algorithm Library, as set out below:

[0421] • The Algorithm Query Engine uses its received data payload to generate a summary payload which is sent to the Algorithm Library o Instead of sending all the dynamic data to the Algorithm Library only an example is sent (first row)

[0422] • Example API call to Algorithm Library:

[0423] URI: https : / / < intern al URI> / AlgorithmLibrary

[0424] METHOD: POST

[0425] BODY: Request Payload JSON (JavaScript Object Notation)

[0426] {

[0427] "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" ,

[0428] "subprocesslD":"0a5684bb-257b-48c7-8707-44b0e98b29c4",

[0429] "config": {

[0430] "category":"human sperm", resultTarget":"packaging recommendation

[0431] },

[0432] "data": {

[0433] "motiliyPercent":25.9,

[0434] "motilityCategory":"slowly progressive motility",

[0435] "concentration":47,

[0436] "volumemMI":5

[0437] },

[0438] "dataSet": {

[0439] "dataLocation":"ARTDataLakeDatabase",

[0440] "rows":11346,

[0441] "dataResultExample": {

[0442] "ID": 1 ,

[0443] "motilityPercent":40,

[0444] "motilityCategory":"slowly progressive motility",

[0445] "concentration":56.14,

[0446] "volumemMI":5,

[0447] "packaging":"macro packaging"

[0448] }

[0449] }

[0450] }

[0451] Step 1008 - Specific Algorithm Selected

[0452] Summary of data payload generated in Step 1006 received by Algorithm Library which selects a specific algorithm to be executed

[0453] • The Algorithm Library analyses the received request payload (JSON) and identifies the following o category (Human Sperm) o resultTarget (packaging recommendation) o data (the initial input data) o dataSet rows (11346) o dataset dataResultExample (first row of dynamic data set data)

[0454] • Using the identified key value pairs the Algorithm Library programmatically searches its library of available algorithm index to find the most suitable algorithm for execution.

[0455] Step 1010 - Selected Specific Algorithm returned to Algorithm Query Engine The selected Specific Algorithm is returned to the Algorithm Query Engine:

[0456] • Example API response from Algorithm Library

[0457] {

[0458] "algorithmName":"humanSpermPackaging Recommendation",

[0459] "version":2.13,

[0460] }

[0461] Step 1012 - Selected Specific Algorithm returned to Algorithm / Backbone Platform

[0462] The selected Specific Algorithm is returned to the Algorithm / Backbone Platform, and the Input Data, Dynamic Data Set and Selected Specific Algorithm are then sent to an algorithm execution module.

[0463] • Example API call to the algorithm execution module:

[0464] URI: https : / / < intern al URI> / / AlgorithmExecution

[0465] METHOD: POST

[0466] BODY: Request Payload JSON (JavaScript Object Notation)

[0467] {

[0468] "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" ,

[0469] "subprocesslD":"0a5684bb-257b-48c7-8707-44b0e98b29c4",

[0470] "engine":"algorithm execution”,

[0471] "algorithm": {

[0472] "algorithmName":"humanSpermPackagingRecommendation",

[0473] "version": 2.13,

[0474] },

[0475] "config": {

[0476] "category":"human sperm",

[0477] "resultTarget":"packaging recommendation"

[0478] },

[0479] "data": {

[0480] "motilityPercent":25.9,

[0481] "motilityCategory":"slowly progressive motility",

[0482] "concentration":47,

[0483] "volumemMI":5

[0484] },

[0485] "dataSet": {

[0486] "dataLocation":"ARTDataLakeDatabase",

[0487] "rows": 11346, "dataResult": [{

[0488] "ID": 1 ,

[0489] "motilityPercent": 40,

[0490] "motilityCategory":"slowly progressive motility",

[0491] "concentration": 56.14,

[0492] "volumemMI": 5,

[0493] "packaging":"macro packaging"

[0494] }, {

[0495] ... all other 11345 rows ...

[0496] }]

[0497] }

[0498] }

[0499] Step 1014 - Specific Algorithm Executed

[0500] The Specific Algorithm is then executed using Input Data and Dynamic Data Set.

[0501] • Example API response from the algorithm execution module:

[0502] {

[0503] "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" ,

[0504] "subprocesslD":"0a5684bb-257b-48c7-8707-44b0e98b29c4",

[0505] "algorithm": {

[0506] "algorithmName":"humanSpermPackagingRecommendation",

[0507] "version": 2.13,

[0508] },

[0509] "config": {

[0510] "category":"human sperm",

[0511] "resultTarget":"packaging recommendation"

[0512] },

[0513] "data": {

[0514] "motiliyPercent":25.9,

[0515] "motilityCategory":"slowly progressive motility",

[0516] "concentration":47,

[0517] "volumemMI":5

[0518] },

[0519] "result": {

[0520] "packaging":"micro packaging",

[0521] "confidencePercent":99.25, }

[0522] }

[0523] Step 1016 - Specific Algorithm Validated

[0524] The output of the specific algorithm execution in Step 1014 above is then validated. In the present example, this involves: o Checking that confidencePercent is equal to or above an acceptable confidence threshold for the specific algorithm o Check that the row count used for training and testing the data model is equal or above at acceptable row count threshold for the specific algorithm

[0525] Step 1018 - Validated Specific Algorithm Output sent to Data Lake

[0526] Once validated, the Specific Algorithm Output is sent to the Data Lake together with the Input Data to allow it to be included in data sets for future executions of specific algorithms.

[0527] • Example API call to Algorithm Execution and Validation

[0528] URI: https : / / < intern al URI> / DataLake / AddData

[0529] METHOD: POST

[0530] BODY: Request Payload JSON (JavaScript Object Notation)

[0531] {

[0532] "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" ,

[0533] "subprocesslD":"0a5684bb-257b-48c7-8707-44b0e98b29c4",

[0534] "dataLocation":"ARTDataLakeDatabase",

[0535] "data": {

[0536] "timeStamp":1689612306,

[0537] "motilityPercent":25.9,

[0538] "motilityCategory":"slowly progressive motility",

[0539] "concentration":47,

[0540] "volumemMI":5,

[0541] "packaging":"micro packaging",

[0542] }

[0543] }

[0544] Step 1020 - Is further Al Processing required?

[0545] If yes, return to the Data Query Engine, if no continue to Step 1022.

[0546] Step 1022 - Validated Specific Algorithm Output returned to Algorithm / Backbone Platform Validated Specific Algorithm Output is returned to the Algorithm Backbone / Platform.

[0547] • Example API response from Algorithm Validation:

[0548] {

[0549] "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" ,

[0550] "subprocesslD":"0a5684bb-257b-48c7-8707-44b0e98b29c4",

[0551] "algorithm": {

[0552] "algorithmName":"humanSpermPackagingRecommendation",

[0553] "version": 2.13,

[0554] },

[0555] "config": {

[0556] "category":"human sperm",

[0557] "resultTarget":"packaging recommendation"

[0558] },

[0559] "data": {

[0560] "motilityPercent":25.9,

[0561] "motilityCategory":"slowly progressive motility",

[0562] "concentration":47,

[0563] "volumemMI":5

[0564] },

[0565] "result": {

[0566] "packaging":"micro packaging",

[0567] "confidencePercent":99.25,

[0568] "validated":true

[0569] }

[0570] }

[0571] Step 1024 - Validated Specific Algorithm Output returned to Subprocess

[0572] Validated Specific Algorithm Output is returned to the subprocess (e.g., part of a smart contract) that called it.

[0573] Example API response from Algorithm Backbone / Platform returned to related subprocess: {

[0574] "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" ,

[0575] "subprocesslD":"0a5684bb-257b-48c7-8707-44b0e98b29c4",

[0576] "algorithm": { 'algorithmName":"humanSpermPackagingRecommendation",

[0577] 'version": 2.13,

[0578] },

[0579] "config": {

[0580] "category":"human sperm",

[0581] "resultTarget":"packaging recommendation"

[0582] },

[0583] "data": {

[0584] "motilityPercent":25.9,

[0585] "motilityCategory":"slowly progressive motility",

[0586] "concentration":47,

[0587] "volumemMI":5

[0588] },

[0589] "result": {

[0590] "packaging":"micro packaging",

[0591] "confidencePercent":99.25,

[0592] "validated":true

[0593] }

[0594] }

[0595] Specific Algorithm Further Details

[0596]

[0173] FIG. 11 shows an exemplary workflow of how a specific algorithm is executed when it is called from Step 1014 “Specific Algorithm Executed” of FIG. 10. The specific algorithm in this example is a human sperm packaging recommendation algorithm.

[0597]

[0174] At Step 1102, an instance of the specific algorithm (e.g., Human Sperm Packaging Recommendation) is initialised, to which the input data and dynamic data Set are sent.

[0598]

[0175] At Step 1104, the algorithm loads model code. This code may include commonly available code such as those available in publicly-available machine learning code repositories. In this example, the specific machine learning model used is a logistic regression model, with supporting more generic code also loaded from publicly available sources.

[0599]

[0176] At Step 1106, the dynamic data set is split into a training data set and a testing data set using dynamically selected split ratio (e.g., based on the size of the dynamic data set).

[0600]

[0177] At Step 1108, the algorithm applies any required feature scaling.

[0601]

[0178] At Step 1110, the logistic regression model is trained using the training data set.

[0602]

[0179] At Step 1112, the input data is passed into the trained model, which returns a predicted result. In this case the result is a human sperm packaging recommendation.

[0180] At Step 1114, the trained model determines and returns a confidence level indicating an estimate of the accuracy of the prediction.

[0603]

[0181] At Step 1116, the predicted result and the associated confidence level are returned to the specific algorithm execution step (Step 1014) that initialised the specific algorithm.

[0604] Integration with a Smart Contract

[0605]

[0182] In at least some embodiments, the control system 102 described above may be integrated with a distributed ledger (e.g., blockchain) through the execution of a smart contract. An exemplary architecture of such a system is shown in FIG. 13.

[0606]

[0183] In the example of FIG. 13, the control system 102 includes Input / Output interfaces 1302, a code module 1304, and a ledger module 1306 in the form of a private blockchain.

[0607]

[0184] The Input / Output interfaces 1302 include one or more of the following : a web application, a mobile app, and a messaging / notification platform for sending / receiving messages and / or notification. Via these interfaces, users can interact with the control system 102, e.g., providing input to the control system 102, or be presented with messages / notifications or output from the control system 102.

[0608]

[0185] Preferably, the Input / Output interfaces 1302 further include one or more Internet of Medical Things (loMT) APIs, which allow the system to communicate with one or more loMT devices, e.g., receiving data from the loMT devices, and / or sending output data to the loMT devices, to control the processing of biological materials in these loMT devices.

[0609]

[0186] The Input / Output interfaces 1302 are in data communication with the code module 1304, and are configured to use the data received from the user and / or the loMT devices to generate data input for the code module 1304, and to send data / messages / notifications to the user and / or the loMT devices based on the data output from the code module 1304.

[0610]

[0187] The ledger module 1306 includes a blockchain gatekeeper module 1320 and a series of data blocks 1322A, 1322B, ...1322N. The blockchain gatekeeper module 1320 is configured to receive data from or send data to the code module 1304, to initialise new entities of one or more smart contracts, to submit entity transactions (write into the data blocks) and to query entity states and history (read from the data blocks). Preferably, to enhance the security of the system, blockchain gatekeeper module 1320 is only accessible from the code module 1304.

[0611]

[0188] The code module 1304 includes a code engine 1310, a smart contract logic submodule 1312 and an Al submodule 1318.

[0612]

[0189] The code engine 1310 coordinates the data communication with the Input / Output interfaces 1302 and the ledger module 1306, and the execution of the smart contract logic.

[0613]

[0190] The smart contract logic submodule 1312 executes the logic / code defined in an initialised smart contract template. The smart contract includes a series of milestones, each related to a specific stage or point in the handling of a biological material. At least one milestone in the smart contract defines a set of processing logic related to processing of the biological material, which involves using the Al submodule 1318 to determine, based on at least one input parameter, processing parameters for processing (e.g., as indicated by the current or the next milestone of the smart contract) of the biological material.

[0614]

[0191] Preferably, the code module 1304 further includes a validation submodule 1314 and a data processing submodule 1316.

[0615]

[0192] The validation submodule 1314 validates the input data to be sent to the Al submodule 1318, as well as the data output from the Al submodule 1318. For example, the input data may be checked to confirm if it is in the correct format, and whether its data values are in a valid range (e.g., predefined for each category of input). The output data may be checked against a predetermined range of values which is defined as acceptable output data. As described in further detail hereinafter, this data validation process may be integrated into the smart contract logic submodule 1312, or the Al submodule 1318.

[0616]

[0193] The data processing submodule 1316 performs pre-processing on the data to be sent to the Al submodule 1318, as well as post-processing on the data output from the Al submodule 1318. As described in further detail hereinafter, the pre-processing and the postprocessing may be integrated into the smart contract logic submodule 1312, or the Al submodule 1318.

[0617]

[0194] FIG. 14 shows a more detailed example of the smart contract logic submodule 1312 and the Al submodule 1318.

[0618]

[0195] The Al submodule 1318 includes the Algorithm Backbone / Platform (i.e., the orchestration module 104), the data retrieving module 202 (i.e., the Data Query engine, or DQE), the algorithm selecting module 204 (i.e., the Algorithm Query Engine, or AQE), and the algorithm execution module 210.

[0619]

[0196] The Al submodule 1318 may further include the algorithm library 206 and the data lake 208.

[0620]

[0197] Alternatively, one or both of the algorithm library 206 and the data lake 208 may be provided outside of the Al submodule 1318 or the code engine 1310, but accessible from the Al submodule 1318, e.g., via the data retrieving module 202 and / or the algorithm selecting module 204.

[0621]

[0198] As shown in FIG. 14, a subprocess of the milestone executed by the smart contract logic submodule 1312 can utilise the Al submodule 1318 by sending input data and receiving Al processed output data. This Al processed output data can then be used to determine the next subprocess required in the non-deterministic smart contract process flow.

[0199] FIG. 14 also shows an exemplary workflow of the Al processing being executed as part of the smart contract:

[0622] 1 . Milestone x executes Subprocess x.1 as determined by the smart contract.

[0623] 2. Subprocess x.1 requires Al processing and thus forwards input data as well as Al processing configuration to the Algorithm Backbone / Platform in the Al submodule 1318.

[0624] 3. The Algorithm Backbone / Platform processes the input data for Al processing along with the supplied Al processing configuration. This processing determines the dynamic model data that is required and sends the model data query details to the data lake for processing.

[0625] 4. The data lake inspects the model data query and facilitates the execution of this query and returns the latest available data it has back to the Algorithm Backbone / Platform as a data set object.

[0626] 5. The Algorithm Backbone / Platform then sends on the input data, configuration data and dynamic model data for Specific Algorithm Selection.

[0627] 6. Using the received input data, configuration data and dynamic model data, the required Specific Algorithm is requested from the Algorithm Library.

[0628] 7. The Algorithm Library returns the requested Specific Algorithm that is required for Al processing.

[0629] 8. The selected Specific Algorithm along with the input data, configuration data and dynamic model data are now used to execute the Specific Algorithm.

[0630] 9. The output from the Specific Algorithm processing, e.g., prediction (result) along with prediction probability (accuracy / confidence), are returned to the Algorithm Backbone / Platform. Dependent upon the configuration data, the Algorithm Backbone / Platform will determine if further Al processing is required. If so, steps 3 to 9 will be repeated. At the conclusion of each iteration the Al-processed results along with the initial input data for Al processing is sent to the data lake to be used for Al processing in future execution cycles.

[0631] 10. When the Algorithm Backbone / Platform determines that required Al processing is completed, it will send all Al processed results back to Subprocess x.1 .

[0632] 11 . Using the Al-processed results received from the Algorithm Backbone / Platform along with the subprocess’s specific code / logic, Subprocess x.1 will at this point determine the next Subprocess to be executed. The next subprocess (Subprocess x.2) may or may not be predetermined. Subprocess x.2 may be the next subprocess listed in the related smart contract or may be dynamically selected or generated based on the Al-processed results from Subprocess x.1.

[0633]

[0200] Utilizing a smart contract allows for the real-time selection and / or dynamic creation of specific subprocesses within a milestone to be actioned depending on both static and changing conditions. These subprocesses that require Al processing are able to determine what type of Al processing is required based on the current state of the smart contract and its input data. Using the contract state and input data, the subprocess determines and creates the required Al processing configuration that is sent to the Al submodule 1318 along with the input data. When the Al submodule 1318 receives this data the Algorithm Backbone / Platform then inspects the Al processing configuration to determine which specific algorithm / s are required and then coordinates the dynamic fetching of the required model data needed from the data lake. This approach allows for each specific algorithm to utilise very specific and recent dynamic data for its modelling requirements.

[0634]

[0201] Preferably, the input data payload that requires Al processing has already undergone Al logic pre-processing prior to being sent to the Al submodule 1318. The output from the Al submodule 1318 will then undergo any required Al logic post-processing when returned to the related smart contract instance.

[0635]

[0202] Al Logic pre-processing is a process that undertakes the processing necessary to enable the Algorithm Backbone / Platform to properly interpret the input data payload. For example, it may build the required API data payload that is sent to the Al submodule 1318, which is first received by the Algorithm Backbone / Platform, then passed onto the DQE (Data Query Engine). The Al Logic Pre-processing process builds the API data payload by using the required input data for Al processing (“data”) and adding in a “RequestID” that the subprocess generates to track this processing, the actual Subprocess’s ID (“SubprocessID”) and the determined Al “config” (“category” and “resultTarget”).

[0636] Example of an API data payload (BODY: Request Payload JSON) URI: https : / / < intern al URI> / / DataQueryEngine

[0637] METHOD: POST

[0638] BODY: Request Payload JSON (JavaScript Object Notation) {

[0639] "requestl D" :"860720fd-a448-4a03-8d2e-2a7c4a38462e" , "subprocesslD":"0a5684bb-257b-48c7-8707-44b0e98b29c4", "engine":"data query engine", "config": {

[0640] "category":"human sperm",

[0641] "resultTarget":"packaging recommendation"

[0642] },

[0643] "data":[

[0644] { "type":"manual",

[0645] "typeDescription":"doctor",

[0646] "inputs":{

[0647] "motilityPercent":47,

[0648] "motilityCategory":"slowly progressive motility",

[0649] "concentration":25.9,

[0650] "volumemMI":5,

[0651] "location":{

[0652] "country":"united states",

[0653] "state":"texas",

[0654] "city":"austin"

[0655] }

[0656] }

[0657] }

[0658] ]

[0659] }

[0660]

[0203] The Al Logic Post-processing is performed by the subprocess once the Al processed data is returned to the subprocess that requested it. The Al Logic Post-processing process is a process that transforms the returned Al processed data into a format that is configured by the subprocess. The purpose of the Al Logic Post-processing is to transform the Al processed data into the desired format for subsequent processing, such as it being stored in the private blockchain as well as sent back to the user interface (if required).

[0661]

[0204] In an alternative approach, the input data payload that requires Al processing may have not undergone any Al logic processing prior to being sent to the Al submodule 1318.

[0662]

[0205] In this alternative approach, both the required Al Logic Pre-processing and Al Logic Post-processing are contained within the Algorithm Backbone / Platform, as shown in FIG. 15. With this approach, it is possible to repeat / iterate between Al logic Processing stages from within the Algorithm Backbone / Platform (if required).

[0663]

[0206] In this scenario, the raw input data is sent directly to the Al submodule 1318 and not from a subprocess. Because the Al processing request has not been initiated by a subprocess there has also not been any Al Logic Pre-processing performed on the raw input data payload and no facility for any Al Logic Post-processing to be performed on the output returned from the Al submodule 1318.

[0664]

[0207] In order for the DQE (Data Query Engine) to process the raw input data payload it would need to go through an Al Logic Pre-processing step prior to being sent to the DQE. In this context, the pre-processing step involves processing and formatting the raw input data payload so it can be accepted by the DQE. This pre-processing may include adding the required “config” information to be determined based on the raw input data payload.

[0665]

[0208] In this scenario, a corresponding Al Logic Post-processing step would be performed before the Al processed output is returned. In this instance, this post processing would involve checking the Al processed output against the initial inputs and consolidating the inputs and corresponding output.

[0666]

[0209] By incorporating the Al Logic Pre-processing and Al Logic Post-processing steps into the Algorithm Backbone / Platform, there is the ability for the Al Logic Post-processing to return to the Al Logic Pre-processing stage if required, instead of moving to the output stage.

[0667]

[0210] This option of looping on these steps takes into consideration the scenario where the initial input and Al processed output does not align or validate. In this case, the Algorithm Backbone / Platform can repeat the steps if needed. If this does occur the Al Logic Postprocessing step will monitor, and if required end execution loops to prevent the occurrence of an infinite loop scenario.

[0668]

[0211] According to at least some embodiments, the distributed ledger integrating the system described herein may be part of the system for controlling the handling of a biological material as described in Australian Provisional Patent Application No. 2022903337 in the name of Vitrafy Life Sciences Limited, the entire disclosure of which is incorporated herein by reference.

[0669]

[0212] FIG. 17 shows an example a system 1700 for controlling the handling of a biological material by a plurality of biological material handling apparatuses 1702. As shown, the apparatuses 1702 include a first apparatus 1704 and a second apparatus 1706. The system 1700 includes a coordination system 1708, a distributed ledger 1710, an input device 1712, a data storage location 1714 and a data lake 1728.

[0670] Coordination system

[0671]

[0213] The coordination system 1708 is a computing system including memory 1718 and at least one processor 1720. The coordination system 1708 coordinates the handling and processing of the biological material. To this end, the coordination system 1708 is configured to communicate with the distributed ledger 1710, the input device 1712, the data storage location 1714, the data lake 1728, each apparatus of the plurality of apparatuses 1702, and at least one packaging device 1726.

[0672] Input device

[0673]

[0214] The input device 1712 is configured to receive data relating to biological material and communicate that data to the coordination system 1708. The input device 1712 is associated with a user interface 1716 through which the device 1712 can receive user input of data relating to biological material, e.g., from a medical professional.

[0674] Distributed ledger

[0675]

[0215] The distributed ledger 1710 includes a plurality of distributed nodes 1722. The nodes 1722 are organized as a peer-to-peer network in which each node 1722 may connect to one or more of the other nodes 1722 using a peer-to-peer communication protocol. The configuration of connections between the nodes 1722 may change over time, with the nodes that form part of the network at any given point in time communicating using the peer-to-peer protocol. At least one of the nodes 1722 connects to the coordination system 1708. The distributed ledger 1710 is preferably a secure distributed ledger, and more preferably a cryptographically secured distributed ledger. Preferably, the distributed ledger 1710 is a decentralised distributed ledger. The distributed ledger 1710 may be a public distributed ledger or a private distributed ledger. Use of a private distributed ledger may allow one or more biological material handling apparatuses to host at least one node 1722 of the distributed ledger 1710, as described herein. In embodiments, the distributed ledger 1710 may be a blockchain network (also referred to as a 'blockchain'), such as a private blockchain network. In embodiments, the distributed ledger 1710 may include (at least in part) a public blockchain network.

[0676]

[0216] The coordination system 1708 is configured to write to the distributed ledger 1710 to store information, which includes storing information representing or derived from the mentioned information on the distributed ledger 1710. Where this specification refers to information being written to a distributed ledger, it should be interpreted as including writing that information to the distributed ledger, or writing to the distributed ledger any information representing or derived from that information.

[0677] Smart contracts

[0678]

[0217] Among other things, the distributed ledger 1710 stores one or more smart contract templates 1723 associated with handling or processing biological materials. Each smart contract template 1723 defines executable logic which can be executed by the coordination system 1708. The executable logic of a given smart contract template 1723 defines a set of rules in the form of milestones and corresponding subprocesses that are to take place in relation to biological material. Each smart contract template 1723 may correspond to a respective kind or category of biological material and / or a process related to a kind or category of biological material. For example, a particular template 1723 may correspond to CAR-T cell therapy (where the biological material includes peripheral blood mononuclear cells) or to assisted reproductive therapy (where the biological material may include sperm, eggs or embryos), or any other process or therapy involving the use of biological material (which could include, but is not limited to, extracted biological material and samples of biological material). Each template 1723 stored on the distributed network 1710 may be associated with a corresponding unique identifier ("template identifier").

[0679]

[0218] The distributed ledger 1710 also stores one or more smart contracts 1724, each of which is an instance of a smart contract template 1723. A smart contract 1724 is initialised on the distributed ledger 1710 using a relevant template 1723 in response to user input. The user input indicates the desired smart contract template 1723 to be used to initialise the smart contract 1724. The coordination system 108 receives the user input (e.g., via the input device 1712 as described herein) and accordingly sends a request to the distributed ledger 1710 to initialise and store the smart contract 1724 using the relevant template 1723. The coordination system 108 may assign a unique identifier to the initialised smart contract 1724 ("smart contract identifier"), which is stored along with the smart contract 1724 on the distributed ledger 1710.

[0680]

[0219] By processing a smart contract 1724 that is generated based on a template 1723 (i.e., a smart contract instance 1724 generated from a smart contract template 1723), the coordination system 1708 is able to maintain a record of data relating to the biological material, and control operations of relevant apparatuses 1702 to handle the biological material, e.g., for storage, transport, processing and the like. To control relevant apparatuses 1702, the coordination system 1708 can determine one or more commands or computer executable instructions, and transmit such commands or executable instructions to each of the plurality of apparatuses 1702.

[0681] Biological material handling apparatuses

[0682]

[0220] Each of the plurality of apparatuses 1702 is a biological material handling or processing apparatus. Exemplary biological material handling or processing apparatuses include but are not limited to: cryopreservation apparatuses for cryopreserving biological material by cooling to very low temperatures (appropriate temperatures which may include temperatures below the liquid-to-solid phase change temperature), thawing apparatuses for thawing biological material such as cryopreserved biological material, transport apparatuses for transporting the biological material under controlled conditions (e.g., a transport apparatus configured to transport the biological material using a drone or in temperature controlled conditions), storage apparatuses for storing the biological material under controlled conditions, bioreactor apparatuses, and analysis apparatuses (such as cell counter apparatuses for determining a number and / or type of cells present in the biological material and in vitro diagnostic apparatuses).

[0221] Components of an exemplary biological material handling or processing apparatus 1800 are schematically represented in FIG. 18. The apparatus 1800 includes a processor 1802, a communication module 1804, a data store 1806, and one or more sensors 1808 (three sensors are depicted by example only). The processor 1802 controls the operation of the apparatus 1800 and is configured to execute an application that manages the collection, processing, storage (to the data store 1806) and transmission of data received from any of the sensors 1808. The processor 1802 generates status information relating to operations carried out by the apparatus 1800 in relation to the biological material being handled by the apparatus 1800, the status information being transmitted to the coordination system 1708 by the communication module 1804.

[0683]

[0222] The status information can include monitoring information for the biological material. Monitoring information can include, for example, at least one of temperature monitoring information relating to a current temperature of the biological material, location monitoring information relating to a current location of the biological material, volume monitoring information relating to a volume of the biological material, and cell count information relating to a number of cells associated with the biological material.

[0684]

[0223] The communication module 1804 performs communications between the apparatus 1800 and the coordination system 1708 over at least one network, which may be a local area network (LAN) (such as an Ethernet or Wi-Fi network), a wide area network (WAN) (such as a 4G or 5G cellular network) or a personal area network (PAN) (which may include Bluetooth, ZigBee, Thread, Matter, Z-Wave, RFID or Wireless USB, or other short-range or mesh communication systems). In this regard, the coordination system 1708 may be configured to communicate with each of the plurality of apparatuses 1702 through a mesh network. The coordination system 1708 may also be configured to directly communicate with each of the plurality of apparatuses 1702. Where the communication at least partly uses a mesh network, at least a portion of the apparatuses 1702 can also communicate directly with one another using their respective communication modules 1804. Data communicated between the apparatus 1800 and the coordination system 1708 via the communication module 1804 may be encrypted. The communication module 1804 may communicate data to the coordination system 1708 using an Application Programming Interface (API) and a unique API key generated for the apparatus 1800. The communication module 1804 may also communicate data to the coordination system 1708 by directly writing to an open communications port of the coordination system 1708, or by any other appropriate (and preferably secure) means.

[0685]

[0224] Each of the sensors 1808 captures sensor data relating to biological material being handled or processed by the apparatus 1800. For example, a given sensor 1808 may be one of the following (although the given configuration of sensors may depend on the apparatus): a) a temperature sensor for monitoring a temperature of the biological material being handled or processed by the apparatus 1800; b) a location sensor for monitoring a location of the biological material being handled or processed by the apparatus 1800; c) a volume sensor for monitoring a volume of the biological material being handled or processed by the apparatus 1800; and d) a cell count sensor for monitoring a cell count of the biological material being handled or processed by the apparatus 1800.

[0686]

[0225] Any other appropriate sensor may be included in the biological material handling apparatus 1800.

[0687]

[0226] The processor 1802 collects and processes sensor data received from each of the sensors 1808 to generate status information, including monitoring information, which can be transmitted to the coordination system 1708 by the communication module 1804.

[0688]

[0227] The processor 1802 may store generated status information, including monitoring information, in the data store 1806 of the apparatus 1800. This may be in addition to transmitting the status information to the coordination system 1708 using the communication module 1804, such that the stored data can be later referred to, e.g., for data integrity or recovery purposes. The status information can also be stored in the data store 1806 before it is transmitted to the coordination system 1708 using the communication module 1804, such as where the coordination module 1804 is temporarily unable to communicate with the coordination system 1708 over the at least one network, e.g., due to being temporarily disconnected from the network.

[0689]

[0228] Thus, in the data store 1806 the apparatus 1800 can maintain a local database of information generated by the apparatus 1800. The status information stored in the data store 1806 may be referred to as historical status information. The historical status information can also be transmitted to coordination system 1708 by the communication module 1804. The maintenance of this local database may aid data capture reconciliation, data integrity and data recovery.

[0690]

[0229] Each apparatus 1800 may be associated with a unique identifier ("apparatus identifier"). As is further described herein, the apparatus identifier can be used when transmitting status information from the apparatus 1800 to the coordination system 1708 to allow the coordination system 1708 to identify the source of the information.

[0691]

[0230] In some embodiments, at least one apparatus of the plurality of apparatuses 1702 is configured to host at least one node 1722 of the distributed ledger 1710. Accordingly, spare processing capacity inside one or more of the apparatuses can be utilised by the distributed ledger 1710. The coordination system 108 may be configured to determine whether the apparatus has sufficient processing and storage capacity to host the at least one node 1722 of the distributed ledger. The coordination system 108 may also ensure that the apparatus also has sufficient processing and storage capacity to also carry out primary functions, such as controlling the operation of the apparatus to handle or process biological material, in addition to acting as a node. For example, the coordination system 1708 may determine whether the apparatus has sufficient processing and storage capacity to host the at least one node 1722 based on status information in the form of operational monitoring information that is receives from the apparatus. The operational monitoring information may include instantaneous and / or historical CPU utilisation, memory usage and storage utilisation of the apparatus. The operational monitoring information may be received periodically from the apparatus, e.g., every 10 seconds.

[0692]

[0231] If the coordination system 1708 determines that the apparatus has sufficient processing and storage capacity to host the at least one node 1722 without compromising its capacity to handle biological material, then the coordination system 1708 can allow the apparatus to host the at least one node 1722, such as by transmitting instructions to the apparatus to host the at least one node 1722. Once the apparatus is hosting the at least one node 1722, if the coordination system 1708 determines that the apparatus no longer has sufficient processing and storage capacity to host the at least one node 1722 without compromising its capacity to handle or process biological material (a determination which may be made based on the received operational monitoring information), then the coordination system 1708 can disable the apparatus from hosting the at least one node 1722, such as by transmitting instructions to the apparatus to cease hosting the at least one node 1722.

[0693] Data storage location and data lake

[0694]

[0232] In the system 1700 shown in FIG. 17, the data storage location 1714 stores executable instructions that, when executed by the coordination system 1708, cause the processor 1720 of the coordination system 1708 to perform at least the following:

[0695] (i) process the status information, the processing including validating the status information and determining a part (or parts) of the status information to store on the distributed ledger 1710;

[0696] (II) write to the distributed ledger 1710 to store the determined part (or parts) of the status information; and

[0697] (iii) write to the distributed ledger 1710 to update the status of the smart contract 1724.

[0698]

[0233] An authorised administrator is able to edit executable instructions stored in the data storage location 1714 and add executable instructions to the data storage location 1714 at any time. While the executable instructions are retrieved and executed in accordance with the smart contract 1724, they need not be committed to the distributed ledger 1710. This may allow the executable instructions to be more easily modified by the authorised administrator, who has access to the data storage location 1714 but may not have access to the distributed ledger 1710. Furthermore, where the distributed ledger 1710 is an immutable distributed ledger such as a blockchain network, the storage of the executable instructions in the data storage location 1714 rather than the distributed ledger 1710 avoids the executable instructions being immutably committed to the distributed ledger 1710, and the associated computational / storage resources that would be required in the event that any executable instructions require modification. In this regard, if the executable instructions were to be stored on the distributed ledger 1710, each node 1722 would be required to maintain a separate copy of the executable instructions. Additionally, any modification to the executable instructions stored on the distributed ledger 1710 would require the distributed ledger 171 O to ensure that consensus is reached among the nodes 1722, such as by the nodes 1722 executing a consensus protocol. Furthermore, if the executable instructions were immutably committed to the distributed ledger 1710, then any modification to the executable instructions stored on the distributed ledger would require the both the modified executable instructions and the original executable instructions to be stored on the distributed ledger 1710. However, since the executable instructions are stored in the data storage location 1714, only a single record of the executable instructions is required and the data need not be maintained in more than one location. It is also unnecessary for the data storage location 1714 to execute a consensus protocol or the like when modifications are made to the executable instructions. Meanwhile, it is still possible to maintain security of the executable instructions stored in the data storage location 1714 such as by requiring special permissions to modify data stored in the data storage location 1714.

[0699]

[0234] The coordination system 1708 can query the data storage location 1714 to retrieve executable instructions stored therein.

[0700]

[0235] The data lake 1728 (which may be different from, or the same as, data lake 208) is a data storage location in which the coordination system 1708 stores status information and identification information received from any of the input device 1712, plurality of apparatuses 1702 and packaging device 1726. The coordination system 1708 may also store data that it generates when executing the executable instructions retrieved from the data storage location 1714 in the data lake 1728.

[0701]

[0236] The data storage location 1714 and the data lake 1728 can each include any suitable data storage mechanisms, such as local data stores, cloud storage, or distributed file systems (DFS) (e.g., Interplanetary File System (IPFS)). Although FIG. 17 shows the data storage location 1714 and data lake 1728 separately, the data storage location 1714 and data lake 1728 can be a single data storage location. Packaging device

[0702]

[0237] The packaging device 1726 is for receiving and containing the biological material, such as while it is being processed, stored and / or transported to and between any of the plurality of apparatuses 1702. For particularly sensitive biological materials, the packaging device 1726 may be configured for storage, preservation and / or thawing of biological material contained within the packaging device 1726. For example, the packaging device 1726 may be configured to contain the biological material while the biological material is being preserved, cooled or thawed by one of the plurality of apparatuses 1702. The packaging device 1726 may include an RFID tag that stores identification information of the packaging device 1726. The packaging device 1726 may include one or more thermal contours, where in use the biological material is distributed between sub-compartments of the packaging device 1726 and flow of a heat exchange fluid can be directed by the thermal contours to improve heat transfer between the heat exchange fluid and the biological material contained in the sub-compartments.

[0703] Examples of suitable packaging devices are described in Australian Provisional Application No. 2021904254, the entire disclosure of which is incorporated herein by reference.

[0704]

[0238] Components of an exemplary packaging device 1726 are schematically represented in FIG. 19. The packaging device 1900 includes a processor 1902, a communication module 1904, a data store 1906, and one or more sensors 1908 (three sensors are depicted by example only). The communication module 1904 performs communications between the packaging device 1726 and the coordination system 1708 over at least one network, e.g., a LAN and / or WAN as described in relation to the communication module 1804 of the biological material handling apparatus 1800. Data communicated between the packaging device 1726 and the coordination system 1708 via the communication module 1904 may be encrypted. The communication module 1904 may communicate data to the coordination system 1708 using an Application Programming Interface (API) and a unique API key generated for the packaging device 1726.

[0705]

[0239] Each of the sensors 1908 captures sensor data relating to biological material being stored by the packaging device 1726. For example, a given sensor 1908 may be one of the following: e) a temperature sensor for monitoring a temperature of the biological material being stored by the packaging device 1726; f) a location sensor for monitoring a location of the biological material being stored by the packaging device 1726; g) a volume sensor for monitoring a volume of the biological material being stored by the packaging device 1726; h) a cell count sensor for monitoring a cell count of the biological material being stored by the packaging device 1726; i) a shock sensor for monitoring impacts to the packaging device 1726.

[0706]

[0240] The processor 1902 collects and processes sensor data received from each of the sensors 1908 to generate status information, in the form of monitoring information, which can be transmitted to the coordination system 1708 by the communication module 1904.

[0707]

[0241] Similarly to the apparatus 1800 described above, the processor 1902 may store generated monitoring information to the data store 1906 of the packaging device 1726, such that the stored data can be later referred to, e.g., for data integrity or recovery purposes. Thus, in the data store 1906 the packaging device 1726 can maintain a local database of information generated by the packaging device 1726. The monitoring information stored in the data store 1906 may be referred to as historical monitoring information. The historical monitoring information can also be transmitted to coordination system 1708 by the communication module 1904. The maintenance of this local database may aid data capture reconciliation, data integrity and data recovery.

[0708] Alternative system architecture

[0709]

[0242] In the embodiments described above, the model data set is retrieved from the data lake before the selection of the specific algorithm.

[0710]

[0243] Alternatively, in at least some embodiments, the model data set may be retrieved after the selection of the specific algorithm, as shown in FIG. 16. This alternative approach would also allow the generation of a just-in-time data set for training the specific algorithm. In such a scenario, the specific algorithm is selected based on the input parameters (e.g., the input data and the configuration data). Optionally, the logic for retrieving the model data set may be integrated into the specific algorithm, rather than performed by the data retrieving module (i.e. , Data Query Engine).

[0711]

[0244] Retrieving the data set after the selection of the specific algorithm may allow tailoring the size of the model data set based on the requirement of the specific algorithm. That is, if a specific algorithm can deliver sufficient accuracy by training on a data set of a certain size (e.g., 10,000 observations), then the size of the data set retrieved from the data lake can be limited to that size. This may reduce the size of the data set passed from the data lake to the specific algorithm, and therefore may increase the speed of training the specific algorithm, and the general operational efficiency of the system.

[0712] Advantages and technical effects

[0245] As described above, the system architecture and the Algorithm Backbone / Platform driven approach enable the dynamic fetching of the latest JIT (Just In Time) data set from the data lake just before a specific algorithm is executed. This is achieved with the use of the Data Query Engine.

[0713]

[0246] Using this dynamic JIT data set along with the input data, the latest and most optimal specific algorithm is selected from the available algorithms in the Algorithm Library using the Algorithm Query Engine.

[0714]

[0247] One benefit of fetching the dynamic JIT data set prior to specific algorithm selection is to decouple the data sets from the specific algorithms. This allows for improved flexibility for both dynamic JIT data set creation and specific algorithm selection. It also allows for the most optimal specific algorithm to be selected. The use of this approach and the algorithm library allows for a highly scalable and modular solution that may facilitate the use of a large number of evolving custom algorithms available for selection and execution.

[0715]

[0248] Furthermore, the data in the data lake may be updated by all integrated biological material processing devices (e.g., loMT devices as shown in FIG. 13) in real-time. As well as the real-time data, the data lake also captures the predicted results generated from other specific algorithms preceding a specific algorithm's execution. This approach ensures that the latest available data is always used to create the required specific algorithm data models.

[0716]

[0249] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:1 . A method for controlling the processing of a biological material, including: receiving at least one input parameter associated with a biological material: retrieving, by a data retrieving module, a first data set from a data store based on the at least one input parameter; selecting, by an algorithm selecting module, from a plurality of candidate machine learning algorithms, a first machine learning algorithm for processing the at least one input parameter, wherein the first machine learning algorithm is selected based on the at least one input parameter or the first data set; training the first machine learning algorithm using at least part of the first data set; applying the trained first machine learning algorithm to the at least one input parameter to determine a first processing parameter for subsequent processing of the biological material; and outputting the first processing parameter for subsequent processing of the biological material.

2. The method of claim 1 , further including: storing the input parameter and the first processing parameter in the data store.

3. The method of claim 2, further including determining whether the first processing parameter is valid; wherein the input parameter and the first processing parameter are stored in the data store only when the first processing parameter is valid, and immediately after the first processing parameter is determined to be valid.

4. The method of claim 3, wherein determining whether the first processing parameter is valid includes: determining a confidence level; and determining that the first processing parameter is valid when the confidence level is higher than a predetermined threshold.

5. The method of any one of the preceding claims, wherein the first machine learning algorithm is selected based on the at least one input parameter.

6. The method of any one of claims 1 - 4, wherein the first machine learning algorithm is selected based on the first data set.

7. The method of any one of the preceding claims, wherein the at least one input parameter includes a plurality of data types, each of which is associated with a corresponding data value; and wherein retrieving the first data set includes retrieving data records having one or more corresponding data types and associated data values.

8. The method of claim 1 , wherein the first data set is retrieved further based on an output data type.

9. The method of claim 1 , wherein the candidate machine learning algorithms are stored in an algorithm library, and wherein selecting the first machine learning algorithm includes: retrieving the first machine learning algorithm from the algorithm library.

10. The method of claim 9, further includes: adding, deleting, or updating at least one candidate machine learning algorithm in the algorithm library.11 . The method of claim 1 , wherein the data store stores data including device data or sample data uploaded from at least one biological material processing device.

12. The method of claim 11 , wherein the device data or sample data includes one or more processing parameters generated by the at least one biological material processing device undertaking a method as claimed in any one of claims 1 -9.

13. The method of claim 11 or 12, wherein the upload of device data or sample data is commenced as soon as an appropriate data channel is available after it is generated.

14. The method of any one of the preceding claims, further including: using a proportion of the first data set as a training data set, and the remainder of the first data set as a testing data set.

15. The method of claim 14, wherein the proportion of the first data set used as a training set is at least partly determined by the size of the first data set.

16. The method of any one of the preceding claims, further including:retrieving, by the data retrieving module, a second data set from the data store based on the input parameter; selecting, by the algorithm selecting module, from the plurality of candidate machine learning algorithms, a second machine learning algorithm for processing the input parameter, wherein the second machine learning algorithm is selected based on the input parameter or the second data set; training the second machine learning algorithm using the second data set; applying the trained second machine learning algorithm to the input parameter to determine a second processing parameter for subsequent processing of the biological material; and outputting the second processing parameter for subsequent processing of the biological material.

17. The method of any one of claims 1 to 15, further including: retrieving, by the data retrieving module, a second data set from the data store based on the first processing parameter; selecting, by the algorithm selecting module, from the plurality of candidate machine learning algorithms, a second machine learning algorithm for processing the first processing parameter, wherein the second machine learning algorithm is selected based on the first processing parameter or the second data set; training the second machine learning algorithm using the second data set; applying the trained second machine learning algorithm to the first processing parameter, to determine a second processing parameter for subsequent processing of the biological material; and outputting the second processing parameter for subsequent processing of the biological material.

18. The method of any one of the preceding claims, wherein the biological material includes one or more of the following: a) whole blood; b) blood components, such as blood platelets, red blood cells, white blood cells, plasma and other blood products; c) stem cells, such as haematopoietic stems cells, mesenchymal stem cells and embryonic stem cells; d) modified cells; e) engineered cellsf) gametes, such as egg cells and sperm; g) blastocytes h) oocytes;I) organs, including parts thereof; and j) tissue.

19. The method based on any one of the preceding claims, the subsequent biological material processing includes at least one of: packaging, storing or transporting a biological material; refrigeration, freezing, thawing, cryopreservation of the biological material; assay development; sample collection; cell diagnostics; bioreactor-based processing; and expansion of biomaterials.

20. The method of any one of the preceding claims, wherein the at least one input parameter is received by an orchestration module; the method further including: the orchestration module sending the input parameter to the data retrieving module; the orchestration module receiving the first data set from the data retrieving module; the orchestration module sending the at least one input parameter or the first data set to the algorithm selecting module for selecting the first machine learning algorithm; the orchestration module receiving first processing parameter determined by the first machine learning algorithm.21 . The method of claim 20 when dependent on claim 17, wherein the orchestration module sends the first processing parameter to the data retrieving module of claim 17.

22. The method of any one of the preceding claims, further including: controlling a biological material processing device to perform subsequent processing of the biological material using the first processing parameter.

23. A method for biological material processing, including: receiving at least one input parameter associated with a biological material:selecting, by an algorithm selecting module, from a plurality of candidate machine learning algorithms, a first machine learning algorithm for processing the at least one input parameter, wherein the first machine learning algorithm is selected based on the input parameter; retrieving a first data set from a data store based on the first machine learning algorithm; training the first machine learning algorithm using at least part of the first data set; applying the trained first machine learning algorithm to the at least one input parameter to determine a first processing parameter for subsequent processing of the biological material; and outputting the first processing parameter for subsequent processing of the biological material.

24. A system for controlling the processing of a biological material, the system including: at least one processor; and a memory storing computer program instructions, which when executed by the at least one processor cause the system to perform a method as claimed in any one of the preceding claims.

Images