April 22, 2026

Most people in clinical programming have a complicated relationship with GxP validation. They’ve done a lot of it, but they’ve also spent a lot of time on the version of it that involves checklists, initials, and painstaking corrections. That’s theater, not validation. 

In a recent Atorus Unscripted webinar, Ashley Tarasiewicz and Maya Gans joined Aga Rasińska for an unscripted conversation about what validation actually means in clinical analytics, where the confusion comes from, and how teams can approach it more clearly. Here’s what they covered. 

Verification, Validation, and Testing Are Not the Same Thing 

The conversation started where most confusion starts: the terminology. All three terms get used interchangeably, and that’s a problem because they describe genuinely different things: 

  • Verification is confirming that something meets its specifications  
  • Validation is confirming that it works for its intended use  
  • Testing is the method that gets you to either one 

The verification lives in the SDLC — unit tests, integration tests, the structured process of confirming a system was built correctly. Validation is more of a stakeholder conversation about whether you’re building the right thing for the people who will use it. User stories map to validation. Tests that confirm those user stories map to verification. 

The definitions are close enough that it’s easy to see why they collapse into one. The more important point is that all three concepts circle back to the same underlying goal: building trust that a tool or output does what you need it to do in the context you need it to do it. 

GxP Validation Is About Trust, Not Process 

Trust exists on a spectrum, and validation should be scoped to match it. A statistical output going into a regulatory submission needs rigorous validation. A scratch calculation you’re throwing away after a meeting does not. 

A useful model is the layered approach familiar from SAS®-based statistical programming: You validate the dataset, and then you validate the table, but in the table program you don’t re-derive the treatment-emergent flag. Rather, you calculate with it. Layers stack, and each layer validates what’s new, not what’s already been validated below. 

The same logic applies in open-source environments. A validated R environment like Agerein is one layer. Validated packages like OpenVal® are another. The functions your team builds on top of those packages are another. Instead of re-validating what’s already been proven, you validate what’s new.1 

“Validation is almost ironic — it’s this cumbersome, scary topic, but it’s literally just about making you comfortable and building trust.” — Maya Gans 

Shiny App Validation: What You Need to Trust 

Shiny applications represent a shift from the static validation model most clinical programmers learned. When an app can produce thousands of output permutations depending on how a user interacts with it, you can’t QC every figure. 

The answer is to validate the right things: the validated packages underneath the app, the custom functions built into it, and the UI logic that drives user interactions. If the functions are validated and the filtering logic is confirmed to work correctly, you can trust the output without validating every possible combination the app might produce. There’s no need to test whether a visualization library can draw pixels correctly. What matters is whether the data behind the plot is correct and whether the app responds as expected when a user takes a specific action. 

Together, that’s a GxP validation approach that’s both rigorous and practical. Validate the logic, trust the layers that have already earned that trust. 

“You don’t have to say, ‘I validated a thousand different figures that could come out of this app.’ You have to validate the functions that go into it and the user interaction. And then you can trust what’s being output.” — Ashley Tarasiewicz 

Automation Replaced the Theater 

The older process involved manually initialing checklists, sometimes getting the date wrong, and making manual corrections along the way. That produced documentation, but it didn’t produce efficiency or confidence. 

Today, test requirements can be connected to executable test code automatically. CI/CD pipelines (continuous integration and delivery) can be set up so that nothing moves to development or production unless all tests pass. Reports are generated automatically.2 The checklist session is gone. 

The documentation is still there (as a industry we love receipts), but the process of producing it no longer requires manual effort for every step. That’s GxP validation. 

Two Questions Worth Asking 

When approaching any validation challenge, two questions cut through the noise: 

1. What is my intended use of this output, and what does it affect?  

If it affects a patient outcome or a regulatory submission, more validation is warranted; if it’s exploratory, less may be needed 

2. What do I need to do to trust this, and lose no sleep over it?  

That answer determines the process, not the other way around; approached that way, GxP validation stops being a bureaucratic exercise and becomes what it’s supposed to be: a disciplined method for building confidence in your tools and your outputs 

Watch the full Atorus Unscripted: Validation Without Theater recording.  

Questions about building a GxP validation approach? Contact Atorus. 

Frequently Asked Questions 

Verification confirms that a tool or system was built correctly according to its specifications, typically through unit tests, integration tests, and structured SDLC processes. Validation confirms that the tool works correctly for its intended use, typically through user stories and requirement-mapped tests. Testing is the method used to accomplish either. In practice, the two terms are often used interchangeably, but keeping them distinct helps teams make clearer decisions about what they need to prove. 

Not necessarily, as it depends on the intended use. An exploratory application used to investigate data after a study misses its primary endpoint may not require the same rigorous GxP validation as an application producing outputs that go directly into a regulatory submission. The right question is “What level of trust do I need in this tool for how I plan to use it?” The answer determines the validation approach. 

The layered approach treats validation like the SAS®-based model of datasets, tables, and figures: Each layer validates what’s new, not what was already validated below. In an open-source environment, the layers typically include the validated R environment (such as Ageirein), validated packages within that environment (such as OpenVal), and the custom functions and application logic built on top. When each layer is trusted, teams don’t need to re-validate what’s already been proven at a lower level. 

Rather than attempting to QC every possible output permutation, the recommended approach is to validate the components that drive those outputs: the validated R packages underlying the app, the custom functions performing calculations, and the UI logic that filters and routes user interactions. If those elements are validated, the outputs they produce can be trusted without validating each one individually. 

It depends on whether users will be accessing those dependencies directly and what governance the organization has in place. If a team only needs a primary package like admiral, and there are controls ensuring programmers aren’t accessing its dependencies independently, validating the primary package may be sufficient. If those dependencies are accessible to users without restriction, they may need to be validated as well.  

References 

1 R Validation Hub. “A Risk-Based Approach for Assessing R Package Accuracy within a Validated Infrastructure.” R Validation Hub Working Group, 2020. https://www.pharmar.org/white-paper/  

2 FDA. “General Principles of Software Validation; Final Guidance for Industry and FDA Staff.” U.S. Food and Drug Administration, 2002. https://www.fda.gov/media/73141/download  

Back to Blog