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
Collaborative Communities are sustained, multi-stakeholder forums (including patients, industry, academia, and the FDA) dedicated to solving shared challenges in the medical device ecosystem. These communities are not intended to replace formal regulatory mechanisms. They are equipped to perform activities such as:
Developing best practices and strategies.
Generating and evaluating evidence to support novel approaches.
Clarifying ill-defined challenges and generating consensus on definitions.
Addressing issues related to product quality and safety.

Recommendations
The FDA/CDRH does not establish or fund these communities. Instead, the FDA recommends that interested stakeholders convene and lead these groups. The FDA reviews opportunities on a case-by-case basis for participation, considering:
The community's potential public health impact.
Alignment with the CDRH mission, priorities, and resources.
The existence of a formal governance structure, a convener, a plan to measure success, and a mechanism for sustained engagement.

Regulatory Considerations
The FDA's participation in these communities is a strategic priority for advancing regulatory science and fostering responsible medical device innovation. Examples of digital health-related collaborations include those focused on AI/ML, Digital Biomarkers, Digital Health Technologies (DHTs), and Real-World Data (RWD). The outcomes developed by these groups can inform and accelerate the development of science-based solutions to policy and scientific challenges.

Findings
Regulatory inconsistencies across different FDA divisions and international jurisdictions create inefficiencies in the approval process for digital health products.
Lack of alignment between regulatory approval and payer reimbursement requirements poses a significant barrier to commercialization and widespread adoption of digital health innovations.
There are limited regulatory pathways for novel digital health products, including AI-enabled solutions, requiring new frameworks to address iterative software development and real-world data integration.
Existing health technology assessment (HTA) models do not fully accommodate digital health technologies, limiting their inclusion in reimbursement decisions.
Industry stakeholders emphasize the need for clearer guidelines on cloud-based infrastructure, third-party AI model validation, and digital health interoperability.

Recommendations
FDA and international regulatory bodies should improve coordination to establish standardized approval processes and consistent clinical evidence requirements.
New regulatory pathways should be introduced for AI-driven and software-based digital health products, considering their unique lifecycle and iterative development models.
Greater transparency and communication between FDA divisions should be established to ensure consistent decision-making and regulatory interpretations across centers.
Policymakers should prioritize payer alignment strategies, incorporating real-world evidence (RWE) to streamline reimbursement and market access processes.
The digital health industry should collaborate with regulators to create standardized best practices for AI validation, cloud security, and digital biomarker evaluation.

Regulatory Considerations
FDA should clarify the evidentiary standards for AI-enabled medical devices and establish predefined change control plans for software updates.
Digital health products should adhere to globally recognized standards such as HL7 for interoperability and ISO regulations for data security.
Market access pathways must integrate pricing and reimbursement considerations to facilitate the commercial viability of digital health technologies.
The use of real-world data (RWD) should be expanded in regulatory decision-making, supporting the approval and post-market surveillance of digital health innovations.
Regulatory frameworks should be updated to accommodate cloud-based health platforms, addressing issues such as data privacy, operational security, and compliance with HIPAA and GDPR.

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
Regulation exists to ensure the safety and effectiveness of digital health products and to protect the public from potential risks. Engaging with the FDA throughout product development, even though it may seem burdensome, offers valuable benefits such as shared understanding of requirements, faster outcomes, enhanced efficiency in the review process, and built trust with regulators and the public. Working with the FDA is crucial for understanding a device's risk classification and applicable regulatory requirements.

Recommendations
Developers should follow a three-step approach for successful interaction:
EARLY: Start interacting with the agency as early as possible in development, ensuring the intended use and some basic product functionalities are defined.
OFTEN: Maintain communication, especially if new product features, design changes, or changes to how the product will be used occur, to ensure the FDA's advice remains accurate.
TRANSPARENT: Be honest and upfront about the product, evidence, testing plans, and data.
For both "non-written" (meetings) and "written" communications, best practices include:
Preparation: Define the purpose, have specific goals and questions, and prepare a well-planned meeting package (including supporting documentation and data) in advance.
Format and Tone: Select the right type of interaction for the goal, use a professional tone, and communicate clearly, concisely, and with proper formatting.
Follow-up: Respond to all FDA requests promptly and accurately, as delays can result in regulatory action.

Regulatory Considerations
Manufacturers must be familiar with and in compliance with relevant FDA guidance and regulations. Developers should present their argument for a product's regulatory category but must understand that the FDA determines the final regulatory status and obligations. It is critical to avoid providing false or misleading claims or withholding important information, as failure to cooperate or address concerns raised by the FDA can lead to penalties or failure to clear/approve the product for marketing. All communications may be subject to Freedom of Information requests and could become public

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.