Blockchain-enabled consent management for biobanking with generative artificial intelligence (AL)

Abstract

Methods and systems for managing consent and usage history of biological samples are provided. An identifier corresponding to a first entity providing a biological sample is associated with data characterizing a set of consent parameters and a usage history of the biological sample. The set of consent parameters and the usage history are posted on a blockchain. In response to receiving a request from a second entity to access the biological sample for processing, the usage history on the blockchain is updated to record the access to the biological sample and / or the processing of the biological sample based on the set of consent parameters associated with the identifier. The first entity is then provided with access to a user interface. The user interface is configured to present, upon receiving a query from the first entity, a response describing the updated usage history of the biological sample to the first entity.

Description

Docket No.: 061935-502001 WOBLOCKCHAIN-ENABLED CONSENT MANAGEMENT FOR BIOBANKING WITH GENERATIVE ARTIFICIAL INTELLIGENCE (Al) CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of priority from U.S. Provisional Patent Application No. 63 / 688,145, filed on August 28, 2024, and entitled, “DEMONSTRATED CONSENT,” the contents of which are hereby fully incorporated by reference.TECHNICAL FIELD

[0002] The present disclosure generally relates to decentralized consenting and artificial intelligence / machine learning (AI / ML).BACKGROUND

[0003] Medical research often relies on access to patient genomics to develop therapies and treatment regimens that can be tailored to individual patients. Typically, patient genomics information can be derived from biological samples such as blood, tissue, or other biospecimens provided by patients in clinical settings. In some cases, biobanks can be used as repositories for the collection, storage, and distribution of such biological samples and associated data for use in such medical research and therapeutic development.SUMMARY

[0004] An example implementation of the subject matter described within this disclosure is a method with the following features. An identifier corresponding to a first entity providing a biological sample is associated with data characterizing a set of consent parameters and a usage history of the biological sample. The set of consent parameters and the usage history are posted on a blockchain. In response to receiving a request from a second entity to access the biological sample for processing, the usage history on the blockchain is updated to record the access to the biological sample and / or the processing of the biological sample based on the set of consent parameters associated with the identifier. The first entity is then provided with access to a user interface. The user interface is configured to present, upon receiving aDocket No.: 061935-502001 WO query from the first entity, a response describing the updated usage history of the biological sample to the first entity.

[0005] The disclosed method can be implemented in a variety of ways. For example, within a system that includes at least one data processor and a non-transitory memory storing instructions for the processor to perform aspects of the method. Alternatively or in addition, the method can be included in non-transitory computer readable memory storing the method as instructions which, when executed by at least one data processor forming part of at least one computing system, causes the at least one data processor to perform operations of the method.

[0006] Aspects of the example method, that can be combined with the example method alone or in combination with other aspects, can include the following. The first entity can include a donor of the biological sample. The second entity can include a research institution or a laboratory requesting the access to the biological sample.

[0007] Aspects of the example method, that can be combined with the example method alone or in combination with other aspects, can include the following. The set of consent parameters can be posted as metadata associated with a non-fungible token (NFT) representing the biological sample on the blockchain, the NFT being linked to the identifier corresponding to the first entity. In some implementations, the set of consent parameters can define allowable biological sample use granted by the first entity.

[0008] Aspects of the example method, that can be combined with the example method alone or in combination with other aspects, can include the following. The usage history can include metadata describing the second entity, the access to the biological sample, the processing of the biological sample, and a timestamp associated with the access or the processing of the biological sample.Docket No.: 061935-502001 WO

[0009] Aspects of the example method, that can be combined with the example method alone or in combination with other aspects, can include the following. When updating the usage history of the biological sample, the request can be evaluated against the set of consent parameters to determine whether the access or processing of the biological sample is granted. In some implementations, evaluating the request can include executing a smart contract configured to compare attributes of the request with the set of consent parameters. In some implementations, the smart contract can be configured to initiate a transmission of the biological sample to the second entity in response to the determination that the request is granted. The transmission of the biological sample can trigger a predetermined amount of payment to be sent from the second entity to the first entity.

[0010] Aspects of the example method, that can be combined with the example method alone or in combination with other aspects, can include the following. The query can be a natural language query, and the response can include natural language responsive to the natural language query. In some implementations, the user interface can be in communication with a generative model trained to produce the response. In some implementations, the generative model include a large language model (LLM). In some implementations, the generative model can implement a retrieval-augmented generation (RAG) architecture. In some implementations, the query from the first entity can include information indicative of a reading level associated with the first entity. In some implementations, the response can include an explanation of at least a portion of the updated usage history to the first entity in natural language produced based at least in part on the reading level. In some implementations, the response can include a graphical representation of the usage history of the biological sample.

[0011] Aspects of the example method, that can be combined with the example method alone or in combination with other aspects, can include the following. The first entity can be notified of subsequent updates to the user history via the user interface. In someDocket No.: 061935-502001 WO implementations, the second entity can be provided with access to the user interface as well. The user interface can be configured to present, upon receiving a query from the second entity, a response describing the set of consent parameters.

[0012] Aspects of the example method, that can be combined with the example method alone or in combination with other aspects, can include the following. The NFT representing the biological sample on the blockchain can be burned in response to receiving, at the user interface, a request to modify one or more consent parameters within the set of consent parameters from the first entity. Modifying the one or more consent parameters can include revoking the access to the biological sample.DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, show certain aspects of the subject matter disclosed herein and, together with the description, help explain some of the principles associated with the disclosed implementations. In the drawings,

[0014] FIG. 1 is a flow chart of an example method that can be used with aspects of this disclosure;

[0015] FIG. 2 is an example user interface that can be used with aspects of this disclosure;

[0016] FIG. 3 is an example user interface that can be used with aspects of this disclosure;

[0017] FIG. 4A is a block diagram of an example system that can be used with aspects of this disclosure;

[0018] FIG. 4B is a block diagram of an example system that can be used with aspects of this disclosure;Docket No.: 061935-502001 WO

[0019] FIG. 4C is a block diagram of an example system that can be used with aspects of this disclosure;

[0020] FIG. 4D is a block diagram of an example system that can be used with aspects of this disclosure; and

[0021] FIG. 5 is a block diagram of an example computing system that can be used with aspects of this disclosure.

[0022] When practical, like labels are used to refer to same or similar items in the drawings. It is noted that the drawings are not necessarily to scale. The drawings are intended to depict only typical aspects of the subject matter disclosed herein and therefore should not be considered as limiting the scope of the disclosure.DETAILED DESCRIPTION

[0023] Effective medical practice and the advancement of biomedical knowledge depend on high quality biomedical research. In modern biomedical research, biological samples and associated data are increasingly utilized to enable precision medicine and to accelerate the development of therapeutic and diagnostic tools. Typically, the research often begins with the collection of biological samples from individuals, followed by processing, storage, and eventual distribution of these samples to research entities for specific studies e.g., genomics, proteomics, metabolomics, etc. Biobanks are sometimes used to store and manage these samples, providing researchers with access to resources for these studies.

[0024] Such biomedical research can involve risks which participants may not be able to foresee. Professional norms, ethical and regulatory codes, as well as domestic and international law all recognize duties not to subject anyone to medical experimentation unless, among other criteria, they have given valid consent: i.e., permission or agreement that is voluntary (e.g., free from coercion) and based on an adequate understanding of the risks and benefits involved. For example, participants are informed of the details of a particular researchDocket No.: 061935-502001 WO study, including for example, its objectives, methods, potential risks, and anticipated benefits, and provide authorization before their samples can be used in that study. However, in a biobanking environment, biological samples may remain in storage for extended periods, and their eventual uses are often unknown at the time of collection. This disconnect between sample collection and sample utilization creates administrative burdens for biobanks, slows research progress, and limits the ability of participants to remain informed about how their samples are being used.

[0025] Various alternative consent models have been proposed to address these challenges in the biobanking context, such as broad consent, tiered consent, meta-consent, dynamic consent, among others. While these models provide participants with greater flexibility and transparency regarding the use of their samples, they also exhibit practical and ethical limitations. For example, the dynamic consent model relies on frequent donor interaction with digital interfaces (e.g., Web 2.0 interactive webpages) to manage preferences and authorize new research uses. Over time, such repeated interactions can lead to “consent fatigue,” a phenomenon where participants become desensitized or disengaged due to the cognitive and administrative burden of managing consent requests. Consent fatigue can reduce the quality of consent decisions and, in some cases, undermine trust between participants and research organizations.

[0026] Additionally, existing systems often fail to provide an easily accessible, verifiable, and up-to-date record of how a donor’s samples are being used. Participants may have limited visibility into the types of research being conducted, the institutions accessing their samples, or the outcomes of studies leveraging their contributions. Such lack of transparency can create information asymmetries that hinder participant engagement, complicate compliance with evolving regulatory frameworks, and impede efforts to foster inclusivity and equity in biomedical research.Docket No.: 061935-502001 WO

[0027] Accordingly, methods and systems for managing consent and tracking the usage of biological samples are provided in the present disclosure. In general, an identifier of a donor can be associated with a digital representation of the donor’s biological sample, such as a token recorded on a blockchain. Consent parameters associated with the biological samples can be stored as metadata linked, via the identifier, to the token, and a record of each subsequent access or processing event can be maintained on the blockchain as part of a usage history. Through a user interface, donors can submit queries and receive response regarding how their samples have been or are being used.

