
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.
Cybersecurity in Medical Devices Frequently Asked Questions (FAQs)
Cybersecurity in Medical Devices Frequently Asked Questions (FAQs)
Cybersecurity is an integral part of medical device safety and effectiveness, and manufacturers are responsible for addressing it throughout the entire device lifecycle. The FDA considers a device's cybersecurity as part of its benefit-risk assessment for both premarket and postmarket activities. A lack of robust cybersecurity controls can lead to patient harm, compromised device functionality, and breaches of data privacy. The dynamic nature of cybersecurity threats requires ongoing monitoring, risk management, and timely implementation of mitigation strategies.
Recommendations
Manufacturers should build cybersecurity into devices from the design phase ("secure by design") and conduct a thorough risk analysis to identify and mitigate potential vulnerabilities. Premarket submissions should include comprehensive documentation of the device's cybersecurity controls, a risk management plan, and a plan for postmarket surveillance and response. Manufacturers should establish a robust postmarket surveillance program to monitor for, identify, and address new cybersecurity threats in a timely manner. Clear and informative labeling is essential to help users understand and manage cybersecurity risks.
Regulatory Considerations
The FDA has the authority to take action against devices with inadequate cybersecurity that pose a risk to public health. The agency recommends that manufacturers use the Q-submission process to discuss specific cybersecurity questions related to their device submissions. Compliance with recognized standards and best practices for cybersecurity is strongly encouraged. Manufacturers must report certain cybersecurity incidents to the FDA as part of their postmarket reporting requirements. The FDA collaborates with other government agencies and stakeholders to promote a coordinated approach to medical device cybersecurity.
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.
Delivering regulatory impact from consortium-based projects
Delivering regulatory impact from consortium-based projects
Findings
Establishing cross-sector consortia does not guarantee success without a unified objective and stakeholder buy-in. A neutral, independent facilitator is a key element for successful governance in many collaborative platforms. Many consortia lack consistent methods for storing critical data, meeting minutes, and regulatory briefing packages, which creates barriers after project completion. Regulatory success depends heavily on the early development of a strategy that defines the necessary evidence to validate innovative methodologies. Successful examples include the qualification of biomarkers for polycystic kidney disease and type 1 diabetes, as well as imaging measures for Alzheimer’s disease.
Recommendations
Consortium members should develop an initial regulatory strategy during the project scoping and planning phases. Teams must explicitly define the context of use for any proposed tool to articulate exactly what decisions the output will inform. A robust data strategy should be implemented early, including formal agreements for data use, standardization, and sharing that remain in place in perpetuity. Consortia must prioritize sustainability plans to ensure data and active databases remain available for research and regulatory use after funding expires. Projects should integrate regulatory science expertise from the start to cover both EU and US frameworks.
Regulatory Considerations
Regulators require individual patient-level data that is fully curated, standardized, and presented through formal submissions like qualification applications. Formal regulatory endorsement ensures a tool can be trusted for consistent interpretation in drug development and marketing authorization evaluations. Early engagement with agencies such as the FDA and EMA is essential to gain feedback on novel methodologies and align study designs with regulatory expectations. Specific pathways like the EMA Qualification of Novel Methodologies and the FDA Qualification Process for Drug Development Tools should be utilized. Regulatory qualification may require ongoing access to databases to support the long-term use of the methodology.
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.
Drug Development Tool (DDT) Qualification Programs
Drug Development Tool (DDT) Qualification Programs
The central principle of the DDT Qualification Programs is to create a formal pathway for the FDA to conclude that a specific tool is well-suited for a particular Context of Use (COU) in drug development. A key finding, as reflected in the program's design, is that qualification de-risks drug development by allowing a tool to be used in any regulatory submission for its qualified COU without needing to be re-validated each time. The program is designed to foster stakeholder collaboration, encouraging the development of tools that can benefit the entire research community, thereby reducing the burden on individual sponsors.
Program Activities (Recommendations)
The structure of the DDT programs serves as a series of recommendations for tool developers:
Engage Early and Collaboratively: The programs are designed to provide a framework for early and ongoing scientific collaboration with the FDA to facilitate the development of new tools.
Follow a Staged Process: Developers are guided through a multi-stage process, typically involving a Letter of Intent, a Qualification Plan, and a Full Qualification Package, to systematically build the evidence needed for qualification.
Seek Public Qualification: The ultimate recommendation is to achieve public qualification for a DDT, which makes the tool available for broad use and integrates it into the regulatory review process, expediting future drug development.
Regulatory Considerations
The DDT Qualification Programs are a formal regulatory framework established under the 21st Century Cures Act. A "qualified" DDT has a specific regulatory status; it can be relied upon to have a specific interpretation and application in drug development and regulatory review for its stated Context of Use (COU). This qualification is publicly available and allows the tool to be included in Investigational New Drug (IND), New Drug Application (NDA), or Biologics License Application (BLA) submissions without the FDA needing to reconsider its suitability. This creates a more efficient and predictable regulatory compliance pathway for sponsors who use the qualified tool.
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.
Electronic Submission Template for Medical Device Q-Submissions
Electronic Submission Template for Medical Device Q-Submissions
This guidance establishes that the eSTAR platform will become the mandatory format for the electronic submission of medical device Pre-Submissions to the FDA. A key principle is that a properly completed eSTAR submission is considered a 'complete' submission, which allows it to bypass the traditional Refuse-to-Accept (RTA) process and instead undergo a more focused technical screening within 15 days. The structure of the eSTAR template is designed to align with the FDA's internal review memo, creating a more efficient and consistent review process. The guidance also makes it clear that while eSTAR use is currently voluntary, it will become required for Pre-Subs at least one year after this guidance is finalized.
Recommendations for Industry
The primary recommendation for industry is to familiarize themselves with and begin voluntarily using the eSTAR platform for Pre-Submissions in advance of the mandatory deadline. The guidance recommends that submitters use the structured, dynamic PDF to ensure all necessary elements of a complete submission are included, thereby facilitating a smoother and more efficient review. For certain types of follow-up communications, such as submitting meeting minutes or presentation slides, the guidance recommends they continue to be submitted as an eCopy rather than through the eSTAR template.
Regulatory Considerations
This guidance is issued under the authority of the Federal Food, Drug, and Cosmetic (FD&C) Act, which mandates the transition to electronic-only submissions. Upon finalization, the requirement to use the eSTAR template for Pre-Subs will be a binding regulatory requirement. The guidance outlines a specific technical screening process for eSTAR submissions that will replace the RTA process. If a submission fails this screening, it will be placed on hold, and the review clock will restart upon receipt of the corrected information. The document also specifies certain types of submissions, such as appeals and withdrawal requests, that will be exempt from the mandatory eSTAR requirement.
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.
List of qualified DDTs
List of qualified DDTs
The database provides a transparent and accessible way for the public to track the progress of various Drug Development Tools (DDTs) through the FDA's qualification pipeline. This includes biomarkers, clinical outcome assessments, and animal models. The information available, such as submission status and supporting documentation, offers insight into the types of tools being developed and the evidence required for their qualification. The platform reveals that a wide range of tools are in development across numerous therapeutic areas, highlighting active areas of research and innovation in drug development.
Recommendations
Stakeholders in the drug development ecosystem are encouraged to utilize this database to inform their research and development strategies. By reviewing the status of existing DDT submissions, sponsors can identify opportunities for collaboration, avoid duplicative efforts, and better understand the evidentiary requirements for tool qualification. Prospective tool developers should use the database to learn from successful submissions and to align their own development plans with FDA expectations.
Regulatory Considerations
This database is a direct implementation of the transparency provisions of the 21st Century Cures Act. The public availability of this information is intended to foster trust and collaboration in the DDT qualification process. By providing a clear view of the regulatory journey of various tools, the FDA aims to standardize the qualification process and encourage the development and use of novel, validated tools in drug development. Users of the database should be aware that the information reflects the status of a DDT at a particular point in time and that the qualification process is an iterative one.
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.
Medical Device Development Tools (MDDT)
Medical Device Development Tools (MDDT)
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.
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.
Best Practices and Recommendations for Sites Utilizing Connected Devices
Best Practices and Recommendations for Sites Utilizing Connected Devices
Sites must establish effective data privacy and security plans, especially considering regional and global regulations like GDPR.
Risk mitigation is critical, including plans to address unanticipated issues and potential patient disengagement due to technology challenges.
Budgeting and contracting often involve additional considerations, such as storage, training, and technical support requirements for connected devices.
Sites require adequate training to ensure staff and patients are prepared to use connected devices efficiently.
Companion applications or services often play an essential role in device functionality and data transmission.
Recommendations
Develop a clear plan for data pathways, including storage, security, and regulatory compliance.
Establish detailed risk mitigation and management strategies to handle unexpected challenges.
Ensure comprehensive training programs for site staff and patients to enhance device usability.
Incorporate device storage and resource allocation into budgeting and contracting processes.
Facilitate effective communication with sponsors and vendors to resolve operational and technical issues promptly.
Regulatory Considerations
Ensure connected devices comply with CFR 21, Part 11, and other relevant data collection and transmission regulations.
Understand and adhere to local and regional data privacy laws, such as GDPR, when managing patient data.
Verify that appropriate licenses and regulatory approvals are in place for device data transmission and storage.
Assess and address shipping and handling regulations for devices, ensuring safe and compliant transportation.
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.
Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers
Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers
The FDA considers electronic records and signatures equivalent to their paper counterparts when they meet the requirements of 21 CFR Part 11. Due to technological advances, electronic systems and digital health technologies (DHTs) are now integral to clinical trials, requiring a modern, risk-based approach to ensure data integrity. Sponsors remain ultimately responsible for the quality and integrity of all data submitted, even when using third-party IT service providers or data from real-world sources like EHRs. The authenticity, integrity, and confidentiality of electronic data are paramount and must be maintained through robust system controls throughout the data lifecycle.
Recommendations
Regulated entities should use a justified and documented risk-based approach to validate all electronic systems before and during a clinical trial, with the level of validation depending on the system's potential to impact participant safety and trial result reliability. Secure, computer-generated, time-stamped audit trails must be implemented to track the creation, modification, and deletion of all electronic records without obscuring original data. Robust logical and physical access controls are necessary to limit system access to authorized individuals. Entities should have written agreements with IT service providers that clearly define roles, responsibilities, and procedures for ensuring data security and long-term retention.
Regulatory Considerations
The requirements of 21 CFR Part 11 apply to all electronic records created, modified, or submitted to the FDA under predicate rules for clinical investigations, including those from foreign sites under an IND or IDE. While the FDA does not intend to assess the Part 11 compliance of external source systems like EHRs, data becomes subject to these regulations once transferred into the sponsor's electronic system. During inspections, the FDA will focus on system validation, data handling procedures, security protocols, audit trails, and documentation of sponsor oversight. Users must certify to the FDA that their electronic signatures are the legally binding equivalent of handwritten signatures.
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.