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
General wellness products are defined by two factors: they are intended only for general wellness use and present a low risk to user safety. The FDA categorizes wellness uses into those relating to a general state of health (e.g., weight management, physical fitness, sleep) and those relating to chronic diseases where lifestyle choices are well-accepted to play a role in health outcomes. Products are not considered low risk if they are invasive, implanted, or involve technologies like lasers or radiation that require specific regulatory controls. Software functions intended for maintaining a healthy lifestyle that are unrelated to the diagnosis or treatment of a disease are explicitly excluded from the statutory definition of a medical device.

Recommendations
Manufacturers should ensure that claims for general wellness products are limited to sustaining or improving general health functions or encouraging healthy lifestyle choices for living well with chronic conditions. Disease-related claims must be supported by peer-reviewed scientific publications or official statements from healthcare professional organizations. Labeling and marketing communications must be consistent with and not exceed the product's stated intended use. For products using non-invasive sensing to estimate physiologic parameters, manufacturers should validate these outputs if they mimic values used clinically. If a product includes notifications to see a doctor, these should not name specific diseases or characterize outputs as pathological.

Regulatory Considerations
For products meeting the low-risk general wellness criteria, the FDA does not intend to enforce requirements such as registration and listing, premarket notification, or Quality Management System regulations. The FDA may coordinate with the Consumer Product Safety Commission to determine jurisdiction over specific products. If a product targets the diagnosis, screening, or management of a disease through alerts or clinical thresholds, it is generally not considered a general wellness product and is subject to standard medical device regulations. Industry members may contact the Digital Health Center of Excellence or use the Q-Submission process to discuss alternative approaches or clarify the regulatory status of a specific product.

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
Enhanced documentation is required for high-risk device software where flaws could result in serious injury or death.
Risk management plans should include robust risk assessments, including residual risk evaluations.
Verification and validation activities are critical to confirm software functionality and mitigate risks.
The lack of traceability between software design and requirements can undermine device safety and effectiveness.
Unresolved software anomalies must be carefully documented and justified based on a risk assessment.

Recommendations
Use a risk-based approach to determine whether basic or enhanced documentation levels are required for premarket submissions.
Include comprehensive risk management documentation, detailing hazard identification, risk control measures, and residual risk evaluations.
Provide detailed system and software architecture diagrams, highlighting relationships between modules and external systems.
Document unresolved software anomalies and justify their impact on safety and effectiveness using a risk-based rationale.
Align software development, configuration management, and maintenance practices with FDA-recognized standards like ANSI/AAMI/IEC 62304.

Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System regulations, emphasizing design controls and risk management.
Submission of risk management files and unresolved software anomalies as part of premarket documentation.
Use of system and software architecture diagrams to demonstrate software functionality and risk mitigation.
Implementation of cybersecurity measures as part of software validation and risk management processes.
Documentation of premarket changes and interactions between device functions and external systems, particularly in multi-function devices.

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
AI-DSFs undergo iterative improvements, necessitating a structured framework for modifications to ensure safety and effectiveness.
PCCPs enable manufacturers to streamline modifications by avoiding repeated marketing submissions, reducing regulatory burden.
Critical elements of a PCCP include data management practices, re-training protocols, performance evaluation, and user update procedures.
Comprehensive risk management and transparency are essential to address potential biases and maintain user trust.
Certain modifications, such as those significantly affecting safety or effectiveness, may still require a new marketing submission.

Recommendations
Structure PCCPs with a clear description of planned modifications, a detailed modification protocol, and a robust impact assessment.
Include methods for data collection, re-training, and performance evaluation aligned with quality system regulations.
Specify user update procedures to communicate changes transparently and ensure safe device use.
Address cybersecurity risks and bias mitigation strategies in modification protocols.
Use the FDA Q-Submission Program to discuss PCCPs prior to submitting marketing applications for AI-DSFs.

Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System Regulations, including design controls and risk management.
PCCPs must include modifications that would otherwise require a PMA supplement or new 510(k) submission.
Modifications implemented under PCCPs must conform to FDA-reviewed protocols and be documented in the device master record.
Transparency to users via device labeling updates and public summaries of authorized PCCPs is required.
Modifications outside the scope of an authorized PCCP or deviations from the protocol require new FDA marketing submissions.

