Chapter 5
Phase 1 of WIA-BIO-020 defined what a regenerative-medicine record looks like: the cell preparation, the growth factor, the clinical application, the quality-control measurement. Phase 2 makes those records reachable. It exposes them as a small HTTPS surface plus one streaming channel, and it adds a set of calculation interfaces that capture the engineering questions asked at the bench. How fast will a given tissue regenerate? Did enough cells survive the culture? Will a scaffold hold up mechanically and degrade at a sensible pace? This chapter walks through that surface in the order a cell-therapy facility meets it: registering a preparation, calling the calculators, exchanging characterization and outcome data, and finally monitoring quality, cleanroom conditions and safety.
The specification states that any compliant system must contain six components. Each one answers a recurring operational need in cell therapy:
The network surface maps onto the first, third and sixth components directly, and onto the growth-factor and application records as well. Eight endpoints make up the contract:
POST /regenerative-medicine/v1/preparations # register cell preparation
GET /regenerative-medicine/v1/preparations/{id} # fetch preparation record
POST /regenerative-medicine/v1/factors # register growth factor
POST /regenerative-medicine/v1/applications # register clinical application
GET /regenerative-medicine/v1/audit/{prepId} # audit trail
POST /regenerative-medicine/v1/qc-results # contribute QC measurement
GET /regenerative-medicine/v1/safety/incidents # adverse-event log
WS /regenerative-medicine/v1/cleanroom/stream # cleanroom telemetry
Every endpoint follows a discovery convention at /.well-known/wia-regenerative-medicine, so a client can locate the service before it knows anything else about the host.
The preparation endpoint is the entry point for everything else. POST /preparations accepts the Phase 1 envelope and returns a stable prepId. All later QC results, audit queries and applications refer back to that identifier. The call is gated by an institutional credential, issued to a clinical-grade cell-therapy facility with the appropriate scope. This reflects how the field works: a research-grade culture and a product intended for a patient are different things in law and in practice. A preparation intended for clinical use must therefore also carry the GMP-facility envelope and the regulatory-classification envelope. Read endpoints return the per-batch lot-release record and the chain-of-custody graph from donor to administered dose. That graph is what allows a facility to answer, years later, which donor material produced the dose a given patient received.
| Concern | Endpoint | What it preserves |
|---|---|---|
| Identity of a batch | /preparations | Stable prepId, lot-release record, donor-to-dose custody graph |
| Inputs to potency | /factors | Registered growth factors |
| Use in a patient | /applications | Registered clinical applications |
| History | /audit/{prepId} | Audit trail for one preparation |
| Release decisions | /qc-results | Measurements against a preparation |
| Harm | /safety/incidents | De-identified adverse-event log |
| Environment | cleanroom stream | Per-suite environmental events |
Section 8.2 of the specification defines three request/response pairs. The material gives the shapes but not URL paths for them, so this chapter treats them as typed contracts that a compliant system must honour. They encode the quantities a tissue engineer already reasons about.
The first estimates regeneration for a target tissue:
interface RegenerationRequest {
tissueType: 'cardiac' | 'neural' | 'bone' | 'cartilage' | 'skin';
cellDensity: number; // cells/ml
timeFrame: number; // days
growthFactors: string[];
}
interface RegenerationResponse {
rate: number; // cells/day
recoveryPercentage: number;
timeToComplete: number; // days
feasibility: 'high' | 'medium' | 'low';
}
The closed list of tissue types matters. Cardiac muscle, neural tissue, bone, cartilage and skin differ enormously in their intrinsic capacity to repair, and a single generic "tissue" label would hide that. The request combines a delivered cell density, a time window and the growth factors in play. The response translates them into a rate in cells per day, a projected recovery percentage and a time to completion. It also gives a coarse feasibility verdict of high, medium or low. That verdict is a screening aid, not a clinical prediction. A "low" result tells a planner to revisit the cell dose, the factor combination or the time frame before committing a batch.
The second interface turns a raw cell count into a judgement about culture health:
interface SurvivalRequest {
cellType: string;
viableCells: number;
totalCells: number;
cultureConditions: string;
}
interface SurvivalResponse {
survivalRate: number; // 0-100%
viability: 'excellent' | 'good' | 'fair' | 'poor';
recommendations: string[];
}
The inputs are the two numbers an operator gets from a viability count: live cells and total cells. The service returns the survival rate as a percentage and a four-level label. It also returns a free-text list of recommendations, which is where culture-condition advice appears. Supplying cultureConditions with the counts lets the calculator tie a poor result to a likely cause rather than only report it.
The third addresses the physical carrier of the cells:
interface ScaffoldRequest {
tissueType: string;
material: string;
porosity: number; // 0-1
size: number; // cm³
mechanicalRequirements: {
youngModulus?: number; // MPa or GPa
compressiveStrength?: number;
};
}
interface ScaffoldResponse {
design: {
material: string;
dimensions: { width: number; height: number; depth: number };
poreSize: number; // μm
porosity: number;
degradationTime: number; // months
};
mechanical: {
youngModulus: number;
tensileStrength: number;
compressiveStrength: number;
};
biocompatibility: 'excellent' | 'good' | 'acceptable';
}
A scaffold is a compromise among competing demands. Higher porosity helps cells migrate in and nutrients diffuse through, but it generally reduces stiffness and strength. A scaffold for bone must resist load, so the Young's modulus and compressive strength of the request are the binding constraints. One for soft tissue is judged differently. The response states the achieved pore size in micrometres, the porosity, the expected degradation time in months, and the resulting mechanical profile including tensile strength. Degradation time is the key to timing. The scaffold should give way as new tissue takes over its load. The biocompatibility label, with a floor of "acceptable", records how the chosen material is expected to behave in contact with host tissue.
Two JSON documents anchor the data exchange. The first is the cell characterization record, the evidence that a population is what the label says it is:
{
"cellType": "iPSC",
"passage": 15,
"markers": {
"OCT4": 0.95,
"NANOG": 0.92,
"SSEA4": 0.94
},
"viability": 0.89,
"karyotype": "46,XY",
"mycoplasma": "negative",
"doubling_time_hours": 24
}
Each field corresponds to a routine identity or safety check for induced pluripotent stem cells:
The second document is the tissue regeneration record, which closes the loop from product to patient:
{
"tissue": "cardiac",
"patient_id": "P12345",
"baseline": {
"ejection_fraction": 0.35,
"infarct_size_cm2": 15
},
"post_treatment": {
"ejection_fraction": 0.42,
"infarct_size_cm2": 10,
"vessel_density": 320
},
"improvement_percentage": 20
}
The example is a cardiac case. Ejection fraction, the share of blood the left ventricle expels per beat, rises from 0.35 to 0.42, and the infarct shrinks from 15 to 10 cm². The stated improvement_percentage of 20 is the relative change in ejection fraction: a gain of 0.07 on a baseline of 0.35. Readers should keep that definition in mind. It is not a gain of twenty percentage points. Recording a baseline block and a post-treatment block under the same patient identifier lets an analyst compare like with like. A vessel_density reading appears only after treatment in this example, a reminder that revascularisation is one of the mechanisms the standard expects to be measured. In the API layer, the patient identifier is exactly the kind of subject-identifying field that the safety endpoints project out of de-identified views, as described in the next section.
The quality-control endpoint, POST /qc-results, accepts a measurement against a preparation record. Its payload is deliberately heterogeneous. It can carry the binary output of the assay itself: an immunophenotyping FCS file, a karyotype image, a qPCR plate or a potency-assay reading. It must also carry the analyst's signature and a reference to the calibration record, in line with ISO/IEC 17025. Attaching raw data and calibration provenance means a reviewer can audit how a number was produced, not only what the number was. Results falling within the operator's release-test envelope are gated for release. An out-of-specification result raises an investigation event under the operator's release-control SOP, so a failed test opens a formal investigation instead of being silently re-run.
The specification pairs this with a fixed vocabulary of error codes, each tied to a corrective action:
| Code | Meaning | Action |
|---|---|---|
| B001 | Cell contamination detected | Discard culture, decontaminate |
| B002 | Low viability (<70%) | Optimize culture conditions |
| B003 | Marker expression insufficient | Extend culture, retest |
| B004 | Scaffold degradation too fast | Change material or crosslinking |
| B005 | Growth factor instability | Add stabilizers, reduce temperature |
| B006 | Immune rejection risk | HLA matching, immunosuppression |
The codes read as a map of the failure modes in this field. B001 and B002 concern the culture. B003 concerns identity, the same OCT4/NANOG/SSEA4 evidence from the characterization record. B004 and B005 concern the engineered materials and the biologics that act on cells. B006 concerns the recipient, where histocompatibility (HLA matching) decides whether the graft will be tolerated.
Environmental control is handled by the cleanroom WebSocket, which multiplexes events per suite. Its event classes include:
Subscribers filter by suite identifier and event class. The broker emits alarm events on out-of-band readings, such as a particle excursion or a pressure-cascade reversal, within the safety loop's hard time budget. The pressure cascade is the gradient that keeps air flowing from cleaner rooms toward less clean ones. Its reversal is a genuine contamination risk to an open product, which is why it is treated as an alarm and not just another datapoint. Because the operator of record is part of every shift's data, a deviation can later be tied to who was responsible for the suite at that time.
On the harm side, GET /safety/incidents returns a de-identified adverse-event log that can be filtered by indication, preparation type and date range. It uses FAERS-style narrative summaries for the event categories the standard tracks: tumourigenicity, immunogenicity, acute infusion reactions and off-target engraftment. These are the characteristic risks of cell products. Pluripotent-derived cells can form tumours, allogeneic cells can provoke immune responses, infusions can cause acute reactions, and cells can lodge in tissues other than the intended target. Subject-identifying fields are removed unless the requesting credential carries the subject-data scope. Reporting to the controlling regulator follows the applicable timelines: FDA IND safety reporting under 21 CFR 312.32, EU CTR reporting under Regulation 536/2014, and the KFDA KGCP equivalents. Data-subject requests follow GDPR Article 15 with a 30-day SLA. Rectification (Article 16) and erasure (Article 17, where applicable) follow the documented exceptions for clinical-research records under retention obligations.
Access is tiered: read endpoints allow 100 requests per hour unauthenticated, limited to de-identified data, 1000 authenticated and 5000 on the premium tier. Cell-therapy facilities, regulatory inspectors and partnered Tier-1 CDMOs can instead subscribe to webhooks, so they learn of changes without polling. The QC lifecycle events are in-spec, out-of-spec, investigation and closed. The adverse-event lifecycle events are initial-report, follow-up and closed. Payloads have the same envelope shape as the corresponding GET response and are signed with the WIA tenant key.
Phase 2 turns the biology-aware records of Phase 1 into something a system can call. A preparation receives a stable prepId under an institutional credential. Three calculators answer regeneration, survival and scaffold questions with typed requests and responses. Two JSON documents carry cell identity and patient outcome. A single quality endpoint, a coded error vocabulary and a cleanroom stream guard the product. A de-identified incident log and webhooks carry safety information to the people who must act on it. Throughout, the interface follows the structure of the science. Culture health, marker expression, scaffold mechanics, immune compatibility and environmental control each have a named place in the contract.
For teams building against it, the specification suggests a staged approach. Start from the reference container, which ships every envelope and endpoint with mock data, and exercise it with the published conformance suite. Then replace the mock backend one endpoint at a time. Within the 1.x line, existing envelopes and endpoints must stay reachable; implementers may add optional fields but may not remove existing ones.
What this chapter has not addressed is what happens when these records must cross an organisational boundary: a CDMO handing a lot to a clinical site, or a regulator inspecting another operator's chain of custody. A single HTTPS call between two parties is not enough there. Phase 3 therefore wraps the same envelopes in protocol exchanges designed to cross trust boundaries, and the next chapter takes up how those exchanges are structured.