Electronics Guide

Essential ICH-GCP Principles

E6(R3) restructured the earlier thirteen E6(R2) principles into eleven overarching principles, introducing concepts such as quality by design and proportionality and adopting a "media neutral" stance that treats paper and electronic processes equivalently. For electronic systems, several principles are particularly relevant:

• Subject Protection: Electronic systems must incorporate safeguards to protect the rights, safety, and well-being of trial subjects, whose protection takes precedence over the interests of science and society
• Scientific Soundness: Clinical trials must be scientifically sound, and electronic systems must support the generation of reliable data
• Quality by Design: Quality must be built into trial design and conduct, with systems engineered to manage the factors that are critical to data reliability and subject safety
• Qualified Personnel: Each individual involved in conducting a trial must be qualified by education, training, and experience, with electronic systems providing appropriate access controls
• Informed Consent: Systems must support the informed consent process, ensuring subjects freely give documented consent before trial participation
• Data Reliability: All clinical trial information must be recorded, handled, and stored so that it can be accurately reported, interpreted, and verified throughout the data lifecycle
• Confidentiality: Records must be protected to maintain subject confidentiality in accordance with applicable regulatory requirements

Data Governance Under E6(R3)

A defining feature of E6(R3) is its consolidated treatment of data governance, which gathers expectations for computerized systems and the data they hold across the full lifecycle from capture to archiving. Key electronic system requirements include:

• Computerized Systems Validation: Systems used to generate, modify, maintain, archive, retrieve, or transmit clinical trial data must be validated and fit for purpose before their required use
• Security Measures: Physical and logical security must prevent unauthorized access to data, with user accountability maintained throughout
• Audit Trails and Metadata: Systems must maintain complete audit trails and supporting metadata so that data changes remain traceable
• Data Backup: Backup and recovery arrangements must ensure data protection and availability
• Blinding Integrity: For blinded trials, systems must maintain blinding, including during data entry and access to records
• Risk-Based Quality Management: Controls should be proportionate to the risks each system and dataset pose to subject safety and data reliability

In the European Union, these expectations are elaborated by the EMA Guideline on computerised systems and electronic data in clinical trials, which took effect on September 9, 2023 and replaced the earlier reflection paper on electronic source data. The guideline is notable for the breadth of what it treats as a computerized system requiring control: not only electronic data capture and randomization platforms, but also recruitment databases, participant portals, spreadsheets used for trial data, and the cloud infrastructure beneath them. It also sets out sponsor responsibilities for oversight of service providers, expectations for validation documentation held by the sponsor rather than only by the vendor, and specific guidance on audit trail review.

Protocol-Driven System Design

Electronic systems for clinical trials must be designed to enforce protocol requirements:

• Visit Schedules: Systems should track required visits and assessments per protocol windows
• Eligibility Criteria: Inclusion and exclusion criteria should be systematically verified before enrollment
• Dosing Algorithms: For dose-escalation or adaptive designs, systems must implement protocol-specified dosing rules
• Assessment Timing: Systems should enforce protocol-specified timing for assessments and procedures
• Protocol Deviations: Deviations from protocol must be captured and tracked electronically

Amendment Management

Protocols frequently undergo amendments during trial conduct. Electronic systems must support:

• Version Control: Clear identification of which protocol version applies to each subject
• Transition Management: Systematic handling of subjects transitioning between protocol versions
• Documentation: Complete records of protocol version history and changes
• Retrospective Analysis: Ability to analyze data according to the protocol version in effect at the time of collection

eConsent Requirements

Electronic consent systems must address several regulatory requirements:

• Comprehension: Interactive elements such as videos, quizzes, and glossaries should enhance understanding of trial information
• Accessibility: Systems must be accessible to subjects with varying literacy levels and disabilities
• Language Support: Multi-language capabilities must be available for international trials
• Electronic Signatures: Signatures must comply with 21 CFR Part 11 and equivalent regulations
• Version Management: Systems must track consent form versions and re-consent processes
• Documentation: Complete records of the consent process, including time spent reviewing materials

Witness and Representative Provisions

Consent systems must accommodate special circumstances:

