| Blog
PHUSE SDE Copenhagen 2026: Lessons on clinical programming automation
Automation promises more room for science. PHUSE SDE Copenhagen 2026 offered a harder question: What has to change for teams to actually get that room?
Automation promises more room for science. PHUSE SDE Copenhagen 2026 offered a harder question: What has to change for teams to actually get that room?
If a tool saves an hour, what should happen to that hour? It could become time to investigate an unexpected result, improve a method, or talk through an analysis with a clinical colleague. It could also disappear into checking the output, finding the right version, or starting the next assignment. A faster task does not automatically create a better working day.
Perhaps that is the part we keep missing. We make individual tasks faster while the work around them changes much less. The PHUSE Single Day Event in Copenhagen hosted by Ferring Pharmaceuticals on 22 October 2026 took the theme Better, Faster, Smarter: Clinical Data Science in Practice and offered a way to examine that idea in practice.
For entimo, this is where the technology conversation becomes most useful: where gains from technology become gains in medicine and in business.
Why are statistical programming tools introduced but not used?
At the Copenhagen event, Denis Gavriusev, a Senior Statistical Programmer in Oncology Biometrics at AstraZeneca, put a sharp distinction on the table.[1]
His programming team had a catalogue of more than 270 tools, with more than 70 of them recommended specifically for oncology, yet they could not reliably measure how many were actually being used. His framing was direct: “Rolled out” and “adopted” are different words.
Continuous project deadlines make a powerful case for using the code you already know. Before an alternative can save effort, someone has to find it, understand it, and take the risk of changing an established routine. In Gavriusev’s experience that he documented in the presentation, task-based toolkits and designated champions helped but only when introduced through existing meetings. Outreach that required new engagement did not progress.
The lesson is specific: Put tools where people already look for help, give them an owner, and make it clear what to do when something goes wrong. Then check whether use actually changes. For entimo, those everyday details belong in the same conversation as the technical requirements.
A good idea still has to work with everything around it. It may save one person time but leave another with more to sort out. That is why the Copenhagen examples are worth looking at together: They start with different problems and arrive at different kinds of solutions. Lundbeck and Novo Nordisk illustrated why there is no single technical answer. Mathias Thrane Andersen, from Lundbeck, described a deliberately transparent SAS framework: one program, one SDTM dataset, transformation logic close to the programmer.[2] Vicky Poulsen of Novo Nordisk addressed pooled study data through a cloud-based data lakehouse and shared views, as well as identifying stability problems when data sources were unavailable. It was a different problem with a different solution.[3]
Both approaches take a recognizable difficulty seriously. One protects the programmer's ability to understand and adapt a transformation. The other addresses repeated processing and duplicated data. The useful question for each is not whether simplicity or automation wins, but whether the approach remains manageable as demands grow and whether its dependencies hold.
The same reasoning applies when an entire computing environment changes. Toni Auene Tuxen, Director and Head of Statistical Programming at Zealand Pharma, and Claus Oxvig Stenberg, Director, Statistical Programming at Ascendis Pharma, examined that transition with Kala Shivali, Executive Director, Services at Sycamore Informatics. Their account brought migration, validation, governance, infrastructure, user adoption and support together, including more than a year of preparation and testing before go-live.[4]
Consider even a routine handover. A colleague receives an output and needs to find the input data, the code version, and the execution behind it. If that means piecing together separate files, some of the saving is already gone.
This is the connection entimo builds into clinical computing workflows with entimICE® FastTrack: versioned data, programs and outputs, together with execution traceability and controlled workflows. It gives colleagues a starting point for checking and explaining the work they receive rather than reconstructing it.
The team benefits from a faster draft when the saving survives review. If the next person has to rebuild its reasoning, the work has only moved. Anette Dalsgaard Jakobsen of SAS explored large language models supporting clinical data mapping, code and documentation, with people reviewing and approving the results.[5] The opportunity is real, but a reviewer needs a useful role, not simply a place at the end of the process. For example, reviewing proposed transformation logic requires enough context to judge whether it fits the intended analysis. A polished explanation cannot replace access to the relevant specifications and source information. An approval step has practical value when the reviewer can challenge the work and resolve a question.
R, the statistical programming language, offers reusable packages; deciding whether a particular package is suitable for an intended use requires supporting evidence. The R Validation Hub’s 2020 white paper describes a risk-based approach that considered purpose, development and maintenance practices, community use and testing.[6] The opportunity that automation tools present is to remove the repeated preparation around that judgment, not the judgment itself.
This is the reasoning behind entimICE® ValoRpacks. Automated information gathering and AI-assisted preparation of validation artifacts sit within a process that retains human review, modification and approval. When a package version changes, earlier validation records come forward and highlight what has changed so the reviewer can focus on the useful question: Does this change matter for the intended use?
What should teams do with time saved by automation?
A reliable saving creates an opportunity. The organization decides what happens next.
Copenhagen offered a useful picture of how organizations could decide. Carlotta Porcelli, Clinical Data Science Specialist at Novo Nordisk, described leading interpretation and communication of results from a Phase I trial, working alongside biostatisticians, clinical pharmacology, safety and medical colleagues.[7] What made it possible was not just her technical knowledge but a leadership decision that allocated the responsibility. Jean-Marc Ferran, Consultant and Owner at Qualiance, made a related point, that knowing the disease and the questions that concern medical colleagues changes what a data scientist notices in a result. His formulation was simple: Validated ≠ understood.[8]
An hour saved is not an hour protected. If scientific involvement is the ambition, managers need to decide where that time can go. Technology can remove preparation work. Giving people permission to use the resulting capacity differently remains an organizational choice.
What does entimo bring to a better conversation?
The Copenhagen examples give reasons for optimism: transparent programming, shared infrastructure, AI-assisted preparation and broader scientific responsibilities all offer practical possibilities. They also expose the work needed to realize gains. Adoption needs support. Shared infrastructure needs dependable sources and governance. AI-assisted work needs review that people can carry out effectively. Scientific development needs room in the delivery plan.
For entimo, the connection between those needs is the starting point. A computing environment and a validation workflow should help people carry their work—and the evidence behind it—through to the next decision. That requires understanding where programmers, reviewers and study teams depend on one another. It is a more useful design conversation than beginning with a list of features a team might buy.
Where does the benefit disappear in your workflow and what would need to change for your team to keep it? That is a practical place to start a conversation with entimo.
References
Start a practical conversation with entimo about translating better software into better business.
