Biobank Specimen Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does consent scope get left out of the first scope discussion?

Because it does not look like software. Inventory is visibly a system problem: positions, occupancy, barcodes, a pull screen. Consent looks like paperwork that lives in a document store, so it gets scoped as an attachment rather than as data, and the project ships with a perfect map of where everything is and no ability to say what may be done with it.

This is specific to biobanking because permission is not uniform across your own freezer. Consent carries research area restrictions, commercial use, genomic analysis, data sharing with named categories of recipient, future contact and the right to withdraw. Under the revised Common Rule, broad consent for storage and secondary research is its own construct, and institutions layer local policy on top. The result is one collection governed by several permission sets collected under several protocol versions across a decade.

The fix is to make consent structured before anything else. Turn each consent version into a permission set with effective dates, attach it to the participant, and propagate it down the derivative tree automatically so an aliquot inherits what its parent draw permits. Then check eligibility at request time and return the eligible subset plus an explicit list of exclusions with reasons. That single design decision is the difference between a distribution taking minutes and taking a week, and it is very hard to retrofit onto a system built around locations.

What goes wrong when you migrate twenty years of box maps?

The physical stock and the records stop agreeing, and nobody knows by how much until they start. A long running biobank typically holds inventory across a retired system, several spreadsheets maintained by people who have left, and occasionally a lab notebook. Reconciling those against what is actually in the freezer is real work with a real cost, and it is the single most common line missing from a biobank project budget.

Three things make it worse than a normal migration. Aliquot lineage is often implicit, recorded as a naming convention rather than as a parent link, so the derivative tree has to be inferred and verified. Freeze thaw history frequently exists only at box level, or not at all, which means samples arrive in the new system with unknown handling history. And consent linkage may never have been recorded per participant at all, only per protocol.

Scope it honestly. Migrate the collections you actively distribute from first, with full lineage and structured consent, and leave dormant collections for later or never. Where handling history is genuinely unknown, record it as unknown rather than defaulting to zero, because a scientist who later discovers that a freeze thaw count of zero meant no data will stop trusting every number in the system. Plan a physical audit of the freezers you migrate, and budget it as its own phase.

Why do scanner, printer and freezer monitoring integrations break after launch?

Because each one is a separate driver against a device that lives in a hostile environment. A whole rack two dimensional scanner, a cryogenic label printer and a freezer monitoring platform are three unrelated engineering problems, and a developer who has done one has not necessarily done the others. Vendors change firmware, labels behave differently at vapour phase temperatures than they did on the bench, and the freezer room usually has no network signal.

The failure mode that hurts most is silent. If the pull screen becomes slower than writing on a box lid, staff will write on the box lid, and inventory accuracy drifts until an annual audit nobody enjoys. This is not a discipline problem. It is a design problem, and it is entirely predictable.

Build for the room rather than the office. The pull screen has to work with a scanner in one hand and gloves on the other, and it has to work offline and reconcile afterwards, because signal in a freezer room is not something you can fix with policy. Name the specific scanner, printer and monitoring platform in the contract rather than accepting the phrase hardware integration. Then treat monitoring telemetry as a first class feed, because anomaly detection on compressor duty cycle is genuinely useful: a failing unit usually announces itself in the duty cycle before it announces itself in the temperature.

What happens when withdrawal and chain of custody are not covered?

You end up unable to honour a commitment you made to a participant. Withdrawal is the test that separates a lineage graph from flat inventory rows. A whole blood draw becomes plasma, serum and buffy coat, the buffy coat becomes extracted DNA, the DNA is normalised into a working plate, and an aliquot of that plate went to a collaborator eighteen months ago. When the participant withdraws, you must identify every physical object descended from that draw, know which remain in your possession and which were distributed, to whom and under which agreement, and then apply your withdrawal policy, which may differ by jurisdiction and protocol.

Chain of custody fails in a quieter way. Samples move from collection site to processing, to storage, to a courier, to a collaborator across a border, and each handoff is owned by a different party with a different system. Category B biological material travels under UN3373 packaging and documentation rules, dry ice carries dangerous goods handling requirements, and dry shippers have a charge window that constrains transit time. If none of that is modelled, an excursion on arrival becomes an email rather than a control.

Model the shipment as a first class object with contents by aliquot, packaging type, logger identity, expected transit window and a receipt step where the recipient scans in and the logger readout is attached. Excursions should quarantine the affected aliquots automatically and hold them until a named person releases them with a documented rationale.

Should you build custom or configure Freezerworks or OpenSpecimen?

Some biobanks should not build, and the line is clear. If you run a single collection under one protocol with one consent version across a handful of freezers, buy Freezerworks. It is mature, focused, handles inventory and freeze thaw history well, costs a fraction of a build, and your consent question has one answer that a person can hold in their head. Spend the difference on a backup freezer, which will do more for the collection than any software.

If you have informatics capacity in house and your requirements sit close to its model, OpenSpecimen deserves a serious look. Its biospecimen data model is genuinely good, and it is the right first call for a research institute testing whether it needs more, provided you accept that hosting, validation and any institution specific extension are yours to carry. LabVantage Biobanking and LabWare LIMS are capable enterprise systems where biobanking sits as configuration, which suits organisations that already run one of them and can absorb a configuration project when the consent model changes.

Build when permission, rather than location, is what determines the value of your collection. That means consent scope varies across collections, a wrong distribution would be a reportable event rather than an embarrassment, you hold derivatives of derivatives and cannot currently answer a withdrawal completely, or you operate across sites and jurisdictions with different privacy regimes.

How do hidden costs get into the quote?

Five places, and legacy migration is the largest. After that: hardware integration, because each scanner, printer and monitoring platform is its own driver with its own maintenance. Clinical data linkage, if you want annotations from an electronic health record or registry, because that needs an honest broker layer between identifiable and coded data and is closer to a project than a connector. Multi site operation with different consent regimes, since each site is a policy exercise as well as an engineering one. And processing workflows, if the biobank also runs plate or instrument level work, which pulls the system toward being a laboratory information management system.

Defend against all five by naming them. Put the migration scope in writing, collection by collection. Name the hardware. Ask specifically whether an honest broker layer is in or out. And ask what happens when a second site with a different consent regime is added, because the answer tells you whether permission was designed as data or hard coded around your first protocol.

What separates a biobank build that works from one that fails?

The builds that work start with the model. Ask a developer to whiteboard it before anything else. A partner who has done this draws participant, consent version with permissions, collection event, parent specimen, aliquot, derivative, container position and distribution, and they raise withdrawal without being prompted. A partner who draws samples and locations has built a warehouse system and will hand you one.

They also attach handling history to the individual aliquot rather than to the box, because that is the difference between a sample a scientist trusts and one they do not. And they treat distribution as a governed decision with an eligibility check, a recorded committee outcome and an agreement reference, rather than a warehouse pick. The by product of doing that is utilisation reporting, which is the artifact biobank directors are judged on and which very few can produce.

Finally, settle ownership before kickoff: the repository, the infrastructure accounts and a tested full data export. At Digital Heroes the client owns everything from the first commit. Your inventory and consent data must outlive any software vendor, including the one who builds it, because the samples will.