“The system is validated.”
In clinical research, that sentence sounds reassuring.
My instinct, however, is to ask a second question:
Validated for what?
The question matters because validation can easily become a label. Once a system has been described as “validated”, there is a temptation to treat that status as an intrinsic property of the technology.
But the same platform can support very different trials, configurations, workflows, interfaces, automated checks and calculations.
And those differences matter.
What ICH E6(R3) actually asks us to consider
Section 4.3.4 of ICH E6(R3) takes a risk-based approach to computerised systems validation.
The validation approach should consider the system’s intended use, the purpose and importance of the data or records it manages, and the potential impact of the system on participant rights, safety and the reliability of trial results.
Validation should then demonstrate that the system meets established requirements for completeness, accuracy and reliability, and that its performance is consistent with its intended purpose.
ICH goes further.
Standard functionality, protocol-specific configurations and customisations — including automated data-entry checks and calculations — should be validated appropriately. Interfaces between systems should also be defined and validated, while different degrees of validation may be appropriate depending on the type of system and how it is configured.
That distinction is important.
Imagine an EDC platform already used across dozens of clinical trials.
The underlying software may have extensive validation evidence.
But a new study can introduce a different database configuration, edit checks, derived variables, integrations with external systems or automated calculations.
The relevant question is therefore not simply:
“Is the EDC validated?”
It is also:
“What exactly has been validated for this intended use?”
Validation as evidence, not status
This is the distinction I find most useful.
Validated is not a context-free property of a system. It is a conclusion supported by evidence within a defined context of use and risk.
That changes the conversation.
Instead of looking for a validation label, we start looking at the chain of reasoning behind it:
What is the system expected to do?
Which data and processes are critical?
What could go wrong?
Which requirements address those risks?
What evidence demonstrates that those requirements have been met?
And what happens when the configuration or intended use changes?
A risk-based approach should help direct validation effort toward what matters most rather than applying the same level of control indiscriminately.
Where Clinical Data Management meets Data Governance
There is another implication that interests me.
A possible interpretation is that this way of thinking brings Clinical Data Management increasingly close to Data Governance.
Not because Data Governance should be added as another layer after data collection.
But because many of the questions surrounding validation are fundamentally governance questions:
Who is responsible for the system and its configuration?
Which requirements apply?
Who can access or change the data?
How are changes controlled?
How is traceability maintained?
Which evidence demonstrates that controls continue to work?
The technology is only one part of the system.
The rest consists of processes, responsibilities, controls, data flows and evidence surrounding it.
And those elements determine whether we can trust the data produced or managed through that technology.
The false comfort of “validated”
A validation package can provide evidence of control, but the word validated, when detached from its context, can create exactly the opposite: a false sense of security.
The more complex clinical data ecosystems become — with EDCs, ePRO, wearables, laboratories, EHR-derived data and multiple system integrations — the less useful a binary validated/not-validated mindset becomes.
What matters is whether the validation evidence remains appropriate for the specific purpose, configuration and risk we are asking the system to support.
So the next time someone tells you that a clinical system is validated, perhaps the most useful response is not reassurance.
It is curiosity.
Validated for what?
When you assess a clinical system, what do you challenge first:
the intended use, the configuration, or the validation evidence itself?