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.

Regulatory Considerations
The Premarket Notification (510(k)) database is a critical component of the FDA's regulatory framework for medical devices. Its primary function is to house information on devices that have been cleared through the 510(k) pathway, which is the most common route to market for medical devices in the U.S.

A 510(k) submission's central requirement is to demonstrate "substantial equivalence" to a legally marketed predicate device. This means the new device is as safe and effective as a device already on the market. Clearance of a 510(k) does not denote "approval" in the same way as a Premarket Approval (PMA) application but rather confirms that the device meets the necessary criteria for marketing.

The database provides transparency and serves as an essential resource for manufacturers to identify potential predicate devices for their own submissions. For healthcare providers, patients, and researchers, it offers a way to verify the regulatory status and clearance basis for a specific device.

Findings
The traditional process of evaluating biomarkers within the context of a single drug development program is inefficient and creates uncertainty for sponsors. This case-by-case approach leads to redundant efforts, slows down the development of novel therapies, and hinders the broad adoption of promising scientific tools. There is a clear need for a centralized, collaborative pathway to formally validate biomarkers, which can de-risk drug development, encourage innovation, and make the process more predictable and cost-effective for all stakeholders.

Recommendations
Drug developers, academic researchers, and other stakeholders should proactively engage with the FDA through the formal Biomarker Qualification Program to validate biomarkers for specific contexts of use. It is recommended to form public-private partnerships and other collaborations to pool resources and data, which strengthens the evidence package for a biomarker's utility. Developers should use the qualification process to establish a biomarker's value early, making it a publicly available and reliable tool that can accelerate the development of multiple drug products.

Regulatory Considerations
The Biomarker Qualification Program provides a distinct regulatory pathway for establishing a biomarker's validity for a specific Context of Use (COU), separate from an individual Investigational New Drug (IND) or New Drug Application (NDA). The process involves a three-stage submission and review cycle: the Letter of Intent, the Qualification Plan, and the Full Qualification Package. Once qualified, a biomarker is publicly listed and can be incorporated into multiple drug development programs without the need for sponsors to re-submit and re-justify the validation data for that specific COU, streamlining subsequent regulatory reviews.

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
Cytokine Release Syndrome (CRS) is a common and potentially life-threatening adverse event of immunotherapies, particularly in Oncology, complicating patient care and increasing healthcare costs. Standard-of-care inpatient monitoring for CRS is manual, intermittent, costly, and restrictive, providing an incomplete view of the syndrome’s development and progression. The use of Digital Health Technologies (DHTs) for continuous, remote monitoring of vital signs (like heart rate, respiratory rate, skin temperature, SpO2, and activity) can capture early indicators of CRS up to two hours earlier than standard episodic monitoring. This ability to collect multivariate continuous data is valuable for informing robust model development for CRS risk prediction.

Recommendations
Investigators should deploy DHTs available today to monitor vital signs and symptoms currently observed in the hospital setting, but in an outpatient or home environment. The goal is to develop Early Warning Products that assess the probability of developing CRS, providing clinical decision support. Product developers should follow a strategic roadmap that outlines milestones for building products that are clinically relevant and commercially viable. Researchers should use a common set of digital clinical measures to gather high-quality datasets and ensure comparability across studies to build more robust predictive models. Predictive algorithms should be built on a robust reference measure for analytical validation and be clinically validated with sufficient data.

Regulatory Considerations
The resources are designed to help developers build products that are clinically appropriate, regulatory-acceptable, and commercially viable. Future regulatory submissions for CRS de-risking products will benefit from aligning with this industry-wide dialogue that is being built in collaboration with the FDA. Developing a robust CRS safety biomarker could enhance the safety profile of clinical trials, increase trial access, and streamline regulatory decision-making, possibly through a qualification pathway. Products that aim for a higher level of autonomy, such as a Diagnostic that redefines current CRS grading classes, may require very high clinical evidence and likely stringent regulatory review.

Findings
Clinically Acceptable Performance: A clinical study demonstrated that the weekly AFib burden estimates from the Apple AFib History Feature were in close agreement with a reference ECG patch, with an average difference of just 0.67%. The vast majority of measurements had paired differences within ±10% of the reference device.
Generalizable Across Subgroups: The device's accuracy was similar across various subgroups, including different sexes, races, ages, and skin tones.
Performance Post-Ablation is Uncertain: In a small subgroup of patients with a prior cardiac ablation, the device's performance, while still strong, showed slightly more variability and exceeded a pre-specified acceptance criterion. The study was not designed or powered to demonstrate equivalent performance in this specific group.
Technical Limitations Exist: The feature only provides a retrospective weekly estimate and does not give specific timestamps or durations of AFib episodes. It also does not detect other atrial tachyarrhythmias, like atrial flutter.

Recommendations
Appropriate Use: The document implicitly recommends using the tool precisely within its qualified context of use—as a secondary, not primary, endpoint for comparing AFib burden between study arms in cardiac ablation device trials.
Supplemental Data Collection: For studies involving patients who have had a prior ablation, it would be beneficial to assess the tool alongside other methods of determining AFib burden to better characterize its performance in this population.
Define Study-Specific Endpoints: Investigators using the tool are responsible for defining and justifying their specific study designs and what constitutes a clinically significant reduction in AFib burden.

