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
The traditional medical device regulatory paradigm is not designed for the adaptive nature of AI/ML technologies, which can learn and change after they are on the market. A key benefit of AI/ML is its ability to improve performance by learning from real-world data, but this also presents a unique regulatory challenge. To ensure patient safety and device effectiveness, a new, flexible regulatory framework is required that can accommodate these iterative improvements. Transparency and robust monitoring are essential to manage the risks associated with evolving algorithms.

Recommendations
The FDA proposes a "Predetermined Change Control Plan" (PCCP) to be included in premarket submissions. This plan would specify the anticipated modifications to the device (the "what") and the methodology for implementing and validating those changes (the "how"). The development of "Good Machine Learning Practice" (GMLP) is encouraged to ensure that AI/ML algorithms are developed and validated using best practices. Manufacturers should implement robust real-world performance monitoring to ensure that their devices remain safe and effective after deployment.

Regulatory Considerations
The FDA is developing a new regulatory framework tailored to the unique aspects of AI/ML-based SaMD, which will leverage a TPLC approach. The agency has issued an "AI/ML SaMD Action Plan" that outlines its multi-pronged approach, including issuing draft guidance on PCCPs and promoting the harmonization of GMLP. The FDA is actively collaborating with stakeholders to foster innovation while ensuring patient safety. The agency maintains a public list of authorized AI/ML-enabled medical devices to enhance transparency.

Findings
Cybersecurity is an integral part of medical device safety and effectiveness, and manufacturers are responsible for addressing it throughout the entire device lifecycle. The FDA considers a device's cybersecurity as part of its benefit-risk assessment for both premarket and postmarket activities. A lack of robust cybersecurity controls can lead to patient harm, compromised device functionality, and breaches of data privacy. The dynamic nature of cybersecurity threats requires ongoing monitoring, risk management, and timely implementation of mitigation strategies.

Recommendations
Manufacturers should build cybersecurity into devices from the design phase ("secure by design") and conduct a thorough risk analysis to identify and mitigate potential vulnerabilities. Premarket submissions should include comprehensive documentation of the device's cybersecurity controls, a risk management plan, and a plan for postmarket surveillance and response. Manufacturers should establish a robust postmarket surveillance program to monitor for, identify, and address new cybersecurity threats in a timely manner. Clear and informative labeling is essential to help users understand and manage cybersecurity risks.

Regulatory Considerations
The FDA has the authority to take action against devices with inadequate cybersecurity that pose a risk to public health. The agency recommends that manufacturers use the Q-submission process to discuss specific cybersecurity questions related to their device submissions. Compliance with recognized standards and best practices for cybersecurity is strongly encouraged. Manufacturers must report certain cybersecurity incidents to the FDA as part of their postmarket reporting requirements. The FDA collaborates with other government agencies and stakeholders to promote a coordinated approach to medical device cybersecurity.

Findings
The DHCoE works to strategically advance science and evidence for digital health technologies (DHTs).
Key areas of focus include Artificial Intelligence / Machine Learning (AI/ML) in Software as a Medical Device (SaMD), Cybersecurity, Augmented Reality (AR) and Virtual Reality (VR), and Wireless Medical Devices.
The DHCoE develops and publishes Guidances with Digital Health Content and maintains a Digital Health Policy Navigator to provide clarity on regulatory policies.
Digital health technologies are acknowledged as having the potential to facilitate decentralized clinical trial activities and allow for continuous or frequent measurements of clinical features remotely.
Programs and initiatives include the Software Precertification (Pre-Cert) Pilot Program, the Regulatory Accelerator, and the Diagnostic Data Program.
The center is also involved in international harmonization on device regulatory policy and standards.

Recommendations
The DHCoE recommends that stakeholders, including sponsors and DHT manufacturers, engage with the agency early to discuss the use of DHTs in drug development or for decentralized clinical trials (DCTs).
Stakeholders are encouraged to use the Digital Health Policy Navigator tool to assess whether a particular software function meets the device definition and is the focus of FDA oversight.
The DHCoE emphasizes the need for a patient-centered approach for AI/ML-enabled devices that considers issues like usability, equity, trust, and accountability, and promotes transparency.

Regulatory Considerations
The DHCoE's work includes innovating the regulatory paradigm for digital health, moving towards models that may include shifting scrutiny from the pre-market to the post-market phase and focusing on the capability of firms (Software Pre-Cert Pilot Program).
The FDA has committed, as part of PDUFA VII, to activities such as publishing a Framework for the Use of DHTs in Drug and Biological Product Development and establishing a DHT Steering Committee.
The center provides information to help determine the regulatory status of various digital health products, such as Software as a medical device (SaMD), mobile medical applications (MMA), and General Wellness products.
Submissions for products with device software functions must include recommended documentation for the FDA's evaluation of safety and effectiveness.
For questions regarding upcoming premarket submissions, stakeholders are directed to contact the appropriate review division through a Q-submission.

