Findings
The FDA classifies CDS software as Non-Device CDS only if it meets four specific criteria related to data inputs, information display, HCP support, and independent reviewability. Software functions that analyze medical images, signals from IVDs, or patterns from signal acquisition systems remain regulated as medical devices. Non-Device CDS must be intended for health care professionals and not for patients or caregivers. Automation bias and the time-critical nature of decision-making are key factors in determining whether an HCP can truly review the basis of a recommendation independently. If software provides a specific diagnostic or treatment directive rather than a list of options, it generally fails to meet the exclusion criteria.

Recommendations
Developers should ensure that software intended as Non-Device CDS provides a plain language description of the underlying algorithm and the data used for validation. The software or labeling must clearly identify the intended HCP user, the patient population, and the required input medical information. To support independent review, the software should highlight the source of its clinical recommendations, such as specific clinical practice guidelines or peer-reviewed studies. Developers are encouraged to use usability testing to verify that HCPs can understand the basis of recommendations without relying primarily on the software’s output. For multiple function products, developers should follow the FDA’s policy for assessing products that contain both device and non-device functions.

Regulatory Considerations
The FDA applies a risk-based approach to software oversight, focusing on functions that acquire or analyze complex medical data like ECG waveforms or genomic sequences. Software intended for time-sensitive or critical medical decisions is typically regulated as a device because the user lacks the time to independently verify the recommendation. The agency intends to exercise enforcement discretion for certain software functions that provide only one clinically appropriate recommendation if all other non-device criteria are met. Sponsors may use the Q-Submission process to discuss alternative approaches or clarify the regulatory status of specific software functions. Existing digital health policies continue to apply to software functions that meet the device definition, including mobile medical applications.

Findings
FDA considers electronic records and signatures to be equivalent to paper records and handwritten signatures when they meet the requirements of 21 CFR part 11. Advances in technology, including Digital Health Technologies (DHTs) and cloud computing, necessitate updated guidance on ensuring the authenticity, integrity, and confidentiality of electronic data in clinical investigations. Records submitted to the FDA under predicate rules (e.g., marketing applications) are subject to part 11. FDA does not intend to assess the compliance of external Real-World Data (RWD) sources like Electronic Health Record (EHR) systems with part 11, but the sponsor remains responsible for the quality and integrity of all submitted data.

Recommendations
Risk-Based Validation: Regulated entities should use a risk-based approach to validation for all electronic systems deployed, proportionate to the risks to participant safety and reliability of trial results. Validation must cover system functionality, trial-specific configurations, customizations, and interoperability.
Data Retention & Audit Trails: Electronic records must be retained for the applicable period in a secure and traceable manner. Audit trails must capture all changes (old/new value, user ID, date/time) and should be protected from modification.
Security & Access Controls: Logical and physical access controls (e.g., strong login credentials, multi-factor authentication) must limit system access to authorized users based on a documented risk assessment. Security safeguards (e.g., encryption, antivirus) must be in place to protect data at rest and in transit.
DHT Use: DHTs should be selected and validated to be fit for purpose. The data originator (person, system, or DHT itself) must be associated with every data element as part of the audit trail. The final location of source data for inspection is the durable electronic data repository, not the individual DHT.
Outsourcing: Regulated entities must have a written agreement with IT service providers (including for cloud computing) detailing roles, responsibilities, and the service provider's ability to provide data integrity and security safeguards. The sponsor must maintain oversight.

Regulatory Considerations
FDA does not certify electronic systems or signature methods; they are evaluated during inspection. Users of electronic signatures must submit a letter of non-repudiation to the FDA certifying that the electronic signature is the legally binding equivalent of a handwritten signature. Security breaches impacting participant safety or privacy should be reported to the IRB and FDA in a timely manner.

Findings
The FDA considers electronic records and signatures equivalent to their paper counterparts when they meet the requirements of 21 CFR Part 11. Due to technological advances, electronic systems and digital health technologies (DHTs) are now integral to clinical trials, requiring a modern, risk-based approach to ensure data integrity. Sponsors remain ultimately responsible for the quality and integrity of all data submitted, even when using third-party IT service providers or data from real-world sources like EHRs. The authenticity, integrity, and confidentiality of electronic data are paramount and must be maintained through robust system controls throughout the data lifecycle.

Recommendations
Regulated entities should use a justified and documented risk-based approach to validate all electronic systems before and during a clinical trial, with the level of validation depending on the system's potential to impact participant safety and trial result reliability. Secure, computer-generated, time-stamped audit trails must be implemented to track the creation, modification, and deletion of all electronic records without obscuring original data. Robust logical and physical access controls are necessary to limit system access to authorized individuals. Entities should have written agreements with IT service providers that clearly define roles, responsibilities, and procedures for ensuring data security and long-term retention.

Regulatory Considerations
The requirements of 21 CFR Part 11 apply to all electronic records created, modified, or submitted to the FDA under predicate rules for clinical investigations, including those from foreign sites under an IND or IDE. While the FDA does not intend to assess the Part 11 compliance of external source systems like EHRs, data becomes subject to these regulations once transferred into the sponsor's electronic system. During inspections, the FDA will focus on system validation, data handling procedures, security protocols, audit trails, and documentation of sponsor oversight. Users must certify to the FDA that their electronic signatures are the legally binding equivalent of handwritten signatures.

Findings
Not all CDS software is regulated as a medical device; the FDA applies specific criteria to determine its classification.
CDS software functions are excluded from the device definition if they meet all four criteria in section 520(o)(1)(E) of the FD&C Act.
Automation bias in decision-making poses a risk, particularly in time-critical scenarios, and influences regulatory considerations.
Clear labeling and transparency about the basis for recommendations are essential for enabling HCPs to make independent decisions.
Software functions that provide specific diagnostic outputs or time-critical directives typically fail to meet the criteria for Non-Device CDS.

Recommendations
Clearly define the intended use, user population, and input medical information for CDS software in labeling.
Ensure that software provides transparent and plain language descriptions of algorithms, data sources, and validation results.
Avoid presenting specific treatment or diagnostic directives to ensure the software supports rather than replaces HCP judgment.
Include sufficient information to allow HCPs to independently review and understand the basis for software recommendations.
Engage with the FDA early in the development process for software functions with potential regulatory oversight.

Regulatory Considerations
CDS software functions that meet all four criteria under section 520(o)(1)(E) of the FD&C Act are excluded from FDA’s definition of a device.
Software intended for time-critical decision-making or replacing HCP judgment is generally considered a device.
Developers must ensure that software labeling and functionality align with the criteria for Non-Device CDS.
Transparency in data sources, algorithm logic, and validation methods is required to enable independent HCP decision-making.
The FDA may request additional information or oversight for software that poses significant risks to patient safety.

Findings
High-quality data must be complete, accurate, timely, and fit for purpose, ensuring reliability for RWE generation.
Effective governance is critical to ensure transparency, ethical standards, and stakeholder engagement in managing RWD.
Data capture challenges include standardization, provenance tracking, and interoperability, particularly for EHR-based data.
Data curation is iterative and involves organizing, assessing, and preparing raw data to meet study-specific needs.
The maturity model identifies five stages of organizational data capabilities, emphasizing consistency, completeness, and automation.

Recommendations
Implement robust governance frameworks to address transparency, stakeholder engagement, and ethical considerations in RWD use.
Focus on improving data capture at the point of care through standardization and semantic interoperability.
Use common data models and validated extraction-transformation-loading (ETL) processes to enhance data consistency and reliability.
Prioritize iterative data curation practices, supported by metadata and provenance tracking, to improve fitness for use over time.
Leverage the NESTcc Data Quality Maturity Model to benchmark and enhance organizational capabilities in RWD management.

Regulatory Considerations
Ensure compliance with patient privacy laws such as HIPAA and GDPR, especially when linking data across sources.
Align data capture and curation practices with FDA guidance for RWE generation and medical device evaluation.
Establish clear data use agreements to protect patient data while enabling analysis for regulatory and research purposes.
Document data transformations, including metadata and provenance, to support reproducibility and transparency in regulatory submissions.
Embrace standard terminologies and data dictionaries to facilitate interoperability and regulatory acceptance.

Findings
Software functions for administrative support of healthcare facilities, general wellness, and maintaining electronic patient records are excluded from FDA regulation if they meet specific criteria under section 520(o)(1) of the FD&C Act.
MDDS software functions for transferring, storing, converting formats, and displaying data are not devices unless they include interpretive or analytical features.
Wellness-related software functions that are unrelated to disease diagnosis or treatment (e.g., tracking fitness or sleep) are no longer regulated as devices.
Software functions associated with certified health IT under ONC Health IT Certification are not considered devices, provided they are not intended for interpretation or diagnosis.
Software involving clinical alerts, prioritization of patient information, or medical decision support remains subject to FDA oversight under section 520(o)(1)(E).

Recommendations
Clearly define software functions to assess whether they fall under the excluded categories outlined in section 520(o)(1) of the FD&C Act.
For software functions that combine device and non-device functionalities, ensure that only device-related functionalities are included in FDA regulatory submissions.
Maintain compliance with general FDA requirements for software that still meets the definition of a device, particularly those with interpretive or decision-support capabilities.
Align product labeling and marketing claims with the revised guidance to accurately reflect whether software functions meet the exclusion criteria.
Use the latest FDA-recognized consensus standards to assess compliance for any software functions still considered devices.

Regulatory Considerations
Non-device software functions under section 520(o)(1) are excluded from FDA regulation, but any interpretive or analytical capabilities must still comply with device requirements.
Software functions certified under ONC Health IT Certification are not devices unless intended for analysis or diagnosis.
Hardware associated with MDDS functions remains subject to FDA regulation, but non-device MDDS software functions are excluded from oversight.
FDA continues to regulate functions that prioritize patient-related information or trigger clinical alerts under section 520(o)(1)(E).
Software combining device and non-device functions must clearly delineate each functionality’s regulatory status to avoid unnecessary oversight of non-device components.

Findings
The process of obtaining Informed Consent (IC) involves providing adequate information to facilitate comprehension and must allow subjects the opportunity to ask questions, continuing throughout the research. Electronic Informed Consent (eIC) systems, which can use various electronic media, are increasingly used to supplement or replace paper-based IC processes. The eIC process may be conducted on-site or remotely, but the legal responsibility for obtaining consent cannot be delegated to the electronic system. For FDA-regulated clinical investigations, electronic signatures must comply with 21 CFR Part 11 to be considered equivalent to a handwritten signature.

Recommendations
Presentation & Comprehension: eIC information should be easy to navigate, convey information in understandable language, and may use interactive electronic-based technology (e.g., diagrams, video) to facilitate comprehension. Optional questions can be used to assess a subject's understanding of key study elements.
Remote Consent: If consent is obtained remotely, the electronic system must include a reliable method to verify the identity of the subject (e.g., official identification, biometric methods).
Signature & Documentation: Electronic signatures are permitted and can be created using methods like biometrics or username/password, provided they are uniquely linked to the individual. The subject must be given a copy of the signed eIC, which can be electronic or paper.
Privacy & Security: The eIC system must be secure with restricted access and include methods to ensure confidentiality of subject information. If HIPAA applies, information must be encrypted unless otherwise documented.

Regulatory Considerations
IRB Responsibility: IRBs must review and approve all eIC materials and any subsequent amendments, including optional comprehension questions and the usability of the eIC materials. IRBs must maintain records (electronic or hard copy) of the approved versions of the eIC materials.
Submissions & Inspection: For IDE applications, copies of all eIC materials must be submitted to the FDA. During inspections, investigators must have site-specific signed eICs, amendments, and materials available (electronic or paper) for FDA review.
HIPAA: HIPAA authorizations may be obtained electronically, provided the signature is legally valid, and a copy must be provided to the subject.

Findings:
Challenges in ensuring audit trail visibility for FDA inspections.
Risks of transcription errors when converting paper records into eCRFs.
Limited integration and standardization across electronic health record systems.
Potential security vulnerabilities in electronic signatures and data transmission.
Lack of comprehensive data quality checks in eCRF systems.

Recommendations:
Ensure the use of robust audit trails to track all changes and modifications to electronic source data.
Develop data management plans outlining roles, responsibilities, and data flow processes.
Use automated data capture methods (e.g., direct device transmission to eCRFs) to minimize errors.
Train clinical investigators and staff on maintaining accurate records and using eCRF systems.
Establish clear protocols for managing and retaining source data for FDA inspections.

Regulatory Considerations:
Compliance with FDA Part 11 regulations on electronic records and electronic signatures.
Retention of original or certified copies of source documents for FDA review.
Access control measures, such as unique logins and passwords, for eCRF systems.
Adherence to data traceability requirements, including data element identifiers.
Use of secure and interoperable systems for transmitting data to the eCRF.