[0028] The subject matter as described herein does not require donors to actively manage their consent preferences on an ongoing basis, at least in part because the subject matter provides a secure, transparent, up-to-date, and easily accessible repository of information that donors can engage with at their own pace and to the extent that they wish. In this way, the subject matter as described herein can enable, under the biobanking environment, the donors to make informed decisions about their participation in biomedical research without the risk of choice overload or consent fatigue. The participant would still have their initial willingness to participate in biomedical research assessed by a human researcher.

[0029] Additionally or alternatively, the subject matter as described herein can also streamline operations for research institutions, laboratories, or data analytics facilities, by providing immediate, verifiable access to up-to-date donor consent records. Because the consent parameters associated with each biological sample are securely stored on the blockchain. This provides researchers with a single, synchronized source of truth, allowing them to initiate biomedical research without administrative delays or friction typically associated with re-confirming consent through manual channels.

[0030] FIG. 1 is a flow chart of an example method 100 that can be used with aspects of this disclosure. At 102, an identifier corresponding to a first entity can beDocket No.: 061935-502001 WO associated with data characterizing a set of consent parameters and a usage history of a biological sample provided by the first entity. The identifier can uniquely identify the first entity while preserving anonymity or pseudonymity through encryption or other privacypreserving techniques. In some implementations, the identifier can be generated as a cryptographic hash value derived from attributes or registration information associated with the first entity using a one-way hash function. In some implementations, the identifier can be implemented as a globally unique identifier (GUID), a public / private key pair, an IP address, or the like.

[0031] The biological sample can be a human-, animal-, microorganism-, microbe-, or plant-based biological sample, including but not limited to healthy or diseased specimens. The biological sample can include a biospecimen obtained from the first entity. The first entity can be a donor that is a living or dead human, animal, or plant, including organs, cells, tissues, internal fluids, solid and fluid excrements, gametes, follicles, bones, or components of these, including proteins or molecules, or pathogens, microorganisms, or microbes that were obtained from these, including viruses, bacteria, and parasites. In some implementations, the biological sample can be obtained from the integumentary, skeletal, muscular, nervous, endocrine, cardiovascular, lymphatic, respiratory, digestive, urinary, and / or reproductive systems, etc., or from roots, stems, flowers, fruits, seeds, leaves, etc.

[0032] The set of consent parameters can define one or more rules governing the allowable use, handling, or distribution of the biological sample and any associated data. In some implementations, the set of consent parameters can be configured as user-defined settings that allow the first entity to specify, with granularity, how their sample can be used throughout its lifecycle. For example, the consent parameters can include binary or multilevel preferences, such as “AGREE” or “DISAGREE,” “ON,” or “OFF,” or tiered selections that correspond to specific usage rules. Each user preference can be linked to a respectiveDocket No.: 061935-502001WO operational condition, such as predefined categories of permitted research (e.g., cancer research, rare disease studies, or population genomics), restrictions on specific applications or types of studies (e.g., commercial drug development vs. non-commerci al academic research), conditions for secondary use (e.g., data sharing with third parties), or requirements for additional authorization prior to biological sample processing or transfer. In some implementations, the consent parameters can also encode additional rules, such as temporal constraints (e.g., expiration dates or allowable use duration), geographic or institutional restrictions (e.g., limited to approved facilities or jurisdictions), preferred modes of communication with the first entity for notifications or updates, and the like.

[0033] The usage history can represent a time-stamped, verifiable log of access events, processing activities, and other operations performed on or with the biological sample. In some implementations, the usage history can include metadata describing one or more second entities that accessed the sample. Exemplary second entities can include research institutions or organizations, laboratories, pharmaceutical companies, diagnostic service providers, governmental or regulatory agencies, and / or data analytics facilities. The usage history can also include details of material transfers, such as transfer dates, shipping information, and confirmation of receipt, as well as information related to derived data product generated from the biological sample. In some implementations, the usage history can include information describing the type of analyses performed and results generated from the use of the sample. Each second entity can be uniquely identified within the system, for example, by a digital certificate, digital signature, or any other cryptographic identifier that can be used to trace part or all transactions involving the biological sample.

[0034] As indicated above, to enable transparency and traceability of biological samples, as well as any transactions associated with each stored biological sample that can be transferred between biobanks or second entities, donated biological samples can be stored asDocket No.: 061935-502001 WO digital representations, such as non-fungible tokens (NFTs), on a blockchain. The Blockchain can operate as a decentralized, append-only ledger maintained across multiple nodes. In some implementations, the NFTs can be defined according to standardized protocols, such as the ERC-721 or ERC-1155 token standards. Each NFT can include metadata describing the biological sample, such as the identifier, sample information, consent parameters and usage history associated with the identifier, including for example, storage location, processing status, and links to any derived datasets or analytical results. The metadata can be cryptographically signed and, in some implementations, encrypted using symmetric or asymmetric encryption algorithm. For example, public-key cryptography can be used such that only authorized entities holding the corresponding private key can decrypt sensitive portions of the metadata.

[0035] The creation, or “minting,” of the NFT representing the biological sample can occur automatically upon the registration of the sample within a connected biobank system. For example, when the first entity, such as a donor or participant, provides a biological sample to the biobank, information describing the physical specimen may be stored in a laboratory information management system (LIMS) or equivalent inventory management platform. The LIMS system can communicate with the blockchain network through one or more integrated application programming interface (API), triggering the generation of a unique NFT that represents the donated biological sample. This NFT's metadata can encode information about the sample, including its characteristics, physical storage location, and donor consent preferences (e.g., consent parameters) using a standardized schema, which is available for the donors to see. To this end, donors or participants can access information about their biological samples and their actual usage within studies (as opposed to only general information about the study compared to conventional consent models).Docket No.: 061935-502001 WO

[0036] Continuing the example, the association of the identifier with the consent parameters and usage history as described herein can occur at the point of registering the biological sample within the biobank system, typically concurrent with or immediately following the minting of the NFT representing the sample. An immutable record that securely links the biological sample to the metadata representing the scope and terms of consent granted by the first entity, as well as any existing history of the biological sample’s usage can be generated on the blockchain, if applicable. Such association can include cryptographically binding the identifier of the first entity to the corresponding NFT through secure hashing or other encryption techniques as described herein. In some implementations, the set of consent parameters, as configured by the first entity, can be serialized into a structured schema, such as a JSON- or XML-based data format, and stored as on-chain metadata associated with the NFT. In some implementations, an initial usage history entry can be generated to record the creation event of the NFT. In some implementations, the consent parameters can be dynamically updated upon receiving instructions from the donor or an authorized representative, with each modification posted as a new record on the blockchain. For example, each subsequent modification to the consent parameters or update to the usage history can trigger a new blockchain transaction.

[0037] Additionally or alternatively, when creating the NFT representing the biological sample, instead of minting a single NFT to represent the entirety of the biological sample, a batch of tokens can be generated, each representing a fractional interest or share in the original sample. Each token within the batch can correspond to a discrete portion of the biological material or its derived data. In some implementations, the batch of tokens can represent the dispersion of sample ownership or custodianship resulting from biological or logistical processes. For example, when an immortalized cell line derived from the original sample is cloned, each derivative line can be linked to a corresponding fractional token in theDocket No.: 061935-502001 WO batch. Similarly, when a fixed-volume aliquot of biological material (e.g., plasma, tissue homogenate, or DNA extract) is split into multiple portions for use in separate studies, each portion can be uniquely represented by a token within the batch. These fractional tokens can share common metadata attributes inherited from the parent NFT, such as the donor identifier and the set of consent parameters. Individualized metadata describing specific attributes of the fraction (e.g., its volume) can also be included.

[0038] At 104, the usage history can be automatically updated in response to receiving a digitally signed, authenticated request from the second entity. The request can be initiated by the second entity (e.g., research laboratory, sequencing center, or data analytics facility), and transmitted to a blockchain-enabled consent management platform through a communication channel (e.g., HTTPS with TLS encryption or API integration). The request can be submitted via an integration layer that interfaces with LIMS system or other electronic data capture (EDC) systems. In some implementations, the request includes structured data packets identifying the biological sample (e.g., by the identifier), the intended processing task, and relevant compliance information, such as protocol details, required credentials, or IRB approvals. For example, a request can include a transfer request to physically ship a stored biological sample from a biobank storage facility to a research laboratory for genomic sequencing or proteomic analysis. In another example, the request can involve a query to access metadata associated with the NFT representing the biological sample, such as sequencing files or derived molecular profile, without requiring the physical transfer of the biological sample. Other types of requests, such as request for aliquoting a portion of the sample, performing specific computational analyses, or conducting collaborative studies across multiple entities are also contemplated herein.