Findings
AI/ML technologies offer dynamic learning capabilities but require careful regulation to ensure safety and effectiveness.
The FDA recognizes that traditional regulatory paradigms may not align with the adaptive nature of AI/ML and is developing frameworks to address this.
Guidance documents, such as the AI/ML SaMD Action Plan and predetermined change control plan (PCCP) recommendations, provide a structured approach for handling software updates.
Collaboration across FDA centers (CDRH, CBER, CDER) facilitates consistent regulatory practices for AI/ML across medical products.
Transparency and real-world data integration are key focuses in regulating AI/ML technologies.

Recommendations
Manufacturers should use FDA's premarket pathways, including 510(k), De Novo, or PMA, for AI/ML-enabled SaMD.
Apply Good Machine Learning Practices (GMLP) during development to ensure algorithm reliability, transparency, and patient safety.
Include a predetermined change control plan (PCCP) in submissions to allow for iterative updates without requiring resubmissions.
Follow lifecycle management practices to maintain AI/ML system performance after deployment.
Engage with FDA early in development to align on appropriate regulatory strategies for novel AI/ML implementations.

Regulatory Considerations
AI/ML-driven SaMD updates may require premarket review, depending on the significance of changes and associated risks.
The FDA has outlined principles for transparency, including clear labeling and documentation of AI/ML system capabilities and limitations.
Guidance documents like the "Good Machine Learning Practice" and "Marketing Submission Recommendations for PCCP" should be followed for compliance.
Collaboration between FDA centers ensures alignment on the use of AI in combination products and broader healthcare applications.
Lifecycle management strategies must account for real-world data to ensure continuous learning and safe AI/ML system updates.

Findings
Misclassification of wakefulness during sleep periods and issues with tracking outside main sleep bouts.
Bias in performance evaluation studies due to limited representation of diverse populations.
Hidden complexities in consumer-grade devices related to data access, fees, privacy, and security.

Recommendations
Carefully interpret study results based on wearable sleep-tracking technology data.
Address biases in study populations by including diverse cohorts.
Ensure proper preprocessing of data from consumer-grade devices.
Avoid inserting personally identifiable information in device settings.
Evaluate issues related to specific populations like minors.

Regulatory Considerations
Complexity of privacy laws across different countries.
Need for strategies to protect personal information in device settings.
Consideration of specific population issues, such as minors, in regulatory frameworks.

Findings
There is widespread confusion among digital health developers regarding the complex and evolving regulatory landscape, with many uncertain about whether their products require regulation or which pathway to pursue. This lack of a clear regulatory strategy acts as a significant barrier to market access, investor confidence, and user trust. The heterogeneity of the digital health sector, coupled with varying international requirements, further complicates the path to market for innovators, hindering the scalability of effective solutions.

Recommendations
Digital health innovators should proactively integrate a tailored regulatory strategy into their core business plan, viewing it as a commercial differentiator rather than a hurdle. Developers are encouraged to utilize resources like DiMe’s regulatory pathway tools to navigate the U.S. and global landscapes effectively. Early and continuous engagement with regulators and collaborative efforts across the industry are essential to ensure products are developed to meet both market needs and regulatory standards, ultimately accelerating the delivery of high-quality digital health solutions to patients.

Regulatory Considerations
A comprehensive policy framework is necessary for the successful integration of digital health technologies, encompassing regulatory authorization, value assessment, and reimbursement. Developers must understand the nuances of different regulatory classifications, such as Software as a Medical Device (SaMD), and their specific evidentiary requirements. Greater international harmonization of regulatory standards is crucial for enabling global scalability. Regulatory bodies should continue to develop agile frameworks that can accommodate the rapid pace of innovation in digital health while ensuring patient safety and product effectiveness.

Findings
The US regulatory landscape is more suitable for promoting innovation in digital health compared to Europe.
Traditional regulatory approaches are not keeping pace with technological advancements.
There is a lack of specific guidance on the use of wearables and software in clinical drug trials.
The US has a more advanced regulatory framework for drug development tools than Europe.

Recommendations
Use approved solutions or consider early qualification of drug development tools.
Engage early with FDA and EMA to define evidentiary standards and regulatory pathways.
Ensure correct regulatory classification of digital tools.
Engage early with regulatory authorities to navigate the regulatory landscape.

Regulatory Considerations
Digital tools must be fit-for-purpose for their intended use.
Sponsors must ensure conformity with GxP and local data privacy and cybersecurity laws.
Data from digital tools must deliver reliable data with tangible clinical benefits.
The context of use drives the benefit-risk assessment and evidentiary criteria for regulatory acceptability.

