Chapter 6

Chapter 6: Protocol — The Workflow from Cryopreservation to Infusion

How a released batch becomes a bag at the bedside: the batch state machine, the cold chain, thawing, patient preparation, dosing, the bedside identity check and the monitoring windows that follow.

The previous chapters looked at a cell therapy product from three angles: how it is made (Chapter 2), how it is tested (Chapter 3) and how it is described as data (Chapters 4 and 5). This chapter joins those views into one end-to-end protocol. It follows a single autologous CAR-T batch from the moment the apheresis bag arrives at the manufacturing site to the first hour after the cells enter the patient, and it asks at every step two questions that an implementer of WIA-BIO-005 has to answer in software: what must be true before we move on, and which error code do we raise if it is not.

The chapter relies on sections 5 and 6 of the specification (cryopreservation and clinical administration) and on the SDK types ManufacturingStage, CryopreservationProtocol, ThawingProtocol, PostThawQuality, PatientDose and LymphodepletionRegimen. Formulas that were derived earlier are only referenced here: viability, specific lysis and endotoxin per kilogram in Chapter 3, expansion ratio in Chapter 2, and the dose algorithm in Chapter 5.

6.1 The Batch State Machine

The SDK models the life of a batch with the string union ManufacturingStage, which has eight values: collection, activation, transduction, expansion, harvest, cryopreservation, complete and failed. The first seven describe the normal forward path of a CAR-T batch; failed is a terminal sink that any active stage can fall into. The specification lists the stages but does not define the transitions between them, and the SDK does not enforce them either: trackManufacturing() checks process parameters and viability and raises alerts, but it never changes currentStage. Enforcing the order of stages is therefore the job of the integrating system — typically the manufacturing execution system (MES) or the batch-record layer built on top of the SDK.

Treating the stages as an explicit state machine has three benefits. First, it makes the batch record auditable: every transition is an event with a time, an operator and the evidence that justified it. Second, it gives each in-process test from Chapter 2 a natural home as a gate on a specific edge. Third, it gives the error codes of the standard a precise meaning: a failed gate is not just a bad number but a refused transition.

                      WIA-BIO-005 batch state machine (CAR-T)

 [collection] --G0--> [activation] --G1--> [transduction] --G2--> [expansion]
      |                    |                     |                     |
      |                    |                     |                   G3 (mid-culture)
      |                    |                     |                     |
      |                    |                     |                     v
      |                    |                     |                 [harvest] --G4--> [cryopreservation] --G5--> [complete]
      |                    |                     |                     |                    |
      +--------------------+---------------------+---------------------+--------------------+
                                           |  gate failed, deviation not
                                           |  dispositioned (C006 / C001 / C003 ...)
                                           v
                                       [failed]   (terminal; no outgoing edge)

 G0  starting material accepted, Day 0 viability >= 85 %
 G1  Day 2 activation markers (CD25+/CD69+) >= 50 %
 G2  Day 4 transduction efficiency >= 30 % CAR+
 G3  Day 7 count doubling, viability > 80 % (checked inside expansion)
 G4  Day 10-14 full release panel sampled (results may follow later)
 G5  controlled-rate freeze record complete, unit in <= -150 C storage

Gates on each edge

The in-process testing schedule was explained in Chapter 2; here it becomes a set of preconditions. Leaving collection requires an accepted starting material and a Day 0 viability of at least 85%. Leaving activation requires at least half of the cells to express the activation markers CD25 or CD69. Leaving transduction requires the Day 4 transduction check (≥30% CAR+). Note that this is a different number, with a different purpose, from the release criterion of ≥20% CAR+ used at lot release and from the process target of >40% transduction efficiency; a state machine should store all three separately rather than a single "CAR+ threshold". Inside expansion, the Day 7 check is a mid-course health check rather than an exit gate: if viability falls to 80% or below, the batch is not automatically failed, but a deviation must be opened and assessed. Leaving harvest requires that the release panel was sampled. Leaving cryopreservation requires a complete freezing record and confirmation that the unit reached its storage position.

