
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.
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.
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.
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.
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.
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.
Content of Premarket Submissions for Device Software Functions
Content of Premarket Submissions for Device Software Functions
Enhanced documentation is required for high-risk device software where flaws could result in serious injury or death.
Risk management plans should include robust risk assessments, including residual risk evaluations.
Verification and validation activities are critical to confirm software functionality and mitigate risks.
The lack of traceability between software design and requirements can undermine device safety and effectiveness.
Unresolved software anomalies must be carefully documented and justified based on a risk assessment.
Recommendations
Use a risk-based approach to determine whether basic or enhanced documentation levels are required for premarket submissions.
Include comprehensive risk management documentation, detailing hazard identification, risk control measures, and residual risk evaluations.
Provide detailed system and software architecture diagrams, highlighting relationships between modules and external systems.
Document unresolved software anomalies and justify their impact on safety and effectiveness using a risk-based rationale.
Align software development, configuration management, and maintenance practices with FDA-recognized standards like ANSI/AAMI/IEC 62304.
Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System regulations, emphasizing design controls and risk management.
Submission of risk management files and unresolved software anomalies as part of premarket documentation.
Use of system and software architecture diagrams to demonstrate software functionality and risk mitigation.
Implementation of cybersecurity measures as part of software validation and risk management processes.
Documentation of premarket changes and interactions between device functions and external systems, particularly in multi-function devices.
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.
Digital Health Regulatory Pathways
Digital Health Regulatory Pathways
There is widespread confusion among digital health developers regarding the complex and evolving regulatory landscape, with many uncertain about whether their products require regulation or which pathway to pursue. This lack of a clear regulatory strategy acts as a significant barrier to market access, investor confidence, and user trust. The heterogeneity of the digital health sector, coupled with varying international requirements, further complicates the path to market for innovators, hindering the scalability of effective solutions.
Recommendations
Digital health innovators should proactively integrate a tailored regulatory strategy into their core business plan, viewing it as a commercial differentiator rather than a hurdle. Developers are encouraged to utilize resources like DiMe’s regulatory pathway tools to navigate the U.S. and global landscapes effectively. Early and continuous engagement with regulators and collaborative efforts across the industry are essential to ensure products are developed to meet both market needs and regulatory standards, ultimately accelerating the delivery of high-quality digital health solutions to patients.
Regulatory Considerations
A comprehensive policy framework is necessary for the successful integration of digital health technologies, encompassing regulatory authorization, value assessment, and reimbursement. Developers must understand the nuances of different regulatory classifications, such as Software as a Medical Device (SaMD), and their specific evidentiary requirements. Greater international harmonization of regulatory standards is crucial for enabling global scalability. Regulatory bodies should continue to develop agile frameworks that can accommodate the rapid pace of innovation in digital health while ensuring patient safety and product effectiveness.
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.
Digital Health Technologies for Remote Data Acquisition in Clinical Investigations
Digital Health Technologies for Remote Data Acquisition in Clinical Investigations
There is a need for comprehensive validation and verification processes for DHTs.
Ensuring data security and privacy is a significant concern.
Usability issues for diverse populations need to be addressed.
There is a lack of clarity on whether certain DHTs meet the definition of a device under the FD&C Act.
The guidance does not establish legally enforceable responsibilities.
Recommendations
Ensure DHTs are fit-for-purpose for clinical investigations.
Implement robust data security measures to protect participant information.
Conduct usability evaluations to ensure DHTs can be used by intended populations.
Engage with FDA early to discuss the use of DHTs in clinical investigations.
Develop a risk management plan to address potential issues with DHT use.
Regulatory Considerations
Verification and validation should be addressed regardless of device classification.
Sponsors should ensure compliance with data protection and privacy regulations.
FDA evaluates DHT data based on endpoints, medical products, and patient populations. Sponsors can engage with FDA’s Q-Submission Program for feedback on DHT usage in clinical trials.
Sponsors should understand the legal implications of using DHTs in clinical investigations.
The guidance provides recommendations but does not establish legally enforceable responsibilities.
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.
Off-The-Shelf Software Use in Medical Devices
Off-The-Shelf Software Use in Medical Devices
OTS software introduces unique risks due to its general-purpose design and lack of lifecycle control by medical device manufacturers.
Comprehensive testing and risk management are essential to mitigate safety hazards associated with OTS software in medical devices.
Regular updates and maintenance are critical for managing obsolescence and ensuring long-term safety and effectiveness of OTS components.
Networking and interoperability of OTS software pose additional risks related to data integrity, cybersecurity, and scalability.
Enhanced documentation is required for high-risk devices incorporating OTS software, especially those involving AI or ML functionalities.
Recommendations
Provide comprehensive descriptions of OTS software, including version details and system specifications.
Conduct thorough risk assessments and include mitigation plans in premarket submissions.
Perform rigorous testing, including integration and regression testing, for OTS software components.
Establish mechanisms for continued maintenance, support, and version control of OTS software.
Ensure that device labeling includes warnings and specifications related to OTS software compatibility and restrictions.
Regulatory Considerations
Adherence to 21 CFR Part 820 Quality System regulations, including design controls and purchasing controls for OTS software.
Submission of a risk management file and traceability documentation linking risks, design requirements, and testing outcomes.
Compliance with premarket submission requirements, including 510(k), IDE, and PMA applications, as applicable.
Use of device labeling to communicate hardware and software compatibility and restrictions to users.
Development of beta testing and investigational plans for clinical studies involving OTS software.
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.
Qualification of Medical Device Development Tools
Qualification of Medical Device Development Tools
Lack of publicly available qualified MDDTs may limit their widespread adoption.
Challenges in collecting robust evidence for novel or innovative tools without established paradigms.
Regulatory complexities for tools with dual uses as MDDTs and clinical diagnostic devices.
The need for transparent communication of MDDT advantages and limitations for their qualified COU.
Limited industry awareness of the benefits and processes for MDDT qualification.
Recommendations
Develop clear and specific Context of Use (COU) statements for proposed MDDTs, detailing their application in device evaluation.
Ensure thorough validation of tool performance characteristics, including accuracy, reproducibility, and reliability, to support qualification.
Foster collaboration among stakeholders, such as consortia and organizations, to share resources for MDDT development and qualification.
Provide detailed qualification plans outlining data collection methods, protocols, and acceptance criteria for each performance metric.
Promote transparency by publishing high-level summaries of evidence and qualification decisions while protecting proprietary information.
Regulatory Considerations
MDDTs intended only for device evaluation are typically not classified as medical devices unless used for clinical treatment or diagnosis.
Clinical study tools used as MDDTs must comply with Investigational Device Exemption (IDE) regulations under 21 CFR Part 812.
Qualification does not imply FDA clearance or approval for clinical use; labeling and promotional materials must clearly communicate this distinction.
Modifications to an MDDT’s COU or qualification status may require reevaluation based on new data or scientific advancements.
FDA emphasizes the complementary role of MDDTs alongside consensus standards and device-specific guidance for regulatory evaluations.
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.