
Welcome to the sDHT Adoption Library, featuring NaVi
NaVi is a closed-environment AI research assistant that leverages a carefully curated library of more than 300+ vetted documents, including FDA guidance and industry best practices. NaVi helps you search and explore content across the sDHT Adoption Library and Roadmap using natural language questions.
The Library is intended to serve as a living resource. Content is added periodically as new guidance, standards, and peer-reviewed research are released.
Meet NaVi: Your AI-Powered Research Assistant
Library scope and selection
To ensure high-quality, relevant results, the Library follows a predefined scoping approach:
- Inclusions: FDA guidance, non-commercial standards, and peer-reviewed research (2018–Present) focused on sDHTs being used as measurement tools for medical products in U.S.-based clinical trials.
- Exclusions: Materials from single commercial entities, non-U.S. regulatory bodies (except select EMA guidances with direct U.S. cross-relevance), and conference proceedings, and conference proceedings.
Inclusion in the Library does not imply endorsement, completeness, or regulatory acceptability.
Library scope
Resources in the sDHT Adoption Library are identified using a predefined scoping approach and include publicly available FDA guidance, non-commercial standards and guidance, and peer-reviewed research relevant to sDHT use in U.S.-based clinical trials. Materials from single commercial entities, non-U.S. regulatory bodies, conference proceedings, and studies conducted exclusively outside the United States are excluded; inclusion does not imply endorsement or regulatory acceptability.
Last updated 2026: Library content is reviewed and updated on a periodic basis as new eligible materials become available.
Clinical Decision Support Software (2026)
Clinical Decision Support Software (2026)
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.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
General Wellness: Policy for Low Risk Devices
General Wellness: Policy for Low Risk Devices
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.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
510(k) Premarket Notification
510(k) Premarket Notification
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.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
A Hierarchical Framework for Selecting Reference Measures for the Analytical Validation of Sensor-Based Digital Health Technologies
A Hierarchical Framework for Selecting Reference Measures for the Analytical Validation of Sensor-Based Digital Health Technologies
The quality of evidence for the analytical validation of sensor-based digital health technologies (sDHTs), which is the evaluation of algorithms converting sensor data into a clinically interpretable measure, is often inconsistent and insufficient. The existing V3+ framework codifies the overall evaluation process, which includes verification, usability validation, analytical validation, and clinical validation. To improve the scientific rigor of analytical validation, a hierarchical framework for selecting reference measures is needed because not all potential reference measures are of equal quality. The framework classifies reference measures based on attributes that contribute to reduced measurement variability, with defining and principal measures being the most rigorous due to objective data acquisition and the ability to retain source data.
Recommendations
The proposed framework sequentially moves the investigator through four steps: (1) Compile preliminary information, including the digital clinical measure, context of use (COU), algorithm requirements, and sensor verification evidence . (2) Select an existing reference measure, develop a novel comparator, or identify a set of anchor measures, prioritizing measures with the highest scientific rigor (defining → principal → manual → reported) . (3) Consider the impact of the data collection environment to determine if the analytical validation study can be conducted in the intended use environment with the highest-order measure, or if in-lab validation is necessary, ensuring the results are generalizable . (4) Describe the rationale for key study design decisions to encourage transparency for evaluators, regulators, and payers . Investigators must justify passing over a higher-ranked reference measure, generally only acceptable if the higher-ranked measure poses unacceptable risk or is not applicable to the context of use.
Regulatory Considerations
The principles of the framework for analytical validation apply regardless of the regulatory status of the sDHT (regulated medical device, low-risk general wellness apps, or research product) or its intended use (clinical care or clinical research). The framework is intended to help investigators support the most rigorous claims regarding sDHT performance, which is important for acceptance by evaluators, peer-reviewers, regulators, and payers. The categorization of the digital clinical measure as a digital biomarker or an electronic clinical outcome assessment also does not change the framework's applicability.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
Advancing the Integration of Digital Health Technologies in the Drug Development Ecosystem
Advancing the Integration of Digital Health Technologies in the Drug Development Ecosystem
Findings
The rapid advancement of sensor technology and connectivity has enabled high-frequency, longitudinal monitoring of physiological processes, yet the infrastructure for large-scale deployment remains resource-intensive. Current challenges include a lack of standardized terminology for digital decision-making tools and significant variability in environmental factors that affect sensor performance. Proprietary algorithms and device-specific barriers often hinder the verification and validation processes necessary for regulatory approval. Additionally, there is a distinct gap between granular digital features and their clinical relevance or meaningfulness to patients. Ethical concerns are emerging around data management, patient anxiety in psychiatric contexts, and the responsibility for addressing adverse events detected by remote monitoring.
Recommendations
Stakeholders should develop consensus-driven frameworks for standardized device performance reporting and environmental testing to streamline evaluations for specific contexts of use. The community should adopt a modular approach to data standards that bins requirements by concept of interest and disease-specific needs. Collaborative efforts between patients and developers are essential to bridge the gap between technical metrics and meaningful aspects of health. It is recommended to implement ""bring-your-own-device"" (BYOD) frameworks that ensure data reliability while supporting the inevitable evolution of technology during long-term studies. Researchers and clinicians must be trained in the ethical, legal, and social implications of digital health technology use, particularly regarding data privacy and the management of remote-detected safety signals.
Regulatory Considerations
Digital health technologies used to collect endpoints must meet high evidentiary requirements for validation, with complexity increasing when multiple sensors or complex software are bundled. Regulatory agencies like the FDA and EMA have established pathways for the qualification of drug development tools, including biomarkers and clinical outcome assessments. Integration of new draft guidance on remote health monitoring with existing regulatory workflows is necessary to reduce uncertainty in trial evaluations. While many digital health technologies do not qualify as medical devices unless they have a specific medical purpose, synergies between device risk assessments and drug trial data integrity frameworks should be explored. Early engagement with regulators remains a critical step for obtaining feedback on novel digital endpoints and ensuring the suitability of evidentiary support.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
Advancing the use of sensor-based digital health technologies (sDHTs) for mental health research and clinical practice
Advancing the use of sensor-based digital health technologies (sDHTs) for mental health research and clinical practice
The most promising aspects of mental health for digital measurement are sleep, physical activity, stress, and social behavior, which have the strongest scientific evidence. Core barriers to adoption include high cost and limited access, data privacy concerns, poor technological literacy, and a lack of technology adaptation for specific mental health needs. Essential technology characteristics for "fit-for-purpose" sDHTs include usability, reliable performance, strong data privacy and security, and long battery life.
Recommendations
Research and development should prioritize moving promising measures (sleep, activity, stress, social behavior) to large-scale clinical trials. Algorithms must be refined and clinically validated for mental health indications, and new sensor modalities should be explored. Infrastructure must be developed by creating standards and ontologies for mental health sensor data to ensure interoperability and scalability. To improve access and equity, financial support mechanisms and inclusive, culturally tailored design are critical.
Regulatory Considerations
The report does not provide a separate section for "Regulatory Considerations" but emphasizes that future development and funding should prioritize clinical validation across diverse populations. It notes the importance of a clear understanding of the intended measurement claims and the need for rigorous validation studies to move beyond pilot and feasibility stages to demonstrate real-world clinical utility.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
Artificial Intelligence in Software as a Medical Device
Artificial Intelligence in Software as a Medical Device
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.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations
Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations
AI-enabled medical devices require robust risk assessment to address data drift, bias, and transparency challenges.
The total product lifecycle (TPLC) approach is essential for managing AI-enabled devices, ensuring continuous oversight and updates.
There is a need for improved standardization in AI model validation and performance monitoring to ensure consistency in regulatory submissions.
Effective data management practices, including dataset representativeness and bias control, are critical for AI model development.
Cybersecurity vulnerabilities in AI-enabled medical devices must be proactively addressed to prevent risks to patient safety and data integrity.
Recommendations
AI-enabled device manufacturers should integrate Good Machine Learning Practice (GMLP) principles throughout the device lifecycle.
Marketing submissions should include comprehensive documentation of AI model development, validation, and performance monitoring.
Developers should implement transparency measures, such as model interpretability and explainability, to enhance user trust and understanding.
AI models must undergo rigorous bias evaluation to ensure equitable performance across diverse patient populations.
A predetermined change control plan (PCCP) should be established to allow safe and effective AI model updates post-market without additional FDA submissions.
Regulatory Considerations
FDA encourages early engagement through the Q-Submission Program for AI-enabled device manufacturers.
Compliance with FDA-recognized consensus standards, such as ANSI/AAMI/ISO 14971 for risk management, is recommended.
AI-enabled devices must meet labeling requirements, ensuring that users clearly understand model inputs, outputs, and performance metrics.
Post-market surveillance and continuous monitoring of AI model performance are necessary to ensure ongoing safety and effectiveness.
Cybersecurity measures must be included in regulatory submissions, detailing safeguards against data breaches and unauthorized model modifications.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
Biomarker Qualification Program
Biomarker Qualification Program
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.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
Collaborative Communities: Addressing Health Care Challenges Together
Collaborative Communities: Addressing Health Care Challenges Together
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.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
Condition-Specific Meeting Reports and Other Information Related to Patients’ Experience
Condition-Specific Meeting Reports and Other Information Related to Patients’ Experience
Patient experience data provides critical context for regulatory review by illuminating disease burden, unmet medical needs, and the aspects of a condition that matter most to patients.
A systematic approach is necessary to ensure patient experience data is robust enough for regulatory consideration, moving beyond anecdotal evidence to scientifically rigorous data collection.
Early engagement between sponsors and the FDA is a key factor for successfully incorporating patient perspectives into a drug development program.
The value of patient-reported outcomes (PROs) and other clinical outcome assessments (COAs) is highly context-dependent, varying significantly across different diseases and patient populations.
Recommendations
Drug sponsors should leverage the FDA's meeting process to discuss their strategies for collecting and submitting patient experience data early in the development lifecycle.
Sponsors should utilize the repository of meeting reports as a learning resource to understand best practices and common challenges in patient-focused drug development for specific conditions.
Patient advocacy groups should actively participate in these discussions to ensure the full spectrum of patient experiences is captured and communicated to both regulators and developers.
Researchers should develop and validate novel tools and methodologies for capturing and analyzing patient experience data that are meaningful for both clinical and regulatory purposes.
Regulatory Considerations
Patient experience data is a key component of the benefit-risk assessment, providing evidence that can inform regulatory decisions regarding a drug's approval and labeling.
The FDA's review of patient experience data is guided by a commitment to patient-focused drug development, as mandated by the 21st Century Cures Act and supported by user fee agreements like PDUFA.
The scientific rigor of data collection and analysis is paramount; for patient experience data to be influential, it must meet high standards of validity and reliability.
Transparency is a core principle, and the publication of these meeting reports is intended to provide clear examples of how patient input can be effectively integrated into regulatory submissions.
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.
Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products, Draft, 2025 (FDA)
Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products, Draft, 2025 (FDA)
The document introduces a risk-based credibility assessment framework for establishing and evaluating the credibility of an Artificial Intelligence (AI) model's output when used to support regulatory decisions regarding drug safety, effectiveness, or quality. The framework outlines a 7-step process beginning with defining the question of interest and the Context of Use (COU). Credibility is defined as trust, established through evidence, in the AI model's performance for a particular COU. The credibility assessment is tailored to the AI model risk, which is a combination of model influence (the AI model's evidence contribution relative to other evidence) and decision consequence (the significance of an adverse outcome from an incorrect decision). The document highlights challenges with AI use, including variability in development datasets (training/tuning), the need for methodological transparency due to model complexity, difficulty in quantifying and interpreting uncertainty in model output, and the potential for performance change over time (data drift), which necessitates life cycle maintenance.
Recommendations
Sponsors and interested parties should define the question of interest and clearly define the COU, detailing the AI model's specific role and scope and whether other information will be used. They should assess the AI model risk (low, medium, or high) to ensure that subsequent credibility assessment activities (Step 4) are commensurate with that risk and tailored to the COU. For Step 4, the credibility assessment plan should include a description of the model, model development process (including inputs, architecture, feature selection, and rationale), and data used (training and tuning data). Development data must be deemed fit for use (relevant and reliable) to mitigate issues like algorithmic bias. The plan should also detail the model evaluation process using independent test data and include performance metrics with confidence intervals, an estimate of uncertainty, and a description of model limitations. Early engagement with the FDA is strongly encouraged to discuss model risk and the adequacy of the credibility assessment plan.
Regulatory Considerations
The risk-based credibility assessment framework is intended to help organize and document information for regulatory submissions. The required stringency of assessment activities and the level of documentation should be commensurate with the AI model risk. For AI models whose performance can change over time (e.g., in pharmaceutical manufacturing or postmarketing), sponsors must implement life cycle maintenance plans to monitor performance and manage changes in a risk-based manner. Changes to AI models should be evaluated through the manufacturer's change management system and may require re-execution of parts of the credibility assessment plan. Early engagement can be facilitated through formal meetings (e.g., Pre-IND) or other specialized programs listed in the guidance, such as the Center for Clinical Trial Innovation (C3TI), the Model-Informed Drug Development (MIDD) Paired Meeting Program, and the Emerging Technology Program (ETP) or Advanced Technologies Team (CATT).
Some summaries are generated with the help of a large language model; always view the linked primary source of a resource you are interested in.