A subtle but important point is that complete does not mean released. A 14-day sterility test sampled at harvest will usually still be running when the batch reaches the freezer. The state machine therefore describes the physical process, while lot release (Chapter 3) is a separate decision recorded against the batch — typically by attaching a certificate of analysis. A dispensing system must check both: stage complete and a signed release.

What triggers C006

Error code C006 (MANUFACTURING_DEVIATION) is defined in the specification with the action "document and assess impact". It is the right code for anything that leaves the batch outside its validated process without yet proving that the product is unusable: a critical process parameter excursion reported by trackManufacturing(), a missed feeding window, a skipped or late in-process test, an attempt to move a batch backwards or to skip a stage, or a gate that fails but may be recoverable. C006 does not by itself move the batch to failed. Instead, it blocks the transition until a quality decision (a deviation disposition) is recorded. The batch goes to failed only when that decision says so, or when a condition with a harder code occurs — for example, a confirmed positive sterility result (C003). The SDK defines C006 as an enum value but never throws it; the guard function below shows one way to raise it.

import {
  CellularTherapyError,
  CellularTherapyErrorCode,
  ManufacturingStage,
} from '@wia/bio-005';

// Allowed forward edges. 'complete' and 'failed' are terminal.
const NEXT: Record<ManufacturingStage, ManufacturingStage[]> = {
  collection:       ['activation', 'failed'],
  activation:       ['transduction', 'failed'],
  transduction:     ['expansion', 'failed'],
  expansion:        ['harvest', 'failed'],
  harvest:          ['cryopreservation', 'failed'],
  cryopreservation: ['complete', 'failed'],
  complete:         [],
  failed:           [],
};

// Evidence collected by the MES for the gate on the current stage.
interface GateEvidence {
  passed: boolean;             // in-process acceptance criterion met?
  test: string;                // e.g. 'Day 4 transduction (CAR+ %)'
  value?: number;
  deviationApproved?: boolean; // QA disposition of an open deviation
}

export function transition(
  from: ManufacturingStage,
  to: ManufacturingStage,
  gate: GateEvidence
): ManufacturingStage {
  if (!NEXT[from].includes(to)) {
    throw new CellularTherapyError(
      CellularTherapyErrorCode.MANUFACTURING_DEVIATION,
      `Illegal transition ${from} -> ${to}`,
      { from, to }
    );
  }
  if (to !== 'failed' && !gate.passed && !gate.deviationApproved) {
    throw new CellularTherapyError(
      CellularTherapyErrorCode.MANUFACTURING_DEVIATION,
      `Gate not met: ${gate.test}`,
      { from, to, value: gate.value }
    );
  }
  return to; // caller persists the event with user, time and evidence
}

The guard is deliberately small. It does not decide whether a deviation is acceptable — that is a human quality decision — it only refuses to let software record a transition that the evidence does not support. In a real system the returned stage would be written together with the operator identity, a timestamp and the gate evidence into an append-only audit trail.

6.2 Cryopreservation

Most autologous CAR-T products are cryopreserved after harvest. Freezing decouples manufacturing from the clinical schedule: it buys the time needed for release testing, shipping and patient preparation, and it lets the treating team infuse when the patient is clinically ready rather than when the culture happens to finish. Specification section 5.1 defines two parts of the freezing protocol — the formulation and the cooling program.

Formulation

The cryoprotectant in the specification is dimethyl sulfoxide (DMSO) at a final concentration of 10%, carried in a protein-containing base of human serum albumin (HSA) or plasma, optionally with a macromolecular additive such as dextran 40 or pentastarch; an alternative base of a balanced electrolyte solution or saline with HSA is also described. DMSO permeates the cell and reduces intracellular ice formation; the protein and the macromolecule protect the membrane and moderate osmotic stress. The specification writes both formulations as lists of percentages, but the components in each list add up to more than 100%, so they cannot be read literally as a recipe. This book treats that as an erratum: implement the composition qualitatively — final 10% DMSO in an HSA- or plasma-based carrier, optional dextran 40 — and take the exact recipe from the manufacturer's validated batch record.

