
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.
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.
Has FDA’s Drug Development Tools Qualification Program Improved Drug Development?
Has FDA’s Drug Development Tools Qualification Program Improved Drug Development?
Long and Unpredictable Timelines: The COA Qualification Program is lengthy and unpredictable, with an average qualification time of six years. Nearly half of all submissions experience review times that exceed the FDA's own published targets.
Low Qualification and Uptake: As of October 2024, only seven COAs (8.1% of those listed) have been qualified, and only three of those have been used to support the benefit-risk assessment of new medicines. No COAs submitted after the passage of the 21st Century Cures Act in 2016 have been qualified.
Limited Regulatory Impact: Qualified COAs are consistently designated for "exploratory use" and have never been accepted as a primary endpoint in a clinical trial. In contrast, some non-qualified COAs have been used as key endpoints and included in drug labels, questioning the utility of the formal qualification pathway.
Discrepancy Between FDA Centers: There is a notable difference in how COAs are qualified between the drug (CDER/CBER) and device (CDRH) centers. The Kansas City Cardiomyopathy Questionnaire (KCCQ) was qualified by CDRH for use as a primary or secondary endpoint, while for drugs, it was only qualified as an "exploratory" measure.
Recommendations
Increase Transparency of Timelines: The FDA should publish its actual, historical review timelines for COA qualification so that drug developers can better plan and integrate these tools into their development programs.
Clarify the Use of Qualified COAs: The FDA should clearly articulate how and when qualified COAs can be used as primary or secondary endpoints to support regulatory decision-making and provide a clear pathway for updating a COA's status from "exploratory" to a key endpoint.
Publish Best Practices: Both sponsors and the FDA should be encouraged to publish their experiences with the qualification program to share best practices and learnings with the broader drug development community.
Create a List of Accepted Endpoints: The FDA should create and maintain a public list of qualified COAs that can be used as surrogate endpoints to support drug approval decisions, thereby increasing their utility and adoption.
Regulatory Considerations
"Qualified as a Measure" Ambiguity: The FDA's practice of qualifying COAs as "measures" for "exploratory use" creates regulatory uncertainty for sponsors, as it implies that significant additional evidence is still needed before the tool can be relied upon for a key endpoint.
Qualification is Not Required: The analysis shows that COAs can be accepted for regulatory decision-making and included in drug labels without going through the formal qualification program, suggesting that qualification is not a prerequisite for use as a reliable endpoint.
Unclear Path to Endpoint Progression: The current DDT guidance does not specify the process for upgrading a COA's qualification status (e.g., from exploratory to a primary endpoint) after additional data has been generated, which hinders its evolution and broader use.
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.
Tepid Uptake of Digital Health Technologies in Clinical Trials by Pharmaceutical and Medical Device Firms
Tepid Uptake of Digital Health Technologies in Clinical Trials by Pharmaceutical and Medical Device Firms
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.
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.
Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
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.
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.
How Much Evidence Is Enough? Research Sponsor Experiences Seeking Regulatory Acceptance of Digital Health Technology-Derived Endpoints
How Much Evidence Is Enough? Research Sponsor Experiences Seeking Regulatory Acceptance of Digital Health Technology-Derived Endpoints
A need for additional regulatory clarity specific to DHT-derived endpoints.
The official clinical outcome assessment qualification process is impractical for the biopharmaceutical industry.
A lack of comparator clinical endpoints.
A lack of validated DHTs and algorithms for concepts of interest.
A lack of operational support from DHT vendors.
Recommendations
Engage key stakeholders early.
Incorporate DHT-derived endpoints in early-phase trials and observational studies.
Invest in COA development initiatives.
Engage technology manufacturers early in the development process.
Regulatory Considerations
The EMA published a Q&A document on DHT use in clinical trials.
The FDA released guidance on collecting patient data remotely using DHTs.
The FDA established the Digital Health Center of Excellence to facilitate early regulatory engagement.
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.
Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions
Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions
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.
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.
Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program
Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program
Pre-Submissions (Pre-Subs) allow submitters to obtain FDA feedback on specific questions before submitting formal IDEs, 510(k)s, PMAs, or other applications. Early feedback can improve submission quality and streamline the review process.
Submission Issue Requests (SIRs) provide a mechanism for addressing issues raised in FDA hold letters (e.g., 510(k) deficiencies) to help expedite resolutions.
Study Risk Determinations help sponsors clarify whether clinical studies are significant risk (SR), non-significant risk (NSR), or exempt from IDE regulations.
Informational Meetings are non-feedback sessions aimed at familiarizing FDA staff with new devices or sharing updates on ongoing development.
The program encourages timely submissions, including supplements for ongoing discussions and amendments to update materials.
Recommendations
Clearly define the purpose and goals of the Q-Sub in the submission to facilitate effective FDA review.
Include specific, well-formulated questions that focus on a limited number of topics to ensure actionable feedback.
For Pre-Subs, align planned testing and submissions with FDA guidance and include detailed device descriptions, testing protocols, and relevant background information.
Use SIRs to discuss proposed solutions to deficiencies raised in FDA hold letters, focusing on timely resolution.
Draft and submit meeting minutes promptly (within 15 days of meetings) to ensure accurate documentation of FDA feedback.
Regulatory Considerations
Submitters should adhere to the timelines specified for different Q-Sub types, including 70 days for Pre-Sub feedback or 21 days for SIRs submitted promptly after a hold letter.
Q-Subs should include all relevant regulatory history and references to prior FDA communications to streamline the review process.
FDA feedback through the Q-Sub program is non-binding and based on the information available at the time; subsequent submissions must align with the provided feedback to maintain consistency.
Informational Meeting requests should clearly state that feedback is not expected and may be used to track interactions outside other formal Q-Sub types.
Confidentiality of Q-Subs is maintained in compliance with FDA’s disclosure regulations and the Freedom of Information Act (FOIA).
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.
Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data – Premarket Notification [510(k)] Submissions
Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data – Premarket Notification [510(k)] Submissions
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.
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.
Technical Performance Assessment of Quantitative Imaging in Radiological Device Premarket Submissions
Technical Performance Assessment of Quantitative Imaging in Radiological Device Premarket Submissions
Findings
Quantitative imaging extracts numerical values from medical data that are subject to systematic error and random variation. The utility of these values depends on well-characterized performance and sufficient user information for interpretation. Performance specifications often change throughout the operating range of a device, such as volumetric reproducibility varying by structure size. Fully automated functions require more robust analytical validation than manual or semi-automated functions because they lack the opportunity for expert user correction. While phantoms serve as high-quality reference standards for ground truth, they are simplifications that may not fully reflect clinical performance.
Recommendations
Manufacturers should provide a detailed technical description of the quantitative imaging function, including the measurand, algorithm training paradigms, and level of automation. Performance specifications should incorporate objective reference values when available to allow for comparisons between subject and predicate devices. A sensitivity analysis should be conducted to determine the impact of sources of error like patient characteristics, image acquisition protocols, and image processing. Labeling must include clear instructions for user-performed quality assurance and specify any limitations where the function has been found ineffective. For automated devices, manufacturers should help users understand scenarios where the function might generate an incorrect output that is not easily identifiable.
Regulatory Considerations
The FDA recommends following a ten-step technical performance assessment process, ranging from defining the measurand to comparing statistical results against pre-defined acceptance criteria. Premarket submissions should include performance data demonstrating that the device meets claims regarding bias, precision, linearity, and limits of quantitation. Uncertainty should be reported in units of the measurand and cover the entire operating range of the function. Manufacturers are encouraged to use the Q-Submission process to address questions regarding regulatory status or specific requirements. Software implementation details should align with existing FDA guidance for the content of premarket software documentation.
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 development of an evidence dossier to support the use of mobile sensor technology for clinical outcome assessments in clinical trials
Considerations for development of an evidence dossier to support the use of mobile sensor technology for clinical outcome assessments in clinical trials
Mobile sensors provide unique opportunities for objective, real-world data collection but face challenges in achieving regulatory acceptance due to a lack of standardization and validation frameworks.
A comprehensive evidence dossier must address three key components: verification, analytical validity, and clinical validation, to ensure endpoints are fit-for-purpose.
Demonstrating content validity is critical, especially when endpoints are not directly measuring meaningful aspects of health but infer these through related concepts.
Early engagement with regulatory bodies (e.g., FDA, EMA) is recommended to align expectations and address evidentiary gaps.
Usability and feasibility research are vital to ensure patient compliance and data quality in real-world applications.
Recommendations
Develop Comprehensive Dossiers: Include sections on endpoint definition, concept of interest, content validity, clinical validation, analytical validation, and implementation details to support regulatory review.
Ensure Content Validity: Demonstrate a clear relationship between sensor-derived endpoints and meaningful health outcomes, supported by literature, patient interviews, and expert consensus.
Engage with Regulators Early: Discuss the proposed endpoint and its context of use with regulatory agencies to ensure alignment and identify potential challenges.
Standardize Validation Processes: Use rigorous methods for verification, analytical validation, and construct validation to establish the reliability and accuracy of sensor technologies.
Promote Collaboration: Share validation data and methodologies across stakeholders to reduce redundancy and accelerate the adoption of mobile sensor endpoints.
Regulatory Considerations
Verification of Sensor Technologies: Demonstrate that sensors produce accurate, reliable, and consistent raw data under various conditions, including environmental variability.
Analytical Validation: Show that firmware and algorithms used to process raw data maintain high technical performance and align with regulatory standards.
Clinical Validation: Provide evidence that sensor-derived data reliably measure the concept of interest and are responsive to meaningful clinical changes.
Context of Use: Clearly define the intended application of the endpoint, including target populations, trial design, and labeling claims, to guide regulatory evaluation.
Data Security and Privacy: Ensure compliance with data protection regulations, such as 21 CFR Part 11, to secure patient data during collection, transmission, and storage.
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.