[0039] Upon receipt of the request, an evaluation and validation process can be performed to ensure compliance with the set of consent parameters associated with theDocket No.: 061935-502001 WO biological sample. In some implementations, the evaluation and validation process can include 1) verifying the authenticity and integrity of the request using cryptographic signatures; and 2) confirming that the requested activity conforms with the set of consent parameters stored in association with the NFT metadata of the biological sample. This can involve comparing attributes of the request (e.g., the type of proposed research, the nature of the data or biological sample requested, and the identity of the requesting second entity) against the set of consent parameters, for example, verifying that the type of research request falls within donor-approved categories, that the second entity is authorized, and that no temporal, geographic, or ethical restrictions have been violated. In some implementations, the evaluation and validation process can also include checking authorization levels of the second entity against a list of access rules.

[0040] In some implementations, the evaluation and validation process can be executed across distributed nodes of the blockchain network in coordination with off-chain processing modules, such as rule engines or policy decision points (PDPs). These off-chain modules can perform computationally intensive validations, such as matching the request parameters with consent parameters or regulatory compliance databases and then return a cryptographically signed decision to the blockchain ledger for consensus recording. If the request passes validation, the usage history can be updated on-chain to record the transaction, including time-stamped details of the request, processing event, information identifying the second entity, and the like. Conversely, if the request fails any validation or compliance check, the request can be automatically denied. The usage history can also be updated to record such denial events for additional transparency. In some cases, a notification can be generated and sent to the second entity and the first entity via a user interface as described below or other linked communication channels (e.g., secure messaging APIs or mobile applications).

[0041] The update can be performed by LIMS system, clinical trial management systems (CTMS), or other off-chain data management platforms that are synchronized with theDocket No.: 061935-502001 WO blockchain ledger. For example, when a research laboratory initiates a sequencing run on a biological sample, the LIMS system can automatically generate an event record describing the date and time of processing, the type of assay performed, relevant quality control parameters, and any associated data outputs. Before the event record is finalized and appended to the blockchain ledger as a new block, the evaluation and validation process, such as a compliance check against the consent parameters associated with the biological sample can be automatically executed by a software program which interacts with the information contained in the blockchain. In some implementations, a self-executing program deployed on the blockchain which enforces the consent parameters without requiring manual or centralized intervention. Such program can include, for example, a smart contract configured to parse the metadata embedded in the event record and compare the parsed metadata against the consent parameters.

[0042] As different second entities request access to the biological samples, respective smart contracts can automatically verify that the requested usage aligns with the donors' consent preferences as indicated by consent parameters associated with the donors’ identifiers corresponding to the NFTs. If the conditions are met, access to the biological samples is granted, and the biological samples can be securely shared between biobanks using the blockchain infrastructure. Sharing biological samples can include a transmission of the biological sample to the second entity. This can trigger creations of time-stamped, cryptographically signed entry in the blockchain ledger. Integrations with shipping information and bio-monitoring systems can hold the biological sample NFT in escrow until the physical sample arrives at the corresponding biobank. In some implementations, at least a portion of the smart contract can be configured to execute, simultaneously or immediately after the grant of access, a transfer of certain rewards, for example, a predetermined monetary value or predetermined amount of payment from the second entity to the first entity (e.g., the donor),Docket No.: 061935-502001 WO either through a traditional payment channel or via a blockchain-based transaction. This can incentivize continued donor participation and engagement in biobanking programs.

[0043] For example, the smart contract can interface with external financial institutions and systems for fiat currency settlement. In such implementations, the blockchain ledger can trigger an API call to a financial institution or payment processor to wire the reward amount, from second entity’s bank account to the donor’s bank account. In another example, the reward can be tokenized using the same blockchain infrastructure that maintains the consent parameters and usage history. The smart contract can mint or transfer fungible tokens (e.g., ERC-20 tokens) or NFTs representing credits or vouchers that can be redeemed for monetary value, research-related services, or other benefits. The payment can be transmitted to a donor- associated blockchain wallet address that was previously linked to the donor’ s identifier during registration. In some cases, the monetary value or amount of payment can be fixed, dynamically calculated based on the scope or type of processing, or determined according to a predefined, tiered reward structure reflecting the research utility or rarity of the biological sample. The use of smart contracts streamlines the process of data sharing and collaboration, while ensuring that donors' wishes are respected and regulatory requirements are met.

[0044] As indicated above, the blockchain keeps track of all requested and granted transfers as well as downstream uses of donated samples. As samples are transferred or used in research studies, the associated NFTs are updated with metadata (e.g., usage history) or records about each usage by the second entity, for example, via the lab’s LIMS system. At 106, first entities e.g., sample donors can be provided with access to a user interface. The user interface can allow sample donors to access such records. In this way, the sample donors can effectively track the uses to which their samples are or will be put. The user interface can also enable sample donors to update their consent parameters or to withdraw from individual, planned studies.Docket No.: 061935-502001 WO

[0045] In some implementations, the user interface can be displayed via a user device, such as cellular phones, smart phones, tablet computers, laptop computers, desktop computers, workstations, personal digital assistants (PDA), network appliances, cameras, enhanced general packet radio service (EGPRS) mobile phones, media players, navigation devices, email devices, game consoles, or an appropriate combination of any two or more of these devices or other data processing devices. In some implementations, the user interface can be a web-based portal or a native software application that communicates with the blockchain- enabled backend through one or more APIs (e.g., REST, GraphQL, or gRPC).

[0046] For example, as shown in FIG. 2, the first entity can be provided with access to a donor portal 200. The donor portal 200 can include multiple control buttons 202, 204, a header 206, and a biological sample data panel 208. The control buttons 202, 204 can be configured to provide access to information describing the first entity e.g., donor data. The control buttons 202, 204 can include a profile control button 202 and a donation control button 204. The profile control button 202 can be configured to provide access to the profile data of the authenticated donor. The donation control button 204 can be configured to provide access to donation data associated with the authenticated donor. The donation data can include names of donated materials (electronic biospecimens and / or biological samples), date of donation, and consent forms associated with the donations.

[0047] The header 206 can include multiple tabs 210A, 210B that can be allocated to overall information associated with the donations (e.g., biological samples) of the respective first entity. In some implementations, the tabs 210A, 210B can include statistical information (numerical data) derived from the data associated with the donations of the respective donor and textual identifiers (names) of the statistical information. For example a first tab 210A can include information related to “lives impacted” by the donations and a second tab 210B can include information related to the number of studies performed using the donations.Docket No.: 061935-502001 WO

[0048] As illustrated in FIG. 2, the biological sample data panel 208 can include an assembly grouped biological sample data 212A, 212B, 212C and control buttons 214, 216. The assembly grouped biological sample data 212A and 212B enables simultaneous display and visualization of data related to multiple donated biological samples. Each of the grouped biological sample data 212A, 212B can include data associated with a single (particular) biological sample. Each of the grouped biological sample data 212A, 212B can include a textual identifier 218A, 218B (name or alphanumeric code), location data 220A, 220B, and study data 222A, 222B associated to the respective biological sample.

[0049] It should be understood that the complexities of biobanking consent can involve details concerning genetic information privacy, data protection, research programs and implications, and ethical considerations that may not be readily accessible to individuals without domain-specific regulatory and scientific training. In many cases, the consent language, in its original form, is dense and highly technical in nature, making it difficult for donors to fully comprehend the implications of their consent without assistance from experts in the field. To this end, the user interface as described herein (e.g., the donor portal 200) can be integrated with a support module. The support module can be implemented as a software- and service-based framework that provides donors with interactive assistance such as navigating the user interface, understanding one or more consent terms, providing the sample usage history, and the like. In some implementations, the support module can include automated assistance tools e.g., chatbots. Alternatively or in addition, the support module can include human-operated components. The human-operated components can include support personnel, system administrators, or other authorized users familiar with various data as described above. The support module is described in further detail below with reference to FIG. 3.Docket No.: 061935-502001 WO

[0050] As illustrated in FIG. 2, the donor portal 200 can include a control button 224 that, when actuated, establishes a secure communication channel between the donor and the support module. In some implementations, the control button 224 can include a chat button 224 that launches an interactive messaging interface integrated within the donor portal 200. The interactive messaging interface can be opened as a pop-up window, side panel, or dedicated page, enabling secure, encrypted communication (e.g., via TLS) between the donor and the support module. The interactive messaging interface can support multiple communication modes, including live text messaging, asynchronous messaging for delayed responses, and in some cases, voice or video channels for more complex interaction.

[0051] FIG. 3 illustrates an example interactive messaging interface 300. The interactive messaging interface 300 can include a chat window 302 displaying responses 304 A, 304B from the support module 306 and submissions 308 from the first entity 310 (e.g., the donor). Various controls e.g., control buttons 312, 314, and an input field 316 can be positioned adjacent to the chat window 302. The input field 316 can be configured to enable an entry of inputs from the donor, including, for example, queries to retrieve information regarding consent parameters and / or usage history associated with the biological sample, commands to update consent preferences (e.g., toggling approval or disapproval), modify temporal constraints, authorize or revoke access for specific second entities, and the like. These inputs can be transmitted to the support module 306 for processing via the control button 312. The control button 312 can include a send control button 312. The control button 314 can include an upload control button 314 to enable file sharing. For example, the donor can upload documents such as signed consent forms, authorization letters, feedback forms, or scanned identification documents for identity verification. Other attachments, such as laboratory reports, medical summaries, and correspondence with the second entity are also contemplated herein.Docket No.: 061935-502001 WO