In the data model, CryopreservationProtocol.cryoprotectant has numeric fields dmso, hsa and dextran expressed in percent. A validator should record the final concentration of each component in the formulated product, and it is reasonable to reject records in which the declared percentages sum to more than 100, because such a record cannot describe a real bag.

Timing also matters. DMSO is toxic to cells at room temperature, so the specification requires cooling the cell suspension to 4 °C and adding the cryoprotectant dropwise with gentle mixing before the product is filled into its containers and loaded into the freezer. The time between the first contact with DMSO and the start of the freezing program is a parameter that a batch record should capture, even though the specification does not set a limit for it.

Controlled-rate freezing

Specification section 5.1.2 prescribes a cooling rate of −1 °C/min from 4 °C to −90 °C, a hold at −90 °C for at least 30 minutes, and then transfer to storage at −150 °C or colder. A rate of about −1 °C/min is the classical choice for nucleated cells: slow enough for water to leave the cell osmotically before it freezes inside, fast enough to limit the time cells spend in concentrated solute. At that rate, the ramp from 4 °C to −90 °C takes 94 minutes, so the program runs for a little over two hours including the hold.

 T (C)
   4 |*
     |  *
   0 |    *.   <- latent heat released at nucleation; a controlled-rate
     |      *..   freezer compensates so the sample does not warm back up
 -30 |          *
     |             *         slope = -1 C/min
 -60 |                *
     |                   *
 -90 |                      *=========*  hold >= 30 min
     |                                 \
-120 |                                  \   transfer to storage
     |                                   \
-150 |- - - - - - - - - - - - - - - - - - *~~~~~~~~~~~~~~~~~~ <= -150 C (vapour-phase LN2)
     +------+------+------+------+------+------+------> time (min)
     0     20     40     60     80    100    120    140

 Ramp 4 C -> -90 C at -1 C/min = 94 min; hold >= 30 min.

The curve has one feature that the specification does not mention but every freezing record shows: when ice first nucleates in the extracellular solution, the latent heat of fusion is released and the sample temperature jumps up by several degrees. Validated freezer programs include a step that removes this heat quickly; a record that shows a large, uncontrolled rebound is a signal to investigate. For this reason the freezer's own probe trace should be attached to the batch record rather than only the program name.

Containers and fill

The specification's harvest section (§3.2.4) states a fill of 10–50 mL per bag and a final concentration of 1–10 × 10⁷ cells/mL. The SDK allows three container types (cryovial, cryobag, straw) and records fillVolume in mL and cellConcentration in cells/mL. Clinical doses are almost always frozen in bags; vials are used for retention samples and stability testing (Chapter 3, Section 3.7), so a well-designed batch freezes both — the patient bags and a set of representative vials that experience the same program.

6.3 Storage and Custody

Specification section 5.3 sets four storage requirements: a temperature of −150 °C or colder, a validated storage duration of up to 24 months, continuous temperature monitoring with alarms, and a redundant liquid-nitrogen supply with backup storage. The −150 °C figure is not arbitrary. It lies below the glass-transition temperature of water (around −135 °C), below which ice crystals cannot grow in any practical time. Storage at −80 °C in a mechanical freezer, or transport on dry ice at about −78 °C, sits well above that line; the SDK even defines a separate ULTRA_LOW: -80 constant alongside CRYOGENIC: -150, and the two must never be confused for a clinical unit. Cryopreserved cell products are shipped in liquid-nitrogen dry shippers that hold vapour-phase temperatures, with a temperature logger travelling with the unit.

Vapour-phase storage — the bag sits above, not in, the liquid nitrogen — is preferred because it reduces the risk of cross-contamination through the liquid and of liquid entering a damaged container. The price is a temperature gradient inside the tank: positions near the lid are warmer than positions near the liquid. A monitoring design should therefore place its probe where the warmest product sits, and treat a rising reading as a custody event rather than a nuisance.

Chain of custody in the record

