This is a ready-to-use user requirements specification (URS) for an eConsent and decentralized clinical trial (DCT) platform. Each requirement is numbered, testable, and risk-tagged, so it can be traced to a test case in the validation protocol. Replace every <<FILL: ...>> placeholder and add or remove requirements to match your study. A filled specimen requirement follows. This content is general educational reference, not legal or regulatory advice.
Document control
| Field | Entry |
|---|---|
| Document number | <<FILL: URS-DCT-###>> |
| System | <<FILL>> |
| Version / date | <<FILL>> |
| Author (business/clinical SME) | <<FILL>> |
| Approver (QA) | <<FILL>> |
How to read this URS
Each requirement has an ID, a statement written as a testable “shall,” a risk level (High / Medium / Low), and a source (the regulation or business need it comes from). High-risk requirements are the ones that protect the participant or the integrity of the endpoint, and they get the most rigorous testing. Write every requirement so a tester can prove it pass or fail without interpretation.
1. Consent presentation and elements
| ID | Requirement (shall) | Risk | Source |
|---|---|---|---|
| URS-101 | The system shall present every required element of informed consent under 21 CFR 50.25 for each ICF variant | High | 21 CFR 50.25 |
| URS-102 | The system shall serve only the IRB-approved ICF version for the participant’s site and language | High | 21 CFR 56; eConsent guidance |
| URS-103 | The system shall provide comprehension support (knowledge checks, glossary, contact for questions) | Medium | eConsent guidance |
| URS-104 | The system shall record time spent and knowledge-check responses in the audit trail | Medium | Part 11 11.10(e) |
2. Signature and identity
| ID | Requirement (shall) | Risk | Source |
|---|---|---|---|
| URS-201 | The system shall capture the participant’s electronic signature with signer name, date/time, and the meaning of the signature | High | 21 CFR 11.50 |
| URS-202 | The system shall bind each signature to the specific ICF version signed and prevent reuse or transfer | High | 21 CFR 11.70 |
| URS-203 | The system shall verify the identity of a remote signer and record the verification | High | eConsent guidance; Part 11 11.100/11.200 |
| URS-204 | The system shall capture the person-obtaining-consent and investigator signatures where required, with the same metadata | High | 21 CFR 50.27 |
3. Version control and re-consent
| ID | Requirement (shall) | Risk | Source |
|---|---|---|---|
| URS-301 | On an ICF amendment, the system shall serve the new version to the correct population and block the superseded version at signing | High | eConsent guidance; GCP |
| URS-302 | The system shall prompt re-consent where an amendment requires it and record who re-consented under which version and when | High | GCP; Part 11 |
| URS-303 | The system shall maintain a retrievable mapping of each participant to the ICF version they consented under | High | Part 11 11.10(b)/(c) |
4. Participant copy and records
| ID | Requirement (shall) | Risk | Source |
|---|---|---|---|
| URS-401 | The system shall generate and deliver a copy of the signed ICF to the participant | Medium | 21 CFR 50.27 |
| URS-402 | The system shall produce accurate human-readable and electronic copies of records for inspection | High | 21 CFR 11.10(b) |
| URS-403 | The system shall retain and allow retrieval of records throughout the retention period, including after vendor change | High | 21 CFR 11.10(c) |
5. ePRO / eCOA data capture (where in scope)
| ID | Requirement (shall) | Risk | Source |
|---|---|---|---|
| URS-501 | The system shall present the validated instrument exactly (item wording, response options, recall period, skip logic, scoring) | High | PRO measurement validity |
| URS-502 | The system shall open and close diary entries in the defined windows and flag or prevent out-of-window entries | High | GCP data integrity |
| URS-503 | The system shall use a controlled, server-authoritative timestamp and log any device-clock delta | High | Part 11; data integrity |
| URS-504 | The system shall bind each entry to the correct participant and device, including on BYOD | High | ALCOA+ attributable |
| URS-505 | The system shall render the instrument identically across the supported device matrix | High | Measurement equivalence |
6. Audit trail, access, and change
| ID | Requirement (shall) | Risk | Source |
|---|---|---|---|
| URS-601 | The system shall maintain a secure, computer-generated, time-stamped audit trail that is independently reviewable and tamper-evident | High | 21 CFR 11.10(e) |
| URS-602 | The system shall enforce role-based access with least privilege and support periodic access review | High | 21 CFR 11.10(g); 11.300 |
| URS-603 | The system shall place any change to the production configuration under sponsor-controlled change management | High | Annex 11; change control |
7. Data flow and integrations
| ID | Requirement (shall) | Risk | Source |
|---|---|---|---|
| URS-701 | The system shall transmit data to <<FILL: downstream systems>> completely and reconcilably (counts in equal counts out) | High | Data integrity |
| URS-702 | The system shall preserve original captured data (the signed ICF as served; the raw sensor stream where it is the original) | High | ALCOA+ original |
| URS-703 | The system shall reconcile offline entries correctly on sync, preserving original entry time | High | Data integrity |
8. Acceptance criteria for the URS
The URS is complete when: every regulatory obligation for the in-scope components maps to at least one requirement; every requirement is testable and risk-tagged; and no requirement is a vague aspiration (“user-friendly”, “compliant”) that a tester cannot prove. Each requirement must trace forward to a test case in the validation protocol with no orphans in either direction.
Filled specimen requirement
The following shows one high-risk requirement expanded to the level a tester and a reviewer both need. Details are illustrative.
| Field | Entry |
|---|---|
| ID | URS-301 |
| Statement | On approval of an ICF amendment, the system shall serve the new version to participants at the affected sites/languages and shall block signing of the superseded version |
| Risk | High (version control is the most common eConsent finding) |
| Source | 2016 FDA/OHRP eConsent guidance; GCP |
| Acceptance | With v3.1 pushed, an attempt to sign v3.0 is blocked and v3.1 is served; re-consent is prompted where required; the switch is audit-logged |
| Traces to | Test case TC-09 in the eConsent validation protocol |
| Verification method | Scripted test with screen capture and audit-trail export |
Written this way, the requirement cannot be signed off on someone’s opinion that “the vendor handles amendments.” It forces a scripted test with objective evidence, which is exactly what an inspection expects for the highest-risk function in the system.
Common inspection findings this specification prevents
- Requirements too vague to test (“Part 11 compliant”), so nothing is actually proven.
- A regulatory obligation with no requirement behind it, and therefore no test.
- Requirements with no risk tag, so testing effort is spread evenly instead of concentrated on participant-protecting functions.
- Orphan requirements that trace to no test, or tests that trace to no requirement.
How to adapt this specification
- Delete the ePRO or sensor sections if those components are out of scope for your study, and add sections for televisit or logistics components that are in scope.
- Set the risk level from your own risk assessment; the tags shown are a starting point.
- Point URS-701 and URS-403 at your real downstream systems and retention obligations.
- Build the traceability matrix from this URS to the validation protocol before execution begins.