Biobank Operational Module

Definition:

The “Biobank Operational Module” – BOM – consists of software tools for organization of samples and related data in the context of a collection / study protocol. It includes functionality for sample acquisition and sample metadata management, sample processing (LIMS functionality), sample storage, sample and data retrieval/distribution and administrative tasks. If several parts of this functionality are covered within a single application, this is usually called a “Biobank Information Management System” (BIMS).

The requirements for the Biobank Operational Module (BOM) are described in the following sections:

Organize Collections, Studies and SOPs

Each collection has to be based on a specific study design, follow well-documented rules, and describe responsible stakeholders (including their roles), sample types, data formats, ontologies and business processes. The BOM should provide functionality to handle all this information in a version-controlled manner. Specific well-defined parameters should automatically parameterize the functional behaviour of the BOM.  The BOM shall provide a user management system, that defines users and what actions they are entitled to perform in the system.  The user management system should support user groups and roles.

The BOM shall provide functionality to

  • Define users, user groups and roles
  • Set-up and configure at least one collection  / study.
  • Store SOPs and other collection  / study related documents
  • Define material types and data objects handled by the collection / study.

The BOM may provide functionality to

  • Store and recover document versions.
  • Define administrative approval workflows.
  • Configure multiple collections / studies with a common database but specific user roles.
  • Support multi-tenancy, e.g. for hosted installations.

Sample Acquisition and Sample Metadata Management

Each sample and aliquot in a collection is related to a specific patient / donor  and to a  medical / study event. Basic information about patient / donors and medical / study data objects shall be available in the BOM, at least global unique identifiers for patients and medical/study events shall be provided for each sample and aliquot.

The BOM shall provide functionality to

  • Enforce a master global unique ID’s for each main entity:
    • sample/aliquot (physical objects stored in the biobank)
    • subject/patient/donor (origin of the sample)
    • medical/study event (entity related to the acquisition of the sample, e.g. a histological diagnosis, HL7 medical event, etc.)
  • Link multiple lDs denoting the same entity.
  • Upload and associate signed informed consent forms for human samples.
  • Store information about ownership, accessibility including veto-rights for samples and data.
  • Support for withdrawal, and altering of scope of patient consent.
  • Separate identifying data and non-identifying sample metadata, best in 2 disconnected databases.
  • Import samples with incomplete metadata.
  • Validate received samples and data and generate sample validation reports.

The BOM may provide functionality to

  • Bulk import samples and related metadata.
  • Generate barcodes and/or other machine readable IDs for stored objects.
  • Support documentation of pre-analytical steps and other quality as the sample’s physical condition on arrival, e.g. possible contaminations, thawing, leaks, volume and temperature.

Sample Processing

In a typical biobank environment, various kinds of procedures are carried out on samples, e.g. preservation procedures, generating aliquots and more complex processing such as deviation of the original material. To ensure that the fate of all of the sample material is known, each of these aliquots and sub-samples must be tracked and their relationship to the parent sample shall be recorded. It is also essential, for the chain-of-custody, to record the actions that have been applied to the sample and by whom. This functionality is usually supported by a LIMS. Even if all of the sample material has been consumed, this needs to be recorded, so that the processing history is known.

The BOM shall provide functionality to

  • Link aliquots to the parent-sample.
  • Link derived samples to parent-sample.
  • Distinguish between consumed / intermediate samples and samples preserved in the biobank.
  • Denote the processing SOPs of the study/collection design and record deviations.

The BOM may provide functionality to

  • Support the whole processing chain of a laboratory, typically handled by a LIMS.
  • Support calibration and processing device management.
  • Manage sampling kits, their assembly, components, labels and suppliers.

Sample Storage

After optional processing and validation steps samples are moved to (long term) storage. The BOM shall assist users to organize shelf spaces and to find stored samples again when they need to retrieve them. The system shall track sample locations and monitor freezing and thawing cycles, as well as disposal of them. For bigger biobanks automated systems and storage robots shall be supported.

The BOM shall provide functionality to

  • Store the location of samples at their storage location and container.
  • Track and monitor sample movements.
  • Print and read machine readable labels (barcode, RFID).
  • Monitor storage conditions and record deviations.
  • Manage and monitor storage devices.

The BOM may provide functionality to

  • Bulk import/export, e.g. by scanning of full boxes.
  • Store and retrieve sample with an automated system.

Data Integration and Cataloguing