[0052] In some implementations, the support module 306 can be implemented as a chatbot system having Al processing capability. The chatbot system can be operated by way of one or more user devices and networks, such as internet, short message service (SMS), and multimedia message service (MMS). The interactive messaging interface 300 can be configured to facilitate interaction of the donor with the support module 306 conversationally, by way of at least a submission 308 from the interactive messaging interface 300 to the support module 306, and one or more responses 304 A, 304B from the support module 306 to the interactive messaging interface 300. For example, the donor can submit a submission, such as a query or request through the interactive messaging interface 300, using the input field 316 and the send control button 312. The support module 306 can generate and return one or more responses including, for example, guidance related navigating the user interface, definitions and / or interpretations to one or more consent terms, updates in the sample usage history, and the like to be presented at the interactive messaging interface 300 via the chat window 302.

[0053] In some implementations, one or both of the submission 308 and the responses 304 A, 304B can be text-based communication, image-based communication, audio-based communication, or any combination thereof. In some cases, one or both of the submission 308 and the responses 304 A, 304B include one or more attachments as described above. In some implementations, the support module 306 can be configured to retrieve a pre-parsed response from at least a storage component (e.g., a database or a memory) based upon the submission 308. Alternatively or in addition, the support module 306 can communicate the response 304 A without first receiving the submission 308 from the interactive messaging interface 300, thereby initiating a conversation. For example, the support module 306 (e.g., chatbot) can communicate an inquiry to the interactive messaging interface 300; and the support module can be configured to process an answer to the inquiry in one or more following submissions from the interactive messaging interface 300.Docket No.: 061935-502001 WO

[0054] In some cases, the support module 306 can be powered by a language processing module configured to extract from the submission 308 one or more words (tokens) including strings of one or more characters, for example, any sequence or sequences of letters, numbers, punctuations, diacritic marks, engineering symbols, formulas, and the like. In some instances, the submission 308 and / or data received by the support module 306 can include textual data that can be parsed, using the language processing module, into “n-grams”, where all sequences of n consecutive characters are considered. Any or all possible sequences of tokens or words can be stored as “chains,” for example, for use as a language model, such as a Markov chain or a Hidden Markov Model.

[0055] Additionally or alternatively, the support module 306 can include a machine learning program e.g., a generative model configured to produce associations between one or more words extracted from the received data. For example, associations between language elements include mathematical associations, such as statistical correlations between any language elements and any other language elements representing a likelihood that a given extracted word indicates a given category of semantic meaning. In some implementations, mathematical associations and / or statistical correlations include probabilistic relationships indicating a positive and / or a negative association between at least an extracted word and a given semantic meaning. Whether a word, a phrase, a sentence, or other textual element in the submission 308 constitutes a positive or negative indicator may be determined by mathematical associations between detected words and comparisons to phrases and / or words indicating positive or negative indicators that are stored in the storage component.

[0056] It can be appreciated that the generative model can include a large language model (LLM) that operates on a dedicated backend Al processing server or cluster (either onpremises or in the cloud) that communicates with the blockchain-enabled consent management platform. The LLM can include a machine learning-based model specifically trained for naturalDocket No.: 061935-502001 WO language understanding and generation. The LLM can process submission 308 and provide responses 304A, 304B in natural language. In some cases, the LLM can be a transformer-based architecture, for example, GPT or BERT. The LLM can include multiple layers of attention mechanisms and dense neural networks, enabling the support module 306 to analyze input queries, extract tokens and match them with semantic meaning, and generate responses 304 A, 304B based on its training. In some implementations, the LLM is pre-trained on one or more large datasets, including biomedical literature, clinical trial registries, general language corpora, etc., and fine-tuned using domain-specific data related to biobanking, biobanking consent, data privacy regulations, research terminology related to specific studies, and the like.

[0057] It should be noted that the LLM does not directly write to the blockchain but instead can interface with smart contract APIs or blockchain middleware as described herein. For example, in response to a donor query submitted through the interactive messaging interface 300, such as “How has my biological sample been used over the past six months?”, the LLM can securely communicate with the blockchain middleware to retrieve the usage history associated with donor’s identifier corresponding to donor’s biological sample NFT. Event data such as information related to access requests, processing actions, sample transfers, and derived datasets can be extracted from the distributed ledger. The event data can be passed to the LLM. The LLM can then generate a plain-language response for the donor, such as “Your biological sample was accessed by Research Lab A in March 2025 for genomic sequencing related to an oncology study and by Data Analytics Center B in May 2025 for computational analysis. No additional usage has been recorded since that date.”

[0058] In some implementations, the responses 304A, 304B provided to the donor be produced based on the donor’s reading level or other communication preferences, as determined during user onboarding or inferred through prior interactions with the user interface. Continuing the example, the response can be simple or enriched depending on theDocket No.: 061935-502001 WO profile data. For instance, a donor with an elementary school reading level preference can receive “Your sample was used in two studies this year - one in March for a cancer genetics study and another in May for data analysis.” Conversely, a donor with higher education reading level preference can receive the response including additional details such as assay types, analysis methods, or links to relevant study protocols. In some implementations, the donor’s reading level or communication preference can be explicitly indicated within the submission 308. For example, a donor can submit a query such as, “Explain my sample usage in simple terms,” or “provide a technical breakdown of my sample’s current study involvement.” In some implementations, the donor’s reading level or preferences can be inferred based on historical interaction with the platform, such as the complexity of previous queries, frequency of requests for clarification, or navigation patterns within the donor portal 200. In yet another example, these preferences can be adjusted based on behavioral analytics gathered from the donor portal 200 and / or interactive messaging interface 300.

[0059] In some implementations, the responses 304 A, 304B can include a graphical representation of the usage history of the biological sample. The graphical representation can be generated by the interactive messaging interface 300, donor portal 200, or the blockchain- enabled backend and can visually depict information, such as a timeline of access events, locations of processing, second entities involved, and types of analyses performed. For example, the graphical representation can present a chronological flowchart showing when the sample was donated, when and where it was accessed, the specific research activities performed, and any derivative data generated from the sample. In some implementations, the response 304 A, 304B can be interactive, meaning the donor can engage with the responses 304A, 304B to, for example, filter, expand, or drill down into detail for individual events. For example, a donor can select a specific entry in the timeline to view metadata linked to that transaction. In some cases, links to external resources, such as URLs to published researchDocket No.: 061935-502001 WO articles, can be provided. The donor can also be given options to download activity reports or export their usage history. In some implementations, the responses 304A, 304B can include a map display including one or more markers corresponding the physical location of biobanks or research facilities that have processed the sample. Each of the location markers can be selected to access information related to the donated biological sample data 212A, 212B corresponding to a respective location, including donor’s identifiers and consent parameters.

[0060] Additionally, as indicated above, the interactive messaging interface 300 can also be used by the donor to review or inquire about one or more consent parameters associated with their biological sample in an intuitive and conversational manner. For example, the donor can enter natural language queries requesting clarification of specific consent terms. The donor can submit a query such as, “what studies can my sample currently be used for?” or “Can I prevent my sample from being shared outside of my country?” The support module 306 can retrieve, via the LLM, the relevant consent parameters stored in association with the donor’s identifier corresponding to the donor’s biological sample NFT and generate an explanation of the terms in plain language, including definitions, applicable restrictions, and compliance considerations.

[0061] To achieve contextually relevant and donor-specific outputs, and to ensure that such multifaceted information is customized and tailored to meet the unique informationprocessing needs and preferences of each donor, as well as reducing the unpredictability (e.g., false, out-of-date, or generic information) in responses 304A, 304B, the LLM can employ a retrieval-augmented generation (RAG) architecture that combines one or more information retrieval models or data collection systems with the LLM. Each one of the information retrieval models or data collection system can be configured to search and retrieve domain-specific, authoritative data repositories e.g., the blockchain ledger, metadata (e.g., consent parameters and usage history) associated with the biological sample NFT, laboratory and institutionalDocket No.: 061935-502001 WO knowledge bases, and any other trusted external data sources, before the LLM generates the responses 304A, 304B. This enable the LLM to augment its generative capabilities with realtime, verifiable, and contextually accurate information that resides outside its pre-trained parameters. Accordingly, the donors can have greater control over the accuracy and transparency of the generated responses 304 A, 304B.

[0062] In general, when the donor submits a query to the interactive messaging interface 300, the query can be first analyzed and transformed into a vector representation using an embedding generator trained to map the semantic meaning of the query into a n-dimensional vector space. Each language element of the query can be represented by a vector of the n- dimensional vector space. For example, each vector in the n-dimensional vector space can be represented by an n-tuple of numerical values. In some instances, each element of a vector can include a number representing an enumeration of co-occurrences of the word and / or language element represented by the vector with another word and / or language element. Vectors can be normalized, scaled according to relative frequencies of appearance and / or submission sizes. Such vector representation can then be matched against a vectorized index of the external data sources (e.g., a vector database) used by the RAG framework. This can include computing a degree of vector similarity between a vector representing each language element and a vector representing data entries in the index. The vector similarity can be measured according to any norm for proximity and / or similarity of two vectors including, for example, cosine similarity which measures the similarity of two vectors by evaluating the cosine of the angle between the vectors. Cosine similarity can be computed using a dot product of the two vectors divided by the length of the two vectors. Degree of similarity may include any other geometric measure of distance between vectors. Other exemplary similarity search algorithms, such as approximate nearest neighbor (ANN) can be used to identify the most relevant data entries that correspond to the query without departing from the scope of this disclosure.Docket No.: 061935-502001 WO