• Impartial Witness: For subjects unable to read, systems must support witness attestation
• Legally Authorized Representatives: Systems must allow consent by authorized representatives when subjects cannot consent
• Assent Provisions: For pediatric trials, systems must capture both guardian consent and child assent where appropriate
• Emergency Consent: For emergency research, systems must document circumstances and subsequent consent processes

Core ALCOA Principles

The original ALCOA principles define essential data quality attributes:

Attributable

Data must be traceable to the person who performed the action or made the observation. Electronic systems must capture user identification, dates, and times for all data entries and modifications.

Legible

Data must be readable and permanent. Electronic systems must use appropriate data formats, character sets, and display mechanisms to ensure legibility throughout the data retention period.

Contemporaneous

Data must be recorded at the time of the activity. Systems should include timestamps and may implement controls to flag late or backdated entries.

Original

Data must be the first recording or a certified copy. Electronic systems must clearly identify source data and maintain the relationship between original records and any copies.

Accurate

Data must be free from errors. Electronic systems should implement validation rules, range checks, and edit checks to minimize errors at the point of entry.

Extended ALCOA+ and ALCOA++ Attributes

The extended ALCOA+ framework adds four further attributes, and European clinical trial guidance adds a fifth under the label ALCOA++:

Complete

All data must be recorded, including any repeated tests or re-sampling. Systems must not allow selective deletion of data, and all results must be captured regardless of outcome.

Consistent

Data elements must use consistent definitions, formats, and units throughout the trial. Systems should enforce standardized data collection.

Enduring

Data must be maintained for the required retention period in a format that remains accessible. Migration strategies must preserve data integrity.

Available

Data must be accessible for review throughout the retention period. Systems must support regulatory inspections and audits.

Traceable

Added by the EMA guideline on computerised systems, which uses the label ALCOA++, traceability requires that data can be followed through every transformation from initial capture to the analysis dataset and the final report. Systems must therefore retain not only audit trails but also the mappings, derivations, and transfer records that explain how a submitted value relates to its source.

The distinction matters in practice because traceability is the attribute most often broken by integration rather than by data entry. A value may be attributable, contemporaneous, and accurate at the site yet lose its provenance when it passes through a laboratory transfer, a coding step, and a statistical derivation. Designing for ALCOA++ means treating each hop between systems as a controlled step with its own specification, reconciliation, and evidence.

Validation Lifecycle

EDC validation follows a structured lifecycle approach:

1. User Requirements Specification (URS): Documents the intended use and regulatory requirements the system must meet
2. Functional Specification: Defines the specific functions the system will perform to meet user requirements
3. Design Specification: Details how functions will be implemented technically
4. Installation Qualification (IQ): Verifies the system is installed correctly according to specifications
5. Operational Qualification (OQ): Tests that the system operates according to functional specifications
6. Performance Qualification (PQ): Demonstrates the system performs as intended in the production environment

Study-Specific Validation

Beyond platform validation, each study build requires validation:

• Edit Check Testing: Verification that data validation rules fire correctly and generate appropriate queries
• Derivation Testing: Confirmation that calculated fields produce correct results
• Workflow Testing: Validation of data flow through review and approval processes
• Integration Testing: Verification of data exchange with other systems such as laboratories and interactive response systems
• User Acceptance Testing: Confirmation by study team that the system meets study-specific requirements

Ongoing Validation Activities

Validation is not a one-time event but requires ongoing activities:

• Change Control: Formal processes for evaluating and implementing system changes
• Periodic Review: Regular assessments to confirm continued system compliance
• Incident Management: Tracking and resolution of system issues with impact assessment
• Revalidation: Assessment of whether changes require partial or complete revalidation

Essential Audit Trail Elements

Compliant audit trails must capture:

• User Identification: Unique identifier of the person performing the action
• Date and Time: System-generated timestamp synchronized to a reliable time source
• Action Type: Whether the record was created, modified, or deleted
• Previous Value: The original value before modification
• New Value: The value after modification
• Reason for Change: User-provided explanation for the modification

Audit Trail Protection

Audit trails must be protected against modification or deletion:

• Immutability: Once created, audit trail entries cannot be modified or deleted
• Access Control: Audit trail viewing should be restricted to authorized personnel
• Independent Storage: Audit trails should be stored separately from application data where practical
• Backup: Audit trails must be included in backup and disaster recovery procedures
• Retention: Audit trails must be maintained for the required retention period

