Clinical Trial Sample Tracking: LIMS, Spreadsheets or Custom Software?
Choosing clinical trial sample tracking software: when spreadsheets stop working, what a LIMS does well, when custom software fits, and what every option must meet.
Key Takeaways
- Clinical trial sample tracking has to answer three questions at any moment: where is this sample, who is responsible for it, and how do we know? Whatever tool you choose is judged on those.
- Spreadsheets break down once several sites, couriers and labs edit the same records: there is no reliable audit trail, no scoped access and no single version of the truth.
- A LIMS is strong inside the laboratory: accessioning, storage locations, instruments, testing workflows. It is often weaker at the part that crosses organisations: sites, shipments and confirmations between parties.
- Custom software fits when the hard part of your process is the movement of samples between organisations, or when your workflow is specific enough that configuring a LIMS costs more than building the missing piece.
- Any option must provide audit trails, unique user accounts, scoped access and no patient data where it doesn't belong. Those expectations come from 21 CFR Part 11, ICH E6(R3) GCP and the GDPR.
Clinical trial sample tracking is the record of every biological sample collected in a study: where it was taken, how it travelled, who held it at each step, what was done with it and where it is now. Get it wrong and samples are lost, analyses are delayed, and an inspection turns into an archaeology project. This guide is for sponsors, biotech companies, central labs and CROs deciding between spreadsheets, a laboratory information management system (LIMS) and custom software. It draws on the clinical sample tracking platform we delivered in October 2026; the architecture behind it is described in building clinical sample tracking software.
What any clinical sample tracking system must do
Whatever you choose, check it against these requirements:
| Requirement | Why it matters | What to verify |
|---|---|---|
| Complete sample history | You must be able to explain every status, correction and transfer later | Corrections keep the original value and a reason; nothing is silently overwritten |
| Chain of custody across organisations | Samples move between sites, couriers and labs | Shipments record who sent what, who received it, and that both sides agree |
| Audit trail | Regulators expect computer-generated, time-stamped records of who changed what | The trail is written automatically and can't be switched off or edited by users |
| Unique accounts and scoped access | Each site should see only its own studies and samples | Access rules per study and per site, tested for every role |
| Data minimisation | Sample records often sit next to personal data | Samples identified by codes; no patient data in emails, exports or logs that don't need it |
| Integrations | Labs, couriers and data platforms need the same information | An API or import path that applies the same rules as the user interface |
The audit-trail expectations are spelled out in the US FDA's 21 CFR 11.10, which asks for secure, computer-generated, time-stamped audit trails that record operator entries and actions, and for access limited to authorised individuals. The ICH E6(R3) guideline on good clinical practice, in effect in the EU since 23 July 2025, expects computerised systems used in trials to be fit for purpose and their data traceable. In Europe the GDPR adds data minimisation and pseudonymisation. Software provides the technical controls; compliance also depends on validation, procedures and how the system is used.
Option 1: Spreadsheets and email
Most studies start here, and for a single site with a handful of samples it can be enough.
It stops working when:
- several sites, a courier and a lab all need to update the same records;
- you need to prove who changed a value and why, and the answer is "someone edited the shared file";
- shipments are reconciled by comparing two spreadsheets and an email thread;
- a site sees another site's data because access is per file, not per row;
- the person who understands the spreadsheet goes on holiday.
The signs are usually operational before they are regulatory: samples arriving that nobody expected, or expected samples that never arrive and nobody notices for weeks.
Option 2: A LIMS
A laboratory information management system is built around what happens inside a lab: receiving and accessioning samples, storage locations (freezer, rack, box, position), aliquoting, test requests, instrument results and quality control. Established LIMS products are mature, widely validated in regulated environments and supported by vendors who understand inspections.
Where a LIMS fits well:
- your main problem is sample management inside one or more laboratories;
- you need storage, testing and instrument workflows more than cross-organisation logistics;
- you have the budget and internal capacity for configuration, validation and licences;
- you want a vendor-supported product rather than software you own.
Where it can struggle:
- Sites as users. Giving dozens of clinical sites scoped access to a laboratory system is possible but often clumsy, and licences may be priced per user.
- Shipments between organisations. Two-party confirmation, courier tracking and reconciliation between what a site sent and what a lab received are often handled outside the LIMS, which brings the spreadsheet back.
- Configuration cost. A LIMS is configured, not built, but heavy configuration for a specific workflow can take as long and cost as much as a focused custom build, and still leaves you dependent on the vendor for changes.
Option 3: Custom software
Custom software fits when the hard part of your process is specific to you, or sits between the systems you already have. In our client's case the samples were analysed in its own lab, and the problem was the journey from clinical centers to that lab: who collected what, which shipment it was in, whether both sides agreed on the contents, and what had arrived.
Where custom software fits well:
- the critical workflow is cross-organisation: sites, couriers, labs and sponsors working on the same records;
- your process has rules a product doesn't model well, such as statuses that must be derived from shipments rather than typed in, or confirmations that are voided when a shipment changes;
- you need to own the system and its data model, and change it as studies evolve;
- you already have a LIMS or lab system and need the piece that feeds it.
What it requires:
- a team that understands audit trails, access control and validation, not only web development;
- documentation that lets someone else take the system over. On our project the handover included 25 recorded architecture decisions and 14 handover documents, and more than 180 unit tests covering the business rules;
- a plan for hosting, backups and support once it is live.
Our client's platform went from spreadsheets to production in three months.
A quick way to decide
| Your situation | Likely fit |
|---|---|
| One site, few samples, short study | Well-structured spreadsheets, for now |
| Main pain is inside the lab: storage, testing, instruments | LIMS |
| Main pain is between organisations: sites, shipments, confirmations | Custom software, or a custom layer next to an existing LIMS |
| Highly specific workflow that changes from study to study | Custom software |
| Large organisation with validation teams and an approved vendor list | LIMS, possibly with custom integrations |
These options aren't exclusive. A common, sensible architecture is a LIMS for the lab and a focused custom application for sites and shipments, connected through an API.
Questions to ask any vendor or builder
- How is the audit trail written, and can any user, including administrators, edit or disable it?
- How is access scoped per study and per site, and how is that tested?
- How are shipments confirmed by both parties, and what happens when a shipment changes after confirmation?
- What personal data does the system store, and where does it appear (emails, exports, logs)?
- Do the API and spreadsheet imports apply exactly the same rules as the user interface?
- What documentation and validation support do we receive?
- Who owns the code and the data, and how do we leave? See who owns the code.
Frequently asked questions
Is a LIMS required for clinical trials? No regulation requires a specific type of software. What's required is that the records are reliable, attributable and traceable, and that the systems holding them are fit for purpose. A LIMS is one way to get there, not the only one.
Can custom sample tracking software be 21 CFR Part 11 compliant? Software can provide the technical controls Part 11 expects: audit trails, unique accounts, access limited to authorised people. Compliance also depends on validation, procedures and how the system is operated, which is true of a LIMS as well.
How long does it take to build a custom sample tracking system? It depends on scope. Our client's platform took three months from start to production; a system with storage management, instrument integration or many external integrations would take longer.
How do you handle shipments of biological samples between sites? In the software, by making each shipment a record that both parties confirm and from which sample statuses are derived. Physically, packaging and labelling follow transport regulations for biological substances; the WHO guidance on the transport of infectious substances summarises them.
FNB Solutions builds software for life-sciences teams where traceability matters. See our life sciences page and the clinical sample tracking case study, or tell us about your study.
Sources
- 21 CFR 11.10, controls for closed systems (Cornell Law School, Legal Information Institute)
- ICH E6 good clinical practice, scientific guideline (European Medicines Agency)
- Regulation (EU) 2016/679 (GDPR)
- WHO, guidance on regulations for the transport of infectious substances 2021–2022