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
Cybersecurity threats in healthcare are increasingly frequent and severe, posing risks to device safety and clinical care.
Many vulnerabilities arise from third-party software components and interconnected device ecosystems.
Legacy devices often lack adequate cybersecurity controls, leading to increased patient and organizational risks.
Cybersecurity risk management processes must integrate safety and security assessments throughout the device lifecycle.
Transparency in device cybersecurity is crucial for enabling safe integration and use by healthcare providers and end users.

Recommendations
Implement a Secure Product Development Framework (SPDF) for comprehensive cybersecurity throughout the product lifecycle.
Include a Software Bill of Materials (SBOM) for all premarket submissions to track software dependencies and vulnerabilities.
Perform robust cybersecurity testing, including penetration testing and vulnerability assessments.
Enhance device labeling with clear cybersecurity-related instructions and risks for users.
Develop a coordinated vulnerability disclosure plan for postmarket cybersecurity management.

Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System regulation requirements, including design controls and risk management.
Compliance with Section 524B of the FD&C Act for cybersecurity of cyber devices.
Submission of SBOMs and detailed security risk management reports for premarket applications.
Provision of cybersecurity information as part of device labeling to prevent misbranding under Section 502 of the FD&C Act.
Integration of security testing and validation as part of the FDA review process.

Findings
Quantitative imaging extracts numerical values from medical data that are subject to systematic error and random variation. The utility of these values depends on well-characterized performance and sufficient user information for interpretation. Performance specifications often change throughout the operating range of a device, such as volumetric reproducibility varying by structure size. Fully automated functions require more robust analytical validation than manual or semi-automated functions because they lack the opportunity for expert user correction. While phantoms serve as high-quality reference standards for ground truth, they are simplifications that may not fully reflect clinical performance.

Recommendations
Manufacturers should provide a detailed technical description of the quantitative imaging function, including the measurand, algorithm training paradigms, and level of automation. Performance specifications should incorporate objective reference values when available to allow for comparisons between subject and predicate devices. A sensitivity analysis should be conducted to determine the impact of sources of error like patient characteristics, image acquisition protocols, and image processing. Labeling must include clear instructions for user-performed quality assurance and specify any limitations where the function has been found ineffective. For automated devices, manufacturers should help users understand scenarios where the function might generate an incorrect output that is not easily identifiable.

Regulatory Considerations
The FDA recommends following a ten-step technical performance assessment process, ranging from defining the measurand to comparing statistical results against pre-defined acceptance criteria. Premarket submissions should include performance data demonstrating that the device meets claims regarding bias, precision, linearity, and limits of quantitation. Uncertainty should be reported in units of the measurand and cover the entire operating range of the function. Manufacturers are encouraged to use the Q-Submission process to address questions regarding regulatory status or specific requirements. Software implementation details should align with existing FDA guidance for the content of premarket software documentation.

Findings
Clinical Evaluation Components: Valid Clinical Association: Demonstrates that the SaMD's outputs are clinically meaningful and relevant to the intended healthcare condition. Analytical Validation: Confirms that the SaMD processes input data accurately and reliably to produce the intended output. Clinical Validation: Assesses whether the SaMD achieves its intended purpose in the target population.
Lifecycle Management: Clinical evaluation is an ongoing process that spans pre-market development and post-market monitoring.
Post-market data collection supports continuous improvement, including refining or expanding the SaMD’s intended use.
Risk-Based Approach: The depth and independence of clinical evaluation depend on the SaMD's risk categorization, with higher-risk categories requiring more rigorous oversight and validation.
Real-World Evidence: SaMD manufacturers are encouraged to use real-world performance data for iterative learning, ensuring alignment with evolving clinical needs.
Independent Review: High-risk SaMD (e.g., those used for critical diagnoses or treatments) benefit from independent evaluation to manage bias and validate clinical evidence.

Recommendations
Pre-Market: Generate evidence through clinical trials, literature reviews, and secondary data analysis to demonstrate valid clinical association and analytical validation.
Use a risk-based framework to determine the rigor of clinical evaluation.
Post-Market: Leverage real-world performance data for continuous improvement and risk management.
Monitor safety, effectiveness, and user interactions, adapting the SaMD definition statement as needed.
Regulatory Submissions: Provide a clear SaMD definition statement, including intended use and core functionality.
Include comprehensive validation data, particularly for high-risk SaMD.
Independent Review: Engage third-party reviewers for high-risk SaMD to enhance transparency and confidence in clinical evaluation.
Quality Management: Integrate clinical evaluation activities into the organization’s quality management system to ensure consistency and compliance.

Regulatory Considerations
SaMD manufacturers must comply with jurisdiction-specific pre-market and post-market requirements, such as informed consent for clinical trials and regulatory submissions for significant changes.
Changes to the SaMD’s intended use or performance measures, based on post-market data, may necessitate updated regulatory approvals.
Independent review requirements vary by jurisdiction but are critical for higher-risk SaMD categories.