Audit Trail Review

Regulatory authorities expect periodic audit trail review as part of data quality management:

• Review Procedures: Documented procedures defining what is reviewed, how often, and by whom
• Risk-Based Approach: Focus review on critical data elements and high-risk activities
• Pattern Detection: Analysis for unusual patterns that might indicate data integrity issues
• Documentation: Records of audit trail reviews conducted and findings

Site System Requirements

Investigator sites must maintain appropriate electronic infrastructure:

• Hardware: Adequate computing resources to run trial-required systems reliably
• Network Connectivity: Reliable internet access for cloud-based systems and data transmission
• Security: Firewalls, antivirus software, and other security measures to protect trial data
• Backup: Local backup procedures for site-generated data before transmission
• Physical Security: Secure location for equipment with appropriate access controls

User Access Management

Sites must implement appropriate access controls:

• Role-Based Access: Access permissions aligned with job responsibilities
• Delegation Logs: Documentation of delegated responsibilities and system access
• Training Records: Evidence that users are trained before system access is granted
• Access Review: Periodic review and update of user access rights
• Departure Procedures: Prompt deactivation of accounts when staff leave

Source Documentation

Electronic systems must support appropriate source documentation practices:

• Source Definition: Clear specification of what constitutes source data for the trial
• Direct Data Entry: Where appropriate, systems may serve as the primary source
• Transcription: When data is transcribed from paper, procedures must ensure accuracy
• Integration: Electronic medical records may provide source data through validated interfaces

Remote Monitoring Capabilities

Modern clinical trials increasingly rely on remote monitoring, requiring systems that support:

• Source Data Verification: Ability to compare EDC data against source documentation remotely
• Query Management: Electronic query generation, tracking, and resolution
• Risk Indicators: Automated identification of data patterns requiring attention
• Monitoring Reports: Generation of standard and ad-hoc monitoring reports
• Visit Tracking: Oversight of subject visit completion and data entry timeliness

On-Site Monitoring Support

Systems must facilitate on-site monitoring visits:

• Access Provisioning: Appropriate system access for monitors during site visits
• Report Generation: Ability to generate required monitoring reports on demand
• Audit Trail Access: Monitor access to audit trails for data verification
• Document Access: Access to electronic trial master file documents

Audit Readiness

Systems must maintain continuous audit readiness:

• Documentation Availability: Validation documentation, SOPs, and training records readily accessible
• Inspector Access: Ability to provide appropriate system access to regulatory inspectors
• Data Export: Capability to export data in formats required by regulatory authorities
• System Demonstration: Ability to demonstrate system functionality during inspections

Adverse Event Capture

EDC systems must support comprehensive adverse event documentation:

• Event Description: Free-text and coded description of the adverse event
• Medical Coding: Integration with MedDRA, the Medical Dictionary for Regulatory Activities, whose five-level hierarchy runs from lowest level term through preferred term, high level term, and high level group term to system organ class; coding systems must be version-controlled because MedDRA is updated twice a year
• Severity Assessment: Grading scales such as the Common Terminology Criteria for Adverse Events (CTCAE), which grades severity from 1 (mild) to 5 (death related to the adverse event), widely used in oncology trials
• Causality Assessment: Investigator assessment of relationship to study treatment
• Dates and Duration: Onset, resolution, and duration of the event
• Action Taken: Treatment provided and changes to study drug
• Outcome: Resolution status and any sequelae

Serious Adverse Event Expedited Reporting

Serious adverse events (SAEs) require expedited reporting. An event is serious when it results in death, is life-threatening, requires or prolongs hospitalization, causes persistent or significant disability or incapacity, or produces a congenital anomaly or birth defect; important medical events may also qualify on medical judgment. Expedited timelines are short and unforgiving. Under 21 CFR 312.32, a sponsor must report an unexpected fatal or life-threatening suspected adverse reaction to FDA within 7 calendar days, and other qualifying IND safety reports within 15 calendar days, of the sponsor becoming aware of the information. The corresponding ICH E2A convention for suspected unexpected serious adverse reactions is the same 7-day and 15-day pairing. Electronic systems support these obligations through:

• SAE Identification: Automated flagging based on seriousness criteria
• Notification: Immediate alerts to appropriate personnel upon SAE entry
• Clock Start Capture: Recording the date of first awareness, which starts the regulatory clock and is a frequent inspection finding when it is not captured unambiguously
• Timeline Tracking: Monitoring of regulatory reporting deadlines
• Regulatory Forms: Generation of CIOMS forms or equivalent regulatory reports
• Submission Tracking: Documentation of submissions to regulatory authorities and ethics committees

Safety Database Integration

Clinical trial systems often integrate with pharmacovigilance databases:

• Data Exchange: Automated transmission of safety data to safety databases
• E2B Standards: Compliance with ICH E2B(R3), the current XML-based format for individual case safety reports, used for submission to FDA and to the EudraVigilance database
• Reconciliation: Regular reconciliation between clinical and safety databases
• Signal Detection: Support for aggregate safety analysis and signal detection

Core CTMS Functions

CTMS platforms typically provide:

• Study Planning: Protocol development support, milestone tracking, and resource planning
• Site Management: Site identification, qualification, activation, and performance tracking
• Subject Tracking: Enrollment tracking, visit scheduling, and retention monitoring
• Document Management: Regulatory document collection and tracking
• Financial Management: Budget tracking, payment processing, and grant management
• Resource Management: Staff assignments and workload management

CTMS Integration

CTMS systems typically integrate with multiple other systems:

• EDC Systems: Subject enrollment data and visit completion status
• IRT/RTSM: Interactive response technology and randomization and trial supply management systems, providing randomization status and drug supply information
• eTMF: The electronic trial master file, the controlled repository of the essential documents that demonstrate compliance and permit reconstruction of how the trial was conducted
• Safety Systems: Serious adverse event counts and reporting status
• Financial Systems: Invoice processing and payment tracking

Operational Analytics

CTMS platforms support operational decision-making through:

• Key Performance Indicators: Enrollment rates, data entry timeliness, query resolution times
• Risk Indicators: Identification of sites or activities requiring intervention
• Forecasting: Predictive models for enrollment completion and resource needs
• Benchmarking: Comparison against historical performance or industry standards

eCRF Design Principles

Effective eCRF design considers:

• Data Standards: Alignment with CDISC standards including CDASH for data collection
• User Experience: Intuitive layouts that minimize data entry errors
• Edit Checks: Real-time validation to catch errors at point of entry
• Logical Flow: Organization matching clinical workflow and source documents
• Annotation: Clear mapping to analysis datasets and regulatory submissions

Edit Check Validation

Edit checks are programmatic validations applied to eCRF data:

• Range Checks: Verification that values fall within expected ranges
• Consistency Checks: Cross-field and cross-form logic validation
• Conditional Logic: Checks that apply based on other data values
• Query Generation: Automated discrepancy queries for resolution
• Testing Requirements: Each edit check must be tested with positive and negative test cases

eCRF Completion Guidelines

Documentation supporting eCRF use includes:

• Completion Guidelines: Field-by-field instructions for data entry
• Data Conventions: Standard formats for dates, times, and other data types
• Query Resolution: Procedures for responding to data queries
• Training Materials: Educational content for site personnel

Statistical Analysis Plan Support

Systems should support implementation of statistical analysis plans:

• Analysis Populations: Definition and tracking of analysis populations such as ITT, PP, and safety
• Endpoint Derivation: Calculation of primary and secondary endpoints per protocol specifications
• Interim Analysis: Support for planned interim analyses with appropriate data access controls
• Subgroup Analysis: Capability to define and analyze pre-specified subgroups

Data Standards Compliance

Clinical data must comply with regulatory standards:

• CDISC CDASH: Clinical Data Acquisition Standards Harmonization for data collection
• CDISC SDTM: Study Data Tabulation Model for submission datasets
• CDISC ADaM: Analysis Data Model for analysis-ready datasets
• Define-XML: Metadata specifications for submission datasets
• Controlled Terminology: Use of standardized code lists and terminology

Statistical Programming Validation

Statistical programs require validation before use:

• Double Programming: Independent programming and comparison of results
• Code Review: Peer review of statistical programming code
• Test Data: Use of test datasets to verify program logic
• Documentation: Complete documentation of programming specifications and validation

Randomization Requirements

Randomization systems must ensure:

• Unpredictability: Treatment assignment cannot be predicted before randomization
• Allocation Concealment: The randomization sequence is concealed from investigators
• Stratification: Support for stratified randomization when required by protocol
• Balance: Appropriate balance between treatment groups overall and within strata
• Reproducibility: Ability to recreate the randomization sequence for audit purposes, typically by recording the algorithm, the block structure, and the seed used to generate the list

Common allocation methods carry different engineering consequences. Permuted block randomization within strata is simple to implement and audit, but small block sizes make late assignments in a block predictable, so protocols often use varying block sizes to preserve concealment. Minimization, a covariate-adaptive method, assigns each subject to whichever arm best balances the prognostic factors observed so far, usually with a random element retained so that assignment is not deterministic. Because minimization depends on the accumulated allocation history, the system must be transactionally safe: concurrent enrollments at different sites must not read the same state and produce a duplicated or unbalanced assignment. Response-adaptive designs go further and change allocation ratios based on accruing outcome data, which places the randomization engine inside the blinded firewall and raises the validation burden accordingly.

Blinding Management

For blinded trials, IRT systems must protect treatment assignment:

• Access Controls: Treatment assignment visible only to authorized unblinded personnel
• Emergency Unblinding: Secure procedures for emergency unblinding with documentation
• Blinding Verification: Mechanisms to verify blinding integrity has been maintained
• Audit Trails: Complete records of any access to treatment assignment information

Drug Supply Management

IRT systems typically manage clinical supply:

• Inventory Management: Tracking of drug inventory at depots and sites
• Dispensing: Assignment of specific drug kits to subjects
• Resupply: Automated triggers for site resupply based on inventory levels
• Expiry Management: Tracking of expiration dates and quarantine of expired supplies
• Temperature Excursions: Documentation and handling of storage temperature deviations

ePRO System Requirements

Electronic PRO collection requires specialized considerations:

• Instrument Validation: Validated electronic versions of PRO instruments
• Device Selection: Appropriate devices (provisioned, BYOD, or site-based)
• Accessibility: Systems accessible to patients with varying abilities and technical sophistication
• Reminder Systems: Automated reminders to improve completion rates
• Timestamp Verification: Confirmation that data is collected within protocol windows

PRO Data Quality

Maintaining PRO data quality requires:

• Compliance Monitoring: Tracking of completion rates and missing data patterns
• Window Enforcement: Restrictions on data entry outside specified time windows
• Training: Patient training on device use and questionnaire completion
• Support: Help desk support for patient technical issues
• Migration Validation: For instruments with paper origins, validation of equivalence

Regulatory Considerations

PRO data for regulatory submissions must meet additional requirements:

• FDA PRO Guidance: Compliance with FDA guidance on PRO measures for labeling claims
• EMA Qualification: EMA qualification opinion for novel PRO instruments
• Cross-Cultural Validation: Validated translations for multi-national trials
• Copyright: Appropriate licensing for proprietary instruments

eCTD Requirements

Electronic submissions must comply with eCTD specifications:

• Structure: Organization according to the CTD five-module structure
• Document Format: PDF documents meeting regulatory specifications
• Navigation: XML backbone with hyperlinks and bookmarks
• Lifecycle Management: Tracking of document versions across submissions
• Regional Requirements: Compliance with region-specific requirements such as FDA, EMA, and PMDA

Data Submission Standards

Clinical data submissions follow specific standards:

• Study Data: CDISC SDTM and ADaM datasets, submitted to FDA as SAS Version 5 transport (XPORT) files, with supported versions listed in the agency's data standards catalog
• Metadata: Define-XML describing dataset structure, variable derivations, and controlled terminology
• Analysis Programs: Statistical analysis programs and outputs
• Clinical Study Reports: ICH E3-compliant clinical study reports
• Reviewer Guides: Documentation to assist regulatory reviewers

Submission Management

Managing regulatory submissions requires:

• Publishing Tools: Software for assembling eCTD submissions
• Validation: Technical validation before submission
• Gateway Submission: Electronic submission through regulatory gateways
• Tracking: Management of submission sequences and supplements
• Archive: Long-term retention of submission records