StorageInfo carries location, temperature, freezeDate, an optional expirationDate and a mandatory freezeThawCycles counter. For a clinical unit the counter should be 0 until the bag is thawed for infusion; any other value means the product experienced an unplanned warming and must be reviewed before use. Each move — from the controlled-rate freezer to the storage tank, from the tank to the dry shipper, from the shipper to the hospital's tank — is a custody event that should record who, when, where from, where to and the temperature data for the interval.

Two error codes govern this part of the chain. C008 (STORAGE_VIOLATION) should be raised when the temperature log shows an excursion above the storage limit, when the freeze–thaw counter is non-zero before infusion, or when a gap in the log makes it impossible to show that the unit stayed cold. C009 (EXPIRED_PRODUCT) should be raised when the product is requested after its expiration date. Like C006, both codes are defined in the SDK's CellularTherapyErrorCode enum but are not thrown by any SDK method; they belong to the inventory and dispensing layer. Note also that the SDK's certificate generator fills in the expiry as freeze date plus 24 months; that value is a placeholder for the product-specific shelf life established by the manufacturer's own stability programme (Chapter 3, Section 3.7), not a rule of the standard.

6.4 Thaw

Thawing is the reverse of the freezing problem and has the opposite speed requirement: it must be fast. During slow warming, small ice crystals formed during freezing can recrystallise into larger, damaging ones. The specification therefore prescribes a 37 °C water bath (§5.2.1) and removal of the bag when a small ice crystal remains, which typically takes 2–5 minutes. Leaving a sliver of ice keeps the product cold while DMSO is still present and prevents it from sitting at 37 °C in concentrated cryoprotectant.

From this point on, the product is on a clock. The specification sets a time to infusion of less than 4 hours, ideally less than 1 hour. For licensed products, the product label usually specifies its own, often shorter, limit from the end of thaw to the end of infusion, and that limit prevails. The data model records the method, temperature, duration and number of washes in ThawingProtocol, and the elapsed time in PostThawQuality.timeToInfusion (in hours).

Lab thaw versus bedside thaw

The specification describes two ways of getting from a frozen bag to a patient. In a lab thaw, the bag is thawed in the processing laboratory, immediately diluted about 10-fold with thaw medium, and washed once or twice to remove DMSO before release to the ward. In a bedside thaw (§5.2.2), the bag is thawed next to the patient and infused immediately without washing, and staff watch for reactions to the infused DMSO. Most commercial CAR-T products are given in the bedside style; lab thaw is common in cellular therapy laboratories that handle products needing manipulation after thaw.

Post-thaw acceptance

The post-thaw acceptance criteria are viability ≥85%, recovery ≥70% and retained potency. The SDK makes "retained" concrete in assessPostThawQuality(preFreeze, postThaw): it returns the post-thaw viability, the recovery (post-thaw count ÷ pre-freeze count × 100) and the potency retained (post-thaw potency ÷ pre-freeze potency × 100), and sets acceptable only if viability ≥ MIN_VIABILITY (85), recovery ≥ MIN_RECOVERY (70) and potency retained ≥ 70.

const sdk = new CellularTherapySDK();

// Illustrative numbers only
const r = sdk.assessPostThawQuality(
  { viability: 94, cellCount: 2.5e8, potency: 82 },  // pre-freeze
  { viability: 88, cellCount: 1.9e8, potency: 66 }   // post-thaw vial
);
// r = { viability: 88, recovery: 76, potencyRetained: 80.49..., acceptable: true }

Two practical cautions apply. First, recovery compares counts, so both counts must be measured the same way (total nucleated or viable, same instrument) or the ratio is meaningless. Second, for a bedside thaw the patient's own bag is not tested before infusion; the post-thaw numbers come from a companion vial or from the stability programme. The record should say which, so that a later investigation knows whether the number describes the infused product or a surrogate.

6.5 Patient Preparation

