When I started working in radiopharma in 2004, I was asked to set up an FDG production line in an already functioning facility in the Netherlands. The building existed, the licences were there and the team was operating. Seen from a distance, it could easily have looked like a relatively straightforward extension: add another target to the cyclotron, install transfer lines and establish the production, QC and packaging activities around it.
The reality was very different.
I had registration documentation from our Italian site and my previous pharmaceutical experience, but there was no blueprint telling me how all the pieces should fit together. I had to find materials and suppliers, write SOPs and validation protocols, work out how the new process fitted into existing systems and understand how local requirements affected what we were trying to do. Even something as apparently ordinary as maintenance quickly became part of the problem. I eventually trained as a service engineer because I needed enough understanding to teach others and create the documentation we actually required.
At the time I did not think of this as developing a framework. I was simply trying to make the operation work.
Then Portugal called
A few years later, colleagues in Portugal were building a similar FDG operation and started asking how we had done it. By then I had answers because I had lived through many of the questions already.
When I arrived in Porto in November 2006, however, the context was completely different. Instead of an operating facility into which a new process had to be integrated, I found a cellar under construction, a few rooms and no established team. There was no functioning QC laboratory to validate and no mature local system into which the new operation could be inserted.
There were seven documents from Italy that were intended to form the quality system.
Seven.
I remember explaining that this was not enough. A functioning GMP operation needed much more than a small set of procedures describing the most visible activities. We needed change control, deviation handling, maintenance, recall, supplier management and all the other processes that allow individual activities to operate as one controlled system.
The answer was essentially: perhaps you can write it.
That was an interesting moment, because I had never built a complete quality system from scratch either.
Building once, then learning from it
Fortunately, I was not alone. Together with colleagues including Magdalena, Enriqueta and Theresa in Spain, we started connecting the pieces. We translated and adapted procedures, created the missing processes and gradually built something that could actually support the operation. It took about a year, and the work changed through audits, experience and the questions that emerged as the site became real.
It was difficult and enormously educational.
It also left me with a very clear thought: I did not want the next site to have to start from zero again.
So we began creating a more generic quality-system package: a reusable core that could be adapted to the specific site rather than reinvented every time. When an audit or operational experience showed us something better, we could improve the core and use that learning at the next site.
It was not identical everywhere, nor should it have been. A site in Portugal was not a site in Spain, the UK, Norway or Italy. Local regulation, organisation, equipment and operating reality differed. But much of the thinking did not need to be rediscovered.
That distinction has stayed with me ever since.
Reuse the proven core; understand the configuration
I still see projects struggle with the false choice between standardisation and bespoke design.
One approach says every site is unique, so we start again. The other says we already solved this once, so we simply copy it.
Neither is particularly convincing to me.
There is usually a proven core: things we have learned, structures that work, requirements that repeat and approaches that do not need to be rediscovered. But around that core sits the configured reality of the specific operation: the facility, process, equipment, interfaces, organisation, supply chain, regulation and people who will actually use it.
The work is in understanding which is which.
If we treat everything as unique, projects become unnecessarily expensive and slow. If we treat everything as standard, reality eventually exposes the assumptions we failed to question.
Processes before buildings
That early experience also changed the way I look at facility projects. A building is important, but it is not the process. Equipment is important, but it is not the operation. A quality system matters enormously, but documents alone do not create control.
The process has to connect those elements.
What happens physically? What information is needed? Who makes which decision? Where are the handovers? How does material move? How is an abnormal situation handled? Which activities depend on one another? What must the operator be able to see, reach or understand?
If those questions arrive after the building and equipment decisions have already hardened, the project has fewer options.
That is one of the reasons I have become so insistent on understanding process reality early.
From experience to a connected approach
Looking back, many of the ideas that now sit behind Qualificiency were already present in those first years, although I would not have used the same language then.
I learned that reusable structure saves enormous effort, but only when it is adapted intelligently. I learned that a technically correct component can still fail at the interface with the wider system. I learned that documentation becomes useful when it reflects reality rather than merely describing an intended state. And I learned that capable people can make surprisingly incomplete systems function — but that we should not confuse their adaptability with good design.
Perhaps most importantly, I learned that compliance and performance are not two separate conversations. In radiopharma, they meet every day in the same process.
That is the radiopharma reality I recognise today: not one discipline, one document or one piece of equipment, but a connected operating system in which patient, product, people, process, radiation protection, time and regulation all have to work together.
The framework came later. The experience came first.
