On the surface, sample management does not appear to be so complex—after all, it isn’t rocket science, right? In reality, though, there is a huge diversity in sample management requirements (biobanking itself is a heavily overloaded term), so this blog post provides the key questions that will help you to define your requirements.
What kind of samples will be managed?
The diversity of sample collections is expanding, with increasing interest in biological samples (tissues, plasmids, serum, etc.), small-molecule compounds, biological and chemical reagents, and isotopes. All of these substance types have different properties that need to be recorded, as well as the substance relationships, e.g., from batches, salt forms, and source to derivations, transfections, etc. The physical parameters around these samples also differ greatly—e.g., volumes, concentrations, mass, dimensions, and container types—and the storage requirements will similarly vary, i.e., temperature, safety isolation, and humidity. The sample management system needs to be able to support these sample types, and it is essential that this information is elaborated upon at an early stage.
Where do the substance data reside?
It is good practice to separate out the substance information from the actual sample data. Fundamental properties of the substance need to be retained, even if no samples currently exist in the inventory. It is normal for database links to be set up such that only the required substance information can be viewed by the sample managers. It is bad practice to duplicate the substance data, with problems of concurrency; however, this may be necessary when a live data link cannot be established.
What type of container identification will be used?
If samples are to be retained for any period of time, then a suitable mechanism for uniquely identifying containers should be deployed. It is common for 1-D and 2-D printed barcodes to be applied to containers, but the choice of identification system will depend on the storage and handling environment, e.g., will the samples be covered in frozen condensation? If you are devising a new collection, it is strongly advised to simply ensure uniqueness of container identity and avoid any “smart coding,” as inherently there will be adaptations and reorganizations that will be harder to implement if you have a potentially obsolete coding scheme. It is much easier to change and expand such logical groups and sample data in a database.
How many samples will be managed?
There are many small collections that should continue to be managed using a spreadsheet-type mechanism with supporting SOPs and manual data recording. There are specific situations in which a few thousand samples must be accurately tracked, e.g., radioisotopes, clinical samples, or other high-value entities. For modest collections of samples, i.e., 100,000+ entities, managing the physical inventory is usually the driving factor. It is a matter of considering the consequences of choosing the wrong sample, and equally losing a valuable sample.
How often will the samples be used?
The usage patterns of the samples will vary with the application. Samples in large biobanks may only be requested on a few occasions in their useful lifetime, whereas key small-molecule compounds will be picked frequently. The combination of number of samples and the pick frequency will determine if an automated storage system is required. It is also a matter of the urgency to retrieve a sample—perhaps in a service environment there will be performance targets to meet, or maybe a sample needs to be retrieved and subdivided in a timely manner before it thaws. In this case, the sample management system will need to be closely integrated with any automated storage system.
Will the management of samples be centralized, as a service, or local, self-service?
This can distinguish between two different styles of sample management, but it is not always a black or white answer. It also prefaces two further questions:
- What is the topology of the inventory? (i.e., what is stored in which locations, from site to site, down to the level of shelf position?) and
- What kind of roles have to be managed? (i.e., who submits the samples, who is requesting the samples, and who retrieves and prepares the samples?)
The interaction each type of user has with the system must be appropriate, with easy-to-use interfaces and role-based access to carry out specific tasks.
Do the samples belong to multiple collections or sets, and how will these be managed?
Most sample collections are subdivided into logical sets, where samples are intended to be used for different purposes. There may be overlap across different sets, and the sets may be organized by container, by substance, or by batch. It is worth checking the precise nature of the collections and sets to ensure that the provided system will support the required business logic.
In some cases, the use of specific sets of substances has to be tied in with the sample requesting mechanism. Furthermore, there may be a need to create sets that have restricted access. Restrictions can involve reserving a minimum quantity, confining the use to a particular time period, or permanently restricting to a particular set of users. In the Mosaic system from Titian Software (London, U.K.), restrictions are managed three ways. When a restricted item is requested, it can either be denied, negotiated, or simply involve notifying the restriction holder. All of this business logic needs to be defined and tested against the potential solution.
What are the provisioning, replenishment, distribution, and disposal work flows?
The custodianship of the sample is the main thrust of this question. The system must support the samples through a defined period of their lifetime. If the samples need to be tracked from the point of creation, then there will be work flows that must be set up to record the sample inception. If the system is simply providing a check-in and check-out function, then of course the work flows are greatly simplified. For sample preparation, these work flows may include sample division, dilution, reformatting, QC checking, etc. Capturing such details adequately is where the majority of the system requirement analysis effort is spent; however, the ultimate suitability of a system is how well it can adapt to support these work flows, which will likely evolve over the system’s lifetime.
How much automated storage or instrumentation should be supported, and to what level?
A fully integrated sample management system may include automated storage and dispensing systems. Integrating each item will require careful consideration of the costs versus the benefits. An instrument may not need to be used very frequently or, perhaps when it is used, it is desirable for the protocols on the instrument to be generated automatically. There are choices to be made that will be a trade-off of up-front costs versus productivity, and minimizing handling or dispensing errors.
What other related informatics systems need to connect to the sample management system?
Sample management systems can often be a small part in a larger spiderweb of related systems. Sometimes these are used to hold substance information; they can also be systems for authenticating the user, sending e-mails, and receiving information about the items that have been prepared and issued by the sample management system. It is rare, for example, for Titian to provide a Mosaic system without any links to other systems. It is important to consider the interfaces that will be needed, what data will be exchanged, and how these can be achieved.
In considering these questions, I hope you will be empowered to compare the possible solutions for sample management and find a system that meets your specific needs. Inevitably I have probably succeeded in raising many more questions than you hoped needed to be answered.
David Booth is Regional Sales Manager, Europe, Titian Software; www.titian.co.uk.