One Study, Two Worlds: What Heads of Statistical Programming Need From One Environment

By Michael Stackhouse, Aga Rasinska

November 9, 2026

If you lead a statistical programming team, you’ve sat through this meeting more than once. Someone presents a new platform with polished slides, and the word “transformation” appears early. And you are thinking about different things entirely. Will my team have to start from scratch? Will our SAS^® programs still run? Who validates this, and how long before anyone can do study work in it? What happens to the studies already in flight? 

Those are the right questions when you have watched a migration eat a year, a validation project stall at the last mile, and a good team lose its rhythm to a tool nobody asked for. So, let’s start with a problem every programming head already lives with: most organizations run clinical analytics in two worlds. 

Why Do Teams Run Exploratory and Submission Work in Separate Environments? 

Validated environments are typically expensive to change, while exploratory work needs the freedom to try packages and methods and throw them away if they don’t work. One environment is open, fast, and lightly governed: the place for ideas. The other is locked, validated, and slow to change: the place for evidence. Between them sits a translation step that almost nobody puts on a project plan. 

That has been a reasonable trade-off for a long time. Studies ran mostly in one language, data arrived through a few channels, and submission work had a clear starting line late in the study. 

Those assumptions have worn thin. Programming teams now work across R, Python, and SAS^® in the same study. The typical late-stage protocol collects 3.6 million data points, three times the volume of a decade earlier, and nearly three in four organizations run two or more EDC systems.¹ Regulators have moved too. ICH E6(R3), endorsed in January 2025, treats data governance as a responsibility across the full data life cycle, including metadata, audit trails, and how data is transferred and migrated between computerized systems.^2,3 

Do two worlds still feel safer? Is the gap between them worth what your teams are paying for it? 

The Cost of Moving Work Between Environments 

Moving work between environments costs a rebuild, a second round of QC, and the history of how the analysis was developed. None of it shows up as a line item, and all of it lands on programmers. 

Picture a statistician three weeks into investigating an early safety signal in the exploratory workspace. The analysis holds up. The study team wants it in the next DMC package. Someone asks: Can we just move it over? 

Usually, no. Code written against one set of package versions, paths, and data connections has to be rewritten for another. Two versions can give different numbers — not wrong numbers, but different ones — and someone spends days reconciling a difference the environment created. QC that already happened happens again, because the validated world can’t trust what it didn’t see. And the decisions, the data snapshot, and the dead ends that explain the final method stay behind. The audit trail starts at the copy, not at the thinking. 

Each crossing between environments looks small on its own: an afternoon of rework here, a re-run there. That is what makes it expensive. Study timelines rarely slip in one go; they slip through small delays that add up. Data flow and cross-team coordination look like modest parts of the study, but that work sits closest to the deadlines, where nothing is left to absorb a delay. 

Most teams budget for the environments and their maintenance. Few budget for the crossings. 

Where Do Crossings Show Up in a Study? 

Once you start looking for crossings, you’ll find them everywhere. 

Data arrives through manual EDC exports, so data management and biometrics both wait, and each ends up with its own copy. Study files sit in email threads and shared drives, with access set once in the analytics environment and again everywhere else. SAS^® and R teams produce outputs in parallel and reconcile them by hand. The SRC and DMC dashboards live outside the study, with their own logins and their own extract of the data. And increasingly, AI tools sit outside the validated boundary altogether, which narrows how useful they can be. 

Each of these is a smaller version of the same problem. Spot it in one tool, act on it in another, and maintain the illusion that everything is tracked. 

Every crossing is a place where data is copied, access is defined again, and the audit trail starts over. Together, they are the reason so many teams spend their first months on a study building infrastructure instead of doing analysis. 

Can Exploratory and Submission Work Happen in the Same Validated Environment? 

Yes, when control belongs to the role and the project rather than to the environment, exploratory and submission work can happen in the same place. A version-locked, validated base sits underneath all work. Exploratory projects add what they need on top. Submission projects stay locked. Nothing has to leave to change status. 

This is where most programming heads get uneasy, and fairly so. Doesn’t openness for exploration put GxP compliance at risk? It does, if openness and control are properties of the environment. They don’t have to be. 

Think about what your team already does well. You define who can view, run, edit, and approve. You track every change. You know which data snapshot an output came from. Those disciplines don’t need a second environment. They need one place where they apply to everything, from the first data pull to the final TFL. 

When an analysis is ready to move toward submission, does anyone have to copy it over? If the answer is yes, you don’t have one environment. You have two, with a bridge. 

Does One Environment Mean Starting Over? 

No. The change worth making is in what your team stops doing, not in relearning what it already does well. The environment should feel familiar on the first morning, run the programs your team trusts, and let new ways of working come in as the studies call for them. That matters more than any capability list, because an environment is only as good as the Monday after go-live. 

Your programmers open the tools they already know. SAS^® programmers work in SAS^® Studio. R and Python programmers work in RStudio, Positron, or VS Code. Your existing programs keep running. The SAS^® macros and standards your team has refined over years are the foundation, not legacy to be retired. R comes in alongside them, script by script, when it makes sense for the study. When a pipeline mixes both, it runs in the right order as one job, with a full execution log, instead of someone tracking dependencies in a spreadsheet. You move the files you decide to move, not the whole folder in one risky afternoon. 

And the work you dread most is already done. The environment arrives validated, with R packages documented and version-locked underneath, so there is no validation project before anyone writes a line of code. New studies start from templates that already carry your folder structure, permissions, and audit settings. And the team signs in with the same login they use for the rest of the company. 

Is Ageirein™ a Statistical Computing Environment (SCE)? 

Yes, and more. Ageirein includes an SCE and extends it across the full clinical data workflow, from data intake through SDTM, ADaM, and TFLs to the apps teams use to make decisions, so exploratory and submission work happen in the same validated environment. 

We designed Ageirein around the questions programming heads ask in that first meeting. Data comes in from the EDC directly, so nobody waits on a manual export. Ageirein Projects sets the access controls for each study, and Ageirein Files lets teams browse and preview study files under those same controls. Ageirein Flow runs R and SAS^® programs as one pipeline, in dependency order, with full execution logs. Teams promote exactly the files they choose between validated environments instead of migrating in bulk. SRC, DMC, topline, and other apps open from the project in one click. AI assistance runs inside the compliance boundary. OpenVal^® provides the validated R package base underneath. 

The first login to the new environment comes within two weeks. After that, new projects start in minutes from pre-validated templates. Your team’s skills carry over. What changes first is where their time goes: less on setup and moving work between environments, more on the analysis itself. 

Questions to Bring to Your Next Platform Meeting 

Think about the last analysis your team moved from exploration to submission. How many times was it rebuilt, and how much of that time went to the analysis itself? If a regulator asked how a table was derived, from the first data pull to the final output, would the answer live in one environment or two? And if you were setting up your next study from scratch, would you build two worlds again? 

References

¹ Harper, B., Smith, Z., Snowdon, J., et al. Characterizing Clinical Data Management Challenges and Their Impact. Applied Clinical Trials, February 2021 (Tufts CSDD and IBM Watson Health 2020 benchmark). 
² ICH. E6(R3) Guideline for Good Clinical Practice, Step 4 final consolidated guideline (endorsed January 6, 2025; consolidated with Annex 2, June 2026). 
³ FDA, MHRA and Health Canada GCP Symposium. ICH E6(R3) Draft: Good Data Governance Practices (February 2024).