Method for controlling the handling of biological materials

Abstract

1. A method for controlling the handling of biological material, the method comprising: receiving, from a first device of a plurality of devices, a device associated with a user interface for inputting data related to the biological material, or a biological material packaging device, status information for the material and identification information identifying a smart contract associated with the material; querying a distributed ledger to retrieve a current status of the smart contract associated with the material; querying a secure, non-distributed ledger data store to retrieve executable instructions; and executing the instructions to process the status information, the processing including verifying the status information, determining portions of the status information to store in the distributed ledger, and writing to the distributed ledger to store the determined portion or portions of the status information and updating the status of the smart contract.

Description

[Technical Field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates to methods for controlling the handling of biological material, and more particularly, to controlling the handling of biological material by one or more biological material handling devices. [Background technology]

[0002] Biological materials are collected for a variety of purposes, including, but not limited to, medical therapy, treatment, diagnosis, and research. Depending on the purpose for which the biological material is collected, the biological material may undergo many handling steps, which may include, among other things, transport, processing, and storage of the biological material. For example, if the biological material contains cells (e.g., a blood sample), processing the biological material may include cell isolation, differentiation, or expansion. In this regard, at all stages of handling biological materials, it is important that the biological material be identified by its source, such as a human patient or animal subject.

[0003] For example, in the field of personalized and precision medicine, such as cell and gene therapy, biological materials are collected from patients or donors and transported to processing facilities to generate therapeutic products before being transported and administered to patients. When processing or processing cannot be performed at a single facility, biological materials must be transported between multiple facilities. Depending on the application, the nature of the sample and / or the geographic distance between the collection point, processing facility, and administration point may require the samples to be cooled or cryopreserved prior to storage and transport to avoid damage to the biological material. Furthermore, due to the personalized nature of such therapies, high confidence in the chain of custody, identity, and processing associated with the biological material can be critical. While these goals may be easily achieved at a clinical scale, they can present challenges at a commercial scale, where errors in identification and processing are much more likely to occur and may even go undetected. Summary of the Invention [Problem to be solved by the invention]

[0004] It is desired to address or ameliorate one or more of the disadvantages or limitations associated with the prior art, or at least provide a useful alternative. [Means for solving the problem]

[0005] In accordance with at least one embodiment of the present invention, there is provided a method for controlling the handling of biological material by a plurality of biological material handling devices, the method being carried out by a processor executing computer program instructions stored in a memory, the method comprising: receiving, from one of the plurality of devices, a device associated with a user interface for inputting data related to the biological material, and one of the biological material packaging devices, status information for the biological material and identification information identifying a smart contract related to the biological material; querying a cryptographically secured distributed ledger using the identifying information to retrieve smart contracts associated with the biological material, including the current status of the smart contracts; Querying a data store to retrieve executable instructions based on the retrieved smart contracts and their current status, wherein the data store is not a secure distributed ledger; and Executing the executable instructions to cause the processor to at least process the status information, where the processing includes verifying the status information and determining a portion or portions of the status information to store in the distributed ledger, causing the processor to write to the distributed ledger, storing the determined portion or portions of the status information, and updating the status of the smart contract; Includes.

[0006] In accordance with at least a further embodiment of the present invention, there is further provided a method for controlling the handling of extracted biological material from initial extraction to ultimate use, the handling comprising a plurality of stages, the method comprising carrying out the method described above at each of the plurality of stages.

[0007] In accordance with at least another embodiment of the present invention, a system for controlling the handling of biological material is provided, including a plurality of biological material handling devices, a coordination system, a cryptographically secured distributed ledger, and a data store. The coordination system includes a processor for executing computer program instructions and a memory for storing computer program instructions for execution by the processor. The cryptographically secured distributed ledger stores smart contracts related to the biological material. The data store stores searchable computer-executable instructions rather than a secure distributed ledger. The computer program instructions stored in the memory, when executed by the processor, include instructions that cause the coordination system to: receive biological material status information and identification information identifying the smart contract from one of a first device of the plurality of devices, a device associated with a user interface for inputting data related to the biological material, and a biological material packaging device; query the distributed ledger using the identification information to retrieve the smart contract and its current status; and query the data store based on the smart contract and its current status to retrieve the computer-executable instructions. The computer-executable instructions stored in the data store include instructions that, when executed by the processor, cause the coordination system to process the status information by verifying and determining a portion or portions of the status information for storage in the distributed ledger, store the determined portion or portions of the status information, and write to the distributed ledger to update the status of the smart contract.

[0008] In accordance with at least another embodiment of the present invention, there is further provided a coordination system for controlling the handling of biological material, the coordination system including at least one processor and a memory storing computer program instructions that, when executed by the at least one processor, cause the coordination system to perform the above method.

[0009] In accordance with the present invention, there is further provided a non-transitory machine-readable storage medium having computer program instructions that, when executed by at least one processor of a coordination system, cause the coordination system to perform the above method.

[0010] Some embodiments of the present invention will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a schematic diagram illustrating one embodiment of a system for controlling the handling of biological material by multiple biological material handling devices. [Figure 2] FIG. 2 is a schematic diagram showing components of one embodiment of a biological material handling device. [Figure 3] FIG. 3 is a schematic diagram showing components of one embodiment of a packaging device. [Figure 4] FIG. 4 is a flow chart illustrating one embodiment of a method for controlling the handling of biological material by one or more biological material handling devices. [Figure 5] FIG. 5 is a flowchart illustrating steps that may be included in some embodiments of a method involving receiving historical status information and historical identification information. [Figure 6] FIG. 6 is a flowchart illustrating steps that may be included in some embodiments of a method involving receiving historical status information and historical identification information. [Figure 7]FIG. 7 is a schematic diagram illustrating an example of a coordination system that receives and processes status information to identify subsequent sub-processes to be executed. [Figure 8] FIG. 8 is a schematic diagram illustrating an example of a coordination system that receives and processes status information to identify subsequent sub-processes to be executed. [Figure 9] FIG. 9 is a schematic diagram illustrating an example of a coordination system that receives and processes status information to identify subsequent sub-processes to be executed. [Figure 10] FIG. 10 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 11] FIG. 11 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 12A] FIG. 12A is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 12B] FIG. 12B is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 13] FIG. 13 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 14] FIG. 14 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 15] FIG. 15 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 16]FIG. 16 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 17] FIG. 17 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 18] FIG. 18 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 19] FIG. 19 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 20] FIG. 20 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 21] FIG. 21 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 22] FIG. 22 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 23] FIG. 23 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 24A] FIG. 24A is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 24B]FIG. 24B is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 25] FIG. 25 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 26] FIG. 26 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 27] FIG. 27 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 28] FIG. 28 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. [Figure 29] FIG. 29 is a flowchart illustrating the milestones and sub-processes of a smart contract for controlling the handling of biological materials intended for CAR-T therapy. DETAILED DESCRIPTION OF THE INVENTION

[0012] In at least some embodiments, the present invention provides systems and methods for controlling the handling of biological material by one or more of a plurality of biological material handling devices.

[0013] 1 illustrates one embodiment of a system 100 for controlling the handling of biological material by a plurality of biological material handling devices 102. As shown, the devices 102 include a first device 104 and a second device 106. The system 100 includes a coordination system 108, a distributed ledger 110, an input device 112, a data store 114, and a data lake 128.

[0014] Coordination System Coordination system 108 is a computing system including memory 118 and at least one processor 120. Coordination system 108 coordinates the handling of biological material. To this end, coordination system 108 is configured to communicate with distributed ledger 110, input device 112, data store 114, data lake 128, each device of plurality of devices 102, and at least one packaging device 126.

[0015] Input Devices The input device 112 is configured to receive data related to the biological material and communicate the data to the coordination system 108. The input device 112 is associated with a user interface 116 through which the device 112 can receive user input of data related to the biological material, for example from a medical professional.

[0016] Distributed Ledger The distributed ledger 110 includes a plurality of distributed nodes 122. The nodes 122 are configured as a peer-to-peer network, with each node 122 being able to connect to one or more of the other nodes 122 using a peer-to-peer communication protocol. The configuration of connections between the nodes 122 may change over time, with the nodes forming part of the network at any given time communicating using the peer-to-peer protocol. At least one of the nodes 122 connects to the coordination system 108. The distributed ledger 110 is preferably a secure distributed ledger, and more preferably a cryptographically secure distributed ledger. Preferably, the distributed ledger 110 is a distributed distributed ledger. The distributed ledger 110 may be a public or private distributed ledger. The use of a private distributed ledger may enable one or more biological material handling devices to host at least one node 122 of the distributed ledger 110, as described herein. In an embodiment, the distributed ledger 110 may be a blockchain network (also referred to as a "blockchain"), such as a private blockchain network. In embodiments, the distributed ledger 110 may include (at least in part) a public blockchain network.

[0017] Coordination system 108 is configured to write information to distributed ledger 110, including storing information in distributed ledger 110 that represents or is derived from the information stored therein. References herein to information being written to a distributed ledger should be interpreted as including writing that information to the distributed ledger, or writing information to the distributed ledger that represents or is derived from that information.

[0018] Smart Contracts Among other things, the distributed ledger 110 stores one or more smart contract templates 123 related to the handling of biological materials. Each smart contract template 123 defines executable logic executable by the coordination system 108. The executable logic of a given smart contract template 123 defines a set of rules in the form of milestones and corresponding subprocesses to be performed in connection with the biological material. Each smart contract template 123 may correspond to a respective type or category of biological material and / or a process associated with the type or category of biological material. For example, a particular template 123 may correspond to CAR-T cell therapy (where the biological material includes peripheral blood mononuclear cells), or assisted reproductive technology (where the biological material may include sperm, eggs, or embryos), or other process or therapy involving the use of biological material (which may include, but is not limited to, extracted biological material and samples of biological material). Each template 123 stored in the distributed network 110 may be associated with a corresponding unique identifier (a "template identifier").

[0019] The distributed ledger 110 also stores one or more smart contracts 124, each of which is an instance of a smart contract template 123. A smart contract 124 is initialized on the distributed ledger 110 using an associated template 123 in response to user input. The user input indicates the desired smart contract template 123 to be used to initialize the smart contract 124. The coordination system 108 receives the user input (e.g., via an input device 112 as described herein) and, in response, sends a request to the distributed ledger 110 to initialize and save the smart contract 124 using the associated template 123. The coordination system 108 may assign a unique identifier to the initialized smart contract 124 (a "smart contract identifier"), which is stored along with the smart contract 124 on the distributed ledger 110.

[0020] By processing smart contracts 124 generated based on the templates 123 (i.e., smart contract instances 124 generated from the smart contract templates 123), the coordination system 108 can maintain records of data related to the biological material and control the operation of associated devices 102 for handling the biological material, e.g., storing, transporting, processing, etc. To control the associated devices 102, the coordination system 108 can determine one or more commands or computer-executable instructions and send such commands or executable instructions to each of the multiple devices 102.

[0021] Biological Material Handling Equipment Each of the plurality of devices 102 is a biological material handling device. Exemplary biological material handling devices include, but are not limited to, a cryopreservation device for cryopreserving biological material by cooling to a cryogenic temperature (a suitable temperature that may include a temperature below the liquid-to-solid phase change temperature), a thawing device for thawing biological material, such as cryopreserved biological material, a transport device for transporting biological material under controlled conditions (e.g., a transport device configured to transport biological material using a drone or under temperature-controlled conditions), a storage device for storing biological material under controlled conditions, a bioreactor device, and an analytical device (such as a cell counter device for determining the number and / or type of cells present in a biological material, and an in vitro diagnostic device).

[0022] The components of an exemplary biological material handling device 200 are represented schematically in Figure 2. Device 200 includes a processor 202, a communications module 204, a data store 206, and one or more sensors 208 (three sensors are depicted by way of example only). Processor 202 is configured to execute applications that control the operation of device 200 and manage the collection, processing, storage (in data store 206), and transmission of data received from any of sensors 208. Processor 202 generates status information related to operations performed by device 200 in connection with biological material handled by device 200, which status information is transmitted by communications module 204 to coordination system 108.

[0023] The status information may include monitoring information of the biological material, such as at least one of temperature monitoring information related to a current temperature of the biological material, location monitoring information related to a current location of the biological material, volume monitoring information related to a volume of the biological material, and cell count monitoring information related to a number of cells associated with the biological material.

[0024] The communications module 204 facilitates communications between the devices 200 and the coordination system 108 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 communications systems). In this regard, the coordination system 108 may be configured to communicate with each of the plurality of devices 102 over a mesh network. The coordination system 108 may also be configured to communicate directly with each of the plurality of devices 102. When communications at least partially use a mesh network, at least some of the devices 102 may also communicate directly with each other using their respective communications modules 204. Data communicated between the devices 200 and the coordination system 108 via the communications module 204 may be encrypted. The communications module 204 may communicate data to the coordination system 108 using an application programming interface (API) and a unique API key generated for the device 200. The communications module 204 may also communicate data to the coordination system 108 by writing directly to an open communications port of the coordination system 108 or by other suitable (and preferably secure) means.

[0025] Each of the sensors 208 captures sensor data related to the biological material handled by the device 200. For example, a given sensor 208 may: a) a temperature sensor for monitoring the temperature of the biological material handled by the device 200; b) a position sensor for monitoring the position of the biological material handled by the device 200; c) a volume sensor for monitoring the volume of biological material handled by the device 200; and d) a cell count sensor for monitoring the cell count of biological material handled by the device 200; (although the specific configuration of the sensor may be device dependent).

[0026] The biological material handling device 200 may include any other suitable sensors.

[0027] The processor 202 collects and processes the sensor data received from each sensor 208 and generates status information, including monitoring information, that can be transmitted to the coordinate system 108 via the communication module 204 .

[0028] Processor 202 may store the generated status information, including the monitoring information, in data store 206 of device 200. This, in addition to transmitting the status information to coordination system 108 using communication module 204, can allow the stored data to be referenced at a later time, for example, for data integrity or recovery purposes. The status information can also be stored in data store 206 before being transmitted to coordination system 108 using communication module 204 if coordination module 204 is temporarily unable to communicate with coordination system 108 over at least one network, for example, because coordination module 204 is temporarily disconnected from the network.

[0029] Thus, in data store 206, device 200 can maintain a local database of information generated by device 200. The status information stored in data store 206 is sometimes referred to as historical status information. Historical status information can also be transmitted to coordination system 108 by communication module 204. Maintaining this local database can assist in data capture collation, data integrity, and data recovery.

[0030] Each device 200 can be associated with a unique identifier ("device identifier"). As described further herein, the device identifier can be used when sending status information from device 200 to coordination system 108, allowing coordination system 108 to identify the source of the information.

[0031] In some embodiments, at least one device among the plurality of devices 102 is configured to host at least one node 122 of the distributed ledger 110. Thus, spare processing power within one or more devices can be utilized by the distributed ledger 110. The coordination system 108 may be configured to determine whether a device has sufficient processing and storage power to host at least one node 122 of the distributed ledger. The coordination system 108 may also ensure that a device has sufficient processing and storage power to perform its primary function, such as controlling the operation of the device for handling biological material, in addition to functioning as a node. For example, the coordination system 108 may determine whether a device has sufficient processing and storage power to host at least one node 122 based on status information in the form of performance monitoring information received from the device. The performance monitoring information may include instantaneous and / or historical CPU utilization, memory utilization, and storage utilization of the device. The performance monitoring information may be received from the device periodically, for example, every 10 seconds.

[0032] If coordination system 108 determines that the device has sufficient processing and storage capabilities to host at least one node 122 without compromising its ability to handle biological material, coordination system 108 may allow the device to host at least one node 122, such as by sending instructions to the device to host at least one node 122. Once the device has hosted at least one node 122, if coordination system 108 determines that the device no longer has sufficient processing and storage capabilities to host at least one node 122 without compromising its ability to handle biological material (a determination that may be made based on received operational monitoring information), coordination system 108 may disable the device from hosting at least one node 122, such as by sending instructions to the device to cease hosting at least one node 122.

[0033] Data Residency and Data Lakes In the system 100 shown in FIG. 1, the data store 114, when executed by the coordinate system 108, provides the processor 120 of the coordinate system 108 with at least: (i) processing the status information, which processing includes verifying the status information and determining a portion (or portions) of the status information to store in the distributed ledger 110; (ii) writing to the distributed ledger 110 to store the determined portion(s) of the status information; (iii) writing to the distributed ledger 110 to update the status of the smart contract 124; The executable instructions for executing the above are stored.