[0063] For example, upon receiving a donor query such as, “Summarize the studies that have used my sample this year,” the RAG framework can identify context data e.g., relevant entries from synchronized data sources (e.g., LIMS system, donor’ s EMR / HER, local or cloud-based databases) in addition to the usage history posted on the blockchain. The context data can then be passed to the LLM for generating responses 304 A, 304B. In some implementations, the RAG framework can operate iteratively, meaning that additional RAG retrieval and LLM generation cycles can be triggered to refine the responses 304 A, 304B further if the initial output requires additional context or detail. Alternatively or in addition, the RAG framework can be powered by a search engine. One of the advantages of using RAG is that it enables the LLM to remain relatively lightweight while still providing detailed and context-aware responses by outsourcing the task of retrieving relevant context to the one or more information retrieval models or data collection systems.

[0064] In some implementations, the interactive messaging interface 300 can also support direct consent modifications. For example, the donor can enter a request such as “Update my consent to allow participation in oncology studies only,” or “Revoke access to my data for commercial research.” Upon receiving such instructions, the support module 306 can validate the request for authenticity, prompt the donor for confirmation, and once confirmed, initiate an update to the consent parameters through the blockchain-enabled backend. The donors can also manage their consent settings via other user interfaces, such as a setting page in the donor portal 200 (not shown), using one or more controls (e.g., toggles, sliders, dropdown menus, radio buttons, check boxes, and the like). Notably, the consent update includes burning the NFT representing the biological sample currently associated with the prior set of consent parameters. In some implementations, burning the NFT invalidates the existing token representation and its associated metadata, thereby revoking any previously granted accessDocket No.: 061935-502001 WO rights to the biological sample. Subsequently, a new NFT can be minted to reflect the updated consent parameters.

[0065] In some implementations, donors can be notified of subsequent updates to the user history of their biological sample through the donor portal 200 or other integrated communication channels. Notifications can be delivered in real time or in scheduled digests, depending on the donor’s preferences, and can alert the donor to events such as new access requests, approvals, denials, processing activities, or the generation of derivative data from the biological sample. For example, when a second entity completes an approved sequencing run or data analysis, the system can generate a notification that is securely transmitted to the donor’s user interface. The notification can include a brief summary of the event e.g., “Your sample was processed on Aug. 15, 2025, for a whole-genome sequencing study at Research Lab A,” along with a link to more detailed information in the donor portal. In some implementations, these notifications can also highlight updates to associated metadata, such as changes in consent parameters or status updates for ongoing studies. Notifications can be delivered through multiple channels, including push notifications on the user device (e.g., a mobile device), email alerts, or in-app messages within the donor portal 200, to ensure accessibility and donor engagement. In some implementations, part or all notifications can be encrypted in transit and can require authentication before the donor can view the details. In some implementations, part or all notifications can be delivered to donors in one or more responses displayed in the interactive messaging interface 300. In some implementations, the donor can have the ability to customize one or more notification settings on donor portal 200, for example, enabling or disabling specific types of notifications or adjusting delivery frequency to suit individual preferences.

[0066] It should be noted that the user interface can be configured differently in terms of graphical elements, functions, and controls depending on whether it is presented to the firstDocket No.: 061935-502001 WO entity (e.g., donor or sample provider) or the second entity (e.g., research institution, laboratory, or data analytics facility). In some implementations, the second entity can also be provided with access to a user interface specifically configured for their operational and compliance needs. Such a user interface can also be presented as a web-based portal or a native software application similar to the donor portal 200 as described above. For example, user interface presented to the second entity can allow one or more authorized users, such as researchers, laboratory managers, or system administrators to query, retrieve, and review donor consent parameters and associated metadata. Researchers can input a query to confirm whether a biological sample is approved for a specific type of research or whether geographic or temporal restrictions apply to a planned study. For example, a response, such as “Consent verified: Sample ID-12456 is approved for genomic analysis in oncology studies until December 31, 2026. Restricted for use outside the United States,” can be presented to the second entity through a lab portal.

[0067] A person skilled in the art will appreciate that the user interface can have various other configurations. Various exemplary implementations of the user interface, such as a marketplace portal and a specimen portal, are described further in, for example, U.S. Pat. App. No. 18 / 339,743, entitled “TRANSFERRING BLOCKCHAIN-BASED TOKENS REPRESENTING BIOSPECIMENS,” filed on June 22, 2023, the contents of which are hereby fully incorporated by reference.

[0068] The operations and functionalities of method 100, as described above, can be implemented and supported by various system components. FIGS. 4A-4D illustrate example systems that can be used with aspects of this disclosure. Referring to FIG. 4A, the example system 400A includes a LIMS system 402, a user device 404, a data collection system 408, biobank node 406A, a database 410, a shipping system 412, and a network 414. The LIMS system 402 can include any form of servers including, but not limited to a web server (e.g.,Docket No.: 061935-502001 WO cloud-based server), an application server, a proxy server, a network server, and / or a server pool. In general, the LIMS system 402 can include a computing device including one or more central processing units, graphical processing units, and / or the like. The LIMS system 402 can be configured to provide access to software LIMS applications 416, to enable blockchain-based biological sample token transfer services by the node systems 408 and biological sample tracking services to any number of user devices (e.g., the user device 404) over the network 414. The LIMS software application 416 can be any cloud-based, or in-house / offline software application. The biobank node 406A can act as a data bridge to authenticated system participants using the user device(s) 404, who can be authenticated in the example system 400A by their association with the tokenized biological sample. For example, the biobank node 406 A can process received orders to transfer NFTs representing biological sample and, in response, can retrieve data from the database 410 and LIMS system 402 and notify the user device 404 of a portion of associated information being transferred. The biobank node 406A can authorize transactions based on consent parameters retrieved by the LIMS system 402 from the database 410 and based on consent parameters which can be stored on the blockchain as metadata of a token that represents a donated specimen.

[0069] The user device 404 can be and / or include any type of processor and memory based device, such as cellular phones, smart phones, tablet computers, laptop computers, desktop computers, workstations, personal digital assistants (PDA), network appliances, cameras, enhanced general packet radio service (EGPRS) mobile phones, media players, navigation devices, email devices, game consoles, or an appropriate combination of any two or more of these devices or other data processing devices. The user device 404 can include a user interface 418. The user device 404 can include a user interface 418, a processor, a memory, a storage component, a bus and any combination of fixed and variable computing components.Docket No.: 061935-502001 WOThe user interface 418 can include a user input interface, output interface, and / or a communication interface.

[0070] The input interface 418 can include a component that permits the user device 404 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, a camera, and / or the like). Additionally or alternatively, in some embodiments input interface can include a sensor that senses information (e.g., user biometric data and / or the like). The output interface can include a component that provides output information from the user device 404 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), and / or the like). The communication interface can include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, and / or the like) that enables the user device 404 to communicate with other devices via a wired connection, a wireless connection, or a combination of wired and wireless connections. In some implementations, the communication interface can permit the user device 404 to receive information from the LIMS system 402 or the data collection system 408 and / or provide information to the LIMS system 402 or the data collection system 408. In some implementations, the communication interface includes an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi® interface, a cellular network interface, and / or the like. Even though not illustrated, in some implementations, multiple user devices 404 including different computing system configurations, such as different operating systems, different processing capabilities, different hardware components, and / or other differences can concurrently request updates regarding the biological sample related transaction data. For example, the user device 404 can interact with the biobank node 406A to visualize data related to their biological samples, which was accessed from the LIMS software application 416, and / or the data collection system 408. The user interface 418 can enable an entry of a user inputDocket No.: 061935-502001 WO including a request to access data associated with a biological sample including biological sample usage history. The user device 404 can transmit the request to the biobank node 406A. The user device 404 can receive, from the biobank node 406A, notifications including a biological sample transfer data (e.g., location data and study data). The user interface 418 can display the notifications indicating the biological sample transfer data (e.g., biological sample transfer status).

[0071] Each biobank node 406A can be and / or include any type of processor and memory based device, such as cellular phones, smart phones, tablet computers, laptop computers, desktop computers, workstations, personal digital assistants (PDA), network appliances, cameras, enhanced general packet radio service (EGPRS) mobile phones, media players, navigation devices, email devices, game consoles, or an appropriate combination of any two or more of these devices or other data processing devices that can be connected to a blockchain network to run on a continuous server. Each biobank node 406A can include an installed blockchain wallet 420A (e.g., wallet software) or can be connected to a blockchain wallet 420A, a node connection module for connecting the biobank node 406A and the wallet 420A, and a node communication module for causing the wallet 420A to perform encrypted communication with the other biobank nodes 406 A, via the network 414. The blockchain wallet 420A can include a software package configured independently of the biobank node 406A. The blockchain wallet 420A includes: an address creation module, configured to create an account address in an online or offline environment; and a transaction signature module, configured to perform transaction signature in an online or an offline environment. The blockchain wallet 420A is connected through the node connection module to the biobank node 406A and communicates through the node communication module to send transaction information to other biobank nodes 406A or obtain wallet balance from the blockchain network, when aDocket No.: 061935-502001 WO transaction can be sent or balance can be obtained for transferring NFTs representing biological samples.

