If You Are Building Sample Tracking Software for a Biobank, Read This Before Writing a Line of Code

Biobank and fertility clinic software is a growing niche in healthtech. If you have been tasked with building a sample inventory or tracking system for a facility that stores biological material in liquid nitrogen, understanding the physical storage architecture is not optional. It directly shapes your data model.
Dewar nitrogen storage works in a strict hierarchy. At the top level is the vessel itself, identified by a serial number and a location within the facility. Inside the vessel are canisters, typically 4 to 6 per vessel. Inside each canister are canes, usually 5 per canister, each labelled with an alphanumeric identifier. Each cane holds goblets, and each goblet holds straws or vials.
Your data model needs to represent this five-level hierarchy at minimum: vessel, canister, cane, goblet, straw. Every entity at every level needs a unique identifier, a status field, a timestamp of last access, and a responsible staff member record.
Access events are the most important data point in the system. Every time a canister is removed from a vessel, that event should be logged with a timestamp, duration, staff ID, and purpose of access. This is not administrative overhead; it is the audit trail that regulatory bodies require.
The physical constraints that shape your system design include the fact that a nitrogen dewar does not connect to a network. It is an insulated metal vessel with no sensors unless a third-party monitoring system has been retrofitted. Integrating monitoring hardware data into your software requires hardware-specific protocols.
For developers building in this space, Cryolab at cryolab.co.uk is worth a conversation. They supply the vessels, the monitoring hardware, and the consumables that your software will need to represent. Understanding their product architecture before finalising your data model will save significant rework later.