Findings
OTS software introduces unique risks due to its general-purpose design and lack of lifecycle control by medical device manufacturers.
Comprehensive testing and risk management are essential to mitigate safety hazards associated with OTS software in medical devices.
Regular updates and maintenance are critical for managing obsolescence and ensuring long-term safety and effectiveness of OTS components.
Networking and interoperability of OTS software pose additional risks related to data integrity, cybersecurity, and scalability.
Enhanced documentation is required for high-risk devices incorporating OTS software, especially those involving AI or ML functionalities.

Recommendations
Provide comprehensive descriptions of OTS software, including version details and system specifications.
Conduct thorough risk assessments and include mitigation plans in premarket submissions.
Perform rigorous testing, including integration and regression testing, for OTS software components.
Establish mechanisms for continued maintenance, support, and version control of OTS software.
Ensure that device labeling includes warnings and specifications related to OTS software compatibility and restrictions.

Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System regulations, including design controls and purchasing controls for OTS software.
Submission of a risk management file and traceability documentation linking risks, design requirements, and testing outcomes.
Compliance with premarket submission requirements, including 510(k), IDE, and PMA applications, as applicable.
Use of device labeling to communicate hardware and software compatibility and restrictions to users.
Development of beta testing and investigational plans for clinical studies involving OTS software.

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.

Findings
Non-Device-MDDS functions are excluded from FDA regulation, provided they do not interpret or analyze medical data.
Device-MDDS hardware functions are still considered devices but are subject to enforcement discretion.
FDA clarified that functions involving analysis, alarms, or active patient monitoring fall under regulatory oversight due to higher risk.
The guidance addresses scenarios involving multiple function device products with both device and non-device functions.
General-purpose IT infrastructure used for data transfer, storage, or display is not regulated as a medical device.

Recommendations
Clearly delineate whether software functions qualify as Non-Device-MDDS or Device-MDDS under section 520(o)(1)(D) of the FD&C Act.
Avoid adding analysis, interpretation, or real-time monitoring capabilities to Non-Device-MDDS to maintain exemption from regulatory oversight.
For Device-MDDS, adhere to existing classification regulations but note FDA’s intent not to enforce regulatory controls for most low-risk use cases.
Developers of multiple function devices should assess how non-device functions impact the safety and effectiveness of device functions.
Consult FDA guidance on "Multiple Function Device Products" for more details on managing products with both device and non-device functions.

Regulatory Considerations
Non-Device-MDDS functions are not subject to FDA oversight under section 520(o)(1)(D) of the FD&C Act.
FDA does not enforce premarket notification, registration, or quality system requirements for Device-MDDS hardware functions.
Active patient monitoring and alarm systems remain within the scope of FDA regulation due to their higher risk profiles.
The regulatory status of multiple function devices depends on how non-device and device functions interact.
Developers must avoid modifying data or controlling other medical devices unless explicitly regulated as such.

Findings
FDA oversight focuses on software functions that meet the definition of a medical device under section 201(h) of the FD&C Act and pose risks to patient safety.
Many software functions are exempt from regulation if they do not meet the medical device definition or pose minimal risk.
Mobile medical apps that transform general-purpose platforms into regulated devices (e.g., by using sensors or attachments) fall under FDA’s regulatory scope.
Certain apps, like those for general wellness or simple medical calculations, are subject to enforcement discretion due to their low risk.
Manufacturers are encouraged to adopt quality systems to ensure software safety and effectiveness throughout the product lifecycle.

Recommendations
Clearly identify the intended use of software functions and ensure they align with definitions for medical devices under the FD&C Act.
Adopt a robust Quality System (QS) to ensure software safety and mitigate risks.
For mobile medical apps that transform general-purpose platforms into devices, ensure compliance with FDA classification and regulatory requirements.
Distinguish between software functions for general wellness and those with patient-specific analysis to assess regulatory oversight needs.
Engage with FDA early in the development process to clarify requirements for new or novel device software functions.

Regulatory Considerations
Device software functions that meet FDA’s medical device definition and pose safety risks are subject to classification (Class I, II, or III) and regulatory requirements.
FDA exercises enforcement discretion for low-risk software functions, such as apps for medication reminders or wellness tracking.
Mobile apps used solely for administrative purposes or patient education generally do not meet the definition of a medical device.
Developers of regulated software must comply with labeling, quality system, and premarket submission requirements, depending on classification.
Apps that collect, transfer, or display medical device data without modifying it may fall under MDDS guidance and are typically exempt from rigorous regulation.