Electronic Record Requirements

Part 11 requires electronic records to include:

• Validation: Systems must be validated for their intended use
• Record Retention: Ability to generate accurate and complete copies in both human-readable and electronic form
• Record Protection: Protection of records throughout the retention period
• Access Controls: Limiting system access to authorized individuals
• Audit Trails: Secure, computer-generated, time-stamped audit trails
• Operational Checks: Device checks to determine validity of data input
• Authority Checks: Ensuring only authorized individuals can use the system

Electronic Signature Requirements

Electronic signatures under Part 11 must:

• Unique Identification: Be unique to one individual and not reused or reassigned
• Identity Verification: Verify identity before establishing, assigning, or certifying electronic signatures
• Signature Components: Include at least two distinct identification components such as a user identification code and a password; for a series of signings during a single continuous session, all components are used for the first signing and at least one private component for each subsequent signing
• Signature Manifestation: Include printed name, date/time, and meaning of signature
• Linkage: Be linked to electronic records to ensure signatures cannot be transferred

Part 11 Scope Determination

Organizations must determine Part 11 applicability:

• Predicate Rules: Part 11 applies when records are required by FDA predicate rules
• Enforcement Discretion: FDA has exercised enforcement discretion for certain requirements
• Risk Assessment: Organizations should conduct risk-based assessment of Part 11 controls
• Documentation: Document the rationale for Part 11 compliance decisions

Key Annex 11 Requirements

Annex 11 establishes requirements including:

• Risk Management: Formal risk assessment for computerized systems throughout their lifecycle
• Supplier Assessment: Qualification of software suppliers and service providers
• Validation Documentation: Comprehensive documentation including requirements, specifications, and test protocols
• Data Integrity: Controls to ensure data integrity throughout the data lifecycle
• Business Continuity: Procedures for system failure and data recovery
• Periodic Review: Regular evaluation of system validation status

Differences from Part 11

Notable differences between Annex 11 and Part 11 include:

• Risk Management: Annex 11 explicitly requires formal risk management across the system lifecycle, whereas Part 11 is silent on the method and FDA addresses risk only through guidance
• Supplier Qualification: Explicit requirements for assessing suppliers and service providers and for formal agreements defining responsibilities
• Scope of Application: Part 11 attaches to records required by an FDA predicate rule; Annex 11 attaches to any computerized system that forms part of a GMP-regulated activity
• Periodic Review: Explicit requirement for periodic system review, which Part 11 does not state directly

The Annex 11 Revision

Annex 11 was last revised in 2011, before cloud hosting, continuous delivery, and machine learning became ordinary features of regulated systems. On July 7, 2025, the European Commission released a draft revision for public consultation, together with a revised Chapter 4 on documentation and an entirely new draft Annex 22 covering artificial intelligence in the manufacture of active substances and medicinal products. The consultation closed on October 7, 2025.

The draft is a substantial expansion, restructuring a short annex into a document organized by chapter and addressing topics the 2011 text barely touched: cybersecurity as an explicit requirement, identity and access management, audit trail content and review, supplier oversight for cloud and hosted services, data migration, and lifecycle management for systems that change continuously. Organizations building or procuring regulated systems should track the outcome, because the direction of travel is clear even before the final text appears: more explicit expectations for security controls, for evidence held by the regulated party rather than the vendor, and for governance of automated decision-making.

GDPR Requirements

The General Data Protection Regulation impacts clinical trials in the EU:

• Lawful Basis: Establishing appropriate legal basis for processing clinical trial data
• Subject Rights: Balancing data subject rights with scientific research requirements
• Cross-Border Transfer: Mechanisms for transferring data outside the EU/EEA
• Data Protection Impact Assessment: Conducting DPIAs for high-risk processing
• Records of Processing: Maintaining records of processing activities

HIPAA Considerations

US-based clinical trials must address HIPAA requirements:

• Authorization: Obtaining valid HIPAA authorization for research use
• Limited Data Sets: Use of limited data sets with data use agreements
• De-identification: Methods for de-identifying protected health information
• Business Associate Agreements: Appropriate agreements with vendors handling PHI

