Chapter 8

Chapter 8: The Future of Biobanking and the WIA-BIO-019 v1.x Roadmap

The previous seven chapters described WIA-BIO-019 v1.0 as it is and showed how to run a biorepository on it. This last chapter looks ahead. It covers the technical and social forces that will reshape biobanking, the gaps in v1.0 that should be closed before those forces arrive, and a staged plan a hospital biobank can follow to adopt the standard.

A forward-looking chapter can easily turn into speculation, so this one follows three rules. First, it does not repeat the mechanics already covered: the data model (Chapter 3), the interfaces (Chapter 4), the lifecycle protocol (Chapter 5), governance and integration (Chapter 6) and conformance (Chapter 7). It refers back to them instead. Second, anything that goes beyond the published specification is labeled as a proposal or as book commentary. None of it is normative. Third, the chapter uses no market figures, adoption percentages or energy numbers, because the inputs to this book contain no source for them. Where the direction of a trend is well established but its size is not, the text says only which way it points.

8.1 Automation: When a Robot Holds the Tube

Automated cold stores and robotic picking

In most biobanks, retrieving a sample still means a person opens a −80 °C freezer, pulls out a rack, finds a box and picks a tube. Every step lets warm, humid air into the cabinet, and the neighbours of the target tube warm briefly while the rack is out. Automated cold stores change this. Tubes sit in a sealed, temperature-controlled store, and a robot picks them inside an enclosed handling zone that stays well below room temperature. The operator requests a list of tubes and receives an output rack. Nobody opens the storage volume.

For WIA-BIO-019 this has two consequences. The first concerns quality. The v1.0 model has no way to record that a sample stayed in its box while that box sat on a bench for four minutes. temperatureExcursions[] in QualityMetrics is attached to a sample only when someone chooses to attach it. Automation shrinks this hidden exposure, and the store's own logs can often show exactly which positions were moved. Such a store is therefore a better source of excursion data than the manual process it replaces.

The second consequence concerns the chain of custody. In the SDK, CustodyEvent.operator is a free-text string, and the spec's §7.1.2 lists an "Operator ID" among the required fields. When a machine performs the retrieval, the event has two actors. One is the person or service that authorized the pick. The other is the device that carried it out. Recording only one of them loses information an auditor will want later. A v1.x revision should separate the two, for example with an operator for the accountable human and an agent for the instrument, with its firmware version when that is available.

RFID and bulk inventory

§7.2 of the spec already names passive UHF tags on freezer boxes, active tags with temperature sensors and bulk reading as "advanced" tracking options. Bulk reading turns an inventory check from a tube-by-tube exercise into a single scan of a rack or box. The data problem is that one scan produces presence confirmations for dozens or hundreds of samples at once. If each confirmation becomes a CustodyEvent with its own hash, every sample's chain grows at every inventory sweep, and those events carry almost no information.

A better approach is to treat a sweep as a single container-level event (a box was seen at a location at a time) and to link each sample's chain to it only when something unexpected is found: a missing tube, a tube in the wrong box, or a temperature reading from an active tag outside its band. This is also how CustodyAction.QUALITY_CHECK is most naturally used. A clean check leaves the chain alone, and a failed check writes an entry.

What changes in the event log

Situation	Manual practice today	With automation	Suggested v1.x handling
Retrieval	One retrieval event; operator = technician	Pick performed by the store's robot on request	Record both the requesting person (operator) and the device (agent)
Neighbouring tubes	Warming of tubes in the same rack goes unrecorded	Store logs report which positions were moved	Attach a short exposure record to affected samples when the store reports one
Inventory audit	Periodic tube-by-tube scan; rarely logged per sample	RFID bulk read of boxes and racks	One container-level event per sweep; per-sample event only on a discrepancy
Temperature	Cabinet logger (§7.3, 1-minute interval)	Cabinet plus handling-zone logs, and sometimes tag sensors	Feed all streams into the sample's time-temperature history (Section 8.3)

8.2 Federated Networks and Data Visiting

From shipping tubes to visiting data

The classic distribution flow described in Chapter 5 moves physical material. A researcher submits a SampleRequest, the access committee reviews it, a Material Transfer Agreement (MTA) is signed, and aliquots leave the building. That flow will remain necessary for wet-lab work. A growing share of the value of a collection, however, now lies in data already derived from it: genotypes, sequence reads, proteomic profiles, digitised histology. Much of that data cannot leave the institution freely either, because it is personal data under regimes such as GDPR, or because the consent does not allow it.

