
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.
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.
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.
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.
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.
Complex clinical trials – Questions and answers
Complex clinical trials – Questions and answers
Complex clinical trials involve unique challenges in design, operational feasibility, and regulatory compliance, necessitating early engagement with stakeholders.
Master protocols streamline trial processes by integrating shared scientific frameworks across sub-protocols, enhancing efficiency and data integrity.
Bayesian approaches, while promising, require transparency and rigorous validation to ensure robustness in trial outcomes.
The use of biomarkers and related assays in CCTs introduces added complexity, particularly concerning regulatory status and performance validation.
Effective risk-based quality management systems are essential to safeguard participant safety and maintain trial reliability.
Recommendations
Develop clear and detailed master protocols to define the shared framework, communication plans, and statistical methodologies for CCTs.
Employ risk-based quality management strategies, including robust risk assessment and targeted training for site personnel.
Ensure early and continuous engagement with regulators, investigators, and patients to address design complexities and operational challenges.
Pre-specify statistical plans and evaluation frameworks for Bayesian methods, adaptive designs, and biomarker integration.
Establish mechanisms for transparent reporting and management of safety data across sub-protocols while safeguarding trial integrity.
Regulatory Considerations
Adhere to EU CTR and IVD regulations, ensuring compliance in the use of biomarkers, companion diagnostics, and related assays.
Include comprehensive documentation of trial design, including shared frameworks, sub-protocols, and statistical methodologies, in submissions.
Implement robust data governance frameworks to ensure ALCOA++ (attributable, legible, original, accurate, complete, consistent) standards for regulatory submissions.
Plan for periodic reassessment of benefit-risk ratios during the trial, particularly when modifications or new data emerge.
Establish independent Data Monitoring Committees (DMCs) for long-term and complex trials to oversee safety and interim analyses.
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 Devices; Quality System Regulation Amendments
Medical Devices; Quality System Regulation Amendments
The QS regulation under 21 CFR Part 820 has been effective but requires updates to align with global standards like ISO 13485.
Adopting ISO 13485 will harmonize FDA requirements with international practices, benefiting manufacturers that sell devices globally.
FDA’s proposed amendments retain some unique provisions to ensure alignment with the Federal Food, Drug, and Cosmetic Act (FD&C Act).
The incorporation of risk management principles throughout the product lifecycle is more explicit in ISO 13485 than in the current QS regulation.
The proposed changes are expected to reduce regulatory burdens and enhance device quality and accessibility.
Recommendations
Align quality management systems with ISO 13485 to ensure compliance with both U.S. and international regulatory requirements.
Establish documentation processes that meet FDA’s additional requirements, such as those for traceability and complaint handling.
Incorporate risk management throughout the device lifecycle, as emphasized in ISO 13485.
Manufacturers should train personnel and update their systems to comply with the new requirements within the proposed one-year transition period.
Provide comments on the proposed rule to FDA before the deadline to address any potential concerns or suggestions for improvement.
Regulatory Considerations
The proposed rule incorporates ISO 13485:2016 by reference and aligns FDA’s QS regulation with international QMS standards.
FDA-specific requirements include:
Traceability for certain life-supporting devices.
Documentation of unique device identifiers (UDI) in compliance with FDA’s regulations.
Complaint handling and servicing records that meet FDA standards.
FDA inspections will not issue ISO 13485 certifications but will assess compliance with the proposed Quality Management System Regulation (QMSR).
Manufacturers must continue to comply with existing FDA regulations where conflicts with ISO 13485 arise.
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.
Policy for Device Software Functions and Mobile Medical Applications
Policy for Device Software Functions and Mobile Medical Applications
FDA oversight focuses on software functions that meet the definition of a medical device under section 201(h) of the FD&C Act and pose risks to patient safety.
Many software functions are exempt from regulation if they do not meet the medical device definition or pose minimal risk.
Mobile medical apps that transform general-purpose platforms into regulated devices (e.g., by using sensors or attachments) fall under FDA’s regulatory scope.
Certain apps, like those for general wellness or simple medical calculations, are subject to enforcement discretion due to their low risk.
Manufacturers are encouraged to adopt quality systems to ensure software safety and effectiveness throughout the product lifecycle.
Recommendations
Clearly identify the intended use of software functions and ensure they align with definitions for medical devices under the FD&C Act.
Adopt a robust Quality System (QS) to ensure software safety and mitigate risks.
For mobile medical apps that transform general-purpose platforms into devices, ensure compliance with FDA classification and regulatory requirements.
Distinguish between software functions for general wellness and those with patient-specific analysis to assess regulatory oversight needs.
Engage with FDA early in the development process to clarify requirements for new or novel device software functions.
Regulatory Considerations
Device software functions that meet FDA’s medical device definition and pose safety risks are subject to classification (Class I, II, or III) and regulatory requirements.
FDA exercises enforcement discretion for low-risk software functions, such as apps for medication reminders or wellness tracking.
Mobile apps used solely for administrative purposes or patient education generally do not meet the definition of a medical device.
Developers of regulated software must comply with labeling, quality system, and premarket submission requirements, depending on classification.
Apps that collect, transfer, or display medical device data without modifying it may fall under MDDS guidance and are typically exempt from rigorous regulation.
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.
Vendor selection considerations for clinical trial design utilizing digital measurement of nocturnal scratch
Vendor selection considerations for clinical trial design utilizing digital measurement of nocturnal scratch
Vendor selection should assess 13 categories, including General organizational operation and products, Quality Management Principles, Practices of product or service design, Device supply and provisioning, Account provisioning, Study specific materials, Live trial support, Trial closeout activities, Data handling/processing and data flow (GDPs), Device and Data (sensors + raw data) algorithm accessibility, Interoperability/Integration, Validation/Clinical Relevance/standard of documentation, and Cybersecurity. Key aspects to consider include having Validation and verification of the device and algorithm in place, ability to support multiple countries, an established quality management system. Vendors must assure maintained data integrity and quality, and provide evidence of Good Clinical Practice (GCP) compliance. Robust practices in Good manufacturing practice, Good product development practices (for hardware and software, including software lifecycle documentation), and Good scientific practices are required.
Recommendations
Sponsors should engage with vendors early in study design to tailor the technology capabilities and data requirements to patient needs and preferences. Vendors are typically responsible for device verification and analytical validation, but collaboration with sponsors and other stakeholders on clinical validation is beneficial to establish validation thresholds, specific needs of target clinical populations, and acceptability and usability of the technology. Sponsors should enable a feedback loop from patients back to vendors to improve technology for specific target populations. Sponsors or researchers should prioritize access to high-fidelity and sensor-level data to enable novel research and assessment of additional health aspects. Specific inquiries for vendors should cover: measurements offered (Accelerometry output for scratch detection, sleep measurement, environmental factors, and vitals), device material and safety testing (irritation/sensitization), usability/patient burden (e.g., disturbance during sleep), and applicability to Pediatrics, different ethnic groups, and different skin colors.
Regulatory Considerations
For software development, vendors should document and monitor the software lifecycle for quality, and demonstrate that algorithms have been tested with appropriate datasets. Assurances of GCP compliance are necessary. Vendors should demonstrate that their manufacturing practices ensure devices from different batches provide the same result measurements. Collaboration on clinical validation with sponsors and other stakeholders is a key component to generate the necessary evidence for the Validation/Clinical Relevance/standard of documentation requirement for regulatory purposes.
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 Vendor Assessment for Clinical Trials
Digital Health Vendor Assessment for Clinical Trials
The lack of standardization in vendor onboarding processes increases operational inefficiencies for sponsors and vendors.
Essential topics such as data security, quality management systems (QMS), and validation studies are under-addressed in ad hoc vendor assessments.
Cybersecurity and patient data privacy, especially compliance with GDPR, HIPAA, and global regulations, require enhanced focus during vendor evaluations.
Tailoring vendor assessments to specific trial requirements and patient populations is critical for effective implementation of digital health tools.
Greater collaboration between sponsors and vendors can improve operational alignment and mitigate risks during trials.
Recommendations
Utilize the 13 vendor assessment categories as a baseline for customizing questionnaires to meet specific project needs.
Establish standardized templates for evaluating data privacy, regulatory compliance, and patient-facing user experience.
Prioritize cybersecurity measures, including penetration testing, access management, and encryption standards, as a core assessment criterion.
Implement continuous feedback loops during vendor selection and onboarding to refine assessment processes and address emerging risks.
Encourage industry collaboration to evolve and expand the open-source framework based on practical implementation experiences.
Regulatory Considerations
Ensure all vendors adhere to relevant global standards, including 21 CFR Part 11, GDPR, and HIPAA, for data security and compliance.
Verify the regulatory status of medical devices and algorithms used in digital health solutions, including certifications such as ISO 13485 and IEC 62304.
Require documentation of informed consent processes and adherence to regional data protection regulations for patient data handling.
Align vendor capabilities with regulatory guidelines for clinical trial endpoints, emphasizing validation studies and clinical relevance.
Maintain transparent and audit-ready documentation for inspections and compliance verifications.
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.
Risk Based Monitoring
Risk Based Monitoring
Traditional on-site monitoring, which often involves 100% source data verification, is not the most effective way to ensure data quality and can divert resources from more critical activities. A risk-based approach allows for the early identification of potential issues, enabling proactive risk mitigation and improved trial oversight. The successful implementation of RBM requires a cultural shift within organizations, moving from a reactive to a proactive mindset. Collaboration among sponsors, CROs, and sites is essential for the effective adoption of RBM methodologies.
Recommendations
Sponsors should adopt a systematic, risk-based approach to monitoring that is tailored to the specific risks of their clinical trial. This includes conducting a thorough risk assessment during the planning phase to identify critical data and processes. The use of centralized monitoring and advanced analytics should be a core component of any RBM strategy to detect unusual patterns or trends in the data. Training for all stakeholders, including site staff and monitors, is crucial for the successful implementation of RBM.
Regulatory Considerations
Global regulatory agencies, including the FDA, EMA, and Japan's PMDA, have issued guidance that supports and encourages the use of risk-based approaches to monitoring clinical trials. Regulatory submissions should include a description of the RBM methodology used in the trial and a justification for the approach taken. The adoption of RBM is consistent with Good Clinical Practice (GCP) principles, which emphasize a focus on patient safety and data quality.
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.