Pseudonymization Strategies

Clinical trial data typically uses pseudonymization:

• Subject Identifiers: Unique study identifiers replacing direct identifiers
• Coding Systems: Secure systems linking study IDs to identities
• Key Management: Controls on access to re-identification keys
• Data Minimization: Collecting only data necessary for trial objectives

Decentralized Clinical Trials

Decentralized or hybrid trials use remote technologies:

• Telemedicine: Remote visits and assessments via video conferencing
• Home Health: Mobile nurses and home sample collection
• Direct-to-Patient: Drug shipment directly to patient homes
• Remote Monitoring: Continuous monitoring through wearable devices
• eConsent: Fully electronic consent processes

FDA issued final guidance on Conducting Clinical Trials With Decentralized Elements on September 18, 2024, covering drugs, biological products, and devices. Its central message is that decentralization creates no separate regulatory regime: the same requirements apply, and sponsors must show how they are met when activities occur outside a traditional site. The practical burden falls on system design. Remote assessments must be attributable to a specific qualified individual, task delegation must be documented when local providers perform trial activities, data from participant-owned devices must be traceable to the participant rather than merely to a device, and direct-to-participant shipment of investigational product must preserve chain of custody and temperature records.

Wearables and Sensors

Wearable devices generate new types of clinical data:

• Continuous Monitoring: Real-time physiological data collection
• Digital Biomarkers: Novel endpoints derived from sensor data
• Data Volume: Managing large volumes of high-frequency data
• Device Validation: Establishing accuracy and reliability of measurements
• Regulatory Acceptance: Engagement with regulators on novel endpoints

Evaluating a sensor-derived endpoint is usually framed as three separate questions. Verification asks whether the hardware measures its raw physical signal correctly, and is answered on the bench against a reference instrument. Analytical validation asks whether the algorithm that converts that raw signal into a physiological measure performs correctly in the intended population, since a step-counting algorithm tuned on healthy adults may fail on a shuffling gait. Clinical validation asks whether the resulting measure relates to how patients feel, function, or survive. A wearable that passes the first two questions and fails the third produces precise numbers that support no labeling claim, which is why regulatory engagement on novel digital endpoints normally happens well before the pivotal trial rather than at submission.

Artificial Intelligence Applications

AI is being applied in clinical trials:

• Patient Recruitment: AI-assisted identification of eligible patients
• Protocol Optimization: Machine learning for protocol design
• Data Review: AI-assisted data cleaning and anomaly detection
• Predictive Analytics: Forecasting enrollment and outcomes
• Regulatory Considerations: Emerging guidance on artificial intelligence and machine learning in clinical development, including the European Commission's draft Annex 22, which would set expectations for model selection, training data, validation, and human oversight in GMP contexts

The compliance problem with machine learning in regulated trial systems is that conventional validation assumes deterministic behavior. A model that retrains on new data is a system that changes without a change request, so organizations must either freeze the model and revalidate on each version or define in advance the boundaries within which adaptation is permitted and the monitoring that detects drift beyond them. Explainability matters for the same reason: if an algorithm flags a data point for review, the reviewer's decision must be defensible without reference to an opaque score. Most current deployments therefore keep artificial intelligence in an advisory role, informing where humans look rather than making regulated determinations directly.

System Selection and Implementation

Best practices for system implementation include:

• Requirements Definition: Clearly define requirements before system selection
• Vendor Assessment: Thoroughly evaluate vendor capabilities and compliance
• Validation Planning: Develop validation approach early in implementation
• Change Management: Implement robust change control procedures
• Training: Provide comprehensive training to all system users

Ongoing Compliance Management

Maintaining compliance requires continuous attention:

• Periodic Review: Regular assessment of system compliance status
• Audit Readiness: Maintain documentation for regulatory inspections
• Regulatory Updates: Monitor and implement changes from regulatory guidance
• Continuous Improvement: Learn from audits, inspections, and operational experience

Quality Culture

Technical compliance must be supported by organizational culture:

• Leadership Commitment: Senior management support for quality and compliance
• Training and Awareness: Ongoing education on regulatory requirements
• Open Communication: Environment where quality concerns can be raised
• Root Cause Analysis: Investigation and correction of quality issues