[0072] The data collection system 408 can include any form of servers including, but not limited to, a web server (e.g., cloud-based server), an application server, a proxy server, a network server, and / or a server pool. In general, the data collection system 408 can include a biobank node 406B and a database 422 to manage data collection. The biobank node 406B can be similar in terms of configuration and functions to the biobank node 406A. For example, the biobank node 406B can include an installed blockchain wallet 420B or can be connected to a blockchain wallet 420B that can be similar to the blockchain wallet 420A. The data collection system 408 can be configured to provide access to data managed and / or processed by the biobank node 406B and stored by the database 422, over the network 414.

[0073] The database 422 can include a storage component that stores data and / or software related to the processing of the data. The database 422 can be implemented as a relational database, a key-value retrieval database, such as a NOSQL database, or any other format or structure for use as a database that a person skilled in the art would recognize as suitable upon review of the entirety of this disclosure. In some implementations, the database 422 can be implemented using a distributed data storage protocol or data structure, such as a distributed hash table or the like. In some cases, data entries in the database 422 can be flagged with or linked to one or more additional elements of information, which may be reflected in data entry cells and / or linked tables such as tables related by one or more indices in a relational database. The database 422 can include a cloud database system environment, an on-premise database system (e.g., system databases, tenant databases, etc.), servers (e.g., name server(s), index server(s), script server(s), etc.) or any other types of databases that can be used as well. In some implementations, the database 422 can store various data as described herein off-chain, including, for example, sample related information, first and second entity related information,Docket No.: 061935-502001 WO user preferences, system settings, logs, etc., that can be accessible (e.g., via queries, procedure calls, etc.) by the user device 404, and by the biobank nodes 406A. The database 422 can include a runtime database that holds most recent data updates to enable access to up-to-date information.