While the product is being made and tested, the patient is prepared. The central step is lymphodepletion: a short course of chemotherapy given before infusion. Its purpose, as the specification puts it, is to "create space" for CAR-T expansion. Reducing the patient's own lymphocytes lowers competition for homeostatic cytokines and reduces cells that could suppress the infused product, which helps the CAR-T cells to engraft and expand.

Specification section 6.2.1 lists three regimens and a timing window of 2–7 days before infusion. They are reproduced below exactly as the standard encodes them, so that implementers can populate reference data; they are not recommendations of this book.

In practice, the regimen and its doses are fixed by the product label for each licensed product and adjusted by the treating team for renal function and other factors, so software should store the regimen that was actually ordered rather than select one from the table. The SDK type LymphodepletionRegimen is shaped for this: a name, a list of drugs each with a free-text dose and the treatment days, a startDate, a completionDate and daysBeforeInfusion. The last field links patient preparation to the product workflow: if the batch is not released in time, the planned infusion date may move outside the window after lymphodepletion, and the clinical team must decide what to do. A scheduling system should therefore raise a warning as soon as the expected release date and the planned infusion date drift apart — before chemotherapy starts, not after.

PatientDose.lymphodepletion is optional, which is correct for products such as MSCs that are not preceded by lymphodepletion. For a CAR-T PatientDose, a validator may reasonably require it.

6.6 Dose Protocol

Chapter 5 derived the dose algorithm and reproduced the specification's worked example: a 70 kg adult receiving a product of 2.5 × 10⁸ total cells at 95% viability and 80% CAR+ gets 1.9 × 10⁸ CAR+ cells, or 2.7 × 10⁶ CAR+ cells/kg. This section places that calculation in the workflow rather than repeating it.

Weight-based versus flat dosing

The specification recognises two dosing styles. In weight-based dosing (§6.1.1), the prescribed dose is expressed per kilogram, and the number of cells to infuse depends on the patient's weight on the day of dosing. In flat dosing (§6.1.2), the dose is a total number of cells regardless of weight; the specification gives 1–6 × 10⁸ CAR+ cells per patient as an example and associates it with adult B-cell malignancies. The specification also quotes product examples, which this book reports only as values recorded in the standard at the time of writing:

Labels usually add details that the table does not carry: dosing bands that differ by indication, weight thresholds that switch a patient from per-kilogram to total dosing, and maximum total doses. A dose module should therefore treat the product label as a versioned reference document and store with each dose which label version was applied.

How the SDK treats each strategy

calculateDose() accepts strategy: 'weight-based' | 'flat-dose' | 'split-dose', but only the first branch is specific. For weight-based CAR-T it divides CAR+ cells by weight when targetMarkerPercent is supplied. For any other strategy, including split-dose, it returns the total viable cells (not CAR+ cells) in the unit 'total cells' and compares it with a fixed range of 1 × 10⁸ to 6 × 10⁸. Two consequences follow for an integrator: a flat CAR-T dose must be computed from the CAR+ fraction by the calling code if the prescribed dose is expressed in CAR+ cells, and a split dose is not split at all by the SDK. The dose record also retains a separate AdministrationRoute; this chapter assumes 'intravenous'. If any other route is used, the endotoxin limit discussed in Chapter 3 must be re-evaluated, because limits for intrathecal administration are far lower than the parenteral 5 EU/kg.

Split dosing

Specification section 6.3.2 describes an optional split schedule — 10% of the total dose on day 1, 30% on day 2 and 60% on day 3 — for patients with high tumour burden or prior severe reactions. The fractions sum to 100%, so the arithmetic is straightforward; what matters in software is that each fraction becomes its own administration event with its own identity check and its own vital-sign record. Using the specification's example product purely for illustration:

Error code C004 (DOSE_OUT_OF_RANGE, action "recalculate or adjust") applies when the calculated dose falls outside the prescribed range. As discussed in Chapter 5, the SDK expresses this through withinRange and assessment rather than by throwing; the dispensing layer decides whether to escalate it to a blocking C004.

6.7 Infusion and the Bedside Identity Check

An autologous product is only safe for one person. Giving it to anyone else is a potentially fatal error, and it cannot be caught by any quality test, because the product would pass every release criterion. The last and most important control in the chain of identity is therefore a procedural one: the bedside check that the product in hand belongs to the patient in the bed.

Pre-infusion checklist

Specification section 6.2.2 lists seven items that must be confirmed before infusion. They translate directly into a checklist that a nursing or pharmacy application can require to be completed, item by item, before it allows the "start infusion" action.

• ☐ Product identity verified — patient name, date of birth and product ID on the bag match the patient and the order
• ☐ Infusion orders signed
• ☐ Pre-medications administered (per institutional protocol)
• ☐ Baseline vital signs recorded
• ☐ IV access confirmed (central line preferred)
• ☐ Emergency equipment available
• ☐ Tocilizumab available on site (for CAR-T)

Identity verification is best done with two independent identifiers and two people, supported by a barcode scan of both the patient wristband and the bag label. The specification lists name, date of birth and product ID; many sites also match the chain-of-identity number that the manufacturer printed on the bag. In the data model this is a comparison between PatientDose.patientId / PatientDose.productId and the scanned values. Any mismatch raises C005 (IDENTITY_MISMATCH), whose action in the specification is "stop and investigate". C005 must be a hard stop: the application should not offer an override, and the event should be reported through the site's incident process. The checklist item for tocilizumab exists because cytokine release syndrome can begin soon after infusion; its management is the subject of Chapter 7.

Infusion

The standard infusion in §6.3.1 uses gravity or a pump at 10–20 mL/min over 10–30 minutes, followed by a normal saline flush to deliver the full contents, with continuous vital-sign monitoring during infusion and for at least one hour afterwards. The specification's step list is: verify product and patient identity; record pre-infusion vitals; prime the tubing with saline; connect the product bag; infuse at the prescribed rate; flush the line; monitor the patient for at least one hour. Two details deserve comment in software. Rate and duration are stated independently, so an order entry screen should compute one from the other using the actual bag volume — a single 50 mL bag at 10–20 mL/min takes about 2.5–5 minutes, and the longer durations in the specification make sense only for larger or multiple bags. Second, leukocyte-depleting filters remove the product itself and must not be used; this is standard practice for cell products even though the specification does not state it.

The administration record should capture the actual start and end times (setting PatientDose.actualDate), the bag identifiers infused, the time from end of thaw to end of infusion, any interruption, and the vital signs. Those times close the loop with section 6.4: if the infusion ended after the permitted post-thaw window, the event is a deviation that QA must review even if the patient is well.

6.8 Post-Infusion Monitoring Windows

After infusion, the workflow hands over to clinical safety monitoring. The specification defines two windows. The inpatient period (§6.4.1) is stated as a minimum of 10 days after CAR-T infusion in a hospital with ICU capability, with vital signs and neurological checks every 4–6 hours and daily assessments: temperature, blood pressure, heart rate and respiratory rate; a neurological examination with the ICE score; complete blood count; comprehensive metabolic panel; CRP, ferritin and fibrinogen; and a cytokine panel where available. The outpatient period (§6.4.2) is stated as up to four weeks after discharge, with at least weekly clinic visits and the requirement that the patient stay within two hours of the treatment centre.

These numbers should be treated as the standard's historical defaults, not as current regulation. A 10-day inpatient stay is not a regulatory requirement: many centres give licensed CAR-T products in an outpatient setting with daily visits and a low threshold for admission. For approved autologous CAR-T products, FDA label updates have since shortened the proximity requirement and the driving restriction to two weeks. The timing that applies to a given patient is set by the current product label and the institution's protocol.

The design lesson is the same one that ran through this chapter: encode the standard's numbers as configuration with provenance — each value tagged with its source (spec section, label version, institutional protocol) and its effective date — rather than as constants in code. When a label changes, the protocol changes with a configuration update and an audit record, not a software release. What happens inside the monitoring window — grading CRS and ICANS, the monitorSafety() risk rollup, and the integration with the EHR and pharmacovigilance systems — is covered in Chapter 7.