This is a ready-to-use validation protocol for the study-specific configuration of an electronic data capture (EDC) system. It assumes the base platform was separately qualified by the sponsor, CRO, or vendor; this protocol tests what your study team actually built on top of it. Replace every <<FILL: ...>> placeholder, scale the test depth to your documented risk assessment, and route it through your normal validation review and approval before first-subject-first-visit. A filled specimen test case follows. Verify each cited regulation against the current source before you rely on it. This content is general educational reference, not legal or regulatory advice.
1. Approval page
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Validation / Data Management) | <<FILL>> | ||
| Clinical Data Management lead | <<FILL>> | ||
| Clinical QA | <<FILL>> | ||
| Biostatistics representative | <<FILL>> | ||
| System owner (EDC platform) | <<FILL>> |
| Field | Entry |
|---|---|
| Protocol number | <<FILL: VAL-EDC-###>> |
| Study / protocol number | <<FILL>> |
| EDC platform / version | <<FILL: e.g. vendor product and release>> |
| Protocol version / date | <<FILL>> |
2. Objective
Provide documented evidence that the study-specific EDC configuration performs as intended: the eCRF pages, edit checks, dynamic display logic, randomization or IRT interface, user roles, audit trail, and export mechanism function per the approved specification and preserve data integrity, in line with GCP, 21 CFR Part 11 (for US submissions), and EU GMP/GCP Annex 11 expectations for computerized systems.
3. Scope
In scope: the study-specific build layered on the qualified base platform for <<FILL: study / protocol number>>, covering eCRF structure, edit checks and validation rules, dynamic forms, user roles and access, audit trail behavior, query workflow, randomization/IRT interface (if applicable), and the export format used by biostatistics. Out of scope: base platform qualification (covered by the vendor/platform qualification record <<FILL: reference>>), and downstream systems validated separately, for example the eTMF or the safety database, tested only at the integration seam in section 7.
4. System description
<<FILL: hosting model (vendor-hosted / sponsor-hosted), user roles (site coordinator, investigator, monitor, data manager, medical coder, biostatistician), integrations (IRT, central lab, ePRO, safety database), languages/sites supported>>
5. Prerequisites
- Approved User Requirements Specification (URS) and risk assessment on file; see User Requirements and Traceability and CSV Risk Assessment Methodology.
- Base platform qualification record referenced and current.
- Configuration specification (build spec) approved and matches the final eCRF.
- Edit check specification approved; see the companion Edit Check Specification template.
- Test environment representative of production, with the same configuration version deployed.
- Test accounts provisioned for every role in scope, including a read-only monitor account and a revoked/expired account for negative testing.
6. Roles and acceptance
Each test case is executed by <<FILL: tester role, e.g. Data Management>> and independently reviewed by <<FILL: QA or a second data manager>>. A case passes when the actual result equals the expected result with objective, dated evidence attached (screenshot, export, or audit trail excerpt). Any deviation is logged in section 8 and dispositioned, with high-risk-function failures resolved and retested, before the summary is signed.
7. Test cases
Record for each: actual result, pass/fail, tester, date, evidence reference. Depth should track the risk assessment: primary-endpoint and safety fields get full scripted coverage; low-risk reference fields can use a lighter, documented rationale.
| ID | Requirement | Test step | Expected result |
|---|---|---|---|
| TC-01 | eCRF page structure matches build spec | Open every page for a fresh subject | Fields, labels, units, and page sequence match the approved configuration spec |
| TC-02 | Required-field enforcement | Attempt to save a page with a required field blank | Save is blocked with a clear message; no partial record is created |
| TC-03 | Range / logic edit check fires | Enter a value outside the specified valid range | The specified query fires with the specified text, at the specified severity |
| TC-04 | Edit check does not over-fire | Enter a valid boundary value from the edit check spec | No query fires |
| TC-05 | Dynamic display / branching logic | Enter a value that should trigger a conditional field or page | The conditional field/page appears (or hides) exactly as specified |
| TC-06 | Query lifecycle | Raise, answer, and close a query | Query state transitions correctly; audit trail captures raise, answer, and close with user and timestamp |
| TC-07 | Audit trail: initial entry | Enter a new value | Trail records user, timestamp, and the value entered |
| TC-08 | Audit trail: modification | Change a previously saved value | Trail records user, timestamp, old value, new value, and reason for change |
| TC-09 | Audit trail cannot be disabled | Attempt to suppress or turn off the trail as a non-privileged user | Not possible; no user-facing control exists to do so |
| TC-10 | Role-based access: site | Log in as a site user | Sees only that site’s subjects; cannot access other sites’ data |
| TC-11 | Role-based access: monitor | Log in as a monitor account | Read-only; cannot edit source-equivalent fields |
| TC-12 | Revoked account | Attempt login with a deactivated account | Access denied; attempt is logged |
| TC-13 | Randomization / IRT interface | Trigger a randomization call from the EDC | Correct treatment arm/kit assignment returned and recorded; no duplicate or missing calls |
| TC-14 | External data reconciliation field | Load a sample central-lab or ePRO transfer | Data lands in the correct fields, matches the transfer specification, and any mismatch triggers a reconciliation flag |
| TC-15 | Export format | Generate the dataset export used by biostatistics | Export structure, variable names, and record counts match the export specification |
| TC-16 | Time zone / timestamp integrity | Enter data from a non-UTC site | Timestamps are captured and displayed consistently with the system’s documented time-handling design |
8. Deviation handling
Log each deviation with description, impact, root cause, and resolution. A high-risk-function failure (audit trail, access control, randomization interface, a primary-endpoint edit check) must be resolved and re-tested before the summary is signed.
| Dev # | Test case | Description | Disposition |
|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
9. Acceptance criteria (protocol level)
- Every eCRF page and field matches the approved configuration specification.
- Every edit check in the approved specification fires correctly and does not over-fire on valid boundary values.
- The audit trail captures initial entry and every modification with user, timestamp, old value, new value, and reason, and cannot be disabled by an end user.
- Role-based access enforces real restrictions for every tested role, including a negative test of a revoked account.
- Randomization/IRT and external data interfaces reconcile completely, with no duplicate or dropped records.
- The export matches the specification biostatistics will actually use.
- Every URS requirement traces to at least one executed test case with no orphans; see the Requirements/Test Traceability Matrix.
10. Summary and conclusion
<<FILL: statement that the study-specific EDC configuration is validated for its intended use, or the conditions/restrictions on release; signed by Data Management and QA>>
11. Attachments
- Requirements traceability matrix (URS to test case).
- Executed test evidence (screenshots, exports, audit-trail excerpts).
- Deviation records and resolutions.
- Edit check specification (referenced, not reproduced).
Filled specimen: TC-08 (audit trail: modification)
The following shows one executed high-risk test case, so you can see the evidence level expected. Details are illustrative.
| Field | Entry |
|---|---|
| Test case | TC-08, audit trail modification capture |
| Precondition | Subject 0142 has a saved systolic blood pressure value of 128 mmHg on the Vitals page |
| Step 1 | As a site user, change the value from 128 to 138 mmHg and select the reason “Transcription error, corrected against source” |
| Step 2 | Save the page, then export the audit trail for this field |
| Expected | Trail shows old value 128, new value 138, user, timestamp, and the selected reason, with the original value still viewable |
| Actual | Audit trail export confirmed old=128, new=138, user J.Kim, timestamp 2026-08-05 14:12 UTC, reason “Transcription error, corrected against source”; original value remained visible in the trail |
| Result | Pass |
| Evidence | Audit trail export AT-TC08; screenshot SC-TC08 |
| Tester / QA | J. Kim / A. Ferreira, 05 August 2026 |
Because audit trail integrity is the control every downstream review depends on, this case is executed with full scripted rigor rather than sampled. A vendor’s platform-level Part 11 claim does not substitute for testing that the study-specific build actually behaves this way.
Common inspection findings this protocol prevents
- An edit check described in the specification but never actually built or tested, discovered only when a bad value reaches the database.
- A “validated” claim resting entirely on vendor documentation, with no evidence the sponsor tested its own study configuration.
- Role-based access that looks correct in the specification but was never negative-tested (a monitor account that can, in practice, edit a field).
- An audit trail that captures the new value but not the reason, or that can be suppressed under some administrative role no one thought to test.
- A randomization interface tested once at build time and never re-verified after a mid-study configuration change.
How to adapt this protocol
- Scale test depth to your risk assessment; primary-endpoint, safety, and randomization functions get full scripted testing, low-risk reference fields can use lighter, documented coverage.
- Add test cases for any study-specific integration not listed here (imaging, genomics, wearables).
- Point section 7’s interface and export tests at your real downstream systems and the export specification biostatistics actually uses.
- If the study amends mid-conduct, re-run the affected test cases under change control rather than treating the original protocol as still fully representative.
- Confirm every cited regulation against the current source before execution.