Regulatory Considerations
MDDT Qualification: The Apple AFib History Feature is officially qualified by the FDA as a Medical Device Development Tool (MDDT), which reduces the burden on device developers, as they no longer need to independently justify its methodology for collecting weekly AFib burden estimates in their clinical studies.
Secondary Endpoint Only: A key limitation for its regulatory use is its qualification only as a secondary endpoint. It cannot, by itself, be used to evaluate the primary safety and effectiveness of cardiac ablation devices. This is partly because FDA typically requires the inclusion of any atrial tachyarrhythmia (not just AFib) for defining ablation success in pivotal studies.
Not a Replacement for Primary Endpoints: The tool's utility is intended to provide supplemental data and help better understand post-treatment AFib burden; it is not meant to replace more clinically well-defined primary endpoints.

Findings
The development and evaluation of medical devices require scientifically plausible and reliable tools for collecting data to support regulatory submissions. A lack of standardized, pre-vetted tools can lead to inefficiencies and unpredictability in the device development and review process. The qualification of development tools can be applied across a wide range of device areas, including cardiovascular, neurology, imaging, and cybersecurity. The evidence required for tool qualification must be robust enough to support its intended context of use.

Recommendations
Tool developers, medical device sponsors, research organizations, and academic institutions are encouraged to voluntarily submit proposals to the MDDT program to qualify their tools. Submissions should include a detailed description of the tool, a clearly defined context of use (COU), specific performance criteria, and a comprehensive plan for collecting evidence to validate the tool's performance and scientific plausibility. Collaboration in developing tools and supporting evidence is recommended to pool resources and increase the acceptance of qualified tools.

Regulatory Considerations
The MDDT program is a formal regulatory mechanism for the FDA to qualify tools that can be used to support assessments of medical device safety, effectiveness, or performance. Once a tool is qualified for a specific context of use, the FDA accepts assessments from that tool in support of regulatory submissions without needing to re-evaluate the tool's suitability. The program recognizes four main categories of tools: Non-clinical Assessment Models (NAM), Biomarker Tests (BT), Clinical Outcome Assessments (COA), and an "Other" category for tools that do not fit the primary classifications.

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
Diverse Pathways to Market Exist: The case studies demonstrate there is no single "right" way to approach the FDA; successful strategies are highly varied and include De Novo requests, 510(k) clearances, and leveraging established pathways for new indications.
Early FDA Engagement is Crucial: A consistent theme across the successful case studies is the value of engaging with the FDA early and often. This collaborative approach helps de-risk the development process, clarify evidentiary requirements, and build trust.
"Drug-like" Evidence Can Be a Differentiator: For novel software-based interventions, particularly digital therapeutics, generating a robust body of evidence similar to that of a pharmaceutical (i.e., randomized controlled trials) is a key strategy for gaining regulatory and commercial success.
Platform-Based Approaches are Emerging: Companies are finding success by moving from single-product solutions to integrated platforms that can monitor multiple health aspects, which requires a more holistic regulatory strategy.

Recommendations
Leverage Pre-Submission (Pre-Sub) Meetings: Sponsors are strongly encouraged to use the Q-Submission program to gain valuable, early feedback from the FDA on their validation plans and overall regulatory strategy.
Build a Multi-faceted Commercialization Plan: Regulatory clearance is only one step. The case studies recommend developing a comprehensive strategy that considers market access, reimbursement, and payer engagement from the outset.
Address Underserved Markets: The examples highlight opportunities for innovation in underserved areas, such as pediatrics and behavioral health, where DHTs can fill significant gaps in care.
Innovate on Evidence Generation: Sponsors should be prepared to innovate not just in their technology, but also in their approach to clinical evidence, tailoring their trial designs to best demonstrate the unique value of their digital product.

Regulatory Considerations
Understand the Risk Classification: The regulatory pathway for a DHT is determined by its intended use and associated risk level. Sponsors must correctly classify their device to determine if a 510(k), De Novo, or other pathway is appropriate.
AI/ML Devices Have Unique Needs: For products incorporating artificial intelligence or machine learning, sponsors must address specific regulatory considerations, such as predetermined change control plans (PCCPs), to manage algorithm updates post-market.
Interoperability is a Key Factor: For devices intended to be part of a connected health ecosystem (e.g., automated insulin dosing systems), demonstrating interoperability and cybersecurity is a critical component of the regulatory submission.

Findings
There is a lack of systematic approaches to guide the processes of collecting, interpreting, analyzing, and translating health data from wearables into digital biomarkers.
Most wearables have fixed measurement capabilities, limiting their translation to digital biomarkers.
Current guidance lacks study design and conduct elements that involve all stakeholders in an iterative approach for implementing digital biomarkers in practice.
Researchers and health professionals often rely on limited guidance for using wearable data in clinical practice and chronic disease management.

Recommendations
Implement the DACIA framework to provide interdisciplinary guidance on using wearable sensor data for digital biomarker development.
Focus on participant needs as a crucial factor for study success, applicable to both short and long-duration studies.
Involve relevant stakeholders in each key step of the DACIA framework in an iterative manner.
Apply the DACIA framework to explore digital biomarkers using various devices or signal measurements.
Reduce participant burden through support and continuous feedback.

Regulatory Considerations
Not mentioned

Findings
Product development firms are hesitant to increase DHT use despite regulatory support.
Conventional hardware-based technologies are preferred over newer digital tools.
Operational barriers contribute to the low adoption of DHTs in product development trials.

Recommendations
Reduce operational barriers to facilitate DHT adoption.
Provide additional regulatory clarity to encourage DHT use.
Encourage the incorporation of more DHTs and patient-centric endpoints in clinical trials.

Regulatory Considerations
The FDA's guidance on DHT use is evolving and not yet fully formalized.
There is a need for harmonization between US and non-US regulatory agencies.
The impact of recent regulatory support may take years to be fully realized.