When people think about a new radiopharmaceutical facility, it is natural to think first about what can be seen: the building, the cleanrooms, the hot cells, the equipment, the shielding and the utilities. Those things matter enormously, but many of the decisions that determine whether the facility will actually work are made before any of them become visible. The invisible foundation is the process reality underneath the design.
That starts with very practical questions. What will people actually do, in what sequence and with which information? Which materials arrive where, which activities compete for the same person, space or equipment, and what happens when something does not go according to plan? What will operators, Quality, Engineering, QC, Radiation Protection, Maintenance and Supply Chain need from the facility once the project team has gone home? If those questions are not mature enough when engineering decisions are made, the project may create a technically sound facility that is still unnecessarily difficult to operate.
A drawing can be correct and still be incomplete
One of the recurring problems in facility projects is that engineering can progress faster than the operational understanding behind it. A layout becomes mature, equipment is selected and interfaces begin to harden; then somebody from the future user organisation asks a very practical question and discovers that the answer is no longer easy to change. This does not necessarily mean the engineering was poor. It often means the intended use was not mature enough when the engineering needed it.
That distinction matters because engineering can only design against the requirements it is given. If the real process, operating scenarios and abnormal situations have not yet been understood, the design may solve the documented requirement while still creating difficulty in daily use. The gap is not between engineering and operations as functions; it is between the maturity of the decision and the maturity of the understanding behind it.
The user requirement is more than a specification
A URS is often treated as a document to produce. I prefer to think of it as evidence that the organisation understands what it is asking the design to achieve. That includes normal operation, but also cleaning, maintenance, interventions, material movement, sampling, waste, data, access, recovery, decontamination, requalification and eventually decommissioning. It includes the constraints created by aseptic processing and radiation protection, and it includes what needs to happen when time is short, information is incomplete or the normal route is unavailable.
If those questions are left until later, the project does not avoid them; it simply moves them downstream, where they become more expensive and harder to solve. This is one of the reasons early user-side work matters so much. The objective is not to describe every future detail before engineering can begin, but to make sure the decisions that depend on process understanding are not being made before that understanding exists.
Design Qualification should influence the design
This is also why Design Qualification matters most before the important choices become difficult to reverse. The value of DQ is not the document itself; its value is the multidisciplinary conversation around intended use, risks, interfaces and practical consequences while meaningful alternatives still exist.
Quality will see different concerns from Engineering. Operations will notice different constraints from the supplier. Radiation Protection may challenge an intervention that looks perfectly reasonable from another perspective, and Maintenance may expose an access problem that nobody sees during normal production. None of those perspectives is complete on its own. The design improves when they are connected early enough for the discussion to change something.
Normal operation is not enough
A facility can look excellent when everything behaves exactly as expected, but the more revealing questions often appear around abnormal situations. What happens when an operator needs to intervene, can they see what they need to see, can equipment be accessed without creating another risk, is the recovery strategy realistic and are alarms useful enough to support a decision? Can the process continue safely when one dependency fails?
These situations are easy to underestimate during design because they are not part of the preferred operating state, yet they are part of the real lifecycle. Many of the difficult moments that operators experience later were not created by the abnormal event itself, but by a design that never fully considered how the abnormal event would have to be managed.
Operability is a design property
Operations is sometimes treated as the group that will receive the facility after Engineering, commissioning and qualification are finished. I think that is too late, because operability is not something Operations adds after handover; it is a property of the design. If routine execution requires constant workarounds, if interventions are unnecessarily difficult, if information is not visible at the moment it is needed or if people must compensate for awkward interfaces every day, the problem is not simply operational. Part of it was designed in.
That does not mean Operations should dictate every engineering decision. It means the design needs enough user-side input to understand the process it is expected to support, including what good operation looks like over the lifecycle rather than only at the point of handover.
Build the invisible foundation first
The earlier the user side becomes clear, the more freedom the project has. Once walls move, equipment is ordered and interfaces are frozen, every unanswered process question becomes more expensive. Projects develop iteratively, so not every operational detail needs to be known before engineering can begin, but the critical intended use, major interfaces, operating scenarios and lifecycle assumptions need to mature at roughly the same pace as the design decisions that depend on them.
That is the subject of our Perspective Paper, The User Side of Radiopharmaceutical Facility Design: not replacing engineering, but making sure engineering receives a sufficiently mature picture of the reality it is expected to support. Because the strongest foundation of a radiopharmaceutical facility is not concrete; it is a shared understanding of how the process needs to work before the design becomes difficult to change.
