Validation is the sponsor's responsibility even when the vendor supplies the software. This checklist follows the lifecycle in the order a small team actually does the work: assess, plan, configure, test, release, and keep it controlled.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Study
DEMO-CARD-04
Risk level
Medium
Target go-live
Week 8
What this checklist is, and is not
Context
Regulations and guidance on electronic systems in clinical investigations put responsibility for fitness for purpose on the sponsor. In the US, 21 CFR Part 11 asks that systems be validated to ensure accuracy, reliability and consistent intended performance, and the ICH GCP framework makes the sponsor responsible for systems used to handle trial data. European guidance on computerised systems and electronic data in clinical trials takes a similar line and expects documentation of the roles of each party. Read our EMA computerised systems guideline guide and the 21 CFR Part 11 compliance checklist for the regulatory detail.
That does not mean you rebuild the vendor's test suite. A well-run approach uses a risk-based, proportional lifecycle: understand what the system is meant to do for this study, collect the evidence the vendor already has, test the parts that are specific to your configuration, and document decisions. Frameworks such as GAMP 5 describe this approach in industry terms.
This page is the practical checklist for that approach. For the concepts behind it see computer system validation for clinical trial software, and for how to run the testing step see the EDC UAT sandbox guide. The in-study rules (what is checked on each field) belong in a data validation plan, which is a different document from the validation of the system itself.
Phase 1
Do this before you commit. A questionnaire alone is not an audit, but it shows how seriously a vendor treats the topic.
Field-level audit trail with old value, new value, user, timestamp and reason; e-signatures; role-based access; edit checks; controlled form states.
Ask how software is developed, tested and released, and how changes are communicated to customers.
Ask what documentation exists to support your validation. Capture enterprise customers receive documentation to support sponsor validation and UAT.
Ask where data is hosted (Capture offers EU Frankfurt and USA N. Virginia) and how it is protected. Use the vendor security questionnaire as a starting list.
Ask about support channels, response time and how incidents are reported to customers.
Confirm full export of data, the audit trail and a data dictionary, so the data is not trapped. See data ownership and portability.
Document what you reviewed, what gaps you found and why you accepted them.
Phase 2
A short plan, written before testing starts, beats a thick report written afterwards.
State what the EDC will be used for in this study: data capture, queries, e-signatures, exports, randomization or ePRO if applicable.
List who does what: sponsor, CRO, vendor, sites. Name the approver.
Rate functions by impact on participant safety and data reliability, and decide how deep to test each. Safety-critical calculations and blinded data deserve the most.
Decide which functions you will test yourself and which you will rely on vendor evidence for, with a reason.
Define pass/fail and how deviations are handled and closed.
Plan the configuration specification, UAT scripts and results, deviation log, and a validation summary report.
Phase 3 and 4
Test your own configuration. Each row is a script family with the evidence to keep. Run them in a sandbox that mirrors the live build.
| Area | What to test | Evidence to keep |
|---|---|---|
| Form build | Every approved form matches the protocol and the specification: fields, units, ranges, required flags | Printed blank eCRF compared to specification; reviewer initials |
| Skip logic | Hidden and shown fields behave for each branch | Screenshots or tester notes per branch |
| Calculated fields | Derived values match a hand calculation for several inputs, including edge values | Input, expected and actual values |
| Edit checks | Each rule fires on a breaking value, does not fire on a valid value, raises an auto-query with the right message and priority | Test data sheet with expected result |
| Roles and permissions | Each role sees only what it should; blinded roles do not see arm values; site coordinators see participant names while others see coded IDs | Role-by-function matrix, tester signature |
| Audit trail | Edit a value, give a reason, confirm timestamp, user, old and new value are recorded and cannot be edited | Audit trail export |
| E-signatures | Sign and countersign, confirm the signature meaning and what happens after a record changes | Signed record export |
| Visit schedule and windows | Visits appear on the right day and out-of-window handling works | Schedule printout against protocol |
| Exports | Export content and format match the specification; data dictionary matches forms | Export file and checklist |
| Query workflow | Raise, answer, close and re-open a query; confirm history is kept | Query log extract |
Use realistic test data and negative tests (wrong values, wrong role), not only the happy path. Capture's free sandbox has every feature so you can run this before go-live.
Build the study, invite your QA reviewer and execute the script families above in the sandbox. Free, every feature, no credit card.
Phase 5
Once testing is complete, make the decision explicit.
Every failed script is fixed and retested, or the risk is documented and approved.
One to two pages: scope, what was tested, results, open items and a statement on fitness for use.
Only approved forms appear in the casebook for live use. Confirm the live build equals the tested build.
Accounts created for the right roles; training records on file; delegation log in place (see the delegation log template).
QA, data management and the study lead sign before the first participant is entered.
Phase 6
Validation is not a one-time event. Protocol amendments and vendor releases both change the system.
Record each amendment-driven form change, its risk and its retest. See eCRF versioning mid-study.
Ask how releases are notified and decide whether a regression check is needed for your study.
Periodically review accounts, roles and leavers. See role-based access control.
Sample edits and confirm reasons for change are meaningful. See audit trail software.
Keep a record of system problems, their impact on data and the fix.
Plan export of data, audit trail and dictionary at study close.
What to look for
Most validation questions come back to a short list of controls. These are the ones Capture provides, described as Part 11-aligned controls rather than a certification.
Weight changed 68.0 to 68.5 kg
Site coordinator · Reason: Transcription error
Query Q-0014 answered on Weight
Site coordinator · Reason: Source checked
Vital signs form locked
Data manager · Reason: Visit cleaned
The sponsor is responsible for showing that the system is fit for its intended use in the study, even when the vendor supplies the software and evidence. A CRO may do the work on the sponsor's behalf.
Generally no. A risk-based approach relies on vendor evidence for the platform and focuses your own testing on your configuration and study-specific rules. Confirm the approach with your quality adviser.
Yes for rehearsing and testing a build: it has every feature and no time limit. Keep records of what you tested; the test record is yours.
Enterprise customers receive documentation to support sponsor validation and UAT. Ask us what is available for your study during a demo.
Re-test when the study build changes or when a vendor release affects a function you rely on, and review periodically. The right cadence follows your risk assessment.
Capture provides 21 CFR Part 11-aligned controls. Compliance is shared with the sponsor's validated use. This is not legal advice.
Keep exploring
Free sandbox with every feature. No credit card, and you pay only when you go live with real participants.