[0074] The database 410 can be similar to the database 422 to include a storage component that stores data and / or software related to biological samples. For example, the database 410 can be configured to store, and can include applications specifically designed for the storage of, clinical data 428 and electronic health records (EHRs) 430. The clinical data 428 include clinical research results associated with one or more donated biological samples, or the donors themselves, such as clinically relevant information derived from research conducted on the biological samples transferred as de-identified samples, the conducted research being performed in a non-human subject context. The electronic healthcare records 430 can include email addresses and consent information associated with biological sample donors (users of the user device 404). The database 410 can include a multitenant database architecture (e.g., multitenant database containers (MDC), such that each tenant of the LIMS system 402 can customize respective clinical data 428 and electronic health records 430 stored by the database 410 and can be served by separate implementations of the LIMS system 402 when using the LIMS software applications 416.

[0075] The shipping system 412 can include a data processing system that can be included in or coupled to one or more vehicles configured to physically ship biological samples according to a transfer and handling protocol, in a safe and secure manner. For example, the shipping system 412 can be suitable for physical storing, transporting temperature-sensitive samples and / or transmitting information related to the physical storage and transportation of the biological samples, including sample location information that can be updated in real timeDocket No.: 061935-502001 WO during biological sample transportation and transmitted over the network 414 to the LIMS system 402, the user device 404, the biobank node 406A and / or the data collection system 408.

[0076] The network 414 can include one or more wired and / or wireless networks. In an example, network 414 includes a cellular network (e.g., a long term evolution (LTE) network, a third generation (3G) network, a fourth generation (4G) network, a fifth generation (5G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the public switched telephone network (PSTN), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, etc., a combination of some or all of these networks, and / or the like.

[0077] The example system 400A as described above can be blockchain-enabled. FIG. 4B illustrates a blockchain network implementation of the example system 400A. The example system 400B includes the LIMS system 402, the user device 404, the data collection system 408, the database 410, and a blockchain network 432. The blockchain network 432 can be a distributed ledger environment configured to automatically execute programs, e.g., smart contracts. In the blockchain network 432, apart from the token being tracked by the distributed ledger on a blockchain, the blockchain network 432 also has programs that can run code associated with the transactions. The code validates conditions and, when set conditions are met, it can automatically make changes to the tokens and / or token records 424, where these changes are also tracked automatically along with the code that made the changes. The blockchain network 432 includes multiple biobank nodes 406A, 406B configured to replicate transaction data according to a consensus algorithm that ensures validation of new information. The blockchain network 432 may be implemented as an immutable mechanism for token issuance and transaction flow management, in which the biobank nodes 406A, 406B involvedDocket No.: 061935-502001 WO in issuing and executing electronic token transactions may write and read data and instructions associated with one or more processes using an electronic ledger.

[0078] Such a distributed ledger provides transparency of information for the permitted biobank nodes 406A, 406B, while eliminating duplication of effort in maintaining the information due to a single source of truth replicated across multiple biobank nodes 406A, 406B. The blockchain network 432 can include a distributed ledger design defining a blockchain system, which employs a chain of biobank nodes 406A-406N to provide security of the information. The biobank nodes 406A-406N are a continuously growing list of records, which are linked using cryptography (e.g., hashing) or similar data security methods as described herein. Each biobank node 406A-406N can contain a cryptographic hash of a previous block to provide security, along with a timestamp and the transaction data. The node data linkage ensures that each transaction is recorded in a manner that creates an audit trail. Once recorded, the data in any given biobank node 406A-406N cannot be altered without invalidating the cryptographic hash of all the subsequent biobank nodes 406A-406N. The node data linkage makes the blockchain network 432 resistant to tampering of the recorded transaction data, as all copies would need to be manipulated. The blockchain network 432 may provide the infrastructure, in which the biobank nodes 406A, 406B that manage the token transaction process may communicate by writing to block addresses designated to the biobank nodes 406A, 406B engaged in the process.

[0079] As shown, the example blockchain network 432 includes multiple linked data blocks including the biobank nodes 406A, 406B. The blockchain network 432 may be communicatively connected or coupled to the LIMS system 402 and data collection system 408 configured to respectively issue and execute one or more digital tokens, such as NFTs representing biological samples (e.g., token records 424 associated to biological samples). The LIMS system 402 can store information pertaining to a new sample arriving at a biobank; theDocket No.: 061935-502001 WO biobank node 406A can detect the receipt of new sample arriving at the biobank and can use the information regarding the new sample to mint an NFT, which is stored within the wallet 420A of the blockchain node. The process model for the blockchain network 432 can define parameters and constraints associated with the manner in which token data is to be utilized or manipulated. For example, in some implementations, the rules for managing the request for tokens 434 can include: a token to be recorded on the blockchain network 432, the token to be freely transferred on the blockchain network 432 subject to smart contracts complying with consent parameters, the token transfer to be exchangeable for a token (e.g., study data), tokens to be stored or redeemed either on the blockchain network 432 or in another system (e.g., an event provider’s point of sale system). The consent parameters defined by the sample donor can also be stored on the LIMS system 402 and then associated with the respective NFT via the biobank node 406A, or it can be stored as NFT metadata on the blockchain network 432, in which it pulled / associated and stored and saved via the data collection system 408 or LIMS system 402. As indicated above, the stored consent parameters can provide an immutable and recallable association between the donated biological sample and the donor consent given for research, powered by the blockchain network 432.

[0080] The process for accessing and / or managing requested tokens 434 may be implemented by enabling one or more biobank nodes 406A, 406B of the blockchain network 432 to execute token transfer operations with respect to one or more records in the blockchain network 432. The indication received as authorized by a first entity (e.g., a seller, donor, or owner of the token and / or the biological sample associated with the token, an originator of the biological sample or an agent of the originator) allows for the exchange of the first token with the second token. The first token, in some implementations, is associated with ownership information that indicates the first token is owned by the first entity. The first token may also include additional information (e.g., data or metadata), such as a usage history 426Docket No.: 061935-502001 WO corresponding to the token record 424. The ownership of the first token is transferable to a second entity (e.g., buyers or resellers) over the electronic ledger environment according to the ownership information associated with the first token. Each token or batch of tokens can be mapped to an encrypted email address of the donor to enable transmission of token transfer data to the donor. In some implementations, the donor's email can be stored instead of the donor’s wallet to abstract blockchain technology away from the donor. The usage of the encrypted email address of the donor can allow for a larger donor population to securely and conveniently use the example system 400B. The encrypted email can be used to give donors the access to the user interface 418 (e.g., a donor portal). In some implementations, one or more donors may opt into using a wallet address after a biological sample donation to increase data security, or to receive monetary incentives, which may be permissible in some implementations of biological sample token transactions.

[0081] In some implementations, the blockchain network 432, in response to receiving an indication to exchange the tokens, generates the second token, which is associated with the ownership information and may also include admission information including compliance with consent parameters. The ownership information can indicate that the second token is owned by either the second entity, or both the first and second entity, depending on whether the second entity acquires the token in its entirety, or if the token is both transferred to the second entity and remains at the first entity. The admission information can indicate that the second entity is to be allowed to use the token representing biological samples by performing a study pertaining to the biological samples.

[0082] Without limitation and by way of example, in some implementations, the generation of the token may be committed to one or more database records of a data collection system 408, or records in the distributed ledger environment, in accordance with one or more protocols, such as database 410. The protocols can control and memorialize the downstreamDocket No.: 061935-502001 WO exchange of the tokens and the related transactions among multiple biobank nodes 406A, 406B, via the blockchain system 400B, and are configured to commit the tokenized transactions including at least a biobank node system 406A, 406B and / or the blockchain network 432.

[0083] FIG. 4C illustrates another example system 400C, corresponding to a particular variation or implementation of the example system 400A described with reference to FIG. 4A or example system 400B described with reference to FIG. 4B. The example system 400C includes the LIMS system 402, the user device 404, the biobank node 406A, the shipping system 412, and a marketplace system 442. The marketplace system 442 includes the marketplace platform 444 and the donor portal 446. The marketplace platform 444 can be accessible to a second entity 448 (e.g., recipient). The donor portal 446 can be accessible to a first entity 450 (e.g., donor).

[0084] In an example context, instances of biological sample exchange between nonprofit and / or research (e.g., academic) biobanks, can be based on material transfer agreements (MTA’s), and instances of data exchange can be based on data usage agreements (DUA’s). MTA’s and DUA’s are types of licensing agreements between two entities (institutions), which stipulate the terms and conditions of material and information exchange, including factors like time of use, scope of research, intellectual property (IP) rights, and other particular clauses and exchange conditions. Biospecimen exchange can be facilitated by human MTA’s, and may in some instances include standardized exchange templates, simple letter agreements (SLA’s), or other uniform templates proposed by consortia (like the Association of University Technology Managers (AUTM)) or government bodies (e.g., National Institutes of Health). The administration of human MTA’s can be conducted by personnel within the sponsored research administration (SPA) office of a given medical body. The marketplace system 442 can use the plurality of tokens representing biological samples stored within a biobank as a platform to simplify human MTA’s and DUA’s, and the personnel that can be given authorization toDocket No.: 061935-502001 WO approve such tech transfer agreements, are herein named as “node administrators”. Within the example implementation, pointers to data and material usage agreements can be stored at an external location upon completion of agreement process. The pointers can be associated with the data and the materials that are being transferred. The completion of the data and / or material transfer process can trigger an automatic association with the pointers to data and material usage agreements and an automatic payment.

[0085] The marketplace system 442 can be coupled to a biobank node 406, or multiple biobank nodes 406A-N that are connected via the blockchain network 432, as described with reference to FIG. 4B. The marketplace system 442 can be configured to distribute sensitive data to participants in a privacy preserving and decentralized fashion. The marketplace system 442 utilizes a distributed network of software application 416, which is run by the biobank nodes 406A (owners of tokenized biological sample). The application 416 of each biobank node 406 A receives data from the LIMS system 402, from the database 410, and via the data collection system 408, which contains data pertaining to respective biological samples. The biobank node 406A can act as a data bridge to authenticated system participants (first entity 450) of the marketplace platform 444. For example, admins can be authenticated, by the marketplace system 442 (e.g., blockchain network 432 described with reference to FIG. IB), by using the association to the tokenized specimens. A node administrator of the marketplace system 442 can authenticate the second entity 448 as non-associated participants, having wallets (e.g., wallet 420A described with reference to FIG. 1 A) designated for sample procurement (e.g., the node system / wallet within the node system can be used to permit access to the marketplace system). The authentication of the second entity 448 can include a verification of whether the second entity 448 are included in a whitelist of the marketplace system 442 (e.g., blockchain network 432 described with reference to FIG. 4B). The softwareDocket No.: 061935-502001 WO application 416 of the biobank node 406A can use a wallet owned by an administrator to perform actions on the marketplace system 442 and hold the tokenized biological samples.

[0086] In some implementations, the first entity 450 can be a primary patient receiving ongoing care. For the first entity 450 being primary patients, the donor portal 446 (e.g., the donor portal 200 as described above with reference to FIG. 2) can serve as a continuous data flow between research conducted on the material and the patient receiving care. For implementations, a biopsy sample donated for research by a cancer patient can be de- identified before being transmitted to the second entity 448 (e.g., primary researchers). The primary researchers can process the biospecimen result data (e.g., during research or clinical studies) and can generate curated data sets. The user device 404 can retrieve data from the curated data sets and display the retrieved data within the donor portal 446 of the user interface 418 with a notification for the patient indicating received information. The user device 404 can be configured to retrieve data from the curated data sets based on a preference included in respective consent data retrieved from the LIMS system 402 or stored by the database 422 at the time of the biological sample donation or based on consent conditions that are stored as metadata of the NFT that represents a donated biological sample. In some implementations, validation of the curated datasets can be executed before the information can be relayed back to the donor portal. In case of validation, a sample that may have otherwise been de-identified and shipped to a number of biobanks, can be still traceable via its unique tokenization and record keeping on the blockchain 432. For example, the biobank node 406A can be configured to transmit to the donor portal 446, in such a way that the sample information, once a given number of nodes validating the same data or research finding has been concluded at the same number of biobank nodes. The biobank nodes 406A-N can also be configured in a way to broadcast messages to one another over the blockchain network 432, to query for validation inDocket No.: 061935-502001 WO a given research finding. The broadcasted messaging can be facilitated via the wallets contained within each blockchain node.

[0087] In some cases, node administrators of the biobank node 406A may desire to transfer (e.g., purchase or sell) biological sample NFTs or their associated data, via MTA’s or DUA’s. Such transactions can be performed by the marketplace system 442, in which specimen availability searches can be conducted by the biobank node 406A, where tokens can be acquired or otherwise exchanged, with or without a financial exchange. In the case that the sample or the data generated from research thereon is purchased, an automatic royalty payment (e.g., issuing of rewards) between both the second entity 448 (managing biobank) and the first entity 450 can occur, and the monetary exchange (e.g., payment or financial asset transaction) can be managed by smart contracts on the blockchain network 432. In some implementations, only biobank nodes 406A can acquire primary genetic material from other nodes, in the form of MTA’s or DUA’s, and typically third-party research entities can access the marketplace platform 444 to purchase or query data sets generated by the second entity 448 (biobanks / nodes), and the first entity 450 themselves. In some implementations, third party research entities can purchase, acquire and / or gain access to primary material (e.g., biological sample), if the donor consent is upheld and if a sufficient number of factors / parameters are included in the purchase conditions to validate the authenticity of the purchase. The transaction factors and parameters can include, transaction receipts, sample arrival at proprietary biobank transmitted to the LIMS system 402 and the biobank node 406A, by the shipping system 412.

[0088] FIG. 4D illustrates another example system 400D, corresponding to a particular variation or implementation of the example system 400A described with reference to FIG. 1 A or example system 400B described with reference to FIG. IB or the example system 400C described with reference to FIG. 1C. The example system 400D includes multiple biobank nodes 406A-406C, the user device 404, and the database 422. The biobank nodesDocket No.: 061935-502001 WO406A-406C can include biobanks, such that the example system 400D creates a distributed and decentralized biobank, where all biobanks can access an inventory of tokenized assets 452. The inventory of tokenized assets 452 reflects the physical storage of donated material at a respective biobank node 406A, 406B, or 406C (biobank). In some implementations, the operators of the biobank, which is running a biobank node 406A-406C may have differing consent frameworks 454, through which the donor (e.g., the first entity 450 described with reference to FIG. 1C) permits use of the donated material. The consent frameworks 454 stored in the database 422 can be filtered by the biobank nodes 406 A, 406B, 406C. In response to processing the consent framework 454, the node systems 406A, 406B, 406C can generate whitelists to identify recipients (e.g., the second entity 448 described with reference to FIG. 1C) that comply with the stored consent.

[0089] The whitelisted recipients, identified by the biobank nodes 406A, 406B, 406C, can request access to the donated biological sample by accessing the marketplace (e.g., marketplace platform 444 described with reference to FIG. 1C). The security of the example system 400D can be increased by limiting tokenized biospecimen transactions to recipients (e.g., biobank nodes 406A, 406B, 406C) that have been whitelisted by the other biobank nodes 406A, 406B, 406C (and the biobank nodes themselves). The whitelisted biobank nodes 406A, 406B, 406C can access the marketplace platform interface (described with reference to FIGS. 3 A-3C), which displays biospecimen data for due diligence for all tokenized biological samples registered by the biobank nodes 406A, 406B, 406C in the network. An available biological sample search on the marketplace platform portal of the user interface 418 only displays results of the tokens that the respective biobank nodes 406A, 406B, 406C are allowed to acquire, based on consent data and the search query itself.

[0090] In some implementations, the current subject matter can be configured to be implemented in a system 500, as shown in FIG. 5. The system 500 can include a processor 510,Docket No.: 061935-502001 WO a memory 520, a storage device 530, and an input / output device 540. Each of the components 510, 520, 530 and 540 can be interconnected using a system bus 550. The processor 510 can be configured to process instructions for execution within the system 500. In some implementations, the processor 510 can be a single-threaded processor. In alternate implementations, the processor 510 can be a multi -threaded processor. The processor 510 can be further configured to process instructions stored in the memory 520 or on the storage device 530, including receiving or sending information through the input / output device 540. The memory 520 can store information within the system 500. In some implementations, the memory 520 can be a computer-readable medium. In alternate implementations, the memory 520 can be a volatile memory unit. In yet some implementations, the memory 520 can be a non-volatile memory unit. The storage device 530 can be capable of providing mass storage for the system 500. In some implementations, the storage device 530 can be a computer- readable medium. In alternate implementations, the storage device 530 can be a floppy disk device, a hard disk device, an optical disk device, a tape device, non-volatile solid state memory, or any other type of storage device. The input / output device 540 can be configured to provide input / output operations for the system 500. In some implementations, the input / output device 540 can include a keyboard and / or pointing device. In alternate implementations, the input / output device 540 can include a display unit for displaying graphical user interfaces.

[0091] In some implementations, one or more application function libraries in the plurality of application function libraries can be stored in the one or more tables as binary large objects. Further, a structured query language can be used to query the storage location storing the application function library.

[0092] The systems and methods disclosed herein can be embodied in various forms including, for example, a data processor, such as a computer that also includes a database, digital electronic circuitry, firmware, software, or in combinations of them. Moreover, theDocket No.: 061935-502001 WO above-noted features and other aspects and principles of the present disclosed implementations can be implemented in various environments. Such environments and related applications can be specially constructed for performing the various processes and operations according to the disclosed implementations or they can include a general-purpose computer or computing platform selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, and can be implemented by a suitable combination of hardware, software, and / or firmware. For example, various general-purpose machines can be used with programs written in accordance with teachings of the disclosed implementations, or it can be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.

[0093] Although ordinal numbers such as first, second, and the like can, in some situations, relate to an order; as used in this document ordinal numbers do not necessarily imply an order. For example, ordinal numbers can be merely used to distinguish one item from another. For example, to distinguish a first event from a second event, but need not imply any chronological ordering or a fixed reference system (such that a first event in one paragraph of the description can be different from a first event in another paragraph of the description).

[0094] The foregoing description is intended to illustrate but not to limit the scope of the invention, which is defined by the scope of the appended claims. Other implementations are within the scope of the following claims.

[0095] These computer programs, which can also be referred to programs, software, software applications, applications, components, or code, include machine instructions for a programmable processor, and can be implemented in a high-level procedural and / or object- oriented programming language, and / or in assembly / machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and / orDocket No.: 061935-502001 WO device, such as for example magnetic discs, optical disks, memory, and Programmable Logic Devices (PLDs), used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor. The machine-readable medium can store such machine instructions non-transitorily, such as for example as would a non-transient solid state memory or a magnetic hard drive or any equivalent storage medium. The machine-readable medium can alternatively or additionally store such machine instructions in a transient manner, such as for example as would a processor cache or other random access memory associated with one or more physical processor cores.

[0096] To provide for interaction with a user, the subject matter described herein can be implemented on a computer having a display device, such as for example a cathode ray tube (CRT) or a liquid crystal display (LCD) monitor for displaying information to the user and a keyboard and a pointing device, such as for example a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well. For example, feedback provided to the user can be any form of sensory feedback, such as for example visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including, but not limited to, acoustic, speech, or tactile input.

[0097] The subject matter described herein can be implemented in a computing system that includes a back-end component, such as for example one or more data servers, or that includes a middleware component, such as for example one or more application servers, or that includes a front-end component, such as for example one or more user device computers having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described herein, or any combination of such back-end,Docket No.: 061935-502001 WO middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, such as for example a communication network. Examples of communication networks include, but are not limited to, a local area network (“LAN”), a wide area network (“WAN”), and the Internet.

[0098] The computing system can include user devices and servers. A user device and server are generally, but not exclusively, remote from each other and typically interact through a communication network. The relationship of user device and server arises by virtue of computer programs running on the respective computers and having a user device-server relationship to each other.

[0099] The subject matter described herein can be embodied in systems, apparatus, methods, and / or articles depending on the desired configuration. The implementations set forth in the foregoing description do not represent all implementations consistent with the subject matter described herein. Instead, they are merely some examples consistent with aspects related to the described subject matter. Although a few variations have been described in detail above, other modifications or additions are possible. In particular, further features and / or variations can be provided in addition to those set forth herein. For example, the implementations described above can be directed to various combinations and sub-combinations of the disclosed features and / or combinations and sub-combinations of several further features disclosed above. In addition, the logic flows depicted in the accompanying figures and / or described herein do not necessarily require the particular order shown, or sequential order, to achieve desirable results. For example, the logic flows can include different and / or additional operations than shown without departing from the scope of the present disclosure. One or more operations of the logic flows can be repeated and / or omitted without departing from the scope of the present disclosure. Other implementations can be within the scope of the following claims.

Claims

Docket No.: 061935-502001 WOWHAT IS CLAIMED IS1. A method comprising: associating an identifier corresponding to a first entity providing a biological sample with data characterizing a set of consent parameters and a usage history of the biological sample, the set of consent parameters and the usage history being posted on a blockchain; in response to receiving a request from a second entity to access the biological sample for processing, updating the usage history on the blockchain to record the access to the biological sample and / or the processing of the biological sample based on the set of consent parameters associated with the identifier; and providing the first entity with access to a user interface, the user interface being configured to present, upon receiving a query from the first entity, a response describing the updated usage history of the biological sample to the first entity.

2. The method of claim 1, wherein the first entity comprises a donor of the biological sample, and wherein the second entity comprises a research institution or a laboratory requesting the access to the biological sample.

3. The method of claim 1, wherein the set of consent parameters is posted as metadata associated with a non-fungible token (NFT) representing the biological sample on the blockchain, the NFT being linked to the identifier corresponding to the first entity.

4. The method of claim 1, wherein the set of consent parameters defines allowable biological sample use granted by the first entity.

5. The method of claim 1, wherein the usage history comprises metadata describing the second entity, the access to the biological sample, the processing of the biological sample, and a timestamp associated with the access or the processing of the biological sample.

6. The method of claim 1, wherein updating the usage history of the biological sample comprises evaluating the request against the set of consent parameters to determine whether the access or processing of the biological sample is granted.Docket No.: 061935-502001 WO7. The method of claim 6, wherein evaluating the request comprises executing a smart contract configured to compare attributes of the request with the set of consent parameters.

8. The method of claim 7, wherein the smart contract is configured to initiate a transmission of the biological sample to the second entity in response to the determination that the request is granted, wherein the transmission of the biological sample triggers a predetermined amount of payment to be sent from the second entity to the first entity.

9. The method of claim 1, wherein the query is a natural language query, and the response comprises natural language responsive to the natural language query.

10. The method of claim 1, wherein the user interface is in communication with a generative model trained to produce the response.

11. The method of claim 10, wherein the generative model comprises a large language model (LLM).

12. The method of claim 10, wherein the generative model implements a retrieval- augmented generation (RAG) architecture.

13. The method of claim 1, wherein the query from the first entity comprises information indicative of a reading level associated with the first entity.

14. The method of claim 13, wherein the response comprises an explanation of at least a portion of the updated usage history to the first entity in natural language produced based at least in part on the reading level.

15. The method of claim 1, wherein the response comprises a graphical representation of the usage history of the biological sample.

16. The method of claim 1, further comprising notifying the first entity of subsequent updates to the user history via the user interface.

17. The method of claim 1, further comprising: providing the second entity with access to the user interface, the user interfaceDocket No.: 061935-502001 WO being configured to present, in response to a query from the second entity, a natural language response describing the set of consent parameters.

18. The method of claim 3, further comprising: burning the NFT representing the biological sample on the blockchain in response to receiving, at the user interface, a request to modify one or more consent parameters within the set of consent parameters from the first entity, wherein modifying the one or more consent parameters includes revoking the access to the biological sample.

19. A non-transitory computer-readable storage medium comprising at least one program for execution by one or more processors of a first device, the at least one program including instructions which, when executed by the one or more processors, cause the first device to perform operations comprising: associating an identifier corresponding to a first entity providing a biological sample with data characterizing a set of consent parameters and a usage history of the biological sample, the set of consent parameters and the usage history being posted on a blockchain; in response to receiving a request from a second entity to access the biological sample for processing, updating the usage history on the blockchain to record the access to the biological sample and / or the processing of the biological sample based on the set of consent parameters associated with the identifier; and providing the first entity with access to a user interface, the user interface being configured to present, upon receiving a query from the first entity, a response describing the updated usage history of the biological sample to the first entity.

20. A system, comprising: at least one computer-readable medium storing computer-executable instructions; and at least one processor configured to execute the computer-executable instructions to perform operations comprising: associating an identifier corresponding to a first entity providing a biological sample with data characterizing a set of consent parameters and a usage history of the biological sample, the set of consent parameters and the usage historyDocket No.: 061935-502001 WO being posted on a blockchain; in response to receiving a request from a second entity to access the biological sample for processing, updating the usage history on the blockchain to record the access to the biological sample and / or the processing of the biological sample based on the set of consent parameters associated with the identifier; and providing the first entity with access to a user interface, the user interface being configured to present, upon receiving a query from the first entity, a response describing the updated usage history of the biological sample to the first entity.

Images