Cell and Gene Therapy Orchestration Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does treatment centre onboarding get underestimated so often?

Because it looks like deployment and it is really integration with an organisation. The software is the same at every centre. Everything around it is not: who books apheresis, how the collection slot interacts with the patient's clinical readiness and any washout from prior therapy, which laboratory receives and labels, who owns the freezer, and how the hospital decides whether a new external system is permitted to touch anything.

This is specific to cell and gene therapy because the centre is not a customer, it is a link in the chain of identity. A conventional supply chain can onboard a distribution partner slowly without patient consequence. Here the centre is where the starting material leaves a person and where the finished product is infused, so a centre that is only partially onboarded means a manual workaround at exactly the two points where an identity break is most costly.

Sequence around it. Pilot with two willing centres before broad rollout, and build the coordinator experience for the person who is doing four other jobs rather than for the sponsor's operations team. Sponsors who do this consistently move faster overall than those who build the full platform first and onboard afterwards. Budget centre onboarding as its own workstream with its own timeline, because it is the schedule risk, not the engineering.

What goes wrong with identifiers and the deidentification boundary?

Two failures that are expensive in opposite directions. The first is inventing your own identifier scheme. ISBT 128 is the international standard used for cellular therapy product labelling, and hospital cell processing laboratories and their systems already understand it. A bespoke numbering scheme means every receiving laboratory has to accommodate you, which is a request you will be making of the same people you need to onboard quickly.

The second is leaving the deidentification boundary until later. The manufacturing site should not receive patient identifiers, while the sponsor must still be able to reconstruct the identity link end to end. That is a permission and key management design, not a screen level restriction, and it has to be settled before anything else is built. Retrofitting it is one of the more expensive mistakes in this domain, because it touches every record, every interface and every report already written.

There is a third, quieter problem: every place a human reads an identifier and types it is a break waiting to happen. Verification belongs in software with a scan at each handoff, a hard stop on mismatch, and a record of who scanned, when and where. A mismatch at the bedside is a catastrophe averted. The same mismatch discovered in a report a week later is an investigation, and possibly a product that cannot be administered.

Why do courier, manufacturing and hospital integrations break after launch?

Because each is a different engineering problem with a different owner, and all three change without reference to your release schedule. Courier tracking interfaces are per provider and their event vocabularies differ, so a shipment exception means something slightly different from each one. Manufacturing execution and quality systems change when a process changes, which happens for reasons that have nothing to do with software. Hospital systems change on the hospital's timetable.

The failure that hurts most is a stale slot picture. If the orchestration layer cannot see real manufacturing capacity, it is scheduling against a guess maintained by a person in a spreadsheet, and every backwards schedule built on that guess inherits the error. The failure gets noticed when a slot that the system believed was free turns out to belong to another patient.

Integrate to real capacity rather than to a published plan, and treat any manual capacity entry as a temporary state with an owner and a date. On the courier side, normalise events into your own vocabulary so an exception means one thing across providers, and alert on silence: a shipment with no event for longer than expected is more concerning than one reporting a problem. Ask a developer to name what they have integrated, because a courier interface, a manufacturing execution system, a hospital scheduling system and a label printer are four separate problems and the last one carries a compliance dimension most developers do not expect.

What happens when validation and release paths are not covered?

The project slips at the end, which is the worst place for it to slip. Computer system validation in this domain is not optional, and it typically adds a meaningful proportion to the cost and calendar. Teams that treat it as a phase after build discover that validation evidence has to be generated alongside development rather than assembled afterwards, and that requirements written loosely at the start cannot be traced to tests at the end without being rewritten.

Release testing is the second gap. Sterility results do not come back quickly, and some results arrive after shipment. If the system models release as a single approval gate, it cannot represent the conditional paths your quality system actually defines, which means those cases live outside the platform in email exactly where the risk is highest. Label reprints are a related omission: a reprinted label is a chain of identity risk and needs its own controlled workflow and audit trail, not a print button.

Run validation in parallel from the start, keep requirements traceable to tests, and design release around the tests you genuinely have including the slow ones and the conditional paths. Full audit trail under 21 CFR Part 11 and the evidence your quality system and accreditation bodies require should be a design input rather than a late requirement. Deviations and exceptions should link directly to the patient and the batch rather than living in a separate quality system, because reconciling the two later is manual work that nobody has time for.

Should you build custom or configure TrakCel, Title21 or Vineti?

Buy if you are pre pivotal with a small number of treatment centres and your priority is being compliant and running quickly. TrakCel was built for exactly this problem. Title21 brings quality system depth alongside orchestration. Vineti built a platform specifically for personalised therapy supply. A custom build will not beat any of them on time to first patient, and we would say so rather than take the project. This is a small category with real specialists, which is unusual and worth respecting.

Organisations outgrow them at three predictable points. Treatment centre experience, when coordinator friction starts visibly affecting slot utilisation and time to treatment. Manufacturing integration, when scheduling needs live capacity rather than a weekly reconciliation. And therapy shape, when allogeneic products with lot based inventory, a bridging step, vector supply constraints or in country manufacturing pull the model past the configuration surface you were sold, and each change becomes a vendor request with a lead time you do not control against a launch date that is fixed.

Build when two or more of those hold, or when you are running more than one therapy and would rather have one platform than three vendor relationships.

How do hidden costs get into the quote?

Five drivers. The number of treatment centres, and specifically whether any of them require an interface into their own systems rather than a portal, which turns one onboarding into a project. Multiple manufacturing sites, particularly across regions with different regulatory expectations. Courier integrations, which are per provider and do not amortise. Validation, which is not optional here and is frequently quoted as a percentage without anyone specifying what evidence is included. And multi therapy support, which is far cheaper designed in than retrofitted.

Decide the multi therapy question before you sign even if the second therapy is years away, because the answer changes the data model. Autologous is one patient to one product with no interchangeable inventory and no safety stock. Allogeneic reintroduces lot based inventory, expiry and allocation, which looks more like conventional supply chain while still carrying chain of custody obligations. Designing for both costs less than adding the second model to a platform built entirely around the first.

What separates a chain of identity build that works from one that fails?

The scheduling model, first. Ask a developer what happens when apheresis slips by four days. If the answer is that a coordinator updates the dates, they have built forms rather than orchestration, and your operations team will still be living in a spreadsheet. Scheduling here runs backwards from the manufacturing slot: the slot sets the apheresis window, which must fit centre capacity and patient readiness, then courier booking with a cryoshipper that has its own charge duration, then release testing duration, then the earliest infusion date the centre needs in order to book a bed and plan bridging. Any change has to recalculate the whole chain in both directions.

The second marker is a shared view. One page per patient showing every step, its planned and actual date, who owns the next action and what is at risk, visible to the sponsor and the treatment centre at the same time. That is worth more than any individual feature, because most delays in this industry are not caused by anyone failing at their job. They are caused by two parties holding different versions of the plan.

Finally, settle ownership before kickoff: the repository, the infrastructure accounts and the complete validation package. At Digital Heroes the client owns all three from the first commit. In a domain where one patient's only dose may be in transit, a system that schedules treatment cannot be exposed to a commercial dispute with a supplier.