Preserve identity and custody across cell-therapy handovers

Two patient-specific shipments reach the same site on the same day. Their transport records are complete, but one receiving screen associates a shipment with the other case. The temperature dashboard looks normal while the identity relationship is unresolved.

For cell-therapy operations, identity, custody and condition are distinct evidence dimensions. A reliable software design preserves all three and makes a mismatch visible before the next activity proceeds under the approved process. It must not infer that the correct delivery address or a normal temperature record proves the intended identity association.

This article describes an engineering workflow for authorised operational teams. Product-specific procedures and the applicable regulatory framework determine identity verification, release and clinical actions.

Define the relationships that must survive the journey

Start with the programme's approved identity model. Identify the records used for collection, manufacturing, product units, shipments and the intended recipient relationship where applicable. Establish who controls each identifier and the authoritative mapping between them.

Avoid assuming that every cell-therapy product follows the same patient-specific model. Autologous and other product arrangements can have different relationships and requirements. The system must represent the actual product and process rather than impose a generic one-patient-one-box rule.

EU guidance for advanced therapy medicinal products addresses traceability records linked to the relevant product. Its EU scope must be considered before applying particular requirements elsewhere. EU GMP guidance for ATMPs, section 6.6.

Use the applicable framework and approved procedures to establish the required relationships, then verify that each system handover preserves their meaning.

Keep identity, custody and condition independent

Identity concerns the relationship between the material or product and its authorised case or source records. Custody concerns who held or transferred the physical object. Condition concerns the relevant handling and monitoring evidence.

Show these dimensions together without merging them into a single green status. A resolved custody event can coexist with an unresolved identity discrepancy. The user should know exactly which question remains open and who is authorised to resolve it.

Follow two fictional coded shipments

Consider an illustrative simulation using fictional case codes C-101 and C-102 and shipment codes S-501 and S-502. The approved test data maps S-501 to C-101 and S-502 to C-102. No real patient information is used.

During simulated receiving, the interface presents S-501 under C-102. The operator records the mismatch through the defined exception path. The next dependent activity remains controlled while the authorised team investigates the source records and mapping.

The system retains the scanned identifier, displayed association, relevant transaction references and the correction decision. It does not swap the case code automatically because the second shipment appears to provide an obvious match.

Suppose the investigation identifies an interface mapping error. The correction follows the authorised process and is linked to the original discrepancy. The team also assesses whether the same mapping issue could affect other records. Fixing one screen is insufficient if the underlying transformation continues to produce wrong associations.

The example demonstrates a software acceptance case. It does not prescribe a clinical action or a universal identity-verification method.

Control matching at each handover

For each handover, define the required identifiers, source of truth, authorised verifier and evidence retained. The approved procedure may require additional checks; the application should support those exact checks and roles.

Do not make name similarity or a nearest-match algorithm the deciding mechanism. Similar case references, reused local numbers or inconsistent formatting can create false associations. Keep controlled aliases and transformations documented and test them with confusingly similar synthetic examples.

When labels or identifiers change under an authorised process, preserve the predecessor-successor relationship. A replacement label should not make the original identity trail disappear. If material is split or combined under the actual process, represent the approved relationships explicitly rather than duplicating one record with no genealogy.

The interface should display enough context for the authorised user to perform the required check without exposing unrelated sensitive information.

Design privacy around the actual work

Use the minimum information each participant needs for its authorised role. A transport provider may need coded shipment identity and handling instructions without access to the clinical record. The clinical or authorised operational team may need a controlled route to the underlying identity relationship.

Coded or pseudonymous identifiers do not necessarily make data anonymous. If a relationship can be recovered through a controlled mapping, protect that mapping and the relevant access. Do not label the system anonymous merely because a patient's name is absent from a logistics screen.

Agree applicable privacy, retention and access requirements with the responsible functions for the actual programme and jurisdictions. The clinical data access and privacy guide develops that governance boundary.

Keep production data out of general development and demonstration environments unless its use has the necessary authorisation and controls. Synthetic identities are usually sufficient to test the matching and exception behaviours described here.

Preserve discrepancy evidence across systems

An identity discrepancy can involve several applications and organisations. Create a case reference that links the original observations, affected records, investigation and authorised resolution without allowing unrestricted access to all underlying data.

Record who can change the mapping and who reviews the consequence. A developer's database correction should not silently become the authoritative operational decision. The application needs a controlled correction path that preserves the original association and the reason for change.

The integration exception guide addresses delayed, duplicate and conflicting messages. An old message must not restore an association that has been corrected through an authorised process.

Condition records also need a reliable relationship to the same physical object. The logger identity and time guide explains why device assignments and chronology remain separate evidence questions.

Plan continuity without inventing new authority

Time-sensitive operations need an approved contingency process when a system or interface is unavailable. Define what records are accessible, who can perform the required checks and which activities may continue under that process.

The software should not bypass identity checks because a network outage makes them inconvenient. Nor should it assume that every activity must stop if an approved alternative can support it. The responsible programme determines the permitted workflow and its evidence requirements.

After recovery, reconcile the contingency records with the system. Preserve actual event times and the later entry or upload times. Identify any conflicts before treating the digital history as complete.

Test identity failures deliberately

Use synthetic cases with similar codes, an incorrect mapping, a replaced label, a split record and a repeated interface event. Test access with the actual roles, including a participant who should see the shipment but not the protected identity mapping.

Verify that each discrepancy reaches the authorised owner and that dependent activities follow the approved control. Confirm that a normal condition record cannot clear an identity exception and that correcting the mapping does not erase the original evidence.

Measure unresolved identity exceptions, reconciliation effort and the ability to reconstruct authorised changes. These are process measures; they do not establish clinical safety or regulatory approval by themselves.

NextEdge Labs can help model the identifiers, access boundaries and integration behaviour around the programme's approved procedures. A bounded pilot should demonstrate the difficult mismatch case before broader operational use.

Summary and next actions

Identity, custody and condition provide different evidence. Preserve their relationships and require authorised resolution when they disagree, especially across organisational and system handovers.

• Map the approved identifiers and authoritative relationships for the actual product workflow.
• Define the checks, roles and evidence required at each handover.
• Test confusingly similar synthetic cases and an incorrect association across interfaces.
• Verify that privacy controls and contingency procedures preserve the required identity checks and history.