article
← Insights
What Am I Missing?

Reliability First: Stop Treating Operations as an Afterthought in Radiopharma

A process can pass qualification and still be fragile in routine use. Reliability starts earlier: in the URS, DQ, interfaces, timing assumptions and operating scenarios that define whether the process can withstand real life.

Marlous M. C. van der Hooft · 2026-02-23

Radiopharmaceutical projects quite rightly devote enormous attention to scientific performance, engineering, GMP compliance, aseptic processing and qualification. But there is another question that deserves the same seriousness: will this process work reliably on an ordinary Tuesday, when the project team is no longer standing nearby, not every input arrives exactly on time and normal variability starts to appear?

That is where design becomes reality. A process may perform beautifully during a carefully prepared qualification run and still become fragile in routine operation if the interfaces between people, materials, equipment, QC, QA, data, planning, logistics, maintenance, radiation protection and patient timing have not been understood as one connected system.

Operations should not be the place where unresolved design questions land

There is a familiar project sequence in which Engineering designs, equipment is qualified, procedures are written and Operations is then expected to follow the process. The difficulty is that operations is not a passive phase after design. It is the point at which all the interfaces finally meet, and if one of those interfaces is fragile, the problem appears operationally even when each individual component looked acceptable on its own.

That is why I think operational readiness needs to influence the project earlier. The question is not whether Operations should take over engineering decisions, but whether the people who will eventually run the process have had enough influence on the assumptions, interfaces and operating scenarios that determine whether the whole system can function reliably.

Reliability is not the same as technical function

An equipment item can function correctly and still be difficult to operate reliably within the full process. A system can pass qualification and still create unnecessary delay when used under real timing pressure, while a procedure can be correct yet force people into repeated clarifications because the workflow around it is unclear. A supply chain can work on average and still fail exactly when one tightly timed material does not arrive.

This is why operational reliability has to be considered as a system property. The question is not only whether each element works, but whether the combined process remains controllable when normal variability appears. In radiopharmaceutical manufacturing, that matters particularly because products decay, release timing matters, patient schedules matter and production, QC, QA and logistics are tightly coupled. A relatively small delay can propagate through the process very quickly.

Weak interfaces become visible quickly

That does not mean every operation needs excessive redundancy. It means the important dependencies need to be understood. Where is there no useful buffer? Which information is needed before the next decision can be made? Which equipment or person represents a single point of failure, which activities compete for the same resource, and what happens when a material, result, approval or intervention takes longer than expected?

Those are design questions, even though their consequences often become visible only after go-live. If they are addressed late, Operations is left to manage them through local workarounds, additional checks and individual experience. If they are addressed early enough, the project still has options.

Validate for reality

Representative qualification is therefore not only about proving that equipment can achieve a technical parameter. It should also help us understand whether the process can be executed under representative conditions. Are the timing assumptions realistic? Can operators perform the required sequence without unnecessary conflict between tasks? Is the information needed for decisions actually available at the right time, and can an abnormal but foreseeable situation be recovered without inventing a new process under pressure?

This is also where procedures become a useful reality check. If the written procedure describes something that people cannot genuinely do under the expected operating conditions, routine operation will eventually expose the difference. The earlier we notice that mismatch, the more useful qualification becomes.

Reliability belongs in the URS and DQ

By the time a process is live, many reliability problems are expensive to solve, which is why they need to appear earlier. A good user requirement does not describe only capacity, dimensions and technical performance; it also captures the conditions needed for the process to be operable, including visibility, access, data, maintainability, timing, recovery, interfaces, support and human interaction.

Design Qualification should then challenge whether the proposed solution actually supports that intended use. That is much more useful than discovering after go-live that Operations has become the permanent workaround layer between design intent and process reality.

Reliable systems do not depend on heroics

Experienced operators are extremely good at making imperfect systems work. They remember which step needs extra attention, know whom to call, recognise when a piece of equipment is behaving differently and often prevent small problems from becoming visible. That experience is valuable, but it can also hide system weakness. If the process only performs because particular people repeatedly rescue it, the organisation may mistake human adaptability for process capability.

Reliability should reduce the need for heroics, not celebrate them as the operating model. Experience should remain essential because it adds judgement, anticipation and depth, but it should not be the invisible glue holding routine operations together.

Operations helps define what complete means

I no longer think of operational readiness as a final project phase. Operations should influence what “ready” means from the beginning: whether the process can be executed repeatedly, whether it can recover, whether people can see what they need to know, whether routine decisions can be made at the right level and whether the system can withstand ordinary variability without immediately becoming reactive.

Those questions connect directly to the user-side work described in our Perspective Paper, The User Side of Radiopharmaceutical Facility Design. A successful project is not complete when the facility is built, or even when qualification is finished; it is complete when the process can be operated reliably in the reality for which it was designed. Operations should not be the safety net for what the project did not resolve. Reliability needs to be designed in before go-live.