Chapter 8
How the regulations behind cell therapy become software requirements, how to prove that an implementation actually does what WIA-BIO-005 says, and what the next version of the standard will need.
The previous seven chapters built up a complete picture: the biology of the products, the manufacturing process, the laboratory tests behind a release decision, the data record, the five required software components, the vein-to-vein workflow and the clinical safety layer. This last chapter asks a different question. Suppose an organisation has built all of that. How does it show a regulator, an auditor or a hospital partner that the system is fit for use, and how does it show that the system conforms to WIA-BIO-005 rather than to someone's loose reading of it?
Two points frame everything that follows. First, WIA-BIO-005 is a voluntary technical standard published by WIA. It is not recognised by the FDA, the EMA or the MFDS, and conforming to it does not replace any regulatory obligation; the standard's own section 9 simply lists the regulations that a compliant system must help its operator meet. Second, "certification" in this chapter means the WIA programme at cert.wiastandards.com, an assessment of conformance to a published document. It is not a regulatory status, a licence or an approval of any product.
Section 9 of the specification groups the relevant rules into three families: United States regulations, European Union legislation and ICH guidelines. The list is short, but each entry drags a large body of guidance behind it. The purpose of this section is not to teach regulatory affairs, which is a profession of its own, but to show where each rule touches the data and software that WIA-BIO-005 describes.
21 CFR Part 1271 governs human cells, tissues and cellular and tissue-based products (HCT/Ps). For a cell therapy manufacturer, the parts that matter most are donor eligibility (screening and testing of the donor, the subject of Chapter 2) and the current good tissue practice requirements, which cover facilities, environmental control, equipment, supplies, process controls, labelling, storage, receipt and distribution, records and tracking. A genetically modified T-cell product is more than minimally manipulated, so it is also regulated as a biological drug: 21 CFR Part 211 (current good manufacturing practice for finished pharmaceuticals) applies to its manufacture, and the biologics regulations in the 600-series of Title 21 apply to licensed products.
21 CFR Part 312 covers investigational new drug applications. The spec highlights two reporting obligations that are directly relevant to the Safety Monitor. Under 21 CFR 312.32 a sponsor must submit an IND safety report for a serious and unexpected suspected adverse reaction no later than 15 calendar days after becoming aware of it, and an unexpected fatal or life-threatening suspected adverse reaction must reach the FDA no later than 7 calendar days after the sponsor's initial receipt of the information. Under 21 CFR 312.33 the sponsor files an annual report that includes, among other things, manufacturing changes and protocol amendments. The spec also mentions submitting lot release data; how and when this happens depends on the product's licence and the agreements with the agency, so the software should store release data in a form that can be exported, rather than assume a fixed submission route.
The spec does not list 21 CFR Part 11, the rule on electronic records and electronic signatures, but any system that replaces paper batch records or signs a certificate of analysis electronically falls under it. It is the single regulation that most directly shapes the software architecture: audit trails, unique user identities, signature manifestations and the link between a signature and the record it signs.
Regulation (EC) No 1394/2007 defines advanced therapy medicinal products (ATMPs), which include somatic cell therapy medicinal products and gene therapy medicinal products; a CAR-T product falls under this regulation. ATMPs are medicinal products, so the general framework of Directive 2001/83/EC applies, including the requirement that each batch be certified by a Qualified Person before release. Manufacturing follows EudraLex Volume 4. The spec cites Annex 2 (manufacture of biological active substances and medicinal products for human use); in addition, the European Commission has published GMP guidelines specific to ATMPs as Part IV of Volume 4, and Annex 11 (computerised systems) and Annex 15 (qualification and validation) apply to the software and equipment described in this book. One detail of Regulation 1394/2007 matters for data design: its traceability provision requires that the data needed to trace each product from donor to recipient be kept for at least 30 years after the product's expiry date.
ICH Q10 describes the pharmaceutical quality system: management responsibility, CAPA, change management and management review. ICH E6 is the good clinical practice guideline that governs how clinical data are collected and verified in trials. ICH E2A defines the terms of clinical safety data management (adverse event, adverse drug reaction, serious, unexpected) and the principles of expedited reporting that the 15-day and 7-day clocks above are built on. The spec also lists ICH Q7, GMP for active pharmaceutical ingredients. Its applicability to cell therapy is limited: it was written for chemical and conventional biotechnological APIs, and a patient-specific cell product is regulated under the finished-product and ATMP-specific GMP texts above. Q7 is best treated as background rather than as the governing document.
Section 10.2 of the spec adds the FACT-JACIE standards, the accreditation standards used by many hospital programmes that collect, process and administer cellular therapy products, and four USP chapters. USP <71> (Sterility Tests) and USP <85> (Bacterial Endotoxins Test) define the compendial methods behind two release tests from Chapter 3. USP <1043> covers ancillary materials used in manufacturing, such as cytokines, activation reagents and media. USP <1046> is the informational chapter on cell-based and tissue-based products; its title has changed since the spec was written, so cite the current USP edition rather than the title printed in the spec. Mycoplasma testing, which the spec describes without naming a compendial method, is covered by USP <63> and Ph. Eur. 2.6.7.
Erratum in the spec's reference list. Section 10.2 gives ISO 13022 the title "Medical laboratories — Practical guide to ISO 15189". That is wrong: ISO 13022 deals with medical products containing viable human cells, specifically the application of risk management and requirements for processing practices. The reference list in section 10.1 is also incomplete (items 1, 3 and 4 are missing); of the entries that remain, the FDA's 2020 guidance on chemistry, manufacturing and control information for human gene therapy INDs is the one directly relevant to CAR-T manufacturing data.
For readers in Korea, the national framework is the Act on the Safety of and Support for Advanced Regenerative Medicine and Advanced Biological Products, administered with the MFDS. The spec does not mention it, and the mapping below should be extended with it by any organisation operating under Korean jurisdiction.
Regulations talk about organisations and products, not about functions and fields. The Compliance Checker, the fifth required component in section 8.1 of the spec, is where these obligations become testable rules. The spec names the component but does not specify what it must verify, and the reference SDK does not implement it: there is no checkCompliance method in CellularTherapySDK. The implementer therefore has to derive the rule set from the regulations. The table below is a starting point that follows the regulations listed in the spec.
| Regulation or guideline | System requirement | WIA-BIO-005 component |
|---|---|---|
| 21 CFR 1271 (donor eligibility) | Donor screening and test results recorded and reviewed before the starting material enters manufacturing; allogeneic lots cannot be released without a completed eligibility determination. | Manufacturing Tracker, Compliance Checker |
| 21 CFR 211; EudraLex Vol. 4 incl. Part IV | Complete executed batch record; every deviation (C006) documented and assessed before release; release by an authorised person. | Manufacturing Tracker, Quality Assessor, Compliance Checker |
| Directive 2001/83/EC (QP certification) | Release decision bound to a named, qualified signatory; no shipment status before certification. | Compliance Checker |
| USP <71>, <85>, <63> | Method, result, unit and acceptance criterion stored for each release test; endotoxin evaluated per kg of body weight, not per mL. | Quality Assessor |
| 21 CFR 312.32; ICH E2A | Clock starts at first awareness of a serious adverse event; 15-day and 7-day deadlines computed and escalated. | Safety Monitor, Compliance Checker |
| 21 CFR 312.33 | Manufacturing changes and protocol amendments collected over the reporting year. | Compliance Checker |
| 21 CFR Part 11; EU GMP Annex 11 | Audit trail for every create, change and delete; unique user IDs; electronic signatures linked to records. | All five (platform level) |
| Reg. (EC) 1394/2007 traceability | Donor-to-recipient traceability data retained for the legally required period (at least 30 years after expiry in the EU). | Compliance Checker, storage layer |
| ICH Q10 | CAPA records linked to deviations and out-of-specification results; change control for process and software. | Compliance Checker |
| FACT-JACIE (clinical site) | Chain-of-identity check at receipt and at the bedside before infusion (C005 stops the process). | Dose Calculator workflow, Safety Monitor |
Four design rules come out of this table. The first is completeness before judgement. The Quality Assessor answers "do these results meet the criteria?", but the Compliance Checker first answers "are all required results present, signed and traceable?". A lot with a passing viability value but no recorded mycoplasma result must not reach a release decision at all. In practice this means the Compliance Checker runs before assessQuality, and it uses a list of required tests per product type, not the fields that happen to be filled in.
The second rule is the signature is data. The SDK's generateCertificate writes approvedBy: 'QC Manager', a fixed string. Under Part 11 and Annex 11 an approval is a record in its own right: who signed, when, in what role, with what meaning, bound to which version of the certificate. The certificate the SDK returns should be treated as a draft that the quality system completes, never as the signed document itself. The same applies to the other hard-coded values in that method, discussed in Chapter 5: the fixed 24-month expiry, the facility name and the shipping text. The shipping text in particular mentions dry ice, which (at about −78 °C) is incompatible with the ≤−150 °C storage condition of the spec, so a compliance rule should reject any certificate that carries it.
The third rule is deadlines are computed, not remembered. The Safety Monitor in the SDK (monitorSafety) returns a risk level and recommendations, but it has no notion of reporting deadlines. A conforming system records the date the sponsor first became aware of each serious event, derives whether it is fatal or life-threatening, and computes the due date. This is a small piece of code with a large compliance consequence.
The fourth rule is retention is a jurisdiction setting. There is no single retention period that satisfies every regulator, and the PHASE annex texts that ship with the spec contain a fixed retention figure that has nothing to do with cell therapy law. Retention should be configured per jurisdiction and per record class (donor records, batch records, clinical safety records), with the longest applicable period winning when a product crosses borders.
A conformance claim is only as good as the tests behind it. The strongest test vectors for WIA-BIO-005 are derived directly from the numbers written in the spec, because those numbers are what an auditor will check. Every threshold stated as "≥" or "<" deserves at least three vectors: one just below, one exactly at, and one just above the boundary. A vector that sits comfortably inside the passing range proves little.
Before writing vectors, one fact about the reference SDK must be clear. Its assessQuality method does not throw the spec's error codes C001 to C003. It returns a QualityResult with a failures list, a criteria object and a recommendation. Only a few paths throw a CellularTherapyError: invalid input to calculateDose (C010) and an attempt to generate a certificate for a failed lot (C007). Mapping a failed criterion to C001, C002 or C003 is therefore the job of the integration layer, and the mapping itself must be tested. Likewise, assessICANS takes the grade as input; it does not compute a grade from an ICE score, so the ICE-to-grade rule belongs to the implementer's own code and its tests.
| Vector | Input (spec origin) | Expected result |
|---|---|---|
| V-01 viability boundary, fail | viability 84.9 (§4.2: ≥85%) | passRelease false; mapped code C001 |
| V-02 viability boundary, pass | viability 85.0 | viability criterion passes; SDK adds a below-optimal warning (<90) |
| V-03 potency boundary | specific lysis 69.9% at 10:1 (§4.1.3: ≥70%) | passRelease false; mapped code C002 |
| V-04 sterility | growth detected (sterility: false) | recommendation reject; mapped code C003 |
| V-05 dose example | 2.5×10⁸ cells, 95% viable, 80% CAR+, 70 kg (§6.1.1) | ≈2.7×10⁶ CAR+ cells/kg; within 1×10⁶–5×10⁶; optimal |
| V-06 invalid input | patient weight 0 kg | throws C010 |
| V-07 endotoxin per kg | 4.9 EU/mL, 100 mL, 70 kg (§4.1.5: <5 EU/kg) | 7.0 EU/kg: fail, although the SDK's raw comparison passes |
| V-08 ICE to ICANS | ICE score 7, no other findings | ICANS grade 1 |
| V-09 certificate on failed lot | any failing metrics | throws C007 |
The Jest suite below implements the core of this table against CellularTherapySDK. It assumes two small helpers that belong to the integration layer, not to the SDK: toSpecCodes, which maps failed criteria to spec codes, and endotoxinPerKg, which performs the unit conversion introduced in Chapter 3. The values are taken from the spec; nothing in the suite is a clinical recommendation.
import {
CellularTherapySDK,
CellularTherapyError,
CellularTherapyErrorCode as E,
QualityMetrics,
QualityResult,
} from '@wia/bio-005';
// --- integration-layer helpers (not part of the SDK) ---
function toSpecCodes(r: QualityResult): string[] {
const codes: string[] = [];
if (!r.criteria.viability.pass) codes.push(E.VIABILITY_LOW); // C001
if (!r.criteria.potency.pass) codes.push(E.POTENCY_FAILURE); // C002
if (!r.criteria.sterility.pass) codes.push(E.STERILITY_FAILURE); // C003
return codes;
}
const endotoxinPerKg = (euPerMl: number, doseMl: number, kg: number) =>
(euPerMl * doseMl) / kg;
function iceToIcansGrade(ice: number, unarousable = false): 0 | 1 | 2 | 3 | 4 {
if (unarousable) return 4; // ASTCT 2019: ICE 0 because patient cannot be assessed
if (ice === 10) return 0;
if (ice >= 7) return 1;
if (ice >= 3) return 2;
return 3;
}
function thrown(fn: () => unknown): CellularTherapyError | undefined {
try { fn(); } catch (e) { return e as CellularTherapyError; }
return undefined;
}
// --- a passing lot, built from the spec's JSON example (section 8.3.1) ---
const base: QualityMetrics = {
viability: 92.5, potency: 78.5, sterility: true, endotoxin: 0.25, mycoplasma: false,
identity: { positive: { CD3: 97.8, CAR: 85.3 }, negative: {} },
cellCount: { total: 5.2e8, viable: 4.81e8 },
appearance: { color: 'pale yellow', clarity: 'slightly opaque', particulates: false },
};
describe('WIA-BIO-005 conformance vectors', () => {
const sdk = new CellularTherapySDK();
test('V-01 viability 84.9 % fails and maps to C001', () => {
const r = sdk.assessQuality({ ...base, viability: 84.9 });
expect(r.passRelease).toBe(false);
expect(toSpecCodes(r)).toEqual(['C001']);
});
test('V-02 viability 85.0 % passes the criterion', () => {
const r = sdk.assessQuality({ ...base, viability: 85.0 });
expect(r.criteria.viability.pass).toBe(true);
expect(r.warnings.length).toBeGreaterThan(0); // below-optimal warning (< 90 %)
});
test('V-03 specific lysis 69.9 % at 10:1 maps to C002', () => {
const r = sdk.assessQuality({ ...base, potency: 69.9 });
expect(toSpecCodes(r)).toEqual(['C002']);
});
test('V-04 sterility growth is a reject and maps to C003', () => {
const r = sdk.assessQuality({ ...base, sterility: false });
expect(r.recommendation).toBe('reject');
expect(toSpecCodes(r)).toContain('C003');
});
test('V-05 the 70 kg dose example gives about 2.7e6 CAR+ cells/kg', () => {
const d = sdk.calculateDose({
cellType: 'CAR-T', strategy: 'weight-based',
totalCells: 2.5e8, viability: 95, targetMarkerPercent: 80, patientWeight: 70,
});
expect(d.dose / 1e6).toBeCloseTo(2.714, 3);
expect(d.withinRange).toBe(true);
expect(d.assessment).toBe('optimal');
});
test('V-06 zero body weight is rejected with C010', () => {
const err = thrown(() => sdk.calculateDose({
cellType: 'CAR-T', strategy: 'weight-based',
totalCells: 2.5e8, viability: 95, patientWeight: 0,
}));
expect(err?.code).toBe(E.INVALID_PARAMETERS);
});
test('V-07 endotoxin is judged per kg, not per mL', () => {
expect(endotoxinPerKg(4.9, 100, 70)).toBeCloseTo(7.0, 1); // fails < 5 EU/kg
expect(sdk.assessQuality({ ...base, endotoxin: 4.9 }).criteria.endotoxin.pass)
.toBe(true); // documents the known SDK gap: the wrapper must override this
});
test('V-08 ICE score 7 is ICANS grade 1', () => {
expect(iceToIcansGrade(7)).toBe(1);
expect(iceToIcansGrade(6)).toBe(2);
expect(iceToIcansGrade(2)).toBe(3);
});
test('V-09 no certificate for a failed lot (C007)', () => {
const product = { batchId: 'CT-2024-001' } as any; // minimal stub for the test
const err = thrown(() =>
sdk.generateCertificate(product, { ...base, mycoplasma: true }, {} as any));
expect(err?.code).toBe(E.QUALITY_FAILURE);
});
});
Three things about this suite are worth noting. V-07 deliberately asserts the SDK's current behaviour and the correct behaviour side by side. This is a pattern for known gaps: the test documents the gap, and when a future SDK version fixes it the test fails, which forces someone to remove the workaround in the wrapper consciously. V-08 tests the ASTCT 2019 mapping of the ICE score (10 points: orientation 4, naming 3, following commands 1, writing 1, attention 1); the SDK's iceComponents type still allows 0–2 points for following commands and has no attention field, the erratum discussed in Chapter 7, so the integration layer should validate component scores against the ASTCT ranges before summing them. Finally, V-05 uses a tolerance rather than exact equality, because floating-point arithmetic on quantities like 2.5×10⁸ × 0.95 × 0.80 need not reproduce the decimal result exactly.
Beyond these vectors, a complete suite also covers the dose assessment bands for every cell type the implementation supports (below 0.5× minimum, between 0.5× and 1× minimum, inside the range, up to 1.5× maximum, above), each critical process parameter limit in trackManufacturing, the expansion-behind-schedule alert, the post-thaw acceptance rule in assessPostThawQuality (viability ≥85%, recovery ≥70%, potency retained ≥70%), and the CLI. The CLI deserves its own vectors because, as Chapter 5 showed, its grading bands differ from the SDK's; a suite that only exercises the SDK says nothing about scripts that call wia-bio-005 assess-quality.
Running the tests is half the job; the other half is presenting the results so that someone else can check them without rerunning everything. The PHASE documents that accompany the specification contain non-normative annexes (G to J) that describe an evidence format. Those documents are generic boilerplate: they are titled with a different standard number, carry a different licence and date, and include numeric targets and time windows that have nothing to do with cell therapy. None of those numbers belongs in a WIA-BIO-005 claim. The underlying ideas, however, are sound and are used here as a non-normative guide.
| Item | Content | Why it is there |
|---|---|---|
| Test-vector matrix | Every vector with its input, expected result, actual result and pass/fail; skipped vectors listed with a justification. | Shows exactly which requirements were exercised. An unexplained skip is read as a failure. |
| Profile manifest | Each requirement marked supported, partial (with reason) or excluded (with justification). | Prevents partial conformance from being presented as full conformance. |
| Deviation and erratum register | Known differences between spec, SDK and implementation (ICE domains, endotoxin units, dose units, grading rules) and how each is handled. | Makes deliberate choices visible instead of leaving auditors to discover them. |
| Software bill of materials | SBOM in a standard format such as CycloneDX or SPDX, including the exact @wia/bio-005 version. | Identifies what was tested, down to dependencies. |
| Interface description | If the implementation exposes its own HTTP API, its OpenAPI description. WIA-BIO-005 itself defines TypeScript interfaces, not REST endpoints. | Lets integrators check field names and types against section 8.2 and 8.3. |
| Validation summary | Reference to the computerised-system validation (section 8.5) of the environment in which the tests ran. | Connects conformance with GMP validation. |
| Signed manifest | A manifest listing the files above with their hashes, signed by the organisation (for example using Sigstore, as the annexes suggest). | Proves the package has not been altered since it was produced. |
Because the spec has no formal requirement identifiers, the organisation has to create them. A practical convention is to derive them from section numbers and the criterion, so that every row in the manifest can be traced back to a line in the spec. The following fragment is an illustrative example of a profile manifest, not a format defined by WIA-BIO-005.
{
"standard": "WIA-BIO-005",
"specVersion": "1.0.0",
"implementation": { "name": "example-cell-therapy-platform", "sdk": "@wia/bio-005@1.0.0" },
"requirements": [
{ "id": "BIO005-8.1-dose-calculator", "status": "supported" },
{ "id": "BIO005-4.2-viability-min", "status": "supported" },
{ "id": "BIO005-4.1.5-endotoxin-perkg", "status": "supported",
"note": "wrapper converts EU/mL to EU/kg before comparison" },
{ "id": "BIO005-7.2.1-ice-score", "status": "partial",
"reason": "ASTCT 2019 domains used; spec lists 'following commands' as 2 points" },
{ "id": "BIO005-2.2.1-car-nk-dose", "status": "excluded",
"justification": "CAR-NK products not manufactured at this site" }
]
}Note what the manifest does not contain: no percentage score, no tier such as bronze or gold, and no claim about accuracy. Conformance to a standard like this one is a list of requirements met, met partly or not claimed, each with evidence. Anything more compressed hides exactly the information an auditor needs.
Chapter 2 described IQ, OQ and PQ for equipment: installation qualification proves the incubator was installed as specified, operational qualification proves it holds 37 °C across its operating range, and performance qualification proves it supports the real process. Software used to make GMP decisions needs the same logic, and both Annex 11 in the EU and Part 11 in the US expect it. The ISPE GAMP 5 guide is the most widely used framework for scaling that effort to the risk of the system.
| Equipment stage | Software analogue | Typical evidence |
|---|---|---|
| Installation qualification | Correct build installed in the validated environment; configuration and SDK version recorded. | Installation record, SBOM, configuration export. |
| Operational qualification | Each function behaves as specified, including boundaries and error paths. | The conformance vectors of section 8.3, run in the validated environment. |
| Performance qualification | The system supports the real workflow with real users and interfaces (LIMS, MES, EHR). | End-to-end runs on test lots and test patients, following Chapters 6 and 7. |
| Requalification | Periodic review; revalidation after changes. | Periodic review reports, change-control records. |
Change control is where software and GMP most often collide. A dependency update, a new CLI version or a changed configuration value can alter a release decision. Every such change should go through the organisation's change-control procedure with an impact assessment, and the conformance vectors provide a cheap, objective regression check. Tests that relate to release criteria should be run on every change, not only at major releases.
Versioning needs particular care because there are several independent version numbers. The specification is version 1.0.0, published on 2025-12-26 under the MIT licence. The npm package @wia/bio-005 is also 1.0.0, and the CLI reports its own version 1.0.0. The equal numbers are a coincidence of a first release, not a promise that they will move together. A conforming system records, with every release decision and every dose calculation, which spec version it claims and which SDK and CLI builds were used. Pin exact package versions rather than ranges, because a minor SDK update that changes a threshold or a grade rule would otherwise enter production without passing through change control. Semantic versioning, which the PHASE annexes refer to, is a useful convention: a major version signals a breaking change to a normative requirement, a minor version adds requirements, and a patch is editorial. The deprecation windows in those annexes, however, contradict each other and are not part of WIA-BIO-005.
Finally, the audit trail should capture inputs as well as outputs. When the SDK returns recommendation: 'release', the audit record should hold the metrics object that produced it, the versions involved, the user who ran the check and the user who accepted or overrode the result. An automatic recommendation is an input to a human decision, and the record must show both.
Cell therapy is changing fast, and a standard written around autologous CAR-T products for haematological cancers will need to grow. Several directions are already visible in the field. None of the observations below involves a forecast figure; they describe where the technology is going and what a standard would need to support it.
CAR-NK cells and iPSC-derived effector cells promise products that are manufactured in advance from a healthy donor or a master cell line and stored until needed, instead of being made for one patient. This changes the data model. One batch may supply many patients, so the one-to-one link between product_id and patient_id in the spec's JSON record no longer holds. Donor eligibility and cell-bank records become central, and dose ranges will need to be based on clinical data for each product. The current CAR-NK range in the spec and SDK (10⁷–10⁹ cells/kg) is far higher than doses reported in published trials and should be revised rather than relied upon.
Closed, automated platforms that perform activation, transduction, expansion and harvest in a single device reduce open handling and can reduce the cleanroom grade needed for the surrounding room. For software, this means that more process data arrive as machine records rather than as manual entries, and the Manufacturing Tracker will receive CPP data continuously instead of at checkpoints. A future version of the standard would benefit from a defined event format for device data.
The 14-day compendial sterility test and the 28-day culture method for mycoplasma sit uncomfortably with products that have a short shelf life or are needed urgently. Rapid microbiological methods and nucleic-acid-based mycoplasma tests shorten the wait, subject to validation and acceptance by the relevant authority. A data standard should be able to record which method was used and its validation status, and should allow a lot to move through a documented status of released on a rapid method while a confirmatory result is pending, if the regulator permits it.
The spec already lists HER2 and GD2 among CAR-T targets. Solid tumours bring different challenges (antigen heterogeneity, a hostile tumour microenvironment, on-target off-tumour toxicity), and possibly new routes of administration. Routes other than intravenous infusion also have much lower endotoxin limits; an intrathecal product, for example, is held to 0.2 EU/kg rather than 5 EU/kg, so the endotoxin rule must become route-aware. Gene-edited autologous haematopoietic stem cell products for sickle cell disease and β-thalassaemia have reached approval in several jurisdictions; the SDK's CellType enumeration already contains an HSC value, but the specification defines no rules for it.
HSC, DC, Treg), each with identity markers, release criteria and dose units.conditional) and the SDK (conditional-release, retest).The following checklist summarises what an organisation should have in place before it claims conformance to WIA-BIO-005. It is written as a self-assessment; every "yes" should point to a document or record.
Scope and claim
Components
Known gaps handled
Testing and evidence
GMP and regulatory
That last item applies to the whole book. WIA-BIO-005 encodes clinical numbers so that software can check them consistently, but it is not a clinical guideline. Labels change, and regulators revise monitoring requirements. The value of a data standard lies elsewhere: in giving manufacturers, hospitals and software vendors a shared vocabulary, a shared record and a shared set of checks, so that a cell product can travel from a patient's vein through the laboratory and back into the same patient with its identity, its quality and its history intact. Conformance testing is how an organisation shows that its implementation of that shared language can be trusted.