3.2 Navigating regulatory pathways
With your objectives defined and teams aligned, you’re ready to select the regulatory pathway that fits your development context.
This section reviews engagement opportunities for medical device trials (3.2A) and drug/biologic trials (3.2B), helping you choose an appropriate mechanism, time your interactions strategically, and prepare effective submission materials.
Overview
Navigating regulatory engagement: Choosing your pathway
Regulatory engagement is a series of coordinated interactions mapped to your development timeline. The pathway you choose depends on several factors: the regulatory status of the product under evaluation, the role your sDHT plays in generating evidence, your development stage, and the specific feedback you need.
The landscape differs between medical device and drug/biologic contexts:
Medical device trials are overseen primarily by [CDRH]. If your sDHT is capturing endpoint data to support evaluation of a medical device—or if the sDHT itself qualifies as a medical device—your primary engagement mechanism will be the [Q-Submission (Q-Sub)] program.
Drug and biologic trials are overseen by [CDER] or [CBER]. If your sDHT is capturing endpoint data for a drug or biologic development program, your engagements will typically occur through a [PDUFA meeting] tied to your [IND]. The DHT Steering Committee is available as an informal early touchpoint.
What this section covers—and what it doesn’t
- This section focuses on engagement pathways: mechanisms for obtaining FDA feedback while planning to use sDHTs to capture endpoints in medical product trials (drug, biologic, or device).
- This section does NOT cover approval pathways: If you’re seeking marketing authorization for a medical device ([510(k)], [De Novo], [PMA]), see:
- DiMe’s Digital Health Regulatory Pathways (note: these resources were produced before recent guidance changes; always verify with current FDA guidance).
- DiMe’s International Digital Health Regulatory Pathways to understand and compare regulatory environments across Asia Pacific, Europe, and North America.
- If you’re doing both (developing an sDHT for market AND using it to capture endpoints in trials), you’ll navigate both types of pathways, but this section specifically addresses the engagement side.
A note on terminology – Context of use versus indications for use
Intended use / Indications for use:
- Describes what the medical device will be cleared/approved to do
- Example: “Intended to measure heart rate in adults”
- Relevant when seeking device marketing authorization
Context of use (COU):
- Describes how an endpoint or measure will be used in a specific trial
- Example: “Daily step count in COPD patients as secondary endpoint in Phase 3 trial”
- Relevant when using sDHTs to generate clinical trial endpoints
Both CDER and CDRH use “context of use” when discussing endpoints. CDRH additionally uses “intended use” or “indications for use” when discussing device marketing authorization.
In this roadmap: When we discuss establishing fitness-for-purpose for endpoints captured by sDHTs, we’re referring to context of use. Device marketing authorization (intended use) is a separate regulatory question.
Navigate to your context:
For sDHTs used as measurement tools in medical device trials, or sDHTs that themselves qualify as medical devices.
For sDHTs used to capture endpoints in drug or biologic development programs.
Medical device engagements occur under the MDUFA (Medical Device User Fee Amendments) program, which establishes timelines and expectations for Q-Submissions and other device-focused interactions. While the specific meeting types differ from PDUFA (Prescription Drug User Fee Amendments) meetings, the principle of early, milestone-based engagement is the same.
in practice
3.2A Medical device trials
This subsection is for you if:
You are developing or evaluating a medical device and using an sDHT to capture endpoint data
The sDHT itself qualifies as a medical device (e.g., Software as a Medical Device, a regulated wearable sensor)
You need to clarify device classification, Significant Risk/Non-Significant Risk (SR/NSR) status, or validation requirements with CDRH
New to CDRH? Visit the Regulatory Accelerator Resource Index
If you’re unfamiliar with FDA’s medical device pathways, FDA’s Regulatory Accelerator provides a visual map of CDRH resources organized by product lifecycle phase.
This guide curates tools, engagement opportunities, and guidance across the development lifecycle from market research through post-launch monitoring. It includes many resources detailed below plus additional CDRH-specific materials.
Start here: Is your sDHT a medical device?
FDA provides resources to help you make this determination:
How to Determine if your Product is a Medical Device provides a helpful overview. After reading this information, be sure to visit the Digital Health Policy Navigator.
What it does:
The Navigator provides an interactive decision tree to help you determine whether your product’s software functions are potentially subject to FDA’s regulatory oversight as a device. It accounts for changes resulting from Section 3060 of the 21st Century Cures Act, which narrowed the scope of device regulation for certain clinical decision support software and other functions.
When to use it:
- Early in development, when you’re still determining your regulatory strategy
- Before contacting the Digital Health Center of Excellence, so you can frame your questions appropriately
- When evaluating whether an sDHT you’re considering adopting has device status
- If you’re uncertain whether software functions in your sDHT trigger device regulation
Why it matters for sDHT adoption:
Many sDHTs have software components that may or may not meet the definition of a device depending on their intended use. For example:
- A wearable sensor that measures heart rate for general wellness may be exempt from device regulation
- The same sensor, if marketed to detect arrhythmias, would likely be regulated as a device
- An algorithm that analyzes sensor data to inform clinical decisions may trigger Software as a Medical Device (SaMD) requirements
Understanding your regulatory status shapes everything downstream: which FDA center you engage with, which submission pathway you’ll use, and what validation evidence you’ll need.
PRO TIP FOR ADOPTERS
If you’re evaluating an sDHT developed by someone else, ask the developer if they’ve completed the Digital Health Policy Navigator assessment. Their determination (device vs. non-device) should be documented and justifiable.
PRO TIP FOR DEVELOPERS
Complete this assessment early and document your rationale. If your sDHT’s regulatory status is ambiguous, the Navigator’s output can serve as a starting point for discussions with DICE or DHCoE.
Guidance matures, and quality frameworks endure
Regulatory guidance will continue to evolve, but the fundamental principles of rigorous evidence generation, codified in the V3+ framework, remain constant. Whether your sDHT is regulated as a device or not, demonstrating it is fit-for-purpose requires systematic attention to:
- Technical verification (does the sensor capture accurate data?)
- Analytical validation (does the algorithm reliably produce the intended output?)
- Clinical validation (does the measure reflect meaningful clinical phenomena?)
- Usability validation (can users successfully deploy the technology?)
This Roadmap provides detailed, actionable context on each of these domains (see Section 4: Your Validation Strategy). Each is essential for generating credible evidence that will satisfy regulators, clinical partners, and ultimately, patients.
FDA’s guidance “Software as a Medical Device (SaMD): Clinical Evaluation” was finalized December 8, 2017 and was withdrawn from FDA’s website in early 2026 alongside updates to the the Clinical Decision Support and General Wellness guidances. In addition to following the updated guidances, developers seeking additional recognition of comprehensive quality can apply for DiMe’s Software Evidence and Analysis Library (SEAL) program, which awards recognition to digital health software products that demonstrate performance against a comprehensive framework of standards and best practices in evidence, usability, privacy, and security—with equity woven throughout. SEAL is not a regulatory program and is not intended to replace regulatory review.
Learn more: DiMe SEAL Program
Touchpoint options
Digital Health Center of Excellence (DHCoE) – DigitalHealth@fda.hhs.gov.
The Digital Health Inbox is a helpful opportunity to receive informal answers to your digital health policy questions. For example, you might ask questions specific to digital health technologies, software as a medical device (SaMD), or novel digital measurement approaches.
Once you have a reasonably characterized device concept, intended use, and preliminary development plan, a Pre‑Submission can be used to seek feedback on key elements (e.g., study design, validation strategy, and evidence expectations). An initial email inquiry to the Digital Health Center of Excellence (DHCoE) can help confirm the right review contacts and refine the focus of your Pre‑Submission so that you ask targeted questions and provide sufficient context.
Timing your engagements: Medical device development map
Plan your FDA interactions to align with your development milestones. Earlier engagement generally allows more flexibility to incorporate feedback; later engagement focuses on confirming readiness for submission.
| Recommended engagement | Q-Sub (Pre-Submission) |
| Purpose | Clarify classification, Significant risk/ Non-signficant risk status, and evidence expectations for [Early Feasibility Study] (EFS) protocol. For sDHTs serving as measurement tools, clinical validation can be incorporated into EFS to establish proof-of-concept in the target population before committing to pivotal [IDE]. Align on verification and early validation plans. |
| Recommended engagement | Q-Sub (Pre-Submission) |
| Purpose | Review accumulating validation evidence (V3+). Confirm usability plans for target population. Align on data formats and endpoint definitions before pivotal study. |
| Recommended engagement | Q-Sub (Pre-Submission) |
| Purpose | Finalize evidentiary requirements for sDHT-derived endpoints. Confirm readiness for [510(k)], [De Novo], or [PMA] submission. Address any outstanding questions. |
| Recommended engagement | Breakthrough Device Designation |
| Purpose | For sDHTs offering significant advantages for serious conditions. Provides expedited interactions and senior FDA engagement. |
The medical device development pathway allows for earlier clinical validation compared to drug development.
Early Feasibility Studies (EFS)
Limited-enrollment studies (typically ≤10 patients in the U.S.) designed to provide proof of concept and inform device design. For sDHTs serving as measurement tools (MDDTs), clinical validation substudies can be embedded within EFS to:
✓ Demonstrate the digital measure captures clinically relevant changes in the target population
✓ Establish preliminary evidence of construct validity
✓ Identify and address usability issues before pivotal trials
✓ Generate early data that can inform and support evidentiary strategy for pivotal IDE
Pivotal IDE Studies
Larger studies designed to demonstrate safety and effectiveness. By this stage, your clinical validation strategy should be largely established based on EFS data, allowing the pivotal trial to focus on confirmatory evidence.
Stakeholder considerations
Developer: This earlier validation timeline means sDHT developers partnering with device sponsors should be prepared with preliminary validation data (verification, analytical validation, initial usability testing) before or during EFS. Unlike drug development, where validation often occurs in Phase 2 or later, medical device sponsors may need validated measures much earlier in the development process.
If you’re an sDHT developer without a device sponsor partner, you can still use Q-Subs to clarify classification, discuss validation strategies, or explore MDDT qualification.
Adopter: Use Pre-Submissions before EFS to align with FDA on validation strategy. Early feedback can prevent costly redesigns and increase the chances your pivotal IDE will generate acceptable evidence.
When an sDHT captures endpoint data for your device trial, you (not the sDHT developer) typically lead the regulatory engagement. However, close coordination with the developer ensures technical accuracy and prevents surprises.
Note on the Digital Health Advisory Committee (DHAC): DHAC is an external expert advisory panel that advises FDA on complex digital health policy and scientific questions. Unlike the touchpoints described above (which you initiate), DHAC meetings are convened by FDA when external expert input would inform policy development or review of novel issues. You can participate by attending public meetings or submitting comments, but DHAC is not a mechanism for product-specific regulatory advice. For more on DHAC, see below in Section 3.2B.
in practice
3.2B Drug/biologic trials
This subsection is for you if:
You are developing a drug or biologic and using an sDHT to capture endpoint data in your clinical trials
You have an active or planned IND and need to discuss digital endpoint integration with CDER or CBER
You are exploring novel digital measures for future drug development programs
Primary engagement for drug and biologic programs: PDUFA meetings
For drug and biologic development programs, FDA engagement related to the use of an sDHT should occur through established PDUFA meeting mechanisms, where feedback can be provided in the context of a specific investigational program.
These meetings allow sponsors to discuss the proposed role of the sDHT as it relates to:
- The therapeutic indication
- The trial design
- The proposed endpoint or outcome assessment
- Evidentiary expectations aligned with the development stage
Once a drug development program is defined, PDUFA meetings are the appropriate forum for obtaining FDA feedback on sDHT use.
For informal feedback: The DHT Steering Committee
The DHT Steering Committee is an internal FDA coordination body that may be used as an optional pathway for informal feedback on sDHT-related questions before a specific drug trial is defined, or when questions are not yet appropriate for a formal PDUFA meeting.
This cross-center team coordinates sDHT-related questions and can:
✓ Route your inquiry to the appropriate review division
✓ Help you determine which engagement mechanism is most appropriate
✓ Provide initial guidance on evidentiary expectations
✓ Coordinate expertise across CDER/CBER divisions when needed
✓ Address questions about AI-enabled algorithms and adaptive DHTs
When to engage
You may consider this pathway when:
- You are exploring a potential use of an sDHT prior to having a defined drug trial
- You are seeking help identifying the appropriate FDA entry point for future engagement
This pathway is not a substitute for PDUFA meetings once a drug development program exists.
How to engage
- Provide a brief description of your sDHT, its intended role in your development program, and your specific questions
- The committee can route you to the appropriate division for next steps
What the DHT Steering Committee can help with
- Informal feedback
- Routing to the appropriate review division
- Coordinating cross-center input when needed
As you navigate FDA engagement, you may encounter references to the Digital Health Advisory Committee (DHAC)—a separate body from the DHT Steering Committee.
| Who | FDA staff (internal) |
| Purpose | Coordinate review of your specific program |
| Your role | You initiate contact for your program |
| When | During your development planning |
| Who | External experts (non-FDA) |
| Purpose | Advise FDA on broad policy questions |
| Your role | You observe/comment when FDA convenes |
| When | When FDA seeks expert input on field-wide issues |
What this means for you:
✓ Proactively engage the DHT Steering Committee when planning to use sDHTs in your trial—this is how you get coordinated regulatory feedback on your development program.
✓ Monitor DHAC meetings to understand FDA’s evolving thinking on digital health policy—but DHAC is not the mechanism for product-specific advice.
How to engage with DHAC:
- Attend public meetings when FDA convenes them
- Submit written comments on agenda topics
- Speak during open public hearing portions
- Apply for DHAC membership if interested in serving as an advisor
Learn more: DHAC Charter and Meetings
Timing your engagements: Drug/Biologic development map
Plan your FDA interactions to align with your development milestones. Earlier engagement allows more flexibility to shape your endpoint strategy; later engagement focuses on confirming acceptability.
| Recommended engagement | DHT Steering Committee email; consider INTERACT (CBER) or Pre-IND meeting (CDER) |
| Purpose | Explore intent to include novel sDHT-derived endpoints. Seek early feedback on plausibility and validation approach. Identify potential concerns before IND. |
| Recommended engagement | DHT Steering Committee inquiry → Type B or Type C PDUFA meeting |
| Purpose | Share early validation data and intended trial role. Confirm the sDHT-derived endpoint approach is acceptable for the planned study. Clarify what additional evidence may be needed. |
| Recommended engagement | Type B [PDUFA meeting] |
| Purpose | Discuss endpoint positioning and role (primary, secondary, exploratory). Review completed validation evidence and confirm adequacy. Align on Statistical Analysis Plan (SAP) approach and how the endpoint will be used to support regulatory decision-making. |
| Recommended engagement | Pre-[NDA]/[BLA] meeting |
| Purpose | Confirm data package adequacy, endpoint analysis approach, and any outstanding questions before submission. |
Note on development stages
FDA evaluates sDHTs based on the development stage and context of use rather than specific phase designations. sDHTs can be incorporated at any stage of development, and the timing of engagement should be driven by when you have sufficient information about:
- The specific drug development program and therapeutic indication
- The intended role of the sDHT-derived endpoint (primary, secondary, exploratory)
- Preliminary validation data demonstrating feasibility
Stakeholder considerations
Developer: You can engage FDA even without an adopter partner or active IND. “Sponsors or other interested parties who are considering the use of DHTs not associated with a specific drug development program and would like to discuss general feasibility for their proposed DHT or have general questions about the potential use of their DHT should email DHTsforDrugDevelopment@hhs.fda.gov.” – (FDA).
These interactions can inform your validation strategy and demonstrate regulatory engagement to future partners.
Adopter: As the IND holder, you lead regulatory engagement for your program. Coordinate closely with your sDHT developer to ensure technical details are accurate and that validation evidence aligns with what you present to FDA.
What to bring to the FDA: Submission materials
Regulatory engagement requires a focused briefing package—one that clearly explains the sDHT and associated endpoints, a clear context of use, and the specific feedback needed from FDA.
Compile essential documents demonstrating fit-for-purpose sDHT use, including study protocols, validation data, and context of use details.
Prepare as a team
Even for early or informal FDA engagements, a strong submission reflects thoughtful input from multiple roles. Don’t wait until the end of the process to engage regulatory, data science, and clinical leads; bring them in early to align on goals and ensure the materials tell a coherent story (see Section 2.2: Context of use for suggestions on how to engage across teams):
Developers contribute validation evidence, technical details, and usability insights.
Adopters bring regulatory context, trial design strategy, and endpoint framing.
Components of a strong submission package
Clearly organize information and thoroughly document the evidentiary precedents (Show you’ve done your homework: what’s in the literature? See the Due Diligence call out in Section 2.2: Context of use) as well as current data gathering efforts.
Cover letter and objective bullets. Open with a clear and concise cover letter that outlines the purpose of the submission. Include a bulleted list of 3–5 key objectives or requests to guide FDA reviewers and frame the rest of the materials. This is especially helpful for Q-Subs or pre-IND meetings, where targeted input is the goal.
sDHT overview & context of use. Clearly explain:
- What the tool is
- What it measures
- How the measurement is meaningful for patients in the specific context of use, and whether it complements or replaces traditional endpoints. Show you’ve done your homework and understand the evidence/precedent/unmet measurement need.
- Include the device and algorithm version numbers, and document any plans for updates that may affect future validation or implementation.
Tip: Include a clear, single-sentence Context of Use (COU) statement.
Validation evidence (V3+). Provide a summary of completed or planned:
- Verification
- Analytical validation
- Clinical validation
- Usability validation
Tip: Even if evidence is incomplete, include your plan and request input.
Visual summaries or trial excerpts. Use schematics, timelines, or protocol excerpts to illustrate the proposed use of the sDHT. For PDUFA submissions, consider including a one-page trial schematic or protocol synopsis. For Q-Subs, a visual timeline of bench testing or human factors evaluations can be helpful.
Data management & compliance. If relevant, include summaries of your data architecture, privacy and security posture, and any risk mitigation plans, especially those related to detecting off-target adverse signals. For PDUFA or IDE submissions, include the current status of IRB approval and/or IDE submission, if applicable. Consider:
- Data flow and ownership
- Privacy and informed consent
- Integration with trial workflow
- Plans for missing data or monitoring burden
Ask the right questions. Include specific, numbered questions for FDA feedback. Keep the list concise—ideally no more than 10 questions for Q-Submissions, and 12–15 for PDUFA or pre-IND meetings. Align your questions with your stated objectives, and make sure they’re answerable based on the materials provided.
- Example: “Does FDA agree that the current validation evidence is sufficient for this context of use?”
- Avoid vague asks like “Is this acceptable for approval?”
PRO TIP
It’s worth checking out the examples of well-framed questions provided in Appendix 2 of Requests for feedback and meetings for medical device submissions: The Q-submission program (Guidance for Industry and Food and Drug Administration Staff). Center for Devices and Radiological Health (CDRH); Center for Biologics Evaluation and Research (CBER), Final, FDA, 2025.
While this resource is specific to Q-Submissions, it provides a helpful illustration of the type and scope of questions that are useful across many engagement scenarios.
PRO TIP
Draft agenda and attendee list. For formal meetings, include a proposed agenda and a list of attendees with names and roles. Coordinate with your FDA project manager or RPM to confirm attendance expectations.
Formatting matters. Use headers, bullet points, and visuals to make your materials easy to navigate. The goal is not to impress with volume, but to support clear and efficient review.
Don’t miss this: CDER has a PDUFA commitment to track DHT submissions. When you prepare a submission and submit a Form FDA 1571 (for a pre-IND or IND) or Form FDA 356h (for an NDA/BLA), please check the box to indicate the submission includes DHT data or a proposal to collect DHT data. These forms are available at https://www.fda.gov/about-fda/reports-manuals-forms/forms.
Choose the right pathway
Answer the questions below to assess which opportunity may be right for your current use case.
key takeaways
Regardless of whether you’re working in a medical device or drug/biologic context, several principles apply:
1. Match the mechanism to your question
Informal touchpoints (email inquiries, DHT Steering Committee outreach) are appropriate for early orientation. Formal mechanisms (Q-Subs, PDUFA meetings) generate documented feedback that shapes your program. Choose based on what you need and what you’re ready to discuss.
2. Time your engagements to your development stage
Earlier engagement provides more flexibility to incorporate feedback. Later engagement confirms readiness. Plan interactions at natural milestones rather than waiting until problems arise.
3. Prepare focused, well-organized materials
Whether you’re submitting a Q-Sub package or a PDUFA briefing document, clarity and focus matter more than volume. Frame questions around the decisions you need to make, and provide enough context for FDA to respond meaningfully.
4. Coordinate across functions internally and with partners
Regulatory engagement is most effective when clinical, technical, and regulatory perspectives are aligned. If you’re an adopter working with an sDHT developer (or vice versa), ensure your materials tell a coherent story and that all parties are aligned on the endpoint strategy.
5. Document and build on prior interactions
Where applicable, reference earlier FDA feedback in subsequent submissions. This creates continuity and helps reviewers understand how your program has evolved.
Next steps
If you’re considering formal qualification for broad reuse across programs, see Section 3.3: Formal Qualification Programs
For real-world examples and potential engagement scenarios, see Section 3.4: Examples in practice
3.2 navigating regulatory pathways
Resources to guide you
The sDHT roadmap library gathers 200+ external resources to support the adoption of sensor-based digital health technologies. To help you apply the concepts in this section, we’ve curated specific spotlights that provide direct access to critical guidance and real-world examples, helping you move from strategy to implementation.
Features essential guidance, publications, and communications from regulatory bodies relevant to this section. Use these resources to inform your regulatory strategy and ensure compliance.
Gathers real-world examples, case studies, best practices, and lessons learned from peers and leaders in the field relevant to this section. Use these insights to accelerate your work and avoid common pitfalls.