The BOM shall provide functionality to import and integrate external data objects and generate a catalogue of physical and data objects available in the biobank. A catalogue shall include metadata elements collected in the sample acquisition process including sample availability and access conditions.  In addition biobanks metadata describing storage and quality parameters shall be included. A catalogue shall be available both at sample level and in an aggregated form and shall provide search functionality. Optionally an API to connect to an external sample locator and federated search functionality may be provided.

The BOM shall provide functionality to

  • Import and integrate external data objects.
  • Generate a searchable catalogue at sample level.
  • Generate a searchable catalogue at aggregated level.
  • Anonymize identifiable data for inclusion in the catalogue.
  • Search for biobank members and related researcher.
  • Include access information for samples and data. This should cover restrictions given by the informed consent and study/PI veto rights.
  • Generate descriptive statistical reports about samples and data stored in the biobank.
  • Export a description of all sample collection at aggregated level.

The BOM may provide functionality to

  • Support search for external researchers.
  • Inclusion of internal catalogue information in an external meta catalogue through a API sample locator).
  • Justification, that the risk of finding out the identity of the patient based on their data stored in an anonymized catalogue is below a threshold agreed by ELSI bodies and IRBs.

Sample / data retrieval and shipping

The BOM shall provide functionality to manage samples in transit between source and destination, for both receiving samples and redistributing them to authorized recipients. Shipping is related to the BOM sample chain of custody and storage inventory and the sample access management.

The BOM shall provide functionality to

  • Process a sample / data request.
  • Support workflow in sample / data delivery including approval steps.
  • Anonymization of data objects before transfer.
  • Generate and store sample and material transfer agreements.
  • Keep record of samples and data transfers.
  • Record the return of samples including date, person, change of the sample.

The BOM may provide functionality to

  • Semi-automatically check sample and data access permissions.
  • Support data validation and encryption before transfer.
  • Create a pick list for bulk distribution.
  • Supported automated retrieval with robotic devices.

Sample / Data retention and destruction

The BOM shall support a retention schedule for samples and data defining how long samples and associated sample records have to be kept.  Reasons for retention can be e.g. lack of resources (e.g. insufficient number of freezers), decrease of quality beyond accepted thresholds, withdrawal of consent by patient/donor or when a sample is lost or irrecoverable damaged.  Sample records, must not necessarily be destroyed with physical samples.

The BOM shall provide functionality to

  • Store metadata about planned sample/data retention.
  • Store sample retention and sample destruction records including the reason of retention or destruction.
  • Mark sample retention in sample data records.

The BOM may provide functionality to

  • Remove data objects also from backup storage.

Administrative and quality management support

The BOM shall support all administrative tasks of the biobank operation, including workflow and costumer management. The BOM shall provide functionalities that allow managers and auditors to monitor a biobank to ensure that it is used appropriately. The BOM shall provide a number of standard reports capable of being configured by authorized users. For instance, D1.2 provides the standard forms to be implemented in the system regarding consent and ethical approval for sample collection or studies on human samples.  The BOM may support the training and qualification of biobank members by tracking their qualifications and skill. With this the BOM may ensure that all procedures are carried out by well-trained persons.

The BOM shall provide functionality to

  • User management system and role definition for administrative processes (in addition to user role for a collection study).
  • Produce periodic reports.
  • Support quality management and accreditation.
  • Record security logs.

The BOM may provide functionality to

  • Billing and costumer management.
  • Support training and qualification tasks

Non Functional Requirements

Non-functional requirements such as Usability, Security, Contingency, Scalability and Sustainability are important for the success of a BOM.  The following cross-sectional check list may be useful in the planning and evaluation of a BOM.

Usability

  • How well are users satisfied with BOM components?
  • How long is the learning curve for BOM components?
  • How big is the training effort for BOM components?
  • Does BOM components provide training and help functionality?
  • What qualification is needed to use/operate a specific BOM component?

Security

  • Which authentication and security functionalities are provided by BOM components?
  • Does BOM components provide encryption functionally?
  • Does BOM components support authentication and cross component security mechanisms.
  • Does BOM components provide access and security logs?

Interoperability

  • Does BOM components provide proprietary and/or standard data exchange functionality?
  • Does BOM components provide  proprietary and/or standard APIs and protocols?

Contingency

  • How well can BOM components recover in case of system crashes, disruption or other disasters.
  • Does BOM components provide documentation of internal data structures?

Scalability

  • How well can BOM components support growth in amount of studies, samples, data objects and users?

Sustainability

  • How much effort is needed to keep the different systems running ofer a long time period of time?
  • For commercial software solutions: what is the anticipated life cycle of a  BOM component?
  • For open source solutions: How big is the user community of the BOM component?