[0034] Authorized administrators can edit the executable instructions stored in the data store 114 and add executable instructions to the data store 114 at any time. The executable instructions are retrieved and executed according to the smart contract 124, but do not need to be committed to the distributed ledger 110. This may allow authorized administrators who have access to the data store 114 but not the distributed ledger 110 to more easily modify the executable instructions. Furthermore, if the distributed ledger 110 is an immutable distributed ledger, such as a blockchain network, storing the executable instructions in the data store 114 rather than the distributed ledger 110 avoids the executable instructions being immutably committed to the distributed ledger 110 and the associated computational / storage resources that would be required if the executable instructions require modification. In this regard, storing executable instructions in the distributed ledger 110 requires each node 122 to maintain a separate copy of the executable instructions. Furthermore, when modifying executable instructions stored in the distributed ledger 110, the distributed ledger 110 must ensure that consensus is reached among the nodes 122, such as by the nodes 122 executing a consensus protocol. Furthermore, if executable instructions are immutably committed to the distributed ledger 110, modifying executable instructions stored in the distributed ledger requires storing both the modified and original executable instructions in the distributed ledger 110. However, because the executable instructions are stored in the data store 114, only one record of the executable instructions is required, and data does not need to be maintained in multiple locations. Furthermore, the data store 114 does not need to execute a consensus protocol or the like when modifications are made to the executable instructions. However, it is possible to maintain the security of the executable instructions stored in the data store 114, such as by requiring special permission to modify data stored in the data store 114.

[0035] Coordination system 108 may query data store 114 to retrieve executable instructions stored therein.

[0036] Data lake 128 is a data repository where coordinate system 108 stores status and identification information received from any of input devices 112, devices 102, and packaging devices 126. Coordination system 108 may also store in data lake 128 data generated when executing executable instructions retrieved from data repository 114.

[0037] Data store 114 and data lake 128 may each include any suitable data storage mechanism, such as a local data store, cloud storage, or a distributed file system (DFS) (e.g., Interplanetary File System (IPFS)). Although Figure 1 illustrates data store 114 and data lake 128 separately, data store 114 and data lake 128 may be a single data store.

[0038] packaging equipment The packaging device 126 is for receiving and containing biological material, such as while the biological material is being processed, stored, and / or transported to one of the multiple devices 102. For particularly sensitive biological material, the packaging device 126 may be configured for storage, preservation, and / or thawing of the biological material contained within the packaging device 126. For example, the packaging device 126 may be configured to contain the biological material while it is being stored, cooled, or thawed by one of the multiple devices 102. The packaging device 126 may include an RFID tag that stores identification information for the packaging device 126. The packaging device 126 may include one or more thermal contours. During use, the biological material is distributed between the compartments of the packaging device 126, and the flow of 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 compartments. An example of a suitable packaging device is described in Australian Provisional Patent Application No. 2021904254, the entire disclosure of which is incorporated herein by reference.

[0039] Components of an exemplary packaging device 126 are schematically represented in FIG. 3. The packaging device 300 includes a processor 302, a communications module 304, a data store 306, and one or more sensors 308 (by way of example, only three sensors are depicted). The communications module 304 facilitates communication between the packaging device 126 and the coordination system 108 over at least one network, e.g., a LAN and / or a WAN, as described in connection with the communications module 204 of the biological material handling device 200. Data communicated between the packaging device 126 and the coordination system 108 via the communications module 304 may be encrypted. The communications module 304 may communicate data to the coordination system 108 using an application programming interface (API) and a unique API key generated for the packaging device 126.

[0040] Each of the sensors 308 captures sensor data related to the biological material being stored by the packaging device 126. For example, a given sensor 308 may: e) a temperature sensor for monitoring the temperature of the biological material stored by the packaging device 126; f) a position sensor for monitoring the position of the biological material stored by the packaging device 126; g) a volume sensor for monitoring the volume of biological material stored by the packaging device 126; h) a cell count sensor for monitoring the cell count of biological material stored by the packaging device 126; i) an impact sensor for monitoring impacts to the packaging device 126; It may be one of the following.

[0041] The processor 302 collects and processes the sensor data received from each sensor 308 and generates status information in the form of monitoring information that can be transmitted to the coordinate system 108 by the communication module 304 .

[0042] Similar to the device 200 described above, the processor 302 can store the generated monitoring information in a data store 306 of the packaging device 126, where the stored data can be referenced at a later time, for example, for data integrity or recovery purposes. Thus, in the data store 306, the packaging device 126 can maintain a local database of information generated by the packaging device 126. The monitoring information stored in the data store 306 is sometimes referred to as historical monitoring information. The historical monitoring information can also be transmitted to the coordination system 108 by the communications module 304. Maintaining this local database can assist in data capture reconciliation, data integrity, and data recovery.

[0043] Biological Materials and Their Applications Biological materials include: a) whole blood; b) Blood components such as platelets, red blood cells, white blood cells, plasma, and other blood products; c) stem cells such as hematopoietic stem cells, mesenchymal stem cells, and embryonic stem cells; d) modified cells; e) artificial cells, f) Gametes such as egg cells and sperm; g) blastocyst, h) oocytes, i) an organ containing a part thereof, and j) organization; One or more of the following may be mentioned:

[0044] It should be understood that the examples of biological materials identified herein are not intended to be an exhaustive list and that the packaging may also be used in the storage of other biological materials.

[0045] The systems and methods described herein can be used to control the handling of biological materials for a variety of purposes, for example, the disclosed systems and methods can be used to control the handling of biological materials used in therapeutic treatments and cell therapy.

[0046] method 4 is a flow chart illustrating one embodiment of a method 400 for controlling the handling of biological material by multiple biological material handling devices. In this embodiment, method 400 is performed by processor 120 of coordination system 108. Method 400 begins at step 402.

[0047] In step 402, status information for the biological material and identification information identifying the biological material are received at the coordination system 108. The status information and identification information are received from at least one of a first device 104 of the plurality of devices 102, an input device 112 associated with a user interface 116, and a packaging device 126 for the biological material.

[0048] The identifying information uniquely identifies a smart contract stored in the distributed ledger 110 that corresponds to the biological material (i.e., a particular instance of the biological material) handled by the plurality of devices 102, and corresponds to the intended use or application of the biological material, e.g., chimeric antigen receptor T cell (CAR-T cell) therapy for white blood cells or assisted reproductive technology (ART) for sperm. The identifying information may include or correspond to the smart contract identifier of the associated smart contract.

[0049] The identification information may be generated by the coordination system 108 based on user input received from the user interface 116 via the input device 112 indicating that a new process, and therefore a new smart contract, is to be initiated.

[0050] The status information includes information received by the coordination system 108 that is related to the handling of biological material but is not identification information. For example, the status information may include information indicating the status of biological material handled by multiple devices 102. The status information may include information such as the volume of the biological material (e.g., mL or cell count) and the quality of the biological material. For example, if the biological material is sperm, the status information may indicate the volume, motility, and / or grade of the sperm. The status information may include information indicating the status of one or more devices 102 that handle the biological material.

[0051] By examining the received identification and status information, the coordination system 108 can identify the specific smart contracts 124 stored in the distributed ledger 110 that are needed to coordinate the handling of the biological material.

[0052] In some embodiments, coordination system 108 stores the received status information in data lake 128. Coordination system 108 may save the received status information along with associated identifying information in data lake 128 so that the status information for a particular smart contract 124 can be subsequently retrieved from data lake 128 as needed.

[0053] At step 404, the coordination system 108 queries the distributed ledger 110 to receive the smart contracts 124 determined to be needed. The query uses the identifying information received at step 402. At step 406, in response to the query, the coordination system 108 retrieves the determined smart contracts 124 from the distributed ledger 110. The retrieved smart contracts 124 are associated with the biological material by the identifying information and include the current status of the smart contracts 124. The current status of the smart contracts 124 indicates the "current" milestones and / or sub-processes defined by the smart contracts 124 that are currently occurring or will occur next with respect to the associated biological material.

[0054] In some embodiments, the identifying information includes a smart contract identifier of the required smart contact, as described above, which the coordination system 108 can use to query the distributed ledger 110 for the required smart contract 124.

[0055] Once the coordination system 108 retrieves the smart contract associated with the smart contract identifier, including the current status of that smart contract 124, in step 408, the coordination system 108 queries the data store 114 using the current status of the smart contract 124 and the smart contract 114 to retrieve executable instructions that define how the current milestone or process (determined by the current status of the smart contract 124) is to be executed by the coordination system 108.

[0056] In step 410 , coordination system 108 receives executable instructions from data store 114 in response to the query in step 408 .

[0057] In step 412, the coordination system 108 executes the retrieved executable instructions to execute the current milestone or sub-process. In this regard, execution of the executable instructions causes the processor 120 of the coordination system 108 to, at least, process and write received status information to the distributed ledger 110.

[0058] Processing the status information in step 412 may include validating the status information. Validation includes evaluating the status information to determine whether the status information meets one or more requirements of the current milestone or subprocess. This may include, for example, determining whether the status information meets a required threshold for the status information or is within a required range for the status information, where the threshold or range is defined by the executable instructions.

[0059] Processing the status information in step 412 may include determining a portion or portions of the status information to be stored in the distributed ledger 110. The processing may determine that all or only a portion of the status information needs to be stored in the distributed ledger 110 based on the content and / or characteristics of the status information. For example, if the status information includes temperature monitoring information having temperature readings every second, processing the status information may include determining that only one temperature reading should be stored in the distributed ledger 110 every 60 seconds, unless the difference between consecutive temperature readings exceeds a predetermined threshold. This may reduce the amount of data and associated computational resources required for storage in the distributed ledger 110, while ensuring that relevant information is committed to the distributed ledger.

[0060] By executing the executable instructions, the coordination system 108 can write to the distributed ledger 110 to store the determined portion or portions of the status information in the distributed ledger 110.

[0061] In some embodiments, writing the portion(s) of status information to the distributed ledger may include submitting a write request to a gatekeeper component (not shown) associated with the distributed ledger 110. The gatekeeper component, which may also be referred to as a "gateway," is a component of the distributed ledger 110 that manages interactions between the coordination system 108 and the distributed ledger 110, including requests from the coordination system 108 to read data stored in the distributed ledger 110 and requests from the coordination system 108 to write data to the distributed ledger 110.

[0062] The write request includes a portion of the status information and an associated smart contract identifier. In response to receiving the write request, the gatekeeper component may, for example, perform a process to transform the portion of the status information to make it more suitable for storage in the distributed ledger 110 and store the transformed portion of the status information in the distributed ledger 110.

[0063] As mentioned above, in some embodiments, coordination system 108 may store the status information in data lake 128. Thus, if only some or more portions of the status information are stored in distributed ledger 110 following processing in step 412, system 100 may still have the remaining some or more portions of the status information stored in data lake 128, if they are needed.

[0064] By executing the executable instructions, the coordination system 108 writes to the distributed ledger 110 to update the status of the smart contract. In this regard, by executing the executable instructions, the coordination system 108 determines that the current milestone or sub-process (corresponding to the executable instructions) is complete and identifies the subsequent milestone or sub-process to be achieved. The coordination system 108 updates the current status of the smart contract 124 on the distributed ledger by writing to the distributed ledger to store the new current status corresponding to the subsequent milestone or sub-process to be achieved. Thus, the next time the distributed ledger 110 is queried for the current status of the smart contract, the updated current status is returned.

[0065] Thus, the executable instructions are retrieved and executed according to the smart contract 124 stored in the distributed ledger, but the executable instructions themselves are stored in the data store 114 rather than the distributed ledger 110. This means that the logic defined by the executable instructions does not need to be stored and maintained by the distributed ledger 110, which may reduce the computational resources required by the distributed ledger. Additionally, storing the executable instructions in the data store 114 while the smart contract 124 is stored in the distributed ledger 110 may make it easier to edit the executable instructions as needed.

[0066] Embodiments of the present method enable the coordination system 108 to appropriately process and store received status information related to multiple processes, and therefore smart contracts.

[0067] In some embodiments, by executing the executable instructions, the processor 120 of the coordination system 108 further determines one or more commands or one or more computer-executable instructions to be executed by a second device 106 of the plurality of devices 102 and transmits those commands or computer-executable instructions to the second device 106.

[0068] The commands or computer-executable instructions can cause the coordination system 108 to control the operation of the second device 106 to handle the biological material in a manner directed by the executable instructions executed by the coordination system 108.

[0069] In some embodiments, method 400 includes coordinate system 108 receiving historical status information and historical identification information for the biological material, as shown in steps 502 and 602 of FIGS. 5 and 6 . As shown in steps 502 and 602 of FIGS. 5 and 6 , coordinate system 108 receives historical status information and historical identification information for the biological material. The historical status information and historical identification information are received from at least one of first device 104 and packaging device 126. As described herein above, coordinate system 108, device 102, and packaging device 126 may be connected in a mesh network. When status and identification information is transmitted from device 104, 106, or packaging device 126 to coordinate system 108 via the mesh, the status and identification information may be transmitted to coordinate system 108 via multiple communication paths. Thus, coordinate system 108 may receive the status and identification information multiple times.

[0070] If coordination system 108 has previously received status and identification information that corresponds to the historical status and identification information received in step 502 (or 602), then in step 504, coordination system 108 determines whether the previously received status information should be updated with the historical identification information. This determination is made by comparing the historical status and identification information with the previously received status and identification information. If, based on the comparison, coordination system 108 determines that the status and identification information has already been received (i.e., matches the previously received status and identification information), then it determines that the previously received status information should not be updated with the historical identification information. If, based on the comparison, coordination system 108 determines that there is a discrepancy between the previously received status information and the historical identification information, then in step 506, coordination system 108 updates the previously received status information by storing an additional entry in distributed ledger 110 that records the historical status information and flags the discrepancy.

[0071] Coordination system 108 also uses the historical identification information to determine whether coordination system 108 previously received status information and identification information corresponding to the historical status information and identification information from first device 104 and / or packaging device 126. If, in step 604, coordination system 108 determines that the historical status information has not previously been received, then, in step 406, coordination system 108 stores the historical status information in distributed ledger 110.

[0072] Thus, through receiving past status information and identification information from first device 104 and / or packaging device 126, coordination system 108 can identify errors in previously received status information that may have been stored in distributed ledger 110. Coordination system 108 can also identify "missing" status information that was previously received and should have been stored in distributed ledger 110, but was not. Coordination system 108 can also avoid storing multiple copies of status information and identification information if it is received multiple times.

[0073] Subprocess Selection Process FIG. 7 illustrates an example in which the coordination system 108 receives status information to select a subsequent sub-process in an embodiment in which the biological material is sperm collected from a patient for the purpose of ART.

[0074] In this example, the coordination system 108 receives input from the input device 112 in the form of status information, which is the sperm volume of the collected sample. The input also includes identification information (e.g., a smart contract identifier) ​​that allows the coordination system 108 to retrieve an associated smart contract 126 corresponding to the current patient and ART process, and the current status of that smart contract 126. In response to receiving the status information and the identification information, the coordination system 108 uses the identification information to query the distributed ledger 110 to retrieve the smart contract 126 associated with the sperm collected from the patient, including the smart contract's current status. Once retrieved, the coordination system 108 uses the current status to query the data store 114 to retrieve executable instructions. The retrieved executable instructions are associated with the current status of the smart contract 126. The coordination system 108 executes the retrieved executable instructions to cause a processor to process (at least) the status information and store at least a portion of the status information in the distributed ledger 110 as follows:

[0075] By executing the executable instructions, the coordination system 108 examines the status information to determine whether the sperm volume has passed the transition condition (i.e., the threshold sperm volume). In this example, the coordination system 108 determines that the transition condition has been met (i.e., there is sufficient sperm volume). The coordination system 108 then determines that the current sub-process is complete and queries the distributed ledger 110 to identify the next sub-process to accomplish (i.e., the new "current status" of the smart contract 126). In this case, this includes multiple concurrent sub-processes identified as initiating temperature monitoring of the collected sample contained within the packaging device 126, notifying the associated cryopreservation device of the upcoming biological material (belonging to multiple devices 102) and its characteristics, and verifying that regulatory standards are met by determining the appropriate command or computer-executable instruction and sending the command or computer-executable instruction to the packaging device 126.

[0076] FIG. 8 is another example illustrating how the coordination system 108 receives status information to select a subsequent sub-process in an embodiment where the biological material is sperm collected from a patient for ART.

[0077] In this example, the coordination system 108 receives input from the input device 112 in the form of status information, which is the sperm volume and sperm motility rate of the collected sample. The input also includes identification information (which may include a smart contract identifier or a patient identifier from which the coordination system 108 can derive a smart contract identifier) ​​that allows the coordination system 108 to retrieve an associated smart contract 126 corresponding to the current patient and ART process, and the current status of that smart contract 126. In response to receiving the status information and the identification information, the coordination system 108 uses the identification information to query the distributed ledger 110 to retrieve the smart contract 126 associated with the sperm collected from the patient, including the current status of the smart contract. Once retrieved, the coordination system 108 uses the current status to query the data store 114 to retrieve executable instructions. The retrieved executable instructions correspond to the current status of the smart contract 126. The coordination system 108 executes the retrieved executable instructions to cause a processor to process (at least) the status information and store it in the distributed ledger as follows:

[0078] By executing the executable instructions, coordination system 108 validates the input to determine whether the sperm quantity and sperm motility pass the respective transition conditions (i.e., the threshold sperm quantity and sperm motility requirements). In this example, coordination system 108 determines that the transition conditions are not met (i.e., both fail) and therefore a second donation is required. Coordination system 108 then begins monitoring the sperm temperature and generates a request for an additional sample. Coordination system 108 sends this request to input device 112, which provides the request to the user via user interface 116. Coordination system 108 then determines that a second donation is required and therefore the previous milestone (corresponding to sample collection) must be resumed, and simultaneously identifies the next subprocesses to be accomplished: the second donation (resuming the previous milestone), temperature monitoring of the collected sample, and notifying the associated cryopreservation device (belonging to the plurality of devices 102) of the biological material to be donated and its characteristics.

[0079] FIG. 9 shows a further example of how the coordination system 108 handles receiving status information and selecting subsequent sub-processes in an embodiment where the biological material is sperm collected from a patient for the purpose of ART.

[0080] In this example, the coordination system 108 receives input from the packaging device 126 in the form of status information, which is temperature monitoring information for the collected sample. The input also includes identification information (e.g., a smart contract identifier) ​​that allows the coordination system 108 to retrieve the associated smart contract 126 corresponding to the current patient and ART process, and the current status of that smart contract 126. In response to receiving the status information and the identification information, the coordination system 108 uses the identification information to query the distributed ledger 110 to retrieve the smart contract 126 associated with the sperm collected from the patient, including the smart contract's current status. Once retrieved, the coordination system 108 uses the current status to query the data store 114 to retrieve executable instructions. The retrieved executable instructions correspond to the current status of the smart contract 126. The coordination system 108 executes the retrieved executable instructions to cause a processor to process (at least) the status information and store it in the distributed ledger 110 as follows:

[0081] By executing the executable instructions, coordination system 108 examines the status information to determine whether the temperature of the collected sample at the time of collection passes the transition conditions (i.e., acceptable temperature requirements) defined in the executable instructions. In this example, coordination system 108 determines that the temperature monitoring information is acceptable (i.e., passes the transition conditions). Coordination system 108 then determines an appropriate command or computer-executable instruction and sends the command or computer-executable instruction to packaging device 126 to initiate temperature monitoring of the semen contained within packaging device 126 and store the temperature monitoring information in data lake 128. Coordination system 108 determines at least a portion of the received temperature monitoring information (or data derived from this information) to be stored in distributed ledger 110 and stores that portion of the temperature monitoring information in distributed ledger 110. Coordination system 108 then identifies the next subprocess to be simultaneously accomplished: continuing to monitor the temperature of the collected sample and verifying that regulatory standards are met.

[0082] Example 1: CAR-T (Chimeric Antigen Receptor T Cell) Therapy In a first example, the systems and methods described herein are used to control the handling of biological material intended for CAR-T therapy. In this example, the biological material comprises peripheral blood mononuclear cells ("PBMNCs") that have been genetically engineered into CAR-T cells.

[0083] In this example, the distributed ledger is a private blockchain, but other examples may use a public blockchain.

[0084] Initially, the user interface 116 receives user input requesting to initialize a new process. This input indicates a required smart contract template 123 to be used to initialize the smart contract for the current process. The coordination system 108 can receive the user input via the input device 112 and, based on the user input, determine a template identifier corresponding to the required smart contract template 123. The coordination system 108 then sends a request to the blockchain to initialize a smart contract 124 using the template identifier. This request includes a smart contract identifier that the coordination system 108 generates to be associated with the newly initialized smart contract and that is stored with the smart contract on the blockchain.

[0085] In this example, the user input is a selection indicating that the physician wishes to initiate a CAR-T therapy process. From the received user input, the coordination system 108 can identify an associated template identifier as corresponding to the CAR-T therapy process template 123. In response, the coordination system 108 sends a request to the blockchain to initialize a new smart contract 124 for CAR-T therapy using the CAR-T therapy template identifier. This includes generating a new smart contract identifier that is sent with the request to the blockchain and associated with and stored in the newly initialized smart contract 124.

[0086] In this example, upon initializing smart contract 124, coordination system 108 updates the current status of smart contract 124 to Milestone 1, subprocess 1.1. Updating the current status includes submitting a write request to a gatekeeper component associated with the blockchain for the transaction associated with the current status of subprocess 1.1. The write request includes a smart contract identifier. In response to receiving the write request, the gatekeeper component executes a process to create a new entity transaction for the data and submits the entity transaction to be committed to the blockchain in association with the associated smart contract 124 for the current CAR-T therapy process. Coordination system 108 then confirms from the gatekeeper that the current status has been saved to the blockchain.

[0087] Milestone 1 As shown in FIG. 10, the first milestone in this embodiment is "Doctor-Patient Identification."

[0088] Based on the current status of sub-process 1.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 1.1, which in this example causes processor 110 to:

[0089] In sub-process 1.1, the coordination system 108 requests that the input device 112 instruct the physician to provide physician details (i.e., identifying the physician who will perform the collection of biological material from the patient). In this example, the input device 112 hosts a web application that communicates with the coordination system 108. In this example, the instructions are displayed on a user interface 116 associated with the input device 112, although the instructions may be provided to the physician via additional or alternative means (e.g., voice prompts). The user interface 116 receives input of the physician details from the physician, and the input device 112 sends the entered physician details to the coordination system 108. The coordination system 108 decides to store the received physician details on the blockchain. Accordingly, the coordination system 108 stores the physician details on the blockchain by submitting a write request for a transaction with the physician details to the gatekeeper component. The write request includes a smart contract identifier. In response to receiving the write request, the gatekeeper component executes a process to create a new entity transaction for the data and submits the entity transaction to be committed to the blockchain in association with the associated smart contract 124 for the current CAR-T treatment process. The coordination system 108 receives confirmation from the gatekeeper that the data has been saved to the blockchain and identifies that subprocess 1.1 is complete. Because the smart contract 124 indicates that the next subprocess to accomplish is subprocess 1.2, the coordination system 108 writes to the distributed ledger to update the current status of the smart contract 124 to subprocess 1.2 in the same manner as described above for subprocess 1.1.

[0090] Based on the current status of sub-process 1.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 1.2, which in this example causes processor 110 to:

[0091] In subprocess 1.2, coordination system 108 requests that input device 112 instruct the physician to provide patient details identifying the patient from whom the biological material will be collected. Input device 112 provides the instructions by displaying them on user interface 116. User interface 116 receives the patient details input from the physician, and input device 112 transmits the entered patient details to coordination system 108. Coordination system 108 decides to store the received patient details on the blockchain. Accordingly, coordination system 108 stores the patient details on the blockchain (using the same steps as described above in subprocess 1.1). Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies subprocess 1.2 and milestone 1 as complete. Because smart contract 124 indicates that the next milestone is Milestone 2 and the next sub-process to be completed is Sub-process 2.1, coordination system 108 writes to the distributed ledger to update the current status of smart contract 124 to Milestone 2 Sub-process 2.1 in the same manner as described above for Sub-process 1.1.

[0092] Milestone 2 The second milestone in this example is "Patient Collection," as shown in Figure 11. At this milestone, the physician collects a blood sample from the patient.

[0093] Based on the current status of sub-process 2.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 2.1, which in this example causes processor 110 to:

[0094] In sub-process 2.1, the coordination system 108 instructs the input device 112 (e.g., through instructions displayed on the user interface 116) to inform the physician that information identifying the type of biological material and the associated process or application of the biological material needs to be entered. The user interface 116 receives input from the physician identifying the biological material as PBMNC and the process as CAR-T therapy. The input device 112 transmits this input to the coordination system 108. Upon receiving this input (forming status information for the biological material), the coordination system 108 processes the status information identifying the type of biological material and its application. The processing includes the coordination system 108 verifying the status information to determine whether the identified type of biological material and application are valid for the smart contract 124. If the verification is successful, the coordination system 108 determines that the identified type of biological material and application are to be saved to the blockchain. If the verification fails, the coordination system 108 instructs the input device 112 to notify the user that the verification failed and request new input. Coordination system 108 may store a copy of the received status information in data lake 128. Once processed, coordination system 108 stores the status information in the blockchain (using the same steps as described above in subprocess 1.1).

[0095] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies that subprocess 2.1 is complete. Because smart contract 124 dictates that the next subprocess to be accomplished is subprocess 2.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 2.2 in the same manner as described above for subprocess 1.1.

[0096] Based on the fact that the current sub-process is sub-process 2.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 2.2, which in this example causes processor 110 to:

[0097] In subprocess 2.2, coordination system 108 instructs input device 112 (e.g., through instructions displayed on user interface 116) to notify the physician that status information regarding the quantity of the collected blood sample and the quality of the collected blood sample must be entered. User interface 116 receives input from the physician identifying the quantity and quality of the collected blood sample. In this example, the status information is entered by the physician using user interface 116, but in other examples, the status information may be received by coordination system 108 from one or more devices 102. Input device 112 sends this input to coordination system 108, which processes the entered quantity and quality status information. Processing includes coordination system 108 verifying the status information to determine whether the quantity and quality of the biological material and application are valid for smart contract 124, i.e., whether the quantity and quality meet predefined criteria (or “transition conditions”) defined by the executable instructions. If the verification is successful, coordination system 108 determines that the quantity and quality of the received biological material are to be stored on the blockchain. If the validation fails, the coordination system 108 notifies the physician that the validation failed and instructs the input device 112 to request new input. The coordination system 108 may save a copy of the received status information in the data lake 128. Once processed, the coordination system 108 stores the status information in the blockchain (using the same steps as described above in subprocess 1.1).

[0098] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies that subprocess 2.2 is complete. Because smart contract 124 indicates that the next subprocess to accomplish is subprocess 2.3, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 2.3, in the same manner as described above for subprocess 1.1.

[0099] Based on the current status of sub-process 2.3, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 2.3, which in this example causes processor 110 to:

[0100] In subprocess 2.3, coordination system 108 determines packaging requirements for the biological material. Coordination system 108 may make this determination based on status data associated with the biological material stored on the blockchain, which may be retrieved by querying the blockchain using the smart contract identifier. Relevant status information may include, for example, the sample quantity and quality stored in subprocess 2.2.

[0101] The coordination system 108 then identifies that sub-process 2.3 and Milestone 2 are complete. Because the smart contract 124 indicates that the next milestone and sub-process to be achieved is Milestone 3, sub-process 3.1, the coordination system 108 writes to the distributed ledger to update the current status of the smart contract 124 to Milestone 3, sub-process 3.1, in the same manner as described above for sub-process 1.1.

[0102] Milestone 3 As shown in Figures 12A and 12B, the third milestone in this example is "separated leukocyte therapy," in which medical scientists use leukocyte separation technology to separate blood samples and isolate and recover the desired biological material, i.e., PBMNCs.

[0103] Based on the current status of sub-process 3.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.1, which in this example causes processor 110 to:

[0104] In sub-process 3.1, coordination system 108 instructs input device 112' (which may be separate from input device 112) to notify the medical scientist that a volume of isolated PBMNCs needs to be entered (e.g., through instructions displayed on input device 112 (or its associated user interface 116). User interface 116' receives input from the medical scientist identifying the collected volume. Input device 112' transmits this input to coordination system 108, which processes the details of the volume collection before storing it on the blockchain in a manner similar to that described above.

[0105] The coordination system 108 then receives confirmation from the gatekeeper that the data has been saved to the blockchain and identifies that subprocess 3.1 is complete. Because the smart contract 124 indicates that the next subprocess to complete is subprocess 3.2.1, the coordination system 108 writes to the blockchain to update the current status of the smart contract 124 to subprocess 3.2.1 in the same manner as described above for subprocess 1.1.

[0106] Based on the current status being sub-process 3.2.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.2.1, which in this example causes processor 110 to:

[0107] In sub-process 3.2.1, coordination system 108 instructs input device 112′ (e.g., via instructions displayed on user interface 116′) to notify the medical scientist using input device 112′ that the medical scientist should enter status information related to a pre-cryopreservation treatment performed by the medical scientist in connection with the biological material. The pre-cryopreservation treatment may include adding a cryoprotectant and performing one or more baseline measurements (such as measurements of cell count, cell viability, and / or cell functionality). User interface 116′ receives input from the medical scientist identifying the pre-cryopreservation treatment, and input device 112′ transmits this input to coordination system 108, which processes the pre-cryopreservation treatment information before storing it on the blockchain in a manner similar to that described above.

[0108] The coordination system 108 then receives confirmation from the gatekeeper that the data has been saved to the blockchain and identifies that subprocess 3.2.1 is complete. Because the smart contract 124 indicates that the next subprocess to accomplish is subprocess 3.2.2, the coordination system 108 writes to the blockchain to update the current status of the smart contract 124 to subprocess 3.2.2 in the same manner as described above for subprocess 1.1.

[0109] Based on the current status being sub-process 3.2.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.2.2, which in this example causes processor 110 to:

[0110] In subprocess 3.2.2, the coordination system 108 selects an appropriate packaging device 126 for the biological material. According to the executable instructions, the selection is made based at least on the packaging requirements determined in subprocess 2.3. The coordination system 108 generates a packaging device identifier for the selected packaging device 126. The coordination system 108 stores the selection of the packaging device 126 (including the packaging device identifier) ​​on the blockchain in a manner similar to that described above, and then receives confirmation from the gatekeeper that the data has been stored on the blockchain.

[0111] The coordination system 108 notifies the selected packaging device 126 that it has been selected for the current CAR-T therapy process. Notifying the packaging device 126 may include the coordination system 108 sending a message to the packaging device 126. The message may include a smart contract identifier or other information notifying the packaging device that it has been selected, and optionally the selected treatment process.

[0112] The coordination system 108 instructs the input device 112′ to inform the medical scientist (e.g., through instructions displayed on the user interface 116′) that it is necessary to transfer the biological material (isolated PBMNCs that have undergone cryopreservation pretreatment) to the selected packaging device 126.

[0113] The coordination system 108 then identifies that sub-process 3.2.2 is complete, and because the smart contract 124 indicates that the next sub-process to accomplish is sub-process 3.2.3, the coordination system 108 updates the current status of the smart contract 124 to sub-process 3.2.3 in the distributed ledger in the same manner as described above for sub-process 1.1.

[0114] Based on the current status being subprocess 3.2.3, the coordinate system 108 queries the data storage location 114 to retrieve executable instructions. In response, the coordinate system 108 receives and executes the executable instructions of subprocess 3.2.3, which in this example causes the processor 110 to request the packaging device 126 to begin monitoring with the sensor 308 and provide the monitoring information to the coordinate system 108. The monitoring information is generated from monitoring data captured by the sensor 308 of the packaging device 126. In this example, the monitoring information includes temperature monitoring information and location tracking information. The temperature monitoring information indicates the temperature of the biological material in the packaging device 126 and is generated from the monitoring data of the temperature sensor. The location tracking information indicates the location of the packaging device 126 (and thus the biological material) and is generated from the monitoring data of the location sensor (e.g., a GPS sensor). Along with the monitoring information, the coordinate system 108 also receives identification information including a smart contract identifier. The identification information may also include a packaging device identifier for the packaging device 126.

[0115] The initiated monitoring continues through Milestone 3, i.e., while subprocesses 3.2.4 through 3.2.7 are being performed. Once the coordination system 108 receives the monitoring information and identification information, it queries the blockchain using the smart contract identifier to retrieve the smart contract 124 for the current CAR-T therapy process, including the current status of that smart contract 124. Based on the retrieved smart contract 124 and its current status (which may be any of subprocesses 3.2.3 through 3.2.7), the coordination system 108 queries the data storage location 114 to retrieve executable instructions for that subprocess, which, when executed, cause the processor 110 to process the received monitoring information. This processing includes the coordination system 108 validating the monitoring information to determine whether the received temperature monitoring information and location tracking information meet predefined transition conditions. For example, the temperature monitoring information may be required to be within a certain range necessary to maintain the biological material within the packaging device 126. If the validation fails, the coordination system 108 can send an alert to the medical scientist via the input device 112' and the user interface 116'. If the validation is successful, the coordination system 108 determines the portion of the monitoring information to store on the blockchain. For example, if the temperature monitoring information includes temperature readings retrieved every second, the coordination system 108 can determine to store one reading per minute on the blockchain. Once processed, the coordination system 108 stores the portion of the monitoring information on the blockchain (using the same steps as described above in subprocess 1.1).

[0116] As mentioned above, the coordination system 108 may store a copy of all received monitoring information in the data lake 128 .

[0117] As mentioned above, the packaging device 126 may store a copy of the monitoring information locally in the packaging device data store 306. This local copy of the monitoring information may be received by the coordination system 108 at a later stage, for example, for data integrity or data recovery purposes.

[0118] After initiating monitoring, coordination system 108 identifies that subprocess 3.2.3 is complete, although the initiated monitoring process continues through milestones. Because smart contract 124 indicates that the next subprocess to be completed is subprocess 3.2.4, coordination system 108 writes the current status of smart contract 124 to the blockchain as being subprocess 3.2.4, in the same manner as described above for subprocess 1.1.

[0119] Based on the current status being sub-process 3.2.4, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.2.4, which in this example causes processor 110 to:

[0120] In subprocess 3.2.4, coordination system 108 determines that the biological material will be held in packaging device 126 at a holding temperature until cryopreservation. The holding temperature may include a range of acceptable temperatures. Accordingly, coordination system 108 generates an alert if any of the temperature monitoring information received by the monitoring initiated by subprocess 3.2.3 falls outside the holding temperature range. Coordination system 108 then identifies that subprocess 3.2.4 is complete. Because smart contract 124 indicates that the next subprocess to be completed is subprocess 3.2.5, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 3.2.5 in the same manner as described above.

[0121] Based on the current status being sub-process 3.2.5, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.2.5, which in this example causes processor 110 to:

[0122] In subprocess 3.2.5, coordination system 108 is notified by at least one of packaging device 126 and a first cryopreservation device (belonging to the plurality of devices 102) that the first cryopreservation device has become aware of packaging device 126. The first cryopreservation device may become aware of packaging device 126 by detecting its proximity, for example, using a LAN, WAN, or PAN (e.g., via Wi-Fi™, cellular network, RFID, Bluetooth®, etc.). In response to the notification, coordination system 108 may notify the first cryopreservation device that it will be used in the current CAR-T therapy process and link it to smart contract 124. This may include sending a smart contract identifier to the first cryopreservation device. Additionally or alternatively, it may include sending status information associated with the biological material (cryopreserved by the device), such as the volume and quality information received in subprocess 2.2, to the first cryopreservation device.

[0123] When the first cryopreservation device is made aware of the packaging apparatus 126, it may be notified (either directly from the packaging apparatus 126 via a LAN, WAN, or PAN, or via the coordination system 108) of one or more of the following: the type of packaging apparatus 126 selected in sub-process 3.2.2 (e.g., including size, shape, and / or configuration), the type of biological material, and the pre-cryopreservation treatment performed in sub-process 3.2.1 (e.g., amount of cryoprotectant added).

[0124] In some embodiments, the coordination system 108 being notified that the first cryopreservation device has come to recognize the packaging device 126 may result in the coordination system 108 allowing the packaging device 126 to be inserted into the first cryopreservation device, for example, by communicating with the first cryopreservation device and unlocking the device.

[0125] The coordination system 108 then identifies that sub-process 3.2.5 is complete. When the smart contract 124 identifies that the next sub-process to be completed is sub-process 3.2.6, the coordination system 108 writes to the blockchain to update the current status of the smart contract 124 to sub-process 3.2.6, in a manner similar to that described above for sub-process 1.1.

[0126] Based on the current status being sub-process 3.2.6, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.2.6, which in this example causes processor 110 to:

[0127] In subprocess 3.2.6, the coordination system 108 receives status information in the form of a selected rack system and a cryopreservation protocol for cryopreservation of biological material intended for CAR-T therapy. The status information may be received via a secure API or other known communication mechanism. The rack system is configured to support one or more packaging devices within the first cryopreservation device and facilitates cryopreservation of the biological material within the packaging device. Differently configured rack systems can be used with the first cryopreservation device to achieve different heat transfer rates, and therefore, certain rack systems may be more suitable for use with certain packaging devices and biological materials. The cryopreservation protocol defines the cryopreservation settings of the first cryopreservation device for optimal cryopreservation of the biological material within the packaging device 126, including the processing time, temperature, and heat exchange fluid rate of the cryopreservation process.

[0128] The first cryopreservation apparatus can select a rack system based on one or more of the type of packaging apparatus 126, the type of biological material (i.e., CAR-T cells in this example), the volume of the biological material (e.g., the number of cells), and the quality of the biological material. The cryopreservation apparatus can select a cryopreservation protocol based on one or more of the type of packaging apparatus 126, the type of biological material (i.e., CAR-T cells in this example), the volume of the biological material (e.g., the number of cells), and the quality of the biological material.

[0129] The coordination system 108 processes the received status information by validating it, determining to store it on the blockchain, and writing the status information to the blockchain for storage (using the same steps as described above in subprocess 1.1). In embodiments where the first cryopreservation device is configured to host at least one node 122 of the distributed ledger, the coordination system 108 may submit a write request to a gatekeeper component, which is located on the first cryopreservation device.

[0130] Coordination system 108 then identifies that sub-process 3.2.6 is complete. Because smart contract 124 indicates that the next sub-process to complete is sub-process 3.2.7, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to sub-process 3.2.6 in the same manner as described above for sub-process 1.1.

[0131] The coordination system 108 may request that the input device 112' instruct the medical scientist to load the selected rack system into the first cryopreservation device, for example, by displaying instructions on the user interface 116'.

[0132] Alternatively, in sub-process 3.2.6, the coordination system 108 receives a request from a first cryopreservation device via a secure API to retrieve a rack system and cryopreservation protocol selection for cryopreservation of biological material intended for CAR-T therapy.

[0133] The coordination system 108 processes the received request by verifying that the first cryopreservation device is one of the plurality of devices 102 and is therefore authorized to interact with the coordination system 108, and by verifying the current status of the smart contract by querying the blockchain using the smart contract identifier.

[0134] Once the coordination system 108 processes the request, it invokes a query process on the blockchain via the gatekeeper. The gatekeeper runs the query on the blockchain to retrieve the required information (rack system selection and cryopreservation protocol for the current process). The blockchain query data result containing the required information is returned from the blockchain via the gatekeeper to the coordination system 108. The coordination system 108 processes the blockchain query data result and sends it to the first cryopreservation device via a secure API.

[0135] In embodiments in which the first cryopreservation device is configured to host at least one node 122 of the distributed ledger, the coordination system 108 may instruct the first cryopreservation device to directly invoke a query process on the blockchain via a gatekeeper component on the first cryopreservation device.

[0136] The coordination system 108 can request that the input device 112' instruct the medical scientist to load the selected rack system into the first cryopreservation device, for example, by displaying instructions on the user interface 116'.

[0137] The coordination system 108 confirms that it has received the selected rack system and cryopreservation protocol from the first cryopreservation device. The coordination system 108 then identifies that sub-process 3.2.6 is complete. Because the smart contract 124 indicates that the next sub-process to complete is sub-process 3.2.7, the coordination system 108 writes to the blockchain to update the current status of the smart contract 124 to sub-process 3.2.6, in the same manner as described above for sub-process 1.1.

[0138] Based on the current status being sub-process 3.2.7, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.2.7, which in this example causes processor 110 to:

[0139] In subprocess 3.2.7, the coordination system 108 notifies other associated devices of the plurality of devices 102 that they are needed at future milestones related to the CAR-T therapy process and links them to the smart contract 124. In this example, a first thawing device for milestone 6, a second cryopreservation device for milestone 9, and a second thawing device for milestone 11 are notified. Notifying the associated devices may include sending a smart contract identifier of the smart contract 124 to each device. Notifying the associated devices may include sending status information related to the biological material, such as the type of packaging device 126 selected in subprocess 3.2.2 (e.g., including size, shape, and / or configuration), the type of biological material, and the cryopreservation pre-treatment performed in subprocess 3.2.1 (e.g., amount of cryoprotectant added).

[0140] Coordination system 108 then identifies that sub-process 3.2.7 is complete.

[0141] The coordination system 108 determines whether milestone 3 is complete by determining whether the volume of isolated PBMNCs meets a predetermined threshold (or, as shown in FIG. 9, a "transition condition"). The threshold is the minimum volume required to progress through the CAR-T therapy process. For example, when treating a patient with diffuse large B-cell lymphoma weighing 80 kg, the threshold is approximately 10×10 8If the threshold is not met, the coordination system 108 prompts additional iterations of Milestones 2 and 3, updating the current status of the smart contract to include subprocess 1.2 and writing it to the blockchain to obtain additional biological material to progress the process. In the additional iterations of Milestone 3, the threshold is coordinated to take into account any quantities collected in previous iterations of Milestones 2 and 3.

[0142] If multiple samples are collected and separated due to thresholds not being met as described above, at the end of milestone 3, the coordination system 108 requests that the input device 112' instruct the medical scientist (e.g., by displaying instructions on the user interface 116') to consolidate all separated samples into a single packaging device 126.

[0143] When coordination system 108 identifies that subprocess 3.2.7 and milestone 3 are complete, and smart contract 124 indicates that the next milestone and subprocess to achieve is milestone 4 and subprocess 4.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to milestone 4 subprocess 4.1 (if coordination system 108 determines at milestone 3 that the amount of separated PBMNC does not meet the predetermined threshold, the current status also includes subprocess 1.2), in the same manner as described above for subprocess 1.1.

[0144] Milestone 4 13, the fourth milestone in this example is "Controlled Preservation," in which the medical scientist places the packaging device 126 in a first cryopreservation device, which freezes the biological material within the packaging device 126 at a controlled rate.

[0145] Subprocess 4.1 is performed similarly to subprocess 3.2.3 above, except that a monitoring start request is sent to the first cryopreservation device. The first cryopreservation device generates monitoring information from monitoring data captured by its sensor 208. In subprocess 4.1, the monitoring information may include temperature monitoring information (i.e., information regarding the temperature during cryopreservation) and operational monitoring information. The temperature monitoring information indicates the temperature of the biological material in the packaging device 126 and is generated from the monitoring data of the temperature sensor. The operational monitoring information indicates one or more operations performed by the first cryopreservation device, such as the flow rate of the heat exchange fluid. Along with the monitoring information, the coordination system 108 also receives identification information including a smart contract identifier. The identification information may also include an equipment identifier of the first cryopreservation device.

[0146] The initiated monitoring continues through Milestone 4, i.e., while subprocess 4.2 is being performed. Once the coordination system 108 receives the monitoring information and identification information, it queries the blockchain using the smart contract identifier to retrieve the smart contract 124 for the current CAR-T therapy process, including the current status of that smart contract 124. Based on the retrieved smart contract 124 and the current status (which may now be subprocess 4.2), the coordination system 108 queries the data store 114 to retrieve executable instructions for that subprocess, which, when executed, cause the processor 110 to process the received monitoring information. Processing includes the coordination system 108 verifying the status information to determine that the received temperature and operational monitoring information meet predefined transition conditions. For example, the operational monitoring information may be required to be within a specific range to determine that no malfunction or other unforeseen event has occurred within the first cryopreservation device. If the verification fails, the coordination system 108 can send an alert to the medical scientist via the input device 112' and the user interface 116'. If the verification is successful, the coordination system 108 determines the portion of the monitoring information to be stored on the blockchain. For example, if the operation monitoring information includes monitoring information for multiple operations performed by the first cryopreservation device, the coordination system 108 can determine to store only the monitoring information for a particular operation on the blockchain. Once processed, the coordination system 108 stores the portion of the monitoring information on the blockchain (using the same steps as described above in subprocess 1.1).

[0147] Processing the operational monitoring information may also include generating cost monitoring information based on the operational monitoring information, the cost monitoring information indicating costs associated with operating the first cryopreservation device to perform cryopreservation of the biological material, determining a portion of the cost monitoring information to be stored on the blockchain, and storing the portion of the cost monitoring information to be stored on the blockchain (using the same steps as described above in subprocess 1.1).

[0148] After initiating monitoring, coordination system 108 identifies that subprocess 4.1 is complete, although the initiated monitoring continues through milestones. Because smart contract 124 indicates that the next subprocess to be completed is subprocess 4.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 4.2, in the same manner as described above for subprocess 1.1.

[0149] Based on the current status of sub-process 4.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 4.2, which in this example causes processor 110 to:

[0150] In sub-process 4.2, coordination system 108 controls the first cryopreservation device to coordinate its refrigeration system to achieve the required operating conditions according to the cryopreservation protocol received at milestone 3.

[0151] Coordination system 108 identifies that subprocess 4.2 is complete by determining, for example, based on operational monitoring information, that the operational conditions required by the cryopreservation protocol (selected in subprocess 3.2.6) have been satisfied by the first cryopreservation device. Because smart contract 124 indicates that the next milestone and subprocess to be achieved are milestone 5 and subprocess 5.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to milestone 5 subprocess 5.1 in the same manner as described above for subprocess 1.1.

[0152] Milestone 5 14, the fifth milestone in this example is "Specialized Logistics," in which the biological material within packaging device 126 is maintained in a controlled and monitored environment during transport between the locations of milestones 2-4 and milestone 6.

[0153] Subprocess 5.1 is performed in the same manner as subprocess 3.2.3 above. The initiated monitoring continues through milestone 5, i.e., while subprocess 5.2 is being performed. After monitoring begins, coordination system 108 identifies that subprocess 5.1 is complete, even though the initiated monitoring continues through the milestone.

[0154] Because smart contract 124 indicates that the next subprocess to be completed is subprocess 5.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 5.2 in the same manner as described above for subprocess 1.1.

[0155] Based on the current status of sub-process 5.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 5.2, which in this example causes processor 110 to:

[0156] In sub-process 5.2, the coordination system 108 determines a target destination for the biological material in the packaging device 126. In this example, the target destination corresponds to the location of the first thawing device, which has been predefined and stored on the blockchain. Based on the location tracking information received and stored by the monitoring initiated in sub-process 5.2, the coordination system 108 can also determine a route (e.g., an optimal route) to the target destination.

[0157] Once the coordination system 108 processes the request, it sends the target destination to the secure API, which sends the target destination to the packaging device 126 .

[0158] Coordination system 108 receives confirmation from packaging device 126 that the target destination has been received. Coordination system 108 then identifies that sub-process 5.2 and milestone 5 are complete. Because smart contract 124 indicates that the next milestone and sub-process to achieve is milestone 6 and sub-process 6.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to milestone 6 sub-process 6.1 in the same manner as described above for sub-process 1.1.

[0159] Milestone 6 The sixth milestone of this example is "Controlled Biothaw," as shown in Figure 15. At this milestone 6, the cryopreserved biological material is thawed by a first thawing device in preparation for transformation and expansion at milestone 7.

[0160] Sub-process 6.1 is performed similarly to sub-process 4.1 above, except that a monitoring start request is sent to the first thawing device. The first thawing device generates monitoring information from monitoring data captured by its sensor 208. In sub-process 6.1, the monitoring information may include temperature monitoring information (i.e., information for monitoring the temperature during cryopreservation) and operational monitoring information. The temperature monitoring information indicates the temperature of the biological material in the packaging device 126 and is generated from the temperature sensor monitoring data. The operational monitoring information indicates one or more operations to be performed by the first thawing device, such as the thawing temperature applied by the device.

[0161] The initiated monitoring continues through milestone 6, i.e., while subprocesses 6.2 and 6.3 are being performed. After initiating monitoring, coordination system 108 identifies that subprocess 6.1 is complete, even though initiated monitoring continues through milestone 6. Because smart contract 124 indicates that the next subprocess to accomplish is subprocess 6.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 6.2, in the same manner as described above for subprocess 1.1.

[0162] Based on the current status of sub-process 6.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 6.2, which in this example causes processor 110 to:

[0163] In sub-process 6.2, the coordination system 108 receives status information in the form of a selected thawing protocol for thawing the biological material in the packaging device. The thawing protocol defines the thawing settings of the first thawing device, including the heating rate and temperature for the thawing process.

[0164] The status information is received from the first cryopreservation device via a secure API. The first cryopreservation device can select a thawing protocol based on one or more of the type of packaging device 126, the type of biological material (i.e., CAR-T cells in this example), the volume of the biological material (e.g., cell count), and the temperature at which the biological material has been stored inside the packaging device 126 since cryopreservation.

[0165] Coordination system 108 processes the received status information by validating it and determining that it should be stored on the blockchain, and writes the status information to the blockchain for storage (using the same steps as described above for subprocess 1.1). Coordination system 108 then identifies that subprocess 6.2 is complete. Because smart contract 124 indicates that the next subprocess to complete is subprocess 6.3, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 6.3, in the same manner as described above for subprocess 1.1.

[0166] Alternatively, in sub-process 6.2, the coordination system 108 receives a request from the first thawing device via the secure API to retrieve a selection of a thawing protocol for thawing the biological material in the packaging device 126, including the heating rate and temperature for the thawing process.

[0167] The coordination system 108 processes the received request by verifying that the first decompression device is one of the plurality of devices 102 and is therefore authorized to interact with the coordination system, and by verifying the current status of the smart contract by querying the blockchain using the smart contract identifier.

[0168] Once the coordination system 108 processes the request, it invokes a query process on the blockchain via the gatekeeper. The gatekeeper runs the query on the blockchain to search for the required information. The blockchain query data result containing the required information is returned from the blockchain via the gatekeeper to the coordination system 108. The coordination system 108 processes the blockchain query data result and sends it to the secure API. The secure API sends the blockchain query result to the first thawing device. The first thawing device thaws the biological material in the packaging device 126 using the thawing protocol received in sub-process 6.3.

[0169] Coordination system 108 receives confirmation from the first decompressor that the selected decompression protocol was received. Coordination system 108 then identifies that sub-process 6.2 is complete. Because smart contract 124 indicates that the next sub-process to complete is sub-process 6.3, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to sub-process 6.3 in the same manner as described above for sub-process 1.1.

[0170] Based on the current status of sub-process 6.3, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions of sub-process 6.3, which in this example causes processor 110 to:

[0171] In subprocess 6.3, coordination system 108 controls the first thawing device to coordinate its refrigeration system to achieve the required operating conditions according to the thawing protocol received in subprocess 6.2. Coordination system 108 identifies that subprocess 6.3 is complete by determining, for example, based on operational monitoring information, that the first thawing device has met the operating conditions required by the thawing protocol received in subprocess 6.2. Because smart contract 124 indicates that the next milestone and subprocess to be achieved are Milestone 7 and Subprocess 7.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to Milestone 7, Subprocess 7.1, in a manner similar to that described above for subprocess 1.1.

[0172] Milestone 7 As shown in Figure 16, the seventh milestone in this example is "Differentiation & Transformation." In this milestone, the thawed biological material undergoes differentiation and transformation to generate CAR-T cells. This is generally done by medical scientists: i. removing the biological material from the packaging device 126; ii. Selecting a vector and using it to remove the gene of interest from the DNA-containing cells (the removed DNA can be stored frozen before thawing for use); iii. performing a DNA plasmid process including isolating the plasmid and recombining the plasmid with a gene of interest to produce a recombinant DNA plasmid; iv. Transforming the PBMNC with a recombinant DNA plasmid, for example by transfection, to generate recombinant T cells (i.e., CAR-T cells); and v. Differentiating CAR-T cells, for example, by cell sorting using a flow cytometer; The method includes performing the steps of:

[0173] Based on the current status of sub-process 7.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 7.1, which in this example causes processor 110 to:

[0174] In sub-process 7.1, coordination system 108 instructs input device 112″ (which may be separate from input devices 112 and 112′) to notify the medical scientist performing the differentiation and transformation steps that they need to input status information related to the steps performed while generating the CAR-T cells. For example, the required information may include the selected vector, the identity of the media or cryoprotectant added or removed at each step, the time required to complete each step, the total time required to generate the CAR-T cells, the cell count of the biological material removed from packaging device 126, and the viability count of the biological material removed from packaging device 126. The instructions may be provided by displaying on a user interface 116″ associated with input device 112″.

[0175] Coordination system 108 receives status information entered by the medical scientist through user interface 116 from input device 112. Along with this status information, coordination system 108 also receives identification information including a smart contract identifier. Using the identification information, coordination system 108 queries the blockchain to retrieve smart contract 124 and the current status of sub-process 7.1. Based on the current status of sub-process 7.1, coordination system 108 queries data store 114 to retrieve executable instructions, which coordination system 108 executes to process the status information. Processing includes validating the status information to determine whether the input information meets predefined transition conditions. The transition conditions may be defined in the executable instructions based, for example, on one or more regulatory requirements regarding the process used to generate CAR-T cells used in CAR-T therapy. If the verification is unsuccessful, the coordination system 108 tags the invalid status information to identify that the verification was not passed and instructs the input device 112 to notify the medical scientist that the verification was unsuccessful. The medical scientist can then decide whether the differentiation and transformation steps need to be repeated or whether the generated CAR-T cells cannot be used for CAR-T therapy (meaning the current process must be terminated).

[0176] The processing also includes coordination system 108 determining a portion of the status information to store on the blockchain (where the portion may include all of the status information). Coordination system 108 may save a copy of the received status information in data lake 128. Once processed, coordination system 108 stores the determined portion of the status information on the blockchain (using the same steps as described above in subprocess 1.1).

[0177] Coordination system 108 then identifies that subprocess 7.1 is complete. Because smart contract 124 dictates that the next subprocess to accomplish is subprocess 7.2, coordination system 108 writes to the distributed ledger to update the current status of smart contract 124 to subprocess 7.2 in the same manner as described above for subprocess 1.1.

[0178] Based on the current status of sub-process 7.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 7.2, which in this example causes processor 110 to:

[0179] In sub-process 7.2, the coordination system 108 instructs the input device 112 to notify the medical scientist performing the differentiation and transformation steps that they need to input status information related to the final generated biological material, which is the generated CAR-T cells. For example, the required information may include, but is not limited to, confirmation that the CAR-T cells have the correct protein markers, cell count of the CAR-T cells, viability of the CAR-T cells, etc. With respect to sub-process 7.1, instructions may be provided by displaying on a user interface 116 associated with the input device 112.

[0180] The coordination system 108 receives status information entered by the medical scientist through the user interface 116 from the input device 112. Along with this status information, the coordination system 108 also receives identification information including a smart contract identifier. Using the identification information, the coordination system 108 queries the blockchain to retrieve the smart contract 124 and the current status of sub-process 7.1. Based on the current status of sub-process 7.1, the coordination system 108 queries the data store 114 to retrieve executable instructions, which the coordination system 108 executes to process the status information. The processing includes validating the status information to determine whether the input information meets predefined transition conditions. The transition conditions may be defined in the executable instructions based, for example, on one or more regulatory requirements for CAR-T cells used in CAR-T therapy. If the validation fails, coordination system 108 tags the invalid status information to identify that validation did not pass and prompts input device 112 to notify the user of the failed validation. The process also includes coordination system 108 determining a portion of the status information to store in the blockchain (where the portion may include all of the status information). Coordination system 108 may save a copy of the received status information in data lake 128. Once processed, coordination system 108 stores the determined portion of the status information in the blockchain (using the same steps as described above in sub-process 1.1).

[0181] In some embodiments, in sub-process 7.2, executing the executable instructions of sub-process 7.2 also causes the coordination system 108 to determine packaging requirements and select an appropriate packaging device 126′ for the biological material (now in the form of differentiated CAR-T cells). This can be performed similarly to the steps described in sub-process 2.3 and sub-process 3.2.2 (related to determining packaging requirements and selecting a packaging device 126). The coordination system 108 instructs the input device 112″ to inform the medical scientist (e.g., through instructions displayed on the user interface 116″) that the biological material (differentiated CAR-T cells) needs to be transferred to the selected packaging device 126′. However, as described below in sub-process 8.1, in some embodiments, the selection of the packaging device 126′ may not occur until after the biological material has undergone expansion.

[0182] Coordination system 108 then identifies that milestone 7 and subprocess 7.2 are complete. Because smart contract 124 indicates that the next milestone and subprocess to be achieved is milestone 8 and subprocess 8.1, coordination system 108 writes to the distributed ledger to update the current status of smart contract 124 to milestone 8 subprocess 8.1 in the same manner as described above for subprocess 1.1.

[0183] Milestone 8 The eighth milestone in this example is "Expansion," as shown in Figure 17. In this milestone, CAR-T cells are grown or "expanded" in the laboratory by medical scientists to a quantity sufficient for use in CAR-T therapy.

[0184] Based on the current status of sub-process 8.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 8.1, which in this example causes processor 110 to:

[0185] In sub-process 8.1, the coordination system 108 requests that the input device 112 instruct the medical scientist to expand the CAR-T cells and input status information regarding the expanded cells. For example, the requested information may include the final volume of the expanded cells, the final cell count of the expanded cells, a quality and / or viability measurement of the expanded cells, and the identity and volume of media or cryoprotectant added to the expanded cells. The instructions may be provided to the medical scientist by displaying them on the user interface 116.

[0186] Coordination system 108 receives status information from input device 112″ (received from the medical scientist at user interface 116″). Along with this status information, coordination system 108 also receives identification information including the smart contract identifier. Using the identification information, coordination system 108 queries the blockchain to retrieve the current status of smart contract 124 and sub-process 8.1 of milestone 8. Based on the current status of sub-process 8.1, coordination system 108 queries data store 114 to retrieve executable instructions, which coordination system 108 executes to process the status information. Processing includes coordination system 108 verifying the status information to determine whether it is valid for smart contract 124, e.g., whether the expansion volume meets predefined criteria (or “transition conditions”) defined by the executable instructions. If verification fails, coordination system 108 tags the invalid status information to identify that it did not pass verification and instructs input device 112 to notify the user that verification failed. Processing also includes coordination system 108 determining a portion of the status information to store on the blockchain (where the portion may include all of the status information). Coordination system 108 may save a copy of the received expanded volume in data lake 128. Once processed, coordination system 108 stores the status information on the blockchain (using the same steps as described above in subprocess 1.1).

[0187] In some embodiments, in sub-process 8.1, executing the executable instructions of sub-process 8.1 also causes the coordination system 108 to determine packaging requirements and select an appropriate packaging device 126′ for the biological material (which is now in the form of expanded CAR-T cells). This can be performed similarly to the steps described in sub-processes 2.3 and 3.2.2 (in connection with determining packaging requirements and selecting a packaging device 126). The coordination system 108 instructs the input device 112″ to inform the medical scientist (e.g., through instructions displayed on the user interface 116″) that the biological material (expanded CAR-T cells) needs to be transferred to the selected packaging device 126′. However, as previously described in sub-process 7.2 herein, in some embodiments, the selection of the packaging device 126′ occurs before the biological material undergoes expansion. Whether this occurs before or after the expansion of the biological material may depend on the particular CAR-T therapy process being performed.

[0188] Coordination system 108 then identifies that subprocess 8.1 is complete. Because smart contract 124 indicates that the next subprocess to accomplish is subprocess 8.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 8.2 in the same manner as described above for subprocess 1.1.

[0189] Based on the fact that the current sub-process is sub-process 8.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 8.2.

[0190] In sub-process 8.2, the coordination system 108 requests that the input device 112" instruct the medical scientist to determine and input whether a subsequent expansion cycle is necessary based on the amount of expanded CAR-T cells. This instruction may be provided to the medical scientist by displaying it on the user interface 116".

[0191] Coordination system 108 receives status information from input device 112″ in the form of user input from the medical scientist identifying whether further expansion cycles are required (received at user interface 116″). Along with this status information, coordination system 108 also receives identification information including the smart contract identifier. Using the identification information, coordination system 108 queries the blockchain to retrieve the current status of smart contract 124 and sub-process 8.2. Based on the current status, which is sub-process 8.2, coordination system 108 queries data store 114 to retrieve executable instructions, which coordination system 108 executes to process the status information. The process includes coordination system 108 verifying the status information and deciding to store it on the blockchain. Coordination system 108 stores the status information on the blockchain (using the same steps as described above for sub-process 1.1). Upon confirmation from the gatekeeper that the data has been saved to the blockchain, coordination system 108 identifies sub-process 8.2 as complete.

[0192] After completion of sub-process 8.2, the current status of smart contract 124 is updated based on the "Transition Condition." If the inputs identify that at least one further expansion cycle is required, the "Transition Condition" fails, and smart contract 124 dictates that the next sub-process to be achieved is sub-process 8.1, which is repeated as described above. If the inputs identify that no further expansion cycles are required, the "Transition Condition" passes, and smart contract 124 dictates that the next sub-process to be achieved is sub-process 8.3. Based on the outcome of the "Transition Condition," coordination system 108 writes to the blockchain to update the current status of smart contract 124 to either sub-process 8.1 or 8.3, in the same manner as described above for sub-process 1.1.

[0193] If the current sub-process is sub-process 8.3, then coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 8.3, which in this example causes processor 110 to:

[0194] In subprocess 8.3, coordination system 108 determines that the (expanded) biological material will be held in packaging device 126 at a holding temperature until it undergoes cryopreservation (subprocess 8.3.1) and requests that packaging device 126 initiate monitoring via sensor 308 and provide monitoring information to coordination system 108. The holding temperature may include an acceptable temperature range. Temperature monitoring information is generated in the same manner as described in subprocess 3.2.3. The initiated monitoring continues in the same manner as described in subprocess 3.2.3 for the remainder of milestone 8, i.e., while subprocesses 8.4 and 8.5 are performed, and coordination system 108 stores the relevant determined portion of the monitoring information in the blockchain (using the same steps as described above in subprocess 1.1).

[0195] Thus, coordination system 108 may generate an alert if any of the received temperature monitoring information falls outside the holding temperature range. If the expansion step in sub-process 8.1 is not performed while the biological material is in packaging device 126, coordination system 108 may request that input device 112" instruct the medical scientist to return the expanded biological material to packaging device 126 by displaying instructions on user interface 116".

[0196] Coordination system 108 then identifies that sub-process 8.3 is complete, and because smart contract 124 indicates that the next sub-process to accomplish is sub-process 8.4, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to include sub-process 8.4 in the same manner as described above.

[0197] Based on the current status of sub-process 8.4, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 8.4, which in this example causes processor 110 to:

[0198] In sub-process 8.4, the coordination system 108 is notified by at least one of the packaging device 126 and the second cryopreservation device (belonging to the plurality of devices 102) that the second cryopreservation device has become aware of the packaging device 126. The second cryopreservation device can then become aware of the packaging device 126 in the same manner as described for sub-process 3.2.5.

[0199] Coordination system 108 then identifies that subprocess 8.4 is complete. When smart contract 124 identifies that the next subprocess to complete is subprocess 8.5, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 8.5, in a manner similar to that described above for subprocess 1.1.

[0200] Based on the current status being subprocess 8.5, coordination system 108 queries data storage location 114 to retrieve executable instructions. In response, coordination system 108 receives and executes the executable instructions for subprocess 8.5 in the same manner as described for subprocess 3.2.6, except that coordination system 108 receives status information in the form of a cryopreservation protocol for the selected rack system and cryopreservation of expanded biological material intended for CAR-T therapy with a second cryopreservation device. Unlike subprocess 3.2.6, coordination system 108 identifies that milestone 8 and subprocess 8.5 are complete and identifies that the next milestone and subprocess to be achieved is milestone 9 and subprocess 9.1, and writes to the blockchain to update the current status of smart contract 124 accordingly.

[0201] Milestone 9 As shown in Figure 18, the ninth milestone of this example is "controlled cryopreservation," in which a medical scientist places the packaging device into a second cryopreservation device, which freezes the expanded CAR-T cells within the packaging device at a controlled rate.

[0202] Sub-process 9.1 corresponds to sub-process 4.1 described above.

[0203] Sub-process 9.2 corresponds to sub-process 4.2 above, but for the second cryopreservation device and cryopreservation protocol received at milestone 8.

[0204] Coordination system 108 then identifies that milestone 9 and subprocess 9.2 are complete. Because smart contract 124 indicates that the next milestone and subprocess to be achieved are milestone 10 and subprocess 10.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to milestone 10, subprocess 10.1, in the same manner as described above for subprocess 1.1.

[0205] Milestone 10 19, the tenth milestone in this example is "Specialized Logistics," in which the biological material within packaging device 126 is maintained in a controlled and monitored environment during transport between the locations of milestones 6-9 and milestones 11-12.

[0206] Sub-process 10.1 corresponds to sub-process 5.1 described above.

[0207] Sub-process 10.2 corresponds to sub-process 5.2 described above.

[0208] Coordination system 108 then identifies that milestone 10 and sub-process 10.2 are complete. Because smart contract 124 indicates that the next milestone and sub-process to achieve is milestone 11 and sub-process 11.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to milestone 11 sub-process 11.1 in a manner similar to that described above for sub-process 1.1.

[0209] Milestone 11 As shown in Figure 20, the eleventh milestone in this example is "Controlled Biothaw," in which the cryopreserved CAR-T cells are thawed by a second thawing device in preparation for transplantation at Milestone 12.

[0210] Sub-process 11.1 corresponds to sub-process 6.1 described above.

[0211] Sub-process 11.2 corresponds to sub-process 6.2 above, but for a second decompressor.

[0212] Sub-process 11.3 corresponds to sub-process 6.3 above, but for a second decompressor.

[0213] Coordination system 108 then identifies that milestone 11 and subprocess 11.3 are complete. Because smart contract 124 indicates that the next milestone and subprocess to achieve is milestone 12 and subprocess 12.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to milestone 12 subprocess 12.1 in a manner similar to that described above for subprocess 1.1.

[0214] Milestone 12 As shown in Figure 21, the twelfth milestone in this example is "transplantation," in which a medical professional, such as a physician, transplants the thawed CAR-T cells into the patient's bloodstream.

[0215] Based on the current status of sub-process 12.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 12.1, which in this example causes processor 110 to:

[0216] At milestone 12.1, the coordination system 108 instructs the input device 112 to notify the physician (performing the transplant) that status information needs to be provided in the form of physician details (identifying the physician), patient details (identifying the transplant patient), and biological material details (identifying the biological material in the packaging device 126). The input device 112 can provide instructions to the physician via the user interface 116. The details are entered by the physician using the user interface 116, and the input device 112 sends the entered status information to the coordination system 108. The coordination system 108 processes the received status information. The processing includes verifying the status information to determine whether the physician details, patient details, and biological material are valid for the smart contract 124. In this example, the verification may include querying the blockchain to confirm that the physician details, patient details, and biological material match the corresponding details stored on the blockchain. If the verification is successful, the coordination system 108 decides that the entered physician details, patient details, and biological material are to be stored on the blockchain. If the validation fails, coordination system 108 notifies the user that validation failed and prompts the input device for new input. Coordination system 108 may save a copy of the received status information in data lake 128. Once processed, coordination system 108 stores the status information in the blockchain (using the same steps as described above in subprocess 1.1).

[0217] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies that subprocess 12.1 is complete. Because smart contract 124 dictates that the next subprocess to accomplish is subprocess 12.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 12.2 in the same manner as described above for subprocess 1.1.

[0218] Based on the current status of sub-process 12.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 12.2, which in this example causes processor 110 to:

[0219] In sub-process 12.2, coordination system 108 instructs input device 112 to notify the physician to perform the transplant, for example, through a message displayed on user interface 116. Coordination system 108 then identifies that milestone 12, sub-process 12.2, and thus the entire CAR-T process defined by smart contract 124, is complete.

[0220] Example 2: Assisted Reproductive Technology (ART) In a second example, the systems and methods described herein are used to control the handling of biological material intended for ART treatment. In this example, the biological material includes sperm collected from a patient.

[0221] In this example, the distributed ledger is a private blockchain, but other examples may use a public blockchain.

[0222] Initially, the user interface 116 receives user input requesting to initialize a new process. This input indicates a required smart contract template 123 to be used to initialize the smart contract for the current process. The coordination system 108 can receive the user input via the input device 112 and, based on the user input, determine a template identifier corresponding to the required smart contract template 123. The coordination system 108 then sends a request to the blockchain to initialize a smart contract 124 using the template identifier. This request includes a smart contract identifier that the coordination system 108 generates to be associated with the newly initialized smart contract and that is stored with the smart contract on the blockchain.

[0223] In this example, the user input is a selection by the physician indicating that he or she wishes to initiate an ART process. From the received user input, the coordination system 108 can identify that the associated template identifier corresponds to the ART process template 123. In response, the coordination system 108 sends a request to the blockchain to initialize a new smart contract 124 for the ART using the ART template identifier. This includes generating a new smart contract identifier that is sent with the request to the blockchain and associated with and stored in the newly initialized smart contract 124.

[0224] Upon initializing the smart contract 124, the coordination system 108 updates the current status of the smart contract 124 to Milestone 1 subprocess 1.1. Updating the current status includes submitting a write request to a gatekeeper component associated with the blockchain for the transaction associated with the current status of subprocess 1.1. The write request includes the smart contract identifier. In response to receiving the write request, the gatekeeper component executes a process to create a new entity transaction for the data and submits the entity transaction to be committed to the blockchain in association with the associated smart contract 124 for the current ART process. The coordination system 108 then receives confirmation from the gatekeeper that the current status has been saved to the blockchain.

[0225] Milestone 1 As shown in FIG. 22, the first milestone in this embodiment is "Doctor-Patient Identification."

[0226] Sub-process 1.1 and sub-process 1.2 are the same as sub-process 1.1 and sub-process 1.2 in the above-described Example 1 (CAR-T therapy). However, in this Example, the patient may also be referred to as the donor.

[0227] In sub-process 1.3, coordination system 108 prompts input device 112 to instruct the physician to conduct a psychological evaluation of the patient and to input the results of the psychological evaluation. The instructions may be provided to the physician and / or other medical professional by displaying them on user interface 116 associated with input device 112.

[0228] The psychological evaluation can take any appropriate form. For example, the psychological evaluation may include a physician evaluation and an ART counselor (e.g., an IVF counselor). The physician evaluation may include determining one or more of the following: the patient's age, the patient's length of time trying to conceive, the patient's genetic makeup, the patient's BMI, the patient's lifestyle, whether the patient is a smoker, the patient's alcohol consumption, the patient's caffeinated beverage consumption, the patient's physical activity, the patient's stress factors, the patient's occupation, and the patient's relationship status. The counselor evaluation may include the patient's informed consent for the ART procedure, the patient's understanding of the risks, benefits, side effects, and palliative care associated with the ART procedure, the provision of de-identified patient and treatment information to one or more third-party databases (e.g., the Australia and New Zealand Assisted Reproductive Database (ANZARD)), the patient's understanding of the emotional implications of proceeding with the ART procedure (e.g., associated with adverse or undesirable outcomes), and the patient's understanding of the potential personal and social consequences of the ART procedure.

[0229] The results of the psychological assessment are entered by the physician and counselor using the user interface 116, and the input device 112 transmits this input to the coordination system 108. Upon receiving this input (forming the status information of the biomaterial), the coordination system 108 processes the results of the psychological assessment. Processing includes the coordination system 108 verifying the status information to determine whether the results meet predefined transition conditions. The transition conditions may be defined in executable instructions based on, for example, one or more regulatory requirements for ART procedures. If the verification is successful, the coordination system 108 determines that the results are to be stored in the blockchain. If the verification fails, the coordination system 108 instructs the input device 112 to notify the user that the verification failed and to request new input. The coordination system 108 may save a copy of the received status information in the data lake 128. Once processed, the coordination system 108 stores the status information in the blockchain (using the same procedure as described in Example 1).

[0230] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies that milestone 1 and subprocess 1.3 are complete. Because smart contract 124 indicates that the next milestone and subprocess to achieve are milestone 2 and subprocess 2.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to be milestone 2, subprocess 2.1, in a manner similar to that described above in Example 1.

[0231] Milestone 2 As shown in Figure 23, the second milestone in this example is "Patient Collection." In this milestone, the physician obtains biological material by collecting a semen sample from the patient.

[0232] Sub-process 2.1 is the same as sub-process 2.1 in Example 1, except that the user interface 116 receives input from a physician identifying the biological material as semen, and the process is ART.

[0233] In sub-process 2.2, coordination system 108 instructs input device 112 (e.g., via instructions displayed on user interface 116) to inform the physician that status information related to the collection of the semen sample needs to be entered. In this example, the required information includes the date, time, location, and ambient temperature at which the sample was collected. In this example, the information is entered by the physician using user interface 116, but in other examples, the information may be generated automatically by input device 112. Input device 112 sends this input to coordination system 108, which processes the entered status information, including the date, time, location, and ambient temperature at the time of collection. The processing includes coordination system 108 verifying the status information to determine whether the collection date, time, location, and ambient temperature are valid for smart contract 124, i.e., whether the input meets predefined criteria (or “transition conditions”) defined by the executable instructions. If the verification is successful, coordination system 108 decides that the received date, time, location, and ambient temperature will be saved to the blockchain. If the validation fails, the coordination system 108 instructs the input device 112 to notify the physician that the validation failed and request new input. The coordination system 108 may store a copy of the received status information in the data lake 128. Once processed, the coordination system 108 stores the status information in the blockchain (using the same steps as described above in Example 1).

[0234] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies that subprocess 2.2 is complete. Because smart contract 124 indicates that the next subprocess to accomplish is subprocess 2.3, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 2.3, in the same manner as described above in Example 1.

[0235] Based on the current status of sub-process 2.3, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions of sub-process 2.3, which in this example causes processor 110 to:

[0236] In subprocess 2.3, coordination system 108 notifies input device 112 that a physician needs to collect a semen sample from the donor and instructs the physician to enter status information for the volume of the collected semen sample (e.g., through instructions displayed on user interface 116). User interface 116 receives input from the physician identifying the volume of the collected semen sample. In this example, the status information is entered by the physician using user interface 116, but in other examples, the status information may be received by coordination system 108 from one or more devices 102 (e.g., devices that measure the volume of the collected semen sample). Input device 112 sends this input to coordination system 108, which processes the entered volume status information. Processing includes coordination system 108 verifying the status information to determine whether the amount of biological material is valid for smart contract 124, i.e., whether the amount meets predefined criteria (or “transition conditions”) defined by the executable instructions. If the verification is successful, coordination system 108 determines that the received amount is to be stored on the blockchain. If the validation fails, the coordination system 108 notifies the physician that the validation failed and instructs the input device 112 to request new input. The coordination system 108 may save a copy of the received status information in the data lake 128. Once processed, the coordination system 108 stores the status information in the blockchain (using the same procedure as described above in Example 1).

[0237] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, the coordination system 108 identifies that sub-process 2.3 is complete. Because the smart contract 124 indicates that the next sub-process to complete is sub-process 2.4, the coordination system 108 writes to the blockchain to update the current status of the smart contract 124 to be sub-process 2.4, in the same manner as described above in Example 1.

[0238] Based on the current status of sub-process 2.4, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions of sub-process 2.4, which in this example causes processor 110 to:

[0239] In subprocess 2.4, the coordination system 108 selects an appropriate packaging device 126 for the biological material. According to the executable instructions, the selection can be based on the volume of biological material received in subprocess 2.3. The coordination system 108 generates a packaging device identifier for the selected packaging device 126. The coordination system 108 stores the selection of the packaging device 126 (including the packaging device identifier) ​​on the blockchain in a manner similar to that described above, and then receives confirmation from the gatekeeper that the data has been stored on the blockchain. The coordination system 108 notifies the selected packaging device 126 that it has been selected for the current ART process. Notifying the packaging device 126 can include the coordination system 108 sending a smart contract identifier to the packaging device 126.

[0240] The coordination system 108 instructs the input device 112 (e.g., through instructions displayed on the user interface 116) to inform the physician that the biological material (collected sperm cells) needs to be transferred to the selected packaging device 126.

[0241] Coordination system 108 then identifies that sub-process 2.4 is complete, and because smart contract 124 indicates that the next sub-process to accomplish is sub-process 2.5, coordination system 108 writes to the distributed ledger and updates the current status of smart contract 124 to sub-process 2.5 in the same manner as described above in Example 1.

[0242] Based on the current status being subprocess 2.5, the coordinate system 108 queries the data storage location 114 to retrieve executable instructions, which in this example cause the processor 110 to request the packaging device 126 to begin monitoring with the sensors 308 and provide the monitoring information to the coordinate system 108. The monitoring information is generated from monitoring data captured by the sensors 308 of the packaging device 126. In this example, the monitoring information includes temperature monitoring information and location tracking information. The temperature monitoring information indicates the temperature of the biological material within the packaging device 126 and is generated from the monitoring data of the temperature sensor. The location tracking information indicates the location of the packaging device 126 (and thus the biological material), which is generated from the monitoring data of the location sensor (e.g., a GPS sensor). Along with the monitoring information, the coordinate system 108 also receives identification information including a smart contract identifier. The identification information may also include a packaging device identifier for the packaging device 126.

[0243] Once initiated, monitoring continues until an end condition defined in the executable instructions is met. The end condition may be, for example, a time period (e.g., four hours), the current status of the smart contract 124 being a particular subprocess (e.g., subprocess 3.2), or the coordination system 108 receiving particular status information (e.g., receiving the required screening results in subprocess 3.1). Once the coordination system 108 receives the monitoring information and identification information, it queries the blockchain using the smart contract identifier to retrieve the smart contract 124 for the current ART process, including the current status of that smart contract 124. Based on the retrieved smart contract 124 and the current status of subprocess 2.5, the coordination system 108 queries the data store 114 to retrieve executable instructions for subprocess 2.5, which, when executed, cause the processor 110 to process the received monitoring information. Processing includes the coordination system 108 verifying the monitoring information to determine whether the received temperature monitoring information and location tracking information meet predefined transition conditions. For example, the temperature monitoring information may be required to be within a certain range necessary to maintain the viability of the biological material in the packaging device 126. If the verification fails, the coordination system 108 can send an alert to a physician via the input device 112 and user interface 116. If the verification is successful, the coordination system 108 determines which portion of the monitoring information to store on the blockchain. For example, if the temperature monitoring information includes temperature measurements taken every second, the coordination system 108 can determine that one measurement per minute will be stored on the blockchain. Once processed, the coordination system 108 stores the portion of the monitoring information on the blockchain (using the same steps as described above in Example 1).

[0244] As mentioned above, the coordination system 108 may store a copy of all received monitoring information in the data lake 128 .

[0245] As mentioned above, the packaging device 126 may store a copy of the monitoring information locally in the packaging device data store 306. This local copy of the monitoring information may be received by the coordination system 108 at a later stage, for example, for data integrity or data recovery purposes.

[0246] After initiating monitoring, the coordination system 108 identifies that sub-process 2.5 is complete, although the initiated monitoring process continues after completion of milestone 2 until the exit condition is met.

[0247] Milestone 3 As shown in Figures 24A and 24B, the third milestone in this example is "Sample Preparation," in which a medical scientist prepares the biological material (collected semen sample) so that it is ready for cryopreservation.

[0248] Based on the current status of sub-process 3.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.1, which in this example causes processor 110 to:

[0249] In sub-process 3.1, coordination system 108 instructs input device 112′ (which may be separate from input device 112) to inform a medical scientist (e.g., via instructions displayed on user interface 116′ associated with input device 112′) that status information for screening results of the biological material needs to be entered. The requested screening results include the results of one or more disease or infection tests performed on the biological material, such as the results of an HIV test performed on the biological material. User interface 116′ receives input from the medical scientist identifying the screening results. In this example, the screening results are entered by a physician using user interface 116′, but in other examples, the screening results may be received by coordination system 108 from one or more devices 102 (e.g., one or more in vitro diagnostic devices). Input device 112′ transmits this input to coordination system 108, which processes the entered status information. Processing includes coordination system 108 verifying the status information to determine that the received screening results meet predefined transition conditions. For example, a specific screening result may be required for a semen sample to be usable (e.g., due to regulatory requirements). If validation fails, coordination system 108 can send an alert to a medical scientist via input device 112' and / or user interface 116'. If validation is successful, coordination system 108 determines at least a portion of the screening results to be stored on the blockchain. Once processed, coordination system 108 stores a portion of the monitoring information (screening results) on the blockchain (using the same steps as described above in Example 1). Coordination system 108 then receives confirmation from the gatekeeper that the data has been stored on the blockchain, identifying that subprocess 3.1 is complete.Because smart contract 124 indicates that the next sub-process to be completed is sub-process 3.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to sub-process 3.2 in the same manner as described above in Example 1.

[0250] Based on the current status of sub-process 3.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions of sub-process 3.2, which in this example causes processor 110 to:

[0251] In sub-process 3.2, coordination system 108 instructs input device 112′ (e.g., through instructions displayed on user interface 116′) to notify the medical scientist using input device 112′ that the medical scientist needs to input status information related to genetic testing performed on the biological material. For example, the genetic testing may include testing for characteristics such as eye color, complexion, and / or height.

[0252] The coordination system 108 receives status information entered by the medical scientist through the user interface 116′ from the input device 112′. Along with this status information, the coordination system 108 also receives identification information including a smart contract identifier. Using the identification information, the coordination system 108 queries the blockchain to retrieve the smart contract 124 and its current status. Based on the retrieved current status being subprocess 3.2, the coordination system 108 queries the data store 114 to retrieve executable instructions, which the coordination system 108 executes to process the status information. The processing includes validating the status information to determine whether the input information meets predefined transition conditions. The transition conditions may be defined in the executable instructions based on, for example, one or more predetermined requirements for genetic test results. If the validation fails, the coordination system 108 tags the invalid status information to identify that the validation did not pass and instructs the input device 112′ to notify the medical scientist that the validation failed.

[0253] The processing also includes the coordination system 108 determining a portion of the status information to store on the blockchain (where the portion may include all of the status information). The coordination system 108 may store a copy of the received status information in the data lake 128. Once processed, the coordination system 108 stores the determined portion of the status information on the blockchain (using the same steps as described above in Example 1).

[0254] The coordination system 108 then identifies that sub-process 3.2 is complete. Because the smart contract 124 indicates that the next sub-process to accomplish is sub-process 3.3.1, the coordination system 108 writes to the distributed ledger to update the current status of the smart contract 124 to sub-process 3.3.1 in the same manner as described above for sub-process 1.1.

[0255] Based on the current status being sub-process 3.3.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.3.1, which in this example causes processor 110 to:

[0256] In sub-process 3.3.1, coordination system 108 instructs input device 112′ to notify the medical scientist (e.g., via instructions displayed on user interface 116′) that, in sub-process 3.3.2, the medical scientist needs to enter status information related to pre-analysis preparation performed by the medical scientist in connection with the biological material to prepare it for subsequent analysis. Pre-analysis preparation may include processes such as centrifugation, addition of media, and performing one or more baseline measurements (e.g., measurements of cell count, cell viability, and / or cell functionality). User interface 116′ receives input from the medical scientist identifying the pre-analysis preparation, and input device 112′ transmits this input to coordination system 108, which processes the pre-analysis preparation information before storing it in the blockchain in a manner similar to that described above in Example 1.

[0257] The coordination system 108 then receives confirmation from the gatekeeper that the data has been saved to the blockchain and identifies that subprocess 3.3.1 is complete. Because the smart contract 124 indicates that the next subprocess to be completed is subprocess 3.3.2, the coordination system 108 writes to the blockchain to update the current status of the smart contract 124 to subprocess 3.3.2, in the same manner as described above in Example 1.

[0258] Based on the current status being sub-process 3.3.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.3.2, which in this example causes the processor to:

[0259] In sub-process 3.3.2, coordination system 108 instructs input device 112′ to notify the medical scientist using input device 112′ (e.g., through instructions displayed on user interface 116′) that status information related to analyses performed on the biological material and corresponding analysis results needs to be entered. For example, analyses related to the application may include determining sperm cell motility and determining sperm cell grading.

[0260] The user interface 116′ receives input from a medical scientist identifying analytical steps and results. In this example, the input is received from the user interface 116′, but in other examples, the input may also be received from one or more devices undertaking the analysis of the biological material, where one or more devices belong to the plurality of devices 102. The input device 112′ sends this input to the coordination system 108, which processes the input status information. The processing includes the coordination system 108 verifying the analytical steps and results to determine whether they are valid with respect to the smart contract 124, i.e., whether the steps and results meet predefined criteria (or “transition conditions”) defined by the executable instructions. If the verification is successful, the coordination system 108 determines at least a portion of the analytical steps and results to store on the blockchain. If the verification fails, the coordination system 108 instructs the input device 112′ to notify the medical scientist that the verification failed and to request new input. The coordination system 108 may store a copy of the received status information in the data lake 128. Once processed, the coordination system 108 stores the determined portion of the status information in the blockchain (using the same steps as described above in Example 1).

[0261] Upon receiving confirmation from the gatekeeper that the data has been saved to the blockchain, the coordination system 108 identifies that sub-process 3.3.2 is complete. Because the smart contract 124 indicates that the next sub-process to be completed is sub-process 3.3.3, the coordination system 108 writes to the blockchain to update the current status of the smart contract 124 to sub-process 3.3.3, in the same manner as described above in Example 1.

[0262] Based on the current status being subprocess 3.3.3, coordination system 108 queries data store 114 to retrieve executable instructions. In response, coordination system 108 receives and executes the executable instructions for subprocess 3.3.3, which in this example causes processor 110 to perform the same steps as described for subprocess 3.2.1 in Example 1. Once coordination system 108 identifies that subprocess 3.3.3 is complete, smart contract 124 indicates that the next subprocess to be achieved is subprocess 3.3.4, and therefore coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 3.3.4 in the same manner as described above in Example 1.

[0263] Based on the fact that the current sub-process is sub-process 3.3.4, coordination system 108 queries data store 114 to retrieve executable instructions. In response, coordination system 108 receives and executes the executable instructions for sub-process 3.3.4, which in this example causes processor 110 to perform the same steps as described for sub-process 8.3 in Example 1. When coordination system 108 identifies that sub-process 3.3.4 is complete, smart contract 124 indicates that the next sub-process to be achieved is sub-process 3.3.5, and therefore coordination system 108 writes to the blockchain to update the current status of smart contract 124 to sub-process 3.3.5 in the same manner as described above in Example 1.

[0264] Based on the current status being sub-process 3.3.5, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.3.5, which in this example causes processor 110 to:

[0265] In subprocess 3.3.5, the coordination system 108 selects an appropriate packaging device 126′ for the biological material that has undergone preliminary cryopreservation processing up to this stage. According to the executable instructions, the selection can be based on the volume of the biological material received in subprocess 2.3 and / or the cryopreservation pre-processing steps received in subprocess 3.3.1. The coordination system 108 generates a packaging device identifier for the selected packaging device 126′. The coordination system 108 stores the selection of the packaging device 126′ (including the packaging device identifier) ​​on the blockchain in a manner similar to that described above, and then receives confirmation from the gatekeeper that the data has been stored on the blockchain. The coordination system 108 notifies the selected packaging device 126′ that it has been selected for the current ART process. Notifying the packaging device 126′ may include the coordination system 108 sending a smart contract identifier to the packaging device 126′. In this example, packaging device 126' is different from packaging device 126 selected in sub-process 2.4, although in some examples packaging device 126' may be the same as packaging device 126.

[0266] The coordination system 108 instructs the input device 112' to inform the physician (e.g., through instructions displayed on the user interface 116') that the biological material (collected sperm cells) needs to be transferred to the selected packaging device 126'.

[0267] The coordination system 108 then identifies that sub-process 3.3.5 is complete, and because the smart contract 124 indicates that the next sub-process to be completed is sub-process 3.3.6, the coordination system 108 writes to the distributed ledger and updates the current status of the smart contract 124 to sub-process 3.3.6 in the same manner as described above in Example 1.

[0268] Based on the fact that the current sub-process is sub-process 3.3.6, coordination system 108 queries data store 114 to retrieve executable instructions. In response, coordination system 108 receives and executes the executable instructions for sub-process 3.3.6, which in this example causes processor 110 to perform the same steps as described for sub-process 3.2.5 in Example 1. Once coordination system 108 identifies that sub-process 3.3.6 is complete, smart contract 124 indicates that the next sub-process to be achieved is sub-process 3.3.7, and therefore coordination system 108 writes to the blockchain to update the current status of smart contract 124 to be sub-process 3.3.7, in the same manner as described above in Example 1.

[0269] Based on the fact that the current sub-process is sub-process 3.3.7, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 3.3.7, causing processor 110 to perform, in this example, the same steps as described for sub-process 3.2.6 in Example 1.

[0270] Once the coordination system 108 identifies that milestone 3 and sub-process 3.3.7 are complete, the smart contract 124 indicates that the next milestone and sub-process to be achieved is milestone 4 and sub-process 4.1, so the coordination system 108 writes to the blockchain to update the current status of the smart contract 124 to milestone 4, sub-process 4.1, in a manner similar to that described above in Example 1.

[0271] Milestone 4 As shown in Figure 25, the fourth milestone in this example is "Controlled Preservation," in which the medical scientist places the packaging device 126 in a cryopreservation device, which freezes the biological material within the packaging device 126 at a controlled rate.

[0272] Subprocess 4.1 is performed similarly to that described above in subprocess 3.2.3 of Example 1, except that a monitoring start request is sent to the cryopreservation device. The cryopreservation device generates monitoring information from monitoring data captured by its sensors 208. In subprocess 4.1, the monitoring information may include temperature monitoring information (i.e., information regarding the temperature during cryopreservation) and operation monitoring information. The temperature monitoring information indicates the temperature of the biological material in the packaging device 126 and is generated from the monitoring data of the temperature sensors. The operation monitoring information indicates one or more operations performed in the cryopreservation device, such as the flow rate of the heat exchange fluid. Along with the monitoring information, the coordination system 108 also receives identification information including a smart contract identifier. The identification information may also include an equipment identifier associated with the cryopreservation device.

[0273] The initiated monitoring continues through Milestone 4, i.e., while subprocess 4.2 is being executed. Once the coordination system 108 receives the monitoring information and identification information, it queries the blockchain using the smart contract identifier to retrieve the smart contract 124 for the current ART process (including its current status). Based on the retrieved smart contract 124 and its current status (which may now be subprocess 4.2), the coordination system 108 queries the data store 114 to retrieve executable instructions for that subprocess, executing which causes the processor 110 to process the received monitoring information. Processing includes the coordination system 108 verifying the status information to determine that the received temperature and operational monitoring information meet predefined transition conditions. For example, the operational monitoring information may be required to be within a specific range to determine that no malfunction or other unexpected event has occurred within the cryopreservation device. If the verification fails, the coordination system 108 can send an alert to the medical scientist via the input device 112' and the user interface 116'. If the verification is successful, the coordination system 108 determines the portion of the monitoring information to be stored in the blockchain. For example, if the operation monitoring information includes monitoring information for multiple operations performed by the cryopreservation device, the coordination system 108 can determine to store only the monitoring information for a specific operation in the blockchain. Once processed, the coordination system 108 stores the portion of the monitoring information in the blockchain (using the same steps as described above in Example 1).

[0274] Processing the operational monitoring information may also include generating cost monitoring information based on the operational monitoring information, the cost monitoring information indicating costs associated with operating the cryopreservation device to perform cryopreservation of the biological material, determining a portion of the cost monitoring information to be stored in the blockchain, and storing the portion of the cost monitoring information to be stored in the blockchain (using the same steps as described above in Example 1).

[0275] After initiating monitoring, coordination system 108 identifies that subprocess 4.1 is complete, although the initiated monitoring continues through milestones. Because smart contract 124 indicates that the next subprocess to be completed is subprocess 4.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 4.2, in the same manner as described above in Example 1.

[0276] Based on the current status of sub-process 4.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 4.2, which in this example causes processor 110 to:

[0277] In sub-process 4.2, coordination system 108 controls the cryopreservation device to coordinate the refrigeration system to achieve the required operating conditions according to the cryopreservation protocol received in milestone 3. This is done by determining one or more commands or one or more executable instructions to the cryopreservation device, which then executes the commands or executable instructions to control the functioning of its refrigeration system.

[0278] Coordination system 108 identifies that sub-process 4.2 is complete by, for example, determining, based on operational monitoring information, that the operational conditions required by the cryopreservation protocol (selected in sub-process 3.3.7) have been satisfied by the cryopreservation device. Because smart contract 124 indicates that the next milestone and sub-process to be achieved are milestone 5 and sub-process 5.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to milestone 5, sub-process 5.1, in the same manner as described above in Example 1.

[0279] Milestone 5 As shown in Figure 26, the fifth milestone in this example is "Professional Logistics," in which the biological material within packaging device 126 is maintained in a controlled and monitored environment during transport between the Milestone 2-4 location and the Milestone 6 location.

[0280] Based on the current status being subprocess 5.1, the coordinate system 108 queries the data storage location 114 to retrieve executable instructions. In response, the coordinate system 108 receives and executes the executable instructions of subprocess 5.1, which in this example causes the processor 110 to request the packaging device 126 to begin monitoring with the sensor 308 and provide the monitoring information to the coordinate system 108. The monitoring information is generated from monitoring data captured by the sensor 308 of the packaging device 126. In this example, the monitoring information includes temperature monitoring information and location tracking information. The temperature monitoring information indicates the temperature of the biological material in the packaging device 126 and is generated from the monitoring data of the temperature sensor. The location tracking information indicates the location of the packaging device 126 (and thus the biological material) and is generated from the monitoring data of the location sensor (e.g., a GPS sensor). Along with the monitoring information, the coordinate system 108 also receives identification information including a smart contract identifier. The identification information may also include a packaging device identifier for the packaging device 126.

[0281] The initiated monitoring continues through Milestone 5, i.e., while subprocess 5.2 is being executed. Once the coordination system 108 receives the monitoring information and identification information, it queries the blockchain using the smart contract identifier to retrieve the smart contract 124 for the current ART process (including its current status). Based on the retrieved smart contract 124 and its current status (which may be subprocess 5.2), the coordination system 108 queries the data storage location 114 to retrieve executable instructions for that subprocess, which, when executed, cause the processor 110 to process the received monitoring information. The processing includes the coordination system 108 verifying the monitoring information to determine whether the received temperature monitoring information and location tracking information meet predefined transition conditions. For example, the temperature monitoring information may be required to be within a certain range necessary to maintain the biological material in the packaging device 126. If the verification fails, the coordination system 108 can send an alert to a medical scientist via the input device 112' and user interface 116'. If the verification is successful, the coordination system 108 determines the portion of the monitoring information to be stored on the blockchain. For example, if the temperature monitoring information includes temperature readings retrieved every second, the coordination system 108 may determine to store one reading per minute on the blockchain. Once processed, the coordination system 108 stores the portion of the monitoring information on the blockchain (using the same steps as described above in Example 1).

[0282] As mentioned above, the coordination system 108 may store a copy of all received monitoring information in the data lake 128 .

[0283] As mentioned above, the packaging device 126 may store a copy of the monitoring information locally in the packaging device data store 306. This local copy of the monitoring information may be received by the coordination system 108 at a later stage, for example, for data integrity or data recovery purposes.

[0284] After initiating monitoring, coordination system 108 identifies that subprocess 5.1 is complete, although the initiated monitoring process continues through milestones. Because smart contract 124 indicates that the next subprocess to be completed is subprocess 5.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 5.2, in the same manner as described above in Example 1.

[0285] Based on the current status of sub-process 5.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions of sub-process 5.2, which in this example causes processor 110 to:

[0286] In sub-process 5.2, the coordination system 108 determines a target destination for the biological material in the packaging device 126. In this example, the target destination corresponds to the location of a thawing device that has been predefined and stored on the blockchain. Based on the location tracking information received and stored by the monitoring initiated in sub-process 5.2, the coordination system 108 can also determine a route (e.g., an optimal route) to the target destination.

[0287] Once the coordination system 108 processes the request, it sends the target destination to the secure API, which in turn sends the target destination to the packaging device 126 .

[0288] Coordination system 108 receives confirmation from packaging device 126 that the target destination has been received. Coordination system 108 then identifies that sub-process 5.2 and milestone 5 are complete. Because smart contract 124 indicates that the next milestone and sub-process to achieve is milestone 6 and sub-process 6.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to be milestone 6, sub-process 6.1, in the same manner as described above in Example 1.

[0289] Milestone 6 As shown in Figure 27, the sixth milestone of this example is "Controlled Biological Thawing," in which the cryopreserved biological material is thawed by a thawing device in preparation for post-thaw processing in Milestone 7 and application use in Milestone 8.

[0290] Sub-process 6.1 is performed similarly to sub-process 4.1 above, except that a monitoring start request is sent to the thawing device. The thawing device generates monitoring information from monitoring data captured by its sensors 208. In sub-process 6.1, the monitoring information may include temperature monitoring information (i.e., information for monitoring the temperature during cryopreservation) and operational monitoring information. The temperature monitoring information indicates the temperature of the biological material in the packaging device 126 and is generated from the temperature sensor monitoring data. The operational monitoring information indicates one or more operations to be performed by the thawing device, such as the thawing temperature applied by the device.

[0291] The initiated monitoring continues through milestone 6, i.e., while subprocess 6.2 and subprocess 6.3 are being performed. After initiating monitoring, coordination system 108 identifies that subprocess 6.1 is complete, even though initiated monitoring continues through milestone 6. Because smart contract 124 indicates that the next subprocess to be completed is subprocess 6.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 6.2, in the same manner as described above in Example 1.

[0292] Based on the current status of sub-process 6.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 6.2, which in this example causes processor 110 to:

[0293] In sub-process 6.2, the coordination system 108 receives status information in the form of a thawing protocol selected for thawing the biological material in the packaging device. The thawing protocol defines the thawing settings of the thawing device, including the heating rate and temperature for the thawing process.

[0294] Status information is received from the thawing device via a secure API. The cryopreservation device can select a thawing protocol based on one or more of the type of packaging device 126, the type of biological material (i.e., sperm cells in this example), the volume of the biological material (e.g., cell count), and the temperature at which the biological material was stored inside the packaging device 126 since cryopreservation.

[0295] Coordination system 108 processes the received status information by validating it and determining that it should be stored on the blockchain, and writes the status information to the blockchain for storage (using the same steps as described above for subprocess 1.1). Coordination system 108 then identifies that subprocess 6.2 is complete. Because smart contract 124 indicates that the next subprocess to complete is subprocess 6.3, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 6.3, in the same manner as described above for Example 1.

[0296] Alternatively, in sub-process 6.2, the coordination system 108 receives a request from the thawing device via a secure API to retrieve a selection of a thawing protocol for thawing the biological material in the packaging device 126, including the heating rate and temperature for the thawing process.

[0297] The coordination system 108 processes the received request by verifying that the decompression device is one of the multiple devices 102 and is therefore authorized to interact with the coordination system, and by verifying the current status of the smart contract by querying the blockchain using the smart contract identifier.

[0298] Once the coordination system 108 processes the request, it invokes a query process on the blockchain via the gatekeeper. The gatekeeper runs the query on the blockchain to retrieve the required information (the selection of the thawing protocol for the current process). The blockchain query data result containing the required information is returned from the blockchain via the gatekeeper to the coordination system 108. The coordination system 108 processes the blockchain query data result and sends it via a secure API to the thawing device. The thawing device thaws the biological material in the packaging device 126 using the thawing protocol received in sub-process 6.3.

[0299] Coordination system 108 receives confirmation from the decompressor that the selected decompression protocol was received. Coordination system 108 then identifies that sub-process 6.2 is complete. Because smart contract 124 indicates that the next sub-process to complete is sub-process 6.3, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to sub-process 6.3, in a manner similar to that described above in Example 1.

[0300] Based on the current status of sub-process 6.3, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 6.3, which in this example causes processor 110 to:

[0301] In subprocess 6.3, coordination system 108 controls the thawing device to coordinate its refrigeration system to achieve the required operating conditions according to the thawing protocol received in subprocess 6.2. Coordination system 108 identifies that subprocess 6.3 is complete by determining, for example, based on operational monitoring information, that the operating conditions required by the thawing protocol (received in subprocess 6.2) have been met by the thawing device. Because smart contract 124 indicates that the next milestone and subprocess to be achieved are Milestone 7 and Subprocess 7.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to Milestone 7, Subprocess 7.1, in a manner similar to that described above in Example 1.

[0302] Milestone 7 The seventh milestone in this example is "Post-Thaw Processing," as shown in Figure 28. In this milestone, the thawed biological material undergoes analysis and screening before the thawed sperm cells in Milestone 8 are used in ART procedures.

[0303] Based on the current status of sub-process 7.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 7.1, which in this example causes processor 110 to:

[0304] In sub-process 7.1, coordination system 108 instructs input device 112″ (which may be different from input devices 112 and 112′) to notify the medical scientist performing the analysis and screening steps that they need to input status information related to the analysis steps performed on the thawed biological material, and the corresponding analysis results. For example, the required information may include measurements of sperm cell motility, sperm count of the sperm cells, and / or results of a sperm DNA fragmentation test. The instructions may be provided by displaying on a user interface 116″ associated with input device 112″.

[0305] User interface 116" receives input from the medical scientist identifying the analysis steps and analysis results. Input device 112" transmits this input to coordination system 108, which processes the entered status information. Processing includes coordination system 108 validating the analysis steps and results to determine whether they are valid for smart contract 124, i.e., whether the steps and results meet predefined criteria (or "transition conditions") defined by the executable instructions. If validation is successful, coordination system 108 determines at least a portion of the analysis steps and results to store on the blockchain. If validation fails, coordination system 108 instructs input device 112" to notify the medical scientist that validation failed and to request new input. Coordination system 108 may save a copy of the received status information on data lake 128. Once processed, coordination system 108 stores the determined portion of the status information on the blockchain (using the same steps as described above in Example 1).

[0306] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies that subprocess 7.1 is complete. Because smart contract 124 indicates that the next subprocess to accomplish is subprocess 7.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 7.2, in the same manner as described above in Example 1.

[0307] Based on the current status of sub-process 7.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 7.2, which in this example causes processor 110 to:

[0308] In sub-process 7.2, coordination system 108 instructs input device 112″ to inform the medical scientist (e.g., via instructions displayed on user interface 116″) that status information for the screening results of the thawed biological material needs to be entered. Sub-process 7.2 is performed in a manner similar to sub-process 3.1 described above, but in conjunction with the thawed biological material. Upon receiving confirmation from the gatekeeper that the data has been saved to the blockchain, coordination system 108 identifies that sub-process 7.2 is complete. Because smart contract 124 indicates that the next sub-process to be completed is sub-process 7.3, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to sub-process 7.3, in the same manner as described above in Example 1.

[0309] Based on the current status of sub-process 7.3, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 7.3, which in this example causes processor 110 to:

[0310] In sub-process 7.3, the coordination system 108 instructs the input device 112" to notify the medical scientist that further analytical steps to be performed on the thawed biological material, analyses related to the application at milestone 8, and status information related to the corresponding analysis results are required to be entered. For example, the analyses related to the application may include determining sperm cell motility and determining sperm cell grade. The instructions may be provided by displaying on a user interface 116" associated with the input device 112".

[0311] User interface 116" receives input from the medical scientist identifying the analysis steps and analysis results. Input device 112" transmits this input to coordination system 108, which processes the entered status information. Processing includes coordination system 108 validating the analysis steps and results to determine whether they are valid for smart contract 124, i.e., whether the steps and results meet predefined criteria (or "transition conditions") defined by the executable instructions. If validation is successful, coordination system 108 determines at least a portion of the analysis steps and results to store on the blockchain. If validation fails, coordination system 108 instructs input device 112" to notify the medical scientist that validation failed and to request new input. Coordination system 108 may save a copy of the received status information on data lake 128. Once processed, coordination system 108 stores the determined portion of the status information on the blockchain (using the same steps as described above in Example 1).

[0312] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies that sub-process 7.3 is complete. Because smart contract 124 indicates that the next sub-process to accomplish is sub-process 7.4, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to sub-process 7.4, in the same manner as described above in Example 1.

[0313] Based on the current status of sub-process 7.4, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions of sub-process 7.4, which in this example causes processor 110 to:

[0314] In sub-process 7.4, coordination system 108 instructs input device 112″ (e.g., via instructions displayed on user interface 116″) to use input device 112″ to notify the medical scientist that he or she should input status information related to the post-thaw processing performed by the medical scientist on the biological material. Post-thaw processing may include any processing required before the thawed sperm cells can be used for their application at milestone 8, such as removal of cryoprotectant, dilution of the sperm cells, and other preparation required for the particular ART procedure (e.g., IUI or ICSI) being performed with the sperm cells. Preparation for a particular ART procedure may include, for example, preparation of relevant equipment, dilution of the biological material to a particular dilution factor, and measuring the relevant volume of the biological material. User interface 116″ receives input from the medical scientist identifying the post-thaw processing, and input device 112″ transmits this input to coordination system 108, which processes the post-thaw processing information before storing it on the blockchain in a manner similar to that described above in Example 1.

[0315] Coordination system 108 then receives confirmation from the gatekeeper that the data has been saved to the blockchain and identifies that subprocess 7.4 is complete. Because smart contract 124 indicates that the next subprocess to complete is subprocess 7.5, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 7.5, in the same manner as described above in Example 1.

[0316] Based on the current status of sub-process 7.5, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 7.5, which in this example causes processor 110 to:

[0317] In sub-process 7.5, coordination system 108 instructs input device 112 to inform the medical scientist that the biological material (which at this stage is thawed sperm cells that have undergone post-thaw processing) needs to be reinserted into packaging device 126. Coordination system 108 determines that the biological material will be held in packaging device 126 at a holding temperature until needed for its application and requests that packaging device 126 initiate monitoring via sensor 308 and provide monitoring information to coordination system 108. The holding temperature may include an acceptable temperature range. The temperature monitoring information is generated in the same manner as described for sub-process 3.2.3 in Example 1. The initiated monitoring continues for the remainder of milestone 7, i.e., while sub-process 7.6 is performed, in the same manner as described for sub-process 3.2.3 in Example 1, and coordination system 108 stores the relevant determined portion of the monitoring information in the blockchain (using the same steps as described above in Example 1).

[0318] Therefore, coordination system 108 generates an alert if any of the temperature monitoring information falls outside the holding temperature range. Coordination system 108 then identifies that sub-process 7.5 is complete. Because smart contract 124 indicates that the next sub-process to be completed is sub-process 7.6, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to sub-process 7.6 in the same manner as described above in Example 1.

[0319] Based on the current status of sub-process 7.6, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions of sub-process 7.6, which in this example causes processor 110 to:

[0320] In sub-process 7.6, coordination system 108 instructs input device 112″ to notify the medical scientist that status information needs to be entered related to whether any excess portions of the biological material will undergo further cryopreservation, for example, for subsequent further processing. The medical scientist determines whether there is any excess portion of the biological material (i.e., excess sperm cells not needed for the application at Milestone 8) and whether that excess portion is to be cryopreserved for subsequent use in further ART. User interface 116″ receives input from the medical scientist. Input device 112″ transmits this input to coordination system 108, which processes the information before storing it on the blockchain in a manner similar to that described above in Example 1.

[0321] Coordination system 108 then confirms from the gatekeeper that the data has been saved to the blockchain and identifies milestone 7 and subprocess 7.6 as completed. Because smart contract 124 indicates that the next milestone and subprocess to be achieved is milestone 8 and subprocess 8.1, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to be milestone 8, subprocess 8.1, in a manner similar to that described above in Example 1.

[0322] Milestone 8 As shown in Figure 29, the eighth milestone in this example is "Application Use," in which at least a portion of the thawed biological material is used in an ART procedure, such as in vitro fertilization (IVF), intracytoplasmic sperm injection (ICSI), or intrauterine insemination (IUI).

[0323] Based on the current status of sub-process 8.1, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions for sub-process 8.1, which in this example causes processor 110 to:

[0324] In subprocess 8.1, the coordination system 108 instructs the input device 112 to notify the physician (or other medical professional performing or supervising the ART procedure) that status information needs to be provided in the form of physician details (identifying the physician), patient details (identifying the ART patient), and biological material details (identifying the biological material in the packaging device 126). The input device 112 can provide instructions to the physician via the user interface 116. The physician enters the details using the user interface 116, and the input device 112 transmits the entered status information to the coordination system 108. The coordination system 108 processes the received status information. The processing includes verifying the status information to determine whether the physician details, patient details, and biological material are valid for the smart contract 124. In this example, the verification may include querying the blockchain to confirm that the biological material matches the corresponding biological material stored on the blockchain. If the verification is successful, the coordination system 108 determines that the entered physician details, patient details, and biological material are to be stored on the blockchain. If the validation fails, the coordination system 108 notifies the physician that the validation failed and instructs the input device to request new input. The coordination system 108 may save a copy of the received status information in the data lake 128. Once processed, the coordination system 108 stores the status information in the blockchain (using the same steps as described above in Example 1).

[0325] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies that subprocess 8.1 is complete. Because smart contract 124 indicates that the next subprocess to accomplish is subprocess 8.2, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 8.2, in the same manner as described above in Example 1.

[0326] Based on the current status of sub-process 8.2, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions of sub-process 8.2, which in this example causes processor 110 to:

[0327] In subprocess 8.2, the coordination system 108 instructs the input device 112 to notify the physician that the physician and / or patient must provide security check information for the biological material to be used in the ART procedure. The security check information may include a password and / or biometric information, such as a retinal or fingerprint scan, to verify the identity of the physician and / or patient. The input device 112 may provide instructions to the physician via the user interface 116. Details are entered (if necessary) by the physician and / or patient using the user interface 116 (which may be configured to retrieve biometric information), and the input device 112 sends the entered status information to the coordination system 108. The coordination system 108 processes the received status information. The processing includes verifying the status information to determine that the security check information is valid against the smart contract 124. If the verification is successful, the coordination system 108 decides to save the successful verification on the blockchain. If the verification is unsuccessful, the coordination system 108 notifies the physician that the verification failed, instructs the input device to request new input, and decides to save the failed verification on the blockchain. Once processed, the coordination system 108 stores the associated success or failure of the validation in the blockchain (using the same steps as described above in Example 1).

[0328] Upon receiving confirmation from the gatekeeper that the data has been stored on the blockchain, coordination system 108 identifies that subprocess 8.2 is complete. Because smart contract 124 indicates that the next subprocess to accomplish is subprocess 8.3, coordination system 108 writes to the blockchain to update the current status of smart contract 124 to subprocess 8.3, in the same manner as described above in Example 1.

[0329] Based on the current status of sub-process 8.3, coordinate system 108 queries data store 114 to retrieve executable instructions. In response, coordinate system 108 receives and executes the executable instructions of sub-process 8.3, which in this example causes processor 110 to:

[0330] In sub-process 8.3, coordination system 108 instructs input device 112 to notify the physician to perform the ART procedure, for example, through a message displayed on user interface 116. Coordination system 108 then identifies that milestone 8, sub-process 8.3, and therefore the entire ART process defined by smart contract 124, is complete.

[0331] The reference herein to any prior publication (or information derived therefrom) or publicly known matter is not an acknowledgement or suggestion that the prior publication (or information derived therefrom) or publicly known matter forms part of the general knowledge in the field of endeavor to which this specification pertains. [Prior art documents] [Patent documents]

[0332] [Patent Document 1] Australian Provisional Patent Application No. 2021904254

Claims

1. 1. A method for controlling the handling of biological material by a plurality of biological material handling devices, the method being implemented by a processor executing computer program instructions stored in a memory, the method comprising: receiving, from any of a first device of the plurality of devices, a device associated with a user interface for inputting data related to the biological material, and a biological material packaging device, status information for the biological material and identification information identifying a smart contract related to the biological material; using the identification information to query a cryptographically secured distributed ledger to retrieve the smart contracts associated with the biological material, including their current status; querying a data store to retrieve executable instructions based on the retrieved smart contract and its current status, wherein the data store is not a secure distributed ledger; and executing the executable instructions to cause the processor to at least process the status information, the processing including verifying the status information and determining one or more portions of the status information to store in the distributed ledger; writing to the distributed ledger, storing the determined one or more portions of the status information, and updating the status of the smart contract; A method for providing the above.

2. The method of claim 1 , wherein executing the executable instructions further comprises causing the processor to store the received status information in a data lake.

3. The method of claim 1 or 2, wherein the status information includes monitoring information of the biological material.

4. The method of claim 3 , wherein the monitoring information includes at least one of temperature monitoring information, position monitoring information, volume monitoring information, and cell count monitoring information.

5. The method of claim 1 , wherein the status information includes information regarding one or more previous handling steps performed in connection with the biological material.

6. The biological material whole blood, Blood components, stem cells, modified cells, Gametes, organs, and organization The method according to any one of claims 1 to 5, comprising at least one of:

7. Executing the executable instructions causes the processor to: determining one or more commands or one or more computer-executable instructions to be executed by a second device of the plurality of devices; sending the command or the computer-executable instructions to the second device; The method according to any one of claims 1 to 6, further comprising:

8. The commands or computer-executable instructions are for controlling the second device, the second device comprising: a cryopreservation device for cryopreserving said biological material; a thawing device for thawing said biological material; a transport device for transporting said biological material; a storage device for storing the biological material; and A cell counting device for counting cells of said biological material The method according to claim 7, wherein the

9. 9. The method of claim 1, wherein at least one device of the plurality of devices is configured to host at least one node of the distributed ledger.

10. 10. The method of claim 9, wherein the method includes determining that the second device has sufficient processing and storage capabilities to host the at least one node and execute the one or more commands or computer-executable instructions, and in response, allowing the second device to host the at least one node.

11. The method comprises: receiving historical status information and historical identification information from at least one of the first biological material handling device and the biological material packaging device; comparing the historical status information and historical identification information with previously received status information and identification information to determine whether the previously received status information should be updated with the historical status information; updating the previously received status information by storing an additional entry in the distributed ledger that records the historical status information in response to determining that the previously received status information should be updated with the historical status information; 11. The method of any one of claims 1 to 10, comprising:

12. The method comprises: receiving historical status information and historical identification information from at least one of the first biological material handling device and the biological material packaging device; determining from the history identification information that the history status information has not been previously received; storing the historical status information in the distributed ledger; 9. The method of any one of claims 1 to 8, comprising:

13. 10. A method for controlling the handling of extracted biological material from initial extraction to final use, wherein the handling comprises a plurality of stages, the method comprising, at a plurality of the stages, carrying out the method of any one of claims 1 to 7.

14. 14. The method of claim 13, wherein the method of any one of claims 1 to 7 is performed in each of the stages.

15. 1. A system for controlling the handling of biological material, comprising: a plurality of biological material handling devices; a coordinating system including a processor for executing computer program instructions and a memory for storing computer program instructions to be executed by said processor; a cryptographically secured distributed ledger that stores smart contracts related to said biological material; a secure non-distributed ledger data repository for storing searchable computer-executable instructions; Equipped with The computer program instructions stored in the memory, when executed by the processor, cause the coordinate system to: retrieving status information of the biological material and identification information identifying the smart contract from any of a first device of the plurality of devices, a device associated with a user interface for inputting data related to the biological material, and a biological material packaging device; querying the distributed ledger using the identifying information to retrieve the smart contract and its current status; instructions to query the data store based on the smart contract and a current status to retrieve computer-executable instructions; The computer-executable instructions stored in the data storage location, when executed by the processor, cause the coordinate system to: processing the status information by verifying the status information and determining a portion or portions of the status information to store in the distributed ledger; instructions to write to the distributed ledger, store the determined portion or portions of the status information, and update the status of the smart contract; A system characterized by:

16. 1. A coordination system for controlling the handling of biological material, the coordination system comprising: at least one processor; a memory storing computer program instructions that, when executed by the at least one processor, cause the coordination system to perform the method of any one of claims 1 to 14; A coordination system comprising:

17. A non-transitory machine-readable storage medium having computer program instructions that, when executed by at least one processor of a coordination system, cause the coordination system to perform the method of any one of claims 1 to 14.

Images