Data visiting reverses the direction of travel. The analysis goes to the data, runs inside the holding institution's controlled environment, and only aggregate or otherwise approved results come back. Across several biobanks, this becomes federated analysis: the same code runs at each site, and a coordinator combines the partial results. No specimen and no row-level record crosses a border.

Mapping onto the federated-mesh topology

The PHASE documents shipped with v1.0 carry the wrong standard ID and are template text (see Chapter 4 and Section 8.4). Their Annex J, which is non-normative, still describes four deployment shapes that suit a network of biobanks. In the federated mesh, each participating biobank runs its own runtime and publishes a signed profile manifest to a shared directory service. The directory signs the aggregated index, and callers route each request to the least-common-denominator profile that every participant supports.

Applied to a multi-site network, each hospital biobank is a peer. The directory lists which sample types, storage conditions and consent purposes each peer can serve, but never lists donors. A researcher's query is answered in two steps. The directory first says which peers might have matching material under compatible consent. Each peer then answers the detailed InventoryQuery locally, applying its own validateConsent logic. The air-gapped batch topology from the same annex fits sites whose rules forbid live connectivity: they publish periodic signed extracts that the directory ingests out of band.

What federation needs from the standard

• Machine-readable consent purposes. In v1.0, Consent.purposes is a free array of strings, and validateConsent accepts a match or the wildcard 'any'. Two sites that spell "cancer research" differently will never match. A controlled vocabulary is needed. The GA4GH Data Use Ontology (DUO) is one existing option to map onto, and a v1.x revision could adopt it or define a WIA list with an explicit mapping.
• Directory-level attributes. MIABIS (listed in the spec's §11.4) defines the minimum information for describing biobanks and collections to a directory. Chapter 6 gave a field mapping from Sample. Federation needs the collection level too: counts per type, age ranges and consent categories, all published without identifiers.
• Portable integrity evidence. If a peer's samples or derived data are used in a pooled study, the other parties need to trust its custody records. That is impossible while the hash computation itself is implementation-specific (Section 8.4).
• Result-release rules. Data visiting shifts risk from shipping to output checking. The standard currently has no object for "an analysis request" or "a released result". Both could be modelled next to SampleRequest, with the same access-committee states.

8.3 A Digital Twin for Every Sample

Why a single ΔT is not enough

The Sample Integrity Score of §6.1 multiplies a quality ratio, a temperature factor and a time factor. Chapter 3 showed that the temperature factor uses one number, ΔT, the deviation from the optimal temperature. It does not say whether the deviation lasted one minute or one month. Two cases stored at −80 °C make the problem concrete. Both use the spec's own example value T_max = 10 °C.

• Case A — a one-hour alarm. A compressor fault lets the cabinet reach −60 °C for about an hour before the samples are moved. ΔT = 20 °C, so the temperature factor 1 − 20/10 is negative, and the SDK clamps it to 0. The SIS is 0, "poor", and the guidance is to consider discarding.
• Case B — a quiet drift. A door gasket wears and the cabinet runs at −77 °C for a week. That is inside the ±5 °C tolerance of §4.2.1 and never crosses the −75 °C alarm of §7.3. If ΔT = 3 °C is recorded at all, the factor is 0.7, and a sample that was otherwise "excellent" falls to "acceptable" or below.

Neither verdict follows from chemistry. Degradation depends on how long the sample spent at each temperature, weighted by how fast the relevant reactions run at that temperature. A digital twin of a sample, meaning a continuously updated record of its time-temperature history plus a model that turns that history into an expected quality, can capture this. The 1-minute loggers the spec already requires (§7.3) provide the input.

Proposal: Arrhenius-equivalent storage age

Choose a reference temperature T_ref, normally the set point of the sample's storage condition (193.15 K for −80 °C). Each logger interval i of length Δt_i at absolute temperature T_i is converted into an equivalent time at the reference temperature:

t_eq = Σ_i  Δt_i · exp( (Ea / R) · (1/T_ref − 1/T_i) )

Q(t) = exp( −k_ref · t_eq )          (first-order loss, k_ref measured at T_ref)

When the sample stays at the reference temperature, the exponential equals 1 and t_eq is simply the calendar age. Warmer intervals count for more than their clock time, and colder ones for less. The quality estimate Q then depends on one kinetic constant measured at the reference temperature, not on a linear fraction of shelf life.

For illustration only, take the spec's DNA activation energy (Ea = 80 kJ/mol, from the §6.2.2 parameter table, whose values have no cited source). At that Ea, an hour at −60 °C counts as about 107 hours at −80 °C, or roughly 4.5 days. A week at −77 °C counts as about 15 days. Under this model the quiet drift in Case B ages the sample more than the alarm in Case A, the opposite of what the SIS says. The example does not prove the drift is harmless or harmful. Its point is that a duration-weighted measure can rank the two events, and a single ΔT cannot.

Sketch implementation

The code below turns a series of logger readings into an equivalent age. It is intentionally short: in practice the readings would come from the monitoring system, and the result would be stored next to the sample's QualityMetrics rather than replacing them.

// Proposal only: Arrhenius-equivalent storage age (not in @wia/bio-019 v1.0)
interface LoggerReading {
  t: string;        // ISO 8601 UTC timestamp, e.g. from a 1-minute logger
  celsius: number;  // cabinet or position temperature
}

const R = 8.314; // J/(mol·K)

export function equivalentAgeDays(
  readings: LoggerReading[],
  eaKJPerMol: number,
  refCelsius = -80
): number {
  const tRef = refCelsius + 273.15;
  let minutes = 0;
  for (let i = 1; i < readings.length; i++) {
    const dtMin = (Date.parse(readings[i].t) - Date.parse(readings[i - 1].t)) / 60000;
    const tK = readings[i - 1].celsius + 273.15;          // left-endpoint rule
    const factor = Math.exp(((eaKJPerMol * 1000) / R) * (1 / tRef - 1 / tK));
    minutes += factor * dtMin;
  }
  return minutes / 1440;
}

The twin then keeps a small derived record per sample. The values below are an example: a sample five years old in calendar terms that went through both events from the cases above.

{
  "sample_id": "SAM-7Q2K9D",
  "model": "arrhenius-equivalent-age/0.1-proposal",
  "reference_temp_c": -80,
  "ea_kj_per_mol": 80,
  "calendar_age_days": 1826,
  "equivalent_age_days": 1838.4,
  "readings_used": { "source": "logger", "interval_s": 60, "gaps_filled": false },
  "sis_v1_0": { "score": 0.0, "interpretation": "poor", "note": "single-ΔT factor clamped" }
}

In the record, v1.0's SIS still appears next to the proposed metric. During adoption both can be computed in parallel, a "shadow mode", so that the laboratory can see where the two disagree before it changes any decision rule.

Limits of the model

• Kinetic parameters must be measured, not assumed. The k and Ea values in §6.2.2 carry no cited source. Chapter 3 also showed that the v1.0 "half-life" column is just ln 2 / k with no temperature term. A twin is only as good as the stability data behind it, and those data differ by analyte, not only by sample type.
• Arrhenius behaviour does not hold across phase changes. Frozen biological material goes through glass transitions and changes in ice structure. Extrapolating one Ea from room temperature down to cryogenic temperatures is not reliable. The model is safest over the range where it was calibrated.
• Cabinet air is not the sample. A logger measures one point in the cabinet. A tube near the door experiences more than the probe does. Temperature mapping (§7.3 recommends it quarterly for critical equipment) or position-level sensors reduce this error but do not remove it.
• Freeze-thaw is a separate mechanism. The limit of three freeze-thaw cycles for proteins (Chapter 2) is not captured by an integral of temperature over time. A twin needs a separate counter for thaw events, fed by custody actions such as retrieval and return.

8.4 Known Gaps in v1.0 and Fixes for v1.x

Every chapter of this book has flagged places where the published v1.0 material is inconsistent, incomplete or wrong. This section brings them together in one list for implementers and for whoever drafts the next revision. The table does not grade severity with numbers. The "impact" column says what goes wrong in practice.

Issue in v1.0	Impact	Proposed fix	Discussed in
SQI formula exp(−k·t·exp(Ea/RT)) has the wrong sign in the inner exponent (spec §6.2.1, README, SDK calculateStorageQuality, CLI)	At every storage temperature Ea/RT is large (about 50 for DNA at −80 °C), so SQI collapses to 0 for any storage time greater than 0; colder storage is not rewarded	Use k(T) = kref·exp(−Ea/R·(1/T − 1/Tref)) with kref measured at a stated reference temperature; add monotonicity test vectors	Ch3 §3.6, Ch7 §7.5
"Half-life at −80 °C" column and halfLife_80C constants	Values equal ln 2 / k with no temperature term and contradict the spec's own RNA duration (Appendix B)	Remove the column, or recompute it from measured stability data at stated temperatures	Ch3 §3.6
SIS time factor is linear in shelf life	A perfect sample at half of tmax can never score above 0.5, so it is labeled "poor" whatever its real condition	Replace it with a factor from kinetics (Section 8.3), or with 1 inside a validated storage window	Ch3 §3.5
SIS uses a single ΔT	Duration of the excursion is ignored; a one-minute blip and a week-long drift score the same	Duration-weighted excursion measure (equivalent age), computed from logger data	Ch3 §3.5, Section 8.3
SIS example uses A260/A280 = 1.85 as "viability"	The SDK rejects values above 1 with an error, so the spec's own worked example cannot be run	Define a normalized quality ratio per metric, or accept any positive V0, Vt and document the ratio	Ch3 §3.5, Ch4 §4.6
Custody hash is not canonical: spec uses snake_case fields, SDK calculateEventHash uses camelCase plus id and notes; both rely on JSON.stringify key order	Two conforming implementations produce different hashes for the same event; cross-site verification is impossible	Normative field list and canonical serialization (for example RFC 8785 JSON Canonicalization Scheme); fixed timestamp precision; test vectors with expected digests	Ch5 §5.3–5.4
Bare hash chain with an optional signature	Anyone able to rewrite the whole chain can recompute every hash; the chain alone cannot prove the absence of tampering	Make event signatures (for example Ed25519, RFC 8032) mandatory at a stated conformance level, and/or periodic external anchoring such as RFC 3161 time-stamps	Ch5 §5.4
generateSampleId() returns SAM-<timestamp>-<random>	Contradicts §8.3.1, which requires IDs with no embedded date or sequence; the ID reveals when the sample was registered	Generate random IDs from a cryptographic source only; keep registration time in its own field	Ch3 §3.3
PHASE-1..4 documents carry ID WIA-BIO-018, and their titles do not match their file names	Readers cannot tell which requirements apply; template numbers (accuracy, AUC, rate limits, base URL) look normative but are not	Rewrite the PHASE documents for BIO-019 from the spec's own sections, or withdraw them	Ch4 §4.2, Ch7 §7.6
README, SDK and CLI disagree: SampleType.BLOOD/TISSUE do not exist; README CLI flags --current-viability, --storage-type differ from the script	Copy-pasted examples fail on first use	Generate README examples from the SDK types and the CLI's help output; test them in CI	Ch4 §4.5–4.6
Inventory response shows "total_count": 2,450; section numbered "9.9.2"	Invalid JSON in a normative example; confusing references	Editorial erratum: 2450, renumber to 9.1.2	Ch4 §4.1, §4.6
No normative conformance levels	"Conforms to WIA-BIO-019" means nothing checkable; certification has no defined bar	Define named conformance classes (for example data model only; plus custody; plus API) with required test vectors for each	Ch7 §7.5–7.7
Consent is checked only at registration and when validateConsent is called	Withdrawal does not propagate to aliquots or pending requests automatically	Normative withdrawal propagation rules and a custody action for consent-driven destruction or quarantine	Ch6 §6.2
Referenced editions: ISO 15189:2012, ISBER Best Practices 4th ed.	Both have been superseded (ISO 15189:2022; ISBER 5th edition)	Update the references and review any clause that depended on the older text	Ch7 §7.1
ULT freezer "Power: 6–15 kW" (§4.2.1)	Implausible for a single −80 °C unit; misleads facility planning	Remove it, or replace it with a sourced range and its measurement conditions	Ch2 §2.6, Section 8.6

Sequencing the fixes

Not all of these fixes are the same kind of change. The template Annex H in the PHASE documents describes Semantic Versioning 2.0.0 for WIA standards. It is non-normative and mislabeled, but the principle is standard practice, and applying it separates the list into three groups.

• Editorial errata (patch level). The invalid JSON, the section numbering, outdated edition references and the README examples. None of them changes what a conforming implementation must do.
• Additive requirements (minor level). The agent field, consent-purpose vocabularies, digital-twin records and conformance classes. Existing data stays valid, and new fields are optional until a later major version.
• Breaking corrections (major level). The SQI formula, the SIS time factor and the canonical custody hash. They change computed values, so a v2.0 is the honest label. The alternative is a clearly flagged v1.x correction that states the old outputs were never meaningful. Existing custody chains should not be rehashed: the old hashes stay verifiable under the old rule, and new events follow the new one from a recorded changeover point.

8.5 Ethics Ahead

Dynamic and electronic consent

A single signature at the time of collection, as in broad consent, is still the norm. Its weakness is that the donor's relationship with the biobank ends on the day they sign. Dynamic consent keeps that relationship open. Through a portal or app, donors can see how their samples are used, change their preferences, and receive requests for new kinds of use. Electronic consent capture, which §8.1.2 already mentions ("electronic capture with audit trail"), is the technical base for it.

The v1.0 Consent object is closer to supporting this than it may look. It has formVersion, withdrawalDate, purposes and several yes/no fields. What it lacks is history. A consent record describes the current state, but it does not show which state applied when a given aliquot was distributed. A dynamic-consent implementation should treat each change as a new, versioned consent record and link every distribution to the record in force at that moment. The custody chain is the natural place for that link.

Return of results

Consent.returnResults is a single boolean. In practice, returning individual research results raises harder questions. Is the finding clinically actionable? Was it confirmed in a clinical-grade laboratory? Who explains it to the donor? What happens if the donor has since died or cannot be reached? A future revision could replace the boolean with categories, for example: no return; return of clinically actionable findings only, after confirmation; or return on request. Each category would need a named governance route. The standard should not decide these ethical questions, but it should record the donor's choice precisely enough that the governance body can act on it.

Commercialization and benefit sharing

§8.1.2 lists "commercialization potential" as information donors must receive, and Consent.commercialUse records their answer. The ethical debate has moved beyond this yes/no question. It now asks whether donors or their communities should share in the benefits when research leads to a product, and in what form: access to resulting therapies, investment in local research capacity, or public reporting of what was done with the collection. A standard cannot settle this, but it can make it traceable. If every distribution records its commercial or non-commercial purpose, and derived datasets and products keep a link to their source collection, a biobank can later show where its material went.

Community and indigenous data sovereignty

Consent in v1.0 is individual: a Consent belongs to one donor. Some communities, especially indigenous peoples, hold that decisions about their collective biological heritage cannot be made one person at a time. The CARE Principles for Indigenous Data Governance (Collective benefit, Authority to control, Responsibility, Ethics) express this view and are designed to complement the FAIR principles that the PHASE documents mention. For a biobank this can mean a second layer of authorization: a community-level agreement that must be valid as well as the individual consent. Data-model support would be modest (a reference from the collection to the governing agreement and a check in the request workflow), but without it, the agreement lives on paper, outside the system that enforces access.

8.6 Sustainability

Cold storage runs continuously for decades. A biobank's environmental footprint is therefore driven less by any single experiment than by the size and temperature of the fleet it keeps running. This section stays qualitative on purpose. The inputs to this book give no sourced energy figures, and the one power figure in the spec (6–15 kW per ULT freezer) is implausible for a single unit, which Section 8.4 flags.

ULT fleets and the −70 °C set-point debate

Ultra-low temperature freezers are among the largest continuous electrical loads in many research buildings. Some institutions have raised the set point of suitable units from −80 °C to −70 °C and report lower energy use and less compressor stress. The argument is that many sample types show no measurable difference between the two temperatures. The counter-argument is that the extra margin at −80 °C buys time during a failure. The spec's emergency procedure (§10.3.1) triggers transfer when a unit rises above −70 °C, so a unit already running at −70 °C has no buffer left under the v1.0 rule.

A standard can help by making the decision explicit rather than implicit. If the set point changes, several v1.0 values that assume −80 °C must move with it: the ±5 °C tolerance, the −75 °C alarm threshold, the optimal temperature used for ΔT in the SIS, and the reference temperature of any kinetic model. The equivalent-age approach in Section 8.3 gives a way to judge the change sample type by sample type rather than by habit.

Liquid-nitrogen supply risk

LN₂ storage has no electrical dependency (§4.1.1), which is why the spec recommends it for irreplaceable samples. In exchange it depends on regular deliveries. Supply disruptions, delivery gaps over holidays and price changes are real operational risks. §10.3.2 already treats an LN₂ shortage as an emergency. A sustainability-minded revision could add, for example, a minimum on-site reserve expressed in days of consumption, set by each biobank from its own usage records, plus a documented decision rule for which samples leave LN₂ first if the reserve runs low. That rule belongs to the same family as the freezer-failure priority list in Chapter 5.

Inventory hygiene as an environmental measure

The cheapest freezer is the one that is not needed. Samples in depleted or destroyed status in the database while their empty tubes still occupy space, boxes with no active consent behind them, and duplicate aliquots no study will ever request all consume cold capacity. The getInventorySummary call (Chapter 4) and the lifecycle states (Chapter 5) already give a biobank what it needs to find them. A periodic review of low-value holdings, run through the access committee and recorded with destruction custody events, is both good governance and good resource management. The README's relative cost factors (5× for LN₂ down to 0.1× for ambient) are an index of relative expense, not of energy, but they point the same way: every sample moved to the warmest condition its science allows frees colder capacity.

8.7 An Adoption Roadmap for a Hospital Biobank

The last section turns the book into a plan. The timeline below is illustrative. It suits a hospital biobank that already stores samples and runs a LIMS, and it assumes the first 24 months of adoption. The standard sets no schedule. The order of the phases matters more than their exact length: foundations first, integration second, assurance and networking last.

Months 0–6: foundation

• Carry out a gap assessment against ISO 20387:2018 and the spec's §5, including the ten required SOPs (Chapter 7). Record every gap as a CAPA item so that the internal audit later has a baseline to measure against.
• Take a census of what is actually in the freezers. Reconcile LIMS records with physical positions using the freezer→rack→box→position hierarchy of StorageLocation (Chapter 3). Discrepancies found here are cheaper to fix now than after the chain of custody starts.
• Adopt random sample identifiers in the SAM-XXXXXX form of §8.3.1, generated from a cryptographic random source rather than the timestamp-based generateSampleId(). Relabel existing samples only when they are next handled, and keep a mapping table from legacy IDs.
• Map LIMS fields to Sample, Aliquot and QualityMetrics. Decide the wire format (snake_case) and the SDK format (camelCase) once, in one mapping layer.
• Connect every storage unit to 1-minute temperature logging with the alarm thresholds of §7.3, and write down the escalation contacts the excursion protocol in Chapter 5 needs.
• Fix the custody-hash rules in writing before the first event is recorded: field list, canonical serialization, timestamp precision and signing key management.

Months 6–12: integration

• Expose the three REST endpoints of §9.1.2 (register, inventory, request) behind the security envelope described in Chapter 4, and use the error codes B001–B012 consistently.
• Move consent into structured Consent records with form versions. Implement withdrawal propagation to aliquots and open requests, which v1.0 leaves to the implementer (Chapter 6).
• Start the chain of custody for all new samples. Existing samples receive a signed "baseline" event recording their state at the changeover date.
• Map to HL7 FHIR resources where the hospital's clinical systems need them, following the book's mapping in Chapter 6, and bring the access committee's review and MTA workflow into the RequestStatus states.
• Put the conformance test vectors from Chapter 7 into continuous integration, including corrected-SQI monotonicity and hash-chain tamper tests. Where the SDK behaves as v1.0 is written and that behaviour is wrong, record the deviation openly rather than hiding it.

Months 12–24: assurance and network

• Complete a full internal audit cycle and close the resulting CAPA items. This is the evidence an external ISO 20387 assessment will look for.
• Assemble the conformance evidence package described in Chapter 7: SBOM, OpenAPI document, test vector matrix, signed manifest, and a profile manifest that marks each requirement as supported, partial or excluded. Re-publish it on a fixed cadence even when nothing changed.
• Run a federation pilot with one partner institution, starting with directory-level MIABIS attributes and a single data-visiting analysis before any physical exchange.
• Compute equivalent storage age (Section 8.3) in shadow mode next to the v1.0 SIS, and review disagreements at the quality meeting before any decision rule changes.
• Prepare the WIA certification application with the readiness checklist from Chapter 7. Report the gaps from Section 8.4 that affected the implementation back to the standard's maintainers, so that the next revision is informed by real deployments.

Closing

A biobank makes a promise that outlives the people who make it. A tube frozen today may be thawed by a researcher who is not yet born, for a question nobody can yet phrase. Everything in this book serves that promise: the pre-analytical discipline, the storage ladder, the integrity metrics, the chain of custody and the consent records. WIA-BIO-019 v1.0 gives the promise a shared vocabulary and a working reference implementation. It also contains errors, and this book has named them rather than passing them on. The best way to adopt the standard is to follow it where it is right, correct it openly where it is not, and feed those corrections back so that v1.x becomes a standard a biobank can rely on for the long term.