Computer System Validation for eClinical Systems: A Working Guide
Computer system validation is documented assurance that a system does what you need it to do for your study, maintained over time. The vendor validates the product. You validate your configuration, your build, your integrations, your people and your procedures. That split accounts for most of the arguments and nearly all of the findings.
Validation attracts more theatre than almost any other area of clinical operations. Documents are produced in volume, effort is spread evenly across features that matter and features that do not, and the resulting package asserts that validation happened without describing what was actually examined.
This guide covers the lifecycle, the ownership line, how to allocate effort by risk, and what maintains the validated state after go-live. It is the shape of the subject rather than the procedure for any one part, and each section links to a guide that goes deeper.
After reading this you will be able to:
- Draw the ownership line precisely enough to settle a vendor conversation
- Allocate validation effort by risk instead of by habit
- Produce documentation an inspector can read rather than weigh
- Keep a system validated after the go-live date has passed
What Validation Actually Means Here
Start with the cluster, then the reasoning.
| The question it answers | Who it is for | Guide |
|---|---|---|
| What evidence do inspectors ask for under Part 11? | Quality and data management | 21 CFR Part 11, what inspectors ask to see |
| How do Annex 11 and Part 11 differ? | Teams operating in the EU and US | Annex 11 and Part 11 side by side |
| What does the assurance approach change? | Validation and QA leads | From CSV to CSA, what changes in practice |
| How do we review audit trails defensibly? | Data management and QA | An audit trail review procedure that holds up |
| Who validates what in a cloud system? | Procurement and validation together | Validating a SaaS eClinical system |
| What does ALCOA+ demand in practice? | Data management | Data integrity and ALCOA+ in clinical workflows |
| How do you validate a non-deterministic feature? | Quality and technical leads | Validating AI and ML features under GxP |
Validation is documented assurance that a system does what you need it to do, consistently, for the use you put it to. Two words in that sentence carry the weight. Documented, because assurance you cannot show is not assurance. And your use, because intended use is a property of your study rather than of the product.
That second point is where most vendor conversations go wrong, and it is worth being blunt about: a product cannot be validated for a study it has never seen.
The Lifecycle
The first stage is skipped more often than any other, usually because it looks like paperwork. Writing down what the system must do for this study sounds like a formality until you attempt it and find that two people in the room believed a feature did different things.
The last stage is where validated systems quietly stop being validated. Nothing dramatic happens. A protocol amendment changes the visit structure, the vendor ships a release, two coordinators leave and their accounts stay active, and the package on file describes a system that no longer exists.
The Ownership Line
Read down the vendor column and it empties out. They are genuinely responsible for the product and the infrastructure, and your obligation there is to assess and record rather than to retest. From configuration onward there is no meaningful vendor contribution.
The practical move that makes reliance on vendor evidence defensible is naming it explicitly inside your own validation plan: which of their evidence you are relying on, and what it does not cover. That paragraph converts an implicit assumption into a documented decision, and it is worth more at an inspection than a folder of certificates. The full split is in what the vendor validates and what you still own.
Allocating Effort by Risk
The question is not how much to validate. It is what failure would affect.
Assessing per feature rather than per product is the change that does most of the work. An EDC calculating an eligibility flag a site relies on sits in a different risk band from the same EDC producing an enrollment report for a management meeting, and treating the product as one risk level guarantees that one of those is wrong.
This is the reasoning the computer software assurance approach formalizes: determine intended use, assess impact, select an assurance activity, and size the record to the activity. What that changes in practice, and what it does not excuse, is in what the assurance approach changes.
Which Frameworks Apply
Three come up, and which ones bind you depends on your regions and operations.
21 CFR Part 11 governs electronic records and signatures used in place of paper under a predicate rule, and it applies to how you use a system rather than to the software. ICH E6(R3) sets expectations for computerized systems used in trials. Annex 11 covers computerized systems under EU GMP and is widely treated as a reference point for computerized system expectations more generally.
The practical advice is to state in your validation plan which frameworks you are writing to and why, then write one documentation set to the stricter requirement in each area rather than maintaining parallel sets that drift. The evidence Part 11 inspections ask for is in what inspectors ask to see, and the differences that change your documents are in Annex 11 and Part 11 side by side.
Validation Serves Data Integrity
It is worth remembering what all of this is for. A validated system is not an end in itself; it is the mechanism by which data becomes trustworthy.
The ALCOA+ principles describe what trustworthy means, and most of them are evidenced through controls that validation establishes: unique accounts make data attributable, the audit trail makes corrections traceable, retention controls make records enduring. A system validated with no reference to those principles tends to produce a compliant package and an unconvincing dataset.
The two controls that carry the most weight are audit trail review and source definition. Both are covered in writing an audit trail review procedure and applying ALCOA+ to a real clinical data workflow.
The Case That Breaks the Model
Everything above assumes a system that behaves the same way on Tuesday as it did on Monday. Features built on models do not necessarily, which is why they need a different treatment rather than an exemption.
A test script asserts an expected result, and a generative output has no single one. The assurance moves to the system around the model: a precise intended use statement, bounded risk so a wrong output is caught, baseline performance, drift monitoring, evidenced human review, and a defined withdrawal trigger. That is worked through in validating AI and machine learning features under GxP.
Where to Start
Six steps, and the first two usually reveal the real position.
- Write the intended use statement for the system as you actually use it today.
- Read your existing validation package against it, and list what is not covered.
- Assess risk per feature rather than per product.
- Name the vendor evidence you rely on, and what it does not cover.
- Check that change control and periodic review have named owners.
- Run one audit trail review and one access review, and keep the output.
Clinera EDC ships with the audit trail, role framework and signature components in place, and clinical and R&D AI covers the additional validation questions that arise when a system includes adaptive components. For teams applying the same discipline to regulatory submissions, the regulatory intelligence and submission automation use case works through a related pattern, and our pharma work spans the clinical and manufacturing sides of the question. The data side of the study is covered in the clinical data management guide.
References
- 21 CFR Part 11, Electronic Records; Electronic Signatures. US Code of Federal Regulations, Title 21, Part 11. www.ecfr.gov
- ICH E6(R3) Good Clinical Practice. International Council for Harmonisation, adopted 6 January 2025. www.ich.org
- Annex 11, Computerised Systems. EudraLex Volume 4, Good Manufacturing Practice guidelines. health.ec.europa.eu
- Good Machine Learning Practice for Medical Device Development, Guiding Principles. US Food and Drug Administration, Health Canada and MHRA. www.fda.gov
This guide describes process and regulatory expectations in general terms and is not legal or regulatory advice. Confirm the current version and applicability of any standard or guidance for your study and region.
Frequently Asked Questions
What is computer system validation in an eClinical context?
Establishing and maintaining documented assurance that a system does what you need it to do for your study, consistently, and that you can show it. The phrase covers both the work before release and the controls that keep the state true afterward. The emphasis on your study matters, because intended use is a property of how you use the system rather than of the product you bought.
If the vendor is validated, are we validated?
No, and this is the most expensive misunderstanding in eClinical procurement. The vendor validates the software as a product, covering their development lifecycle and product testing. You validate your configured use: the study you built, the checks you specified, the roles you assigned, the integrations you connected, and the procedures your people follow. Five of the seven ownership rows have nothing meaningful in the vendor column.
How much validation is enough?
Enough to have assurance proportionate to what failure would affect, with the reasoning written down. That means assessing risk per feature rather than per product, matching the assurance activity to the risk, and sizing the record to the activity. Uniform effort applied everywhere is the common failure, because effort spread evenly is by definition not concentrated where it matters.
Does validation end at go-live?
No, and treating it as a pre-release event is how validated systems quietly stop being validated. The state decays through protocol amendments, platform upgrades the vendor initiates, staff changes, and configuration adjustments nobody assessed. Change control, periodic review and access review are what maintain it, and each needs a named owner or it will not happen.
Which frameworks apply to eClinical systems?
It depends on your regions and operations. 21 CFR Part 11 applies to electronic records and signatures used in place of paper under a predicate rule. ICH E6(R3) sets expectations for computerized systems in trials. Annex 11 covers computerized systems under EU GMP and is widely used as a reference point for computerized system expectations more broadly. State in your validation plan which you are writing to and why.
Can Nirmitee Healthtech run validation for a system we already use?
Yes, and the entry point is usually a gap assessment rather than a full revalidation. The assessment reads your intended use against what the vendor supplies and what your existing documentation covers, then lists what is missing in the order an inspector would reach it. From there the work is scoped by risk. The approach applies to whatever systems you run, not only to ours.