Findings
Regulatory frameworks differ across regions, with the FDA focusing on digital health technologies and the EU emphasizing digital methodologies under MDR.
Determining whether a DHT qualifies as a medical device depends on its intended use and functionality, necessitating region-specific evaluations.
Health authority engagement can occur through FDA pathways like Critical Path Innovation Meetings (CPIM) and EMA’s Innovation Task Force (ITF).
Verification and validation of DHTs are crucial to ensure reliability and compliance with regulatory requirements in clinical trials.
Cybersecurity and compliance with privacy laws, such as GDPR, are mandatory considerations for DHT implementation.

Recommendations
Engage Regulators Early: Utilize FDA, EMA, or MHRA pathways (e.g., CPIM, ITF) during early development to align on requirements and mitigate risks.
Conduct thorough assessments to determine if a DHT qualifies as a medical device under regional regulations.
Implement robust validation and verification processes to confirm that DHTs are fit-for-purpose in clinical investigations.
Ensure compliance with GDPR, HIPAA, and other relevant data protection standards to safeguard patient information.
Adhere to GCP guidelines, including the ALCOA+ principles, to maintain data credibility and patient safety throughout the trial.

Regulatory Considerations
FDA Regulations: Evaluate DHTs under the FDA’s framework for medical devices, including exemptions under 21 CFR Part 812 and the Digital Health Software Precertification Program.
EU MDR/IVDR: Comply with MDR for medical devices and IVDR for in-vitro diagnostics, ensuring alignment with Annex VIII for software classification.
UK MHRA Guidance: Reference MHRA’s flowcharts for determining if a software qualifies as a medical device and ensure compliance with UK-specific regulatory requirements.
Global Harmonization Efforts: Consider global standards, such as ICH E6 (R2) and GHTF/IMDRF guidelines, to align multinational clinical trials.
Leverage pathways like EMA’s qualification process for novel methodologies and FDA’s DDT qualification program for broader acceptance of digital endpoints.

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
CADe clinical performance studies must address key variables, including reader variability, disease prevalence, and device design differences.
Properly conducted MRMC studies are critical for assessing diagnostic effectiveness, incorporating both unaided and aided reading conditions.
Enriched datasets, while useful for stress testing, must be carefully designed to avoid bias and reflect intended use populations.
The truthing process (establishing reference standards) is essential to validate device performance claims and should be rigorously defined.
The FDA encourages pre-specification of hypotheses, statistical methods, and endpoints to ensure robust and interpretable results.

Recommendations
Design studies with representative patient populations and include diverse subgroups relevant to the device’s intended use.
Use validated statistical methods for MRMC analyses, reporting sensitivity, specificity, and receiver operating characteristic (ROC) curve metrics.
Develop and document a detailed truthing process for establishing reference standards, ensuring consistency and reliability.
Conduct stress testing with enriched datasets to evaluate device performance under challenging conditions but avoid overrepresenting certain subsets.
Submit a complete study protocol and statistical analysis plan, including sample size justification, randomization methods, and scoring techniques.

Regulatory Considerations
CADe devices classified under 21 CFR 892.2050 or 892.2070 must comply with premarket notification requirements, including performance testing and labeling.
Standalone performance assessments may suffice in certain scenarios, but clinical studies are often necessary for substantial equivalence determinations.
Use of foreign clinical data requires justification of its applicability to U.S. populations and medical practice.
FDA expects data integrity controls, such as firewalls and audit trails, to prevent tuning bias in test datasets reused across studies.
The FDA encourages early engagement (e.g., Pre-Submission requests) for feedback on study protocols and regulatory pathways.

Findings
CADe devices must meet classification requirements under 21 CFR 892.2050, including general and special controls, and require FDA clearance through 510(k) submissions.
Each new CADe device or significant modification must demonstrate substantial equivalence to a predicate device in terms of safety and effectiveness.
Robust testing and validation are necessary, including standalone and clinical performance assessments, to evaluate detection accuracy and false positive rates.
Devices with substantive technological differences or new intended uses may require clinical performance assessments.
Enrichment strategies for study populations (e.g., including challenging cases) are encouraged but should not bias performance evaluations.

Recommendations
Clearly describe the CADe algorithm, training datasets, scoring methodologies, and intended use in premarket submissions.
Conduct standalone performance assessments to measure detection accuracy and generalizability.
Compare new devices to predicate devices whenever possible, using consistent datasets and methodologies.
Develop and submit user training materials that address expected device performance, limitations, and appropriate usage scenarios.
Provide comprehensive labeling, including indications for use, directions, warnings, precautions, and performance metrics, to ensure clinician understanding and appropriate application.

Regulatory Considerations
All CADe devices under 21 CFR 892.2050 must comply with 510(k) premarket notification requirements, including general and special controls.
Changes to CADe algorithms or device characteristics must be evaluated for significant impact on safety and effectiveness, potentially requiring new submissions.
Devices with altered indications for use or significant technological differences may need additional clinical performance studies to demonstrate substantial equivalence.
Labeling must comply with 21 CFR Part 801 and provide sufficient information to describe the device, its intended use, and directions for use.
Manufacturers should consult FDA for guidance on substantial modifications or unique device characteristics.