EDC System Page Definitions

This document describes each page in the Electronic Data Capture (EDC) system prototype. Use this reference to understand page purpose, content, user access, and key functionality when developing or modifying the system.

UI Concept (sidebar and top menu)

---

System Overview

The EDC system is built with FastAPI + PostgreSQL backend and SurveyJS for form design/delivery. It follows 21 CFR Part 11 compliance principles with immutable audit trails, role-based access control (RBAC), and version-controlled forms.

User Roles

Role	Description
Admin	Full system access; manages users, studies, views audit logs
Study Designer	Creates/configures studies, designs forms, manages study settings
Site Staff	Enrolls participants, enters data, manages visits at their assigned site
Monitor	Read-only access to study data for oversight; can raise queries
Participant	Views own schedule, completes surveys, views signed consent

---

Core Navigation

These pages support day-to-day data collection workflows and are accessed primarily by Site Staff, with varying access for other roles.

Dashboard

Purpose: Provide a role-appropriate overview of study status and pending actions.

Content by Role:

• Site Staff: Enrollment counts for their site, overdue visits, pending forms, recent activity feed, upcoming scheduled visits
• Study Designer: Cross-site enrollment summary, form completion rates by visit, data quality metrics
• Monitor: SDV completion status, open queries by site, enrollment trajectory vs. targets
• Admin: System health, active users, recent audit events, study-level summaries

Key Components:

• Summary cards (enrolled/screened/withdrawn counts)
• Enrollment progress chart (actual vs. projected)
• Task list widget (forms due today, overdue items)
• Recent activity feed (last 10 actions relevant to user's scope)

Data Sources: Participant, ScheduledTask, FormResponse, AuditLog

---

Participants

Purpose: Manage participant records including enrollment, status tracking, and individual participant details.

Content:

• Searchable/filterable table of participants within user's access scope
• Columns: Participant ID, Site, Arm, Status, Consent Date, Next Visit Due, Completion %
• Filters: Status (active/withdrawn/completed), Site, Arm, Date range
• Click-through to individual participant detail view

Participant Detail View:

• Demographics summary
• Assigned arm (with randomization timestamp)
• Consent status and signed document link
• Visit completion timeline (visual progress indicator)
• List of all scheduled tasks with status
• Action buttons: Withdraw, Edit, View Responses

Key Actions:

• Enroll New Participant (Site Staff): Opens enrollment wizard → demographics → consent capture → randomization trigger
• Withdraw Participant (Site Staff): Requires reason; updates status; logs to audit trail
• View Participant (All roles with access): Read-only detail view

Access Control:

• Site Staff see only participants at their assigned site(s)
• Monitors see all participants in studies they're assigned to (read-only)
• Study Designers see all participants (read-only unless also assigned site role)

Data Models: Participant, Site, Arm, User

---

Visit Schedule

Purpose: Display and manage the schedule of study visits and associated forms for participants.

Content:

• Calendar or timeline view of scheduled visits across participants
• Filters: Site, Participant, Visit type, Status (upcoming/due/overdue/completed), Date range
• List view alternative showing: Participant ID, Visit Name, Due Date, Window (±days), Status, Forms count

Individual Visit View:

• Visit metadata (name, scheduled date, window, actual date if completed)
• List of forms assigned to this visit with completion status
• Action to mark visit as completed or missed
• Link to start/continue data entry for each form

Key Actions:

• View Schedule (All roles): See upcoming and past visits
• Mark Visit Complete (Site Staff): Records actual visit date; triggers any dependent scheduling
• Mark Visit Missed (Site Staff): Requires reason; flags for protocol deviation review
• Reschedule Visit (Site Staff): Adjusts due date within allowed window; logs change

Scheduling Logic:

• Visits are generated from study protocol (VisitFormAssignment) when participant is enrolled
• Due dates calculated from enrollment date + visit offset (defined in Study Setup)
• Window period (e.g., ±3 days) for visit completion flexibility

Data Models: ScheduledTask, Visit, Participant, FormDefinition

---

Data Entry

Purpose: Interface for completing case report forms (CRFs) using SurveyJS Runner.

Content:

• List of forms requiring completion (filterable by participant, visit, status)
• Form status indicators: Not Started, In Progress, Complete, Verified
• Click-through to SurveyJS form interface

Form Completion Interface:

• SurveyJS Runner embedded component
• Form header: Participant ID, Visit, Form name, Version
• Auto-save indicator (draft responses saved periodically)
• Validation warnings displayed inline
• Submit button (finalizes response; triggers audit log entry)
• "Save as Draft" option for incomplete forms

Key Actions:

• Start Form (Site Staff): Creates new FormResponse record with status "in_progress"
• Save Draft (Site Staff): Persists current answers; remains editable
• Submit Form (Site Staff): Validates required fields; marks complete; logs submission
• Edit Submitted Form (Site Staff, if permitted): Requires reason for change; creates audit entry with old/new values

Validation:

• Client-side validation via SurveyJS (required fields, format checks, skip logic)
• Server-side validation on submit (re-check required fields, data type validation)

Data Models: FormResponse, FormDefinition, ScheduledTask, AuditLog

---

eConsent

Purpose: Manage electronic informed consent capture, storage, and retrieval.

Content:

• List of participants with consent status (pending, signed, expired, re-consent needed)
• Consent document versions available
• Click-through to consent capture interface or signed document viewer

Consent Capture Interface:

• Rendered consent document (from FormDefinition with consent type flag)
• Participant acknowledgment checkboxes (e.g., "I have read and understood...")
• Signature capture widget (typed name, drawn signature, or e-signature)
• Timestamp display (captured at signing)
• PDF generation on completion (archived to storage)

Key Actions:

• Initiate Consent (Site Staff): Presents consent form to participant
• Capture Signature (Site Staff/Participant): Records signature data and timestamp
• Generate PDF (System): Auto-generates signed consent PDF for archival
• View Signed Consent (Site Staff, Monitor, Participant): Retrieves archived PDF
• Re-consent (Site Staff): Required when consent version changes; tracks version history

Compliance Requirements:

• Signature timestamp must be system-generated (not user-entered)
• PDF must be immutable once generated
• Audit trail must capture: who signed, when, which version, witness if applicable

Data Models: FormResponse (consent type), Participant (consent_date, consent_version), AuditLog

---

Queries

Purpose: Manage data queries raised during monitoring or data review.

Content:

• List of open queries with filters: Status (open/answered/closed), Site, Participant, Form, Age (days open)
• Query detail: Form field in question, original value, query text, response history
• Metrics: Queries by site, average resolution time, aging queries

Query Detail View:

• Context: Participant ID, Visit, Form, Field
• Query thread: Initial query → Site response → Resolution or follow-up
• Status controls: Mark resolved, Re-open, Escalate

Key Actions:

• Raise Query (Monitor): Flags a specific field/response with question text
• Respond to Query (Site Staff): Provides clarification or corrects data (with audit trail)
• Close Query (Monitor): Marks as resolved
• Export Query Report (Monitor, Study Designer): Downloads query metrics

Workflow:

1. Monitor reviews data, identifies issue
2. Monitor raises query on specific FormResponse field
3. Site Staff receives notification, responds or edits data
4. Monitor reviews response, closes or follows up
5. All actions logged to audit trail

Data Models: Query (new model: id, form_response_id, field_name, query_text, status, raised_by, raised_at), QueryResponse (id, query_id, response_text, responded_by, responded_at)

---

Study Operations

These pages support study configuration and oversight, accessed primarily by Study Designers, Monitors, and Admins.

Study Setup

Purpose: Define the study protocol structure including arms, visits, and visit-form assignments.

Content:

• Study metadata: Name, description, status (draft/active/closed), date range
• Arms configuration: List of treatment arms with names and descriptions
• Visits configuration: Ordered list of visits with schedule offsets and windows
• Visit-Form matrix: Grid showing which forms are assigned to which visits

Study Configuration Interface:

• Tabs or accordion sections for: General Info, Arms, Visits, Schedule Matrix
• Drag-and-drop visit ordering
• Form assignment via checkbox grid or drag-drop

Key Actions:

• Create Study (Admin, Study Designer): Initialize new study with basic metadata
• Add/Edit Arm (Study Designer): Define treatment arms; cannot delete if participants assigned
• Add/Edit Visit (Study Designer): Define visit with name, day offset (from enrollment), window (±days)
• Assign Forms to Visits (Study Designer): Map which forms appear at which visits
• Activate Study (Study Designer, Admin): Locks protocol structure; enables enrollment
• Close Study (Admin): Prevents further data entry; study becomes read-only

Validation Rules:

• Cannot modify arms/visits after study is activated (or requires formal amendment workflow)
• All visits must have at least one form assigned
• Visit day offsets must be in logical sequence

Data Models: Study, Arm, Visit, VisitFormAssignment, FormDefinition

---

Form Designer

Purpose: Create and manage CRF forms using SurveyJS Creator with version control.

Content:

• List of forms for current study: Name, Version, Status (draft/active/archived), Last modified
• Click-through to SurveyJS Creator interface
• Version history for each form

SurveyJS Creator Interface:

• Embedded SurveyJS Creator component
• Toolbox: Question types (text, dropdown, matrix, etc.)
• Design surface: Drag-and-drop form building
• Properties panel: Validation rules, skip logic, display conditions
• Preview mode: Test form before saving
• Save controls: Save Draft, Publish New Version

Key Actions:

• Create New Form (Study Designer): Initialize blank form in Creator
• Edit Form (Study Designer): Load existing form schema into Creator
• Save Draft (Study Designer): Persists work-in-progress without publishing
• Publish Version (Study Designer): Creates new version; previous version archived
• Clone Form (Study Designer): Copy existing form as starting point for new form
• Archive Form (Study Designer): Soft-delete; removes from active use but preserves data

Version Control Rules:

• Every save after initial publish creates new version
• Participants who started a form version continue with that version
• New form instances use latest published version
• Version history maintained with diffs available in audit trail

Data Models: FormDefinition (id, study_id, name, schema JSON, version, status, created_by, created_at, updated_by, updated_at)

---

Sites

Purpose: Manage multi-center site configuration and site-user assignments.

Content:

• List of sites: Name, Location, Status (active/inactive), Principal Investigator, Enrolled count
• Site detail view with assigned staff and enrollment metrics

Site Detail View:

• Site metadata: Name, address, contact info, regulatory status
• Assigned personnel: List of users with site access and their roles
• Enrollment summary: Screened, enrolled, withdrawn, completed
• Site-specific metrics: Form completion rate, query rate, protocol deviations

Key Actions:

• Add Site (Admin, Study Designer): Create new site record
• Edit Site (Admin, Study Designer): Update site metadata
• Assign User to Site (Admin): Grant site-level access to a user
• Deactivate Site (Admin): Prevents new enrollment; existing data preserved
• View Site Report (Monitor, Study Designer): Download site performance summary

Access Control:

• Site Staff see only their assigned site(s) in other views
• Monitors may be assigned to specific sites or all sites
• Site assignment stored in join table (UserSiteAssignment)

Data Models: Site (id, study_id, name, location, status), UserSiteAssignment (user_id, site_id, role)

---

Monitoring

Purpose: Support clinical monitoring activities including source data verification (SDV) and data review.

Content:

• SDV dashboard: Progress by site, by visit, by form
• SDV checklist: List of responses requiring verification
• Verification status filters: Not verified, Verified, Flagged

SDV Interface:

• Response detail view with all field values
• Verification checkbox per field or per form
• Query shortcut: Raise query directly from this view
• Notes field for monitor comments

Key Actions:

• Mark Verified (Monitor): Confirms data matches source documents
• Flag for Review (Monitor): Indicates discrepancy requiring follow-up
• Raise Query (Monitor): Creates query linked to specific field (redirects to Queries)
• Export SDV Report (Monitor): Download verification status by site/visit

SDV Workflow:

1. Monitor selects site/participant/visit to review
2. Reviews each form response against source documents
3. Marks fields/forms as verified or raises queries
4. SDV progress tracked at visit and site level

Data Models: FormResponse (add: verified_by, verified_at, verification_status), Query

---

Audit Trail

Purpose: Provide immutable, searchable log of all system actions for compliance and investigation.

Content:

• Searchable log of all audit events
• Filters: Date range, User, Action type, Study, Participant, Entity type
• Event detail: Timestamp, User, Action, Entity, Old value, New value, Reason (if applicable)

Key Event Types:

• Authentication: LOGIN, LOGOUT, LOGIN_FAILED, PASSWORD_CHANGE
• User Management: USER_CREATE, USER_UPDATE, USER_DEACTIVATE, ROLE_CHANGE
• Study Management: STUDY_CREATE, STUDY_UPDATE, ARM_CREATE, VISIT_CREATE
• Form Management: FORM_CREATE, FORM_UPDATE, FORM_PUBLISH, FORM_ARCHIVE
• Data Entry: RESPONSE_CREATE, RESPONSE_UPDATE, RESPONSE_SUBMIT
• Consent: CONSENT_SIGNED, CONSENT_PDF_GENERATED
• Participant: PARTICIPANT_ENROLL, PARTICIPANT_WITHDRAW, RANDOMIZATION
• Query: QUERY_RAISED, QUERY_RESPONDED, QUERY_CLOSED

Key Actions:

• Search Audit Log (Admin, Monitor): Filter and browse events
• Export Audit Log (Admin): Download filtered events as CSV
• View Event Detail (Admin, Monitor): See full event context including before/after values

Compliance Requirements:

• Log entries are append-only (no modification or deletion)
• Timestamps are system-generated (UTC)
• All entries include user ID (or "SYSTEM" for automated actions)
• Sensitive value changes include old and new values

Data Models: AuditLog (id, timestamp, user_id, action, entity_type, entity_id, details JSON, old_value, new_value, reason)

---

Reports

Purpose: Generate and view operational and compliance reports.

Content:

• Report catalog: List of available report types
• Report configuration: Parameters (date range, site, etc.)
• Generated reports: View or download output

Standard Report Types:

• Enrollment Report: Screening, enrollment, withdrawal by site and time period
• Form Completion Report: Completion rates by visit, form, and site
• Query Metrics Report: Open/closed queries, resolution time, by site
• Visit Compliance Report: On-time vs. late vs. missed visits
• Protocol Deviation Report: List of recorded deviations with categorization
• SDV Progress Report: Verification completion by site and monitor

Key Actions:

• Generate Report (Study Designer, Monitor): Select report type, set parameters, run
• Schedule Report (Admin): Configure recurring report generation
• Download Report (All roles with access): Export as PDF, CSV, or Excel
• View Historical Reports (All roles): Access previously generated reports

Data Sources: Aggregated queries across Participant, ScheduledTask, FormResponse, Query, AuditLog

---

Administration

These pages support system-level configuration and are restricted to Admin users (with some access for Study Designers).

Users & Roles

Purpose: Manage user accounts, role assignments, and site access.

Content:

• User list: Username/email, Role, Status (active/inactive), Last login, Assigned sites
• User detail view with full profile and permissions

User Detail View:

• Profile: Name, email, contact info, account status
• Role assignment: Current role with change history
• Site assignments: List of sites with access level
• Activity summary: Last login, recent actions count
• Security: Password reset, MFA status (future), session management

Key Actions:

• Create User (Admin): Add new user with role and initial site assignment
• Edit User (Admin): Update profile, change role, modify site access
• Deactivate User (Admin): Revokes access; preserves record for audit purposes
• Reactivate User (Admin): Restores access for previously deactivated user
• Reset Password (Admin): Triggers password reset flow for user
• View User Activity (Admin): Shows filtered audit log for specific user

Role Assignment Rules:

• Users have exactly one system role (admin, study_designer, site_staff, monitor, participant)
• Site access is additive (user can be assigned to multiple sites)
• Role changes logged to audit trail with old/new role

Data Models: User, UserSiteAssignment, AuditLog

---

Form Library

Purpose: Manage reusable form templates and activity modules across studies.

Content:

• Template catalog: List of form templates available for reuse
• Module types: Survey (SurveyJS), Consent, Task (jsPsych - future)
• Template detail: Schema preview, usage history, version info

Template Categories:

• Standard Forms: Demographics, Adverse Events, Concomitant Medications, Visit Log
• Consent Templates: ICF templates for different study types
• Assessment Instruments: Validated questionnaires (PHQ-9, GAD-7, etc.)
• Custom Templates: Study-specific forms saved for reuse

Key Actions:

• Import Template (Study Designer): Copy template into current study as new form
• Create Template (Admin, Study Designer): Save current form as reusable template
• Edit Template (Admin): Modify template schema (new version created)
• Archive Template (Admin): Remove from active catalog

Usage Tracking:

• Track which studies have imported each template
• Alert when template is updated (studies using old version)

Data Models: FormTemplate (id, name, type, schema JSON, version, category, created_by)

---

Data Export

Purpose: Export study data in various formats for analysis, reporting, and regulatory submission.

Content:

• Export configuration: Study, data scope, format, de-identification options
• Export history: Previously generated exports with download links
• Data dictionary: Field definitions for exported data

Export Options:

• Scope: All participants, specific site(s), specific arm(s), date range
• Content: All forms, specific forms, with or without metadata
• Format: CSV (one file per form), JSON (nested structure), Excel (multi-sheet)
• De-identification: None, Limited (remove direct identifiers), Full (date shifting, ID replacement)

Key Actions:

• Configure Export (Study Designer, Monitor): Set scope and options
• Generate Export (Study Designer, Monitor): Queue export job
• Download Export (Study Designer, Monitor): Retrieve generated files
• Export Data Dictionary (Study Designer): Download field definitions
• Export Audit Trail (Admin): Download audit log for regulatory submission

De-identification Levels:

• None: Full data including names, dates, identifiers
• Limited: Remove direct identifiers (name, contact info, MRN)
• Full: Limited + date shifting + participant ID replacement with random codes

Data Models: FormResponse, Participant, FormDefinition, ExportJob (id, study_id, requested_by, status, options JSON, file_path, created_at)

---

Settings

Purpose: Configure system-wide and study-specific settings.

Content:

• Organized into sections: General, Notifications, Integrations, Security

General Settings:

• System name and branding
• Default timezone
• Session timeout duration
• Data retention policies

Notification Settings:

• Email server configuration (SMTP or service integration)
• SMS configuration (Twilio credentials)
• Notification templates: Visit reminders, query alerts, password reset
• Notification timing: Reminder intervals (e.g., 3 days before, 1 day before, day of)

Integration Settings:

• Video conferencing (Zoom, Teams) API credentials for remote visits
• External system connections (EHR, registry - future)
• Export destinations (SFTP, cloud storage - future)

Security Settings:

• Password policy: Minimum length, complexity, expiration
• Session management: Concurrent session limits, timeout
• MFA configuration (future): Enable/require for specific roles
• IP allowlisting (future): Restrict access by IP range

Key Actions:

• View Settings (Admin): See current configuration
• Update Settings (Admin): Modify configuration values
• Test Notification (Admin): Send test email/SMS to verify configuration
• Test Integration (Admin): Verify external service connectivity

Data Models: SystemSetting (key-value store or structured table)

---

Sessions

Purpose: Monitor and manage active user sessions for security oversight.

Content:

• Active session list: User, Login time, IP address, User agent, Last activity
• Session history: Past sessions with duration and logout type (manual, timeout, forced)
• Security alerts: Failed login attempts, unusual activity patterns

Session Detail View:

• User information
• Session timeline: Login → actions → logout
• Device/browser information
• Geographic location (from IP, if available)

Key Actions:

• View Active Sessions (Admin): See all currently active sessions
• Terminate Session (Admin): Force logout a specific session
• Terminate All User Sessions (Admin): Force logout all sessions for a user
• View Login History (Admin): See historical login attempts for a user
• Export Session Report (Admin): Download session data for security audit

Security Features:

• Concurrent session limit enforcement
• Automatic timeout after inactivity period
• Forced re-authentication for sensitive actions
• Failed login attempt tracking and lockout (future)

Data Models: Session (id, user_id, token_hash, created_at, last_activity, ip_address, user_agent, is_active), LoginAttempt (user_id, timestamp, success, ip_address)

---

Participant Portal

Separate interface for participants, accessed via authenticated login with participant role.

My Schedule

Purpose: Show participant their upcoming and past study visits.

Content:

• Timeline or calendar view of scheduled visits
• Status indicators: Upcoming, Due now, Completed, Missed
• Next visit highlight with countdown

Visit Card Content:

• Visit name and date
• Location or "Remote" indicator
• Forms to complete (count and names)
• Video call link if remote visit scheduled
• Action button: "Start Visit" or "View Completed"

Key Actions:

• View Schedule (Participant): See all visits
• Join Remote Visit (Participant): Open video call link
• Start Forms (Participant): Navigate to pending surveys

---

Surveys

Purpose: Interface for participants to complete assigned surveys/forms.

Content:

• List of pending surveys grouped by visit
• In-progress surveys (can resume)
• Completed surveys (view-only)

Survey Completion Interface:

• SurveyJS Runner in mobile-optimized layout
• Progress indicator
• Save and continue later option
• Submit button with confirmation

Key Features:

• Auto-save drafts
• Mobile-responsive design
• Offline capability (future): Queue submissions when offline
• Push notifications for pending surveys

---

My Consent

Purpose: Allow participants to view their signed consent documents.

Content:

• List of consent documents signed
• Consent version and signature date
• Link to PDF download

Key Actions:

• View Consent PDF (Participant): Download or view signed consent
• Re-consent (if prompted): Complete new consent when study version updated

---

Implementation Notes

API Endpoint Mapping

Each page corresponds to one or more API endpoints:

Page	Primary Endpoints
Dashboard	GET /dashboard (aggregated data by role)
Participants	GET/POST /studies/{id}/participants
Visit Schedule	GET /participants/{id}/schedule
Data Entry	GET/POST /forms/{id}/responses
eConsent	POST /consent/sign, GET /consent/{id}/pdf
Queries	GET/POST /queries
Study Setup	GET/POST/PUT /studies, /arms, /visits
Form Designer	GET/POST/PUT /studies/{id}/forms
Sites	GET/POST /studies/{id}/sites
Monitoring	GET/PUT /responses/{id}/verify
Audit Trail	GET /audit
Reports	GET/POST /reports
Users & Roles	GET/POST/PUT /users
Form Library	GET/POST /templates
Data Export	POST /export, GET /export/{id}
Settings	GET/PUT /settings
Sessions	GET/DELETE /sessions

Role-Page Access Matrix

Page	Admin	Study Designer	Site Staff	Monitor	Participant
Dashboard	✓	✓	✓	✓	✓ (limited)
Participants	✓	✓ (read)	✓ (own site)	✓ (read)	✗
Visit Schedule	✓	✓ (read)	✓ (own site)	✓ (read)	✓ (own)
Data Entry	✓	✗	✓	✗	✓ (own)
eConsent	✓	✓ (read)	✓	✓ (read)	✓ (own)
Queries	✓	✓	✓ (respond)	✓	✗
Study Setup	✓	✓	✗	✗	✗
Form Designer	✓	✓	✗	✗	✗
Sites	✓	✓	✗	✓ (read)	✗
Monitoring	✓	✗	✗	✓	✗
Audit Trail	✓	✗	✗	✓ (limited)	✗
Reports	✓	✓	✓ (limited)	✓	✗
Users & Roles	✓	✗	✗	✗	✗
Form Library	✓	✓	✗	✗	✗
Data Export	✓	✓	✗	✓	✗
Settings	✓	✗	✗	✗	✗
Sessions	✓	✗	✗	✗	✗

---

Compliance Checklist by Page

Page	21 CFR Part 11 Requirement
All pages	Unique user identification, role-based access
Data Entry	Audit trail of data changes with old/new values
eConsent	Electronic signature with timestamp, PDF archival
Form Designer	Version control, change documentation
Audit Trail	Tamper-evident, computer-generated timestamps
Sessions	Automatic logout after inactivity
Data Export	Accurate, complete data reproduction