3.4 Examples in practice

Scenarios and success stories

This section presents hypothetical scenarios illustrating common situations developers and adopters face, organized by whether the sDHT is being used in a medical device trial or a drug/biologic trial.

We also highlight real-world proof points that demonstrate successful regulatory outcomes.

Overview

Mapping your journey through examples

This section offers two types of examples:

Hypothetical scenarios

Illustrative situations designed to show how different development contexts lead to different regulatory strategies.

These are not real case studies; they are composites intended to help you pattern-match to your own situation.

Real-world proof points

Documented examples of successful regulatory engagement or qualification, drawn from public sources.

How to use the illustrative scenarios

The scenarios in this section are hypothetical. Each example is a composite intended to:

Illustrate the types of questions teams commonly face when considering regulatory engagement.

Show how different development contexts (e.g., product type, stage, novelty, intended use) can lead to different engagement strategies.

Highlight the importance of internal alignment and cross-functional input before engaging regulators.

Demonstrate how engagement decisions can be anchored in publicly available FDA guidances and programs.

The intent is not to provide templates or prescribe actions, but to make the underlying reasoning process more visible. You should expect to adapt the logic to your own situation rather than replicate any specific pathway shown here. The goal is to help you frame clearer questions, involve the right stakeholders, and prepare more focused, evidence-informed interactions to increase your likelihood for productive engagement with regulators.

in practice

Medical device trial illustrative scenarios

These scenarios involve sDHTs used to capture endpoint data in medical device development programs, or sDHTs that themselves qualify as medical devices.

Scenario A: SaMD for arrhythmia detection

A developer has created a Software as a Medical Device (SaMD) that uses smartphone sensors to detect irregular heart rhythms. The company wants to seek FDA marketing authorization for the SaMD itself and needs to understand classification requirements, validation expectations, and the appropriate regulatory pathway.

The sDHT is the medical device under evaluation—not just a measurement tool.

Classification and intended use must be clearly defined.

AI/ML components may trigger additional documentation requirements.

✓ Start with Device Determination if classification is uncertain (DeviceDetermination@fda.hhs.gov).

✓ Submit a Pre-Submission (Q-Sub) to CDRH to:

Confirm device classification and regulatory pathway (510(k), De Novo, or PMA)

Discuss analytical validation approach and reference standards

Address AI/ML-specific requirements (predetermined change control plan, algorithm transparency)

Align on clinical validation study design

✓ Consider Breakthrough Device Designation if the SaMD addresses an unmet need for a serious condition.

When the sDHT is the product, device-focused engagement (Q-Sub) is primary.

AI/ML components require proactive documentation of algorithm performance and change management.

Early classification clarity prevents downstream pathway confusion.

How the team reasoned their way to this engagement pathway

Before selecting an FDA engagement mechanism, the development team clarified which regulatory decisions needed to be resolved early and reviewed FDA guidance describing when and how sponsors should engage on medical devices.

Key questions the team needed to answer

The team identified several decision-critical questions:

Does the software meet the definition of a medical device, and does it qualify as Software as a Medical Device (SaMD)?

What is the appropriate device classification and regulatory pathway (510(k), De Novo, or PMA) for the proposed intended use?

Are the planned analytical validation methods and clinical reference standards appropriate for detecting arrhythmias in the intended population?

What additional documentation and controls are expected because the SaMD incorporates AI/ML components?

At what stage should clinical validation evidence be generated relative to clearance?

Sponsors should seek feedback before executing planned testing and before finalizing validation strategies for novel or software-based devices.

What information the team had available

At this stage, the team could credibly present:

A defined intended use statement describing arrhythmia detection using smartphone sensor data

Preliminary verification and analytical validation results benchmarking algorithm outputs against clinical reference standards

A high-level description of the AI/ML model and its training approach

A proposed clinical validation study design

Open questions regarding future algorithm updates and performance monitoring

Early engagement does not require a complete validation package, but does require sufficient definition of intended use and planned evidence to support meaningful feedback.

Engagement pathways considered

The team considered whether an informal inquiry (e.g., email-based orientation) would be sufficient. However, because device classification and regulatory pathway selection would affect the entire development program, the team determined that informal feedback alone would be insufficient.

They also considered whether a qualification program might apply. FDA’s Medical Device Development Tool (MDDT) program is intended for tools used to support device evaluation, not for software products seeking marketing authorization.

Why a Q-Submission was selected

The team selected a Pre-Submission (Q-Sub) to CDRH because the Q-Submission program is a primary mechanism for:

Clarifying device classification and regulatory pathway early in development

Obtaining feedback on analytical and clinical validation strategies before studies are executed

Discussing novel technologies and software-based devices, including SaMD

Receiving written, documented feedback that can be referenced in future submissions

Because the SaMD incorporated AI/ML components, the Q-Sub also provided an appropriate forum to discuss algorithm transparency, performance evaluation, and change management approaches, consistent with FDA’s digital health and AI/ML policy direction.

Why this scenario is plausible

Early Q-Submission interactions can be useful for SaMDs with novel algorithms, evolving AI/ML components, or unclear classification. Starting with classification clarification and validation alignment through a Q-Sub is an appropriate approach for developers to de-risk device programs before pursuing marketing authorization.

Scenario B: Wearable sensor for pulmonary function monitoring

A medical device company is developing a chest-worn sensor to monitor respiratory function in patients with chronic obstructive pulmonary disease (COPD). The sensor will be used as an endpoint measure in a pivotal trial for a novel therapeutic device (e.g., an implantable stimulator). The company wants to ensure the sensor-derived endpoint will be acceptable to FDA.

The sDHT is a measurement tool (potential MDDT), not the device under evaluation.

The endpoint must be validated for the specific patient population and context of use or intended use.

The therapeutic device sponsor and sDHT developer must coordinate.

✓ sDHT developer submits a Pre-Submission (Q-Sub) to discuss:

Verification and analytical validation evidence

Planned clinical validation approach

Whether MDDT qualification is appropriate (if intended for use beyond this single trial)

✓ Therapeutic device sponsor can also submit a Pre-Submission to discuss:

The pivotal trial design, including use of the sDHT-derived endpoint

How the endpoint relates to clinical benefit for the intended patient population

✓ Coordinate messaging between developer and sponsor to ensure FDA receives a coherent picture.

When sDHT developer and device sponsor are different entities, explicit coordination is essential.

Validation evidence should address the specific population in the pivotal trial, not just healthy volunteers.

Consider whether MDDT qualification adds value if the endpoint could benefit future device programs.

How the team reasoned their way to this engagement pathway

Before selecting an FDA engagement mechanism, the therapeutic device sponsor and the chest-worn sensor developer aligned on the regulatory questions that needed to be resolved early and reviewed FDA guidances describing expectations for digital health technologies used to generate endpoint data in clinical investigations.

Key questions the team needed to answer

Because the wearable sensor was being used to support evaluation of a separate therapeutic device, the team focused on endpoint acceptability and validation rather than product clearance for the sensor itself:

Is the proposed sensor-derived endpoint is appropriate for use in a pivotal trial in patients with COPD, given the specified context of use?

What verification, analytical validation, clinical validation, and usability validation evidence does FDA expect for a digitally derived endpoint used in a pivotal medical device trial?

How should the sponsor justify that the endpoint is interpretable and relevant to evaluation of clinical benefit in the intended patient population?

At what point in development should this evidence be generated relative to pivotal trial initiation?

Verification, validation, and usability evaluations should be addressed for sDHTs used to collect data in clinical investigations. Sponsors should engage FDA early when novel endpoints or technologies are introduced.

What information the team had available

To support a productive regulatory discussion, the two parties clarified what they could credibly present at this stage:

A defined context of use for the sensor-derived endpoint in a COPD pivotal trial, describing the endpoint’s role in the study

Existing verification and analytical validation evidence for the wearable sensor, with a proposed plan to extend clinical validation in the intended patient population

A preliminary clinical validation approach aligned with pivotal trial use

A usability evaluation plan appropriate for patients with COPD in the trial setting

Early engagement does not require a complete evidentiary package, but sufficient definition of intended use and planned testing is needed to support meaningful feedback.

Engagement pathways considered

The team evaluated several realistic engagement options:

Single Pre-Submission led by the therapeutic device sponsor: efficient, but risked insufficient discussion of the sensor’s technical validation details.

Single Pre-Submission led by the sensor developer: useful for tool validation strategy, but insufficient to address how the endpoint supports the sponsor’s pivotal claims.

Coordinated dual Pre-Submissions: separate but aligned submissions allowing FDA to review both the measurement tool and its application in the pivotal trial.

Why a coordinated Q-Submission strategy was selected

The Q-Submission program is a primary mechanism for obtaining early, documented feedback on clinical study endpoints, validation strategies, and trial design in a medical device context.

Feedback is most effective when requested before execution of planned testing, which is particularly important when finalizing a pivotal trial design.

Separating submissions clarified roles and accountability:
- The sensor developer’s Q-Sub focused on verification, analytical validation, and the proposed clinical validation strategy for the wearable sensor in the COPD population.
- The therapeutic device sponsor’s Q-Sub focused on the pivotal trial design and endpoint justification, including how the sensor-derived endpoint reflects clinically meaningful aspects of health and supports evaluation of device effectiveness, consistent with recommendations for endpoints involving data collected using sDHTs.

This coordinated approach ensured FDA received a coherent, complete picture of both the measurement tool and its role in the pivotal study.

Why this scenario is plausible

Early, structured engagement on endpoint strategy and planned testing for medical device trials, is important, particularly when digital health technologies are used to generate novel or non-traditional endpoints. Using coordinated Q-Submissions to address validation expectations and endpoint acceptability before pivotal execution can help developers understand and respond to regulatory expectations and promote fit-for-purpose device development.

Scenario C: AI-Enabled sDHT for neurological assessment

A developer has created an AI-powered wearable that uses motion sensors and machine learning to quantify motor symptoms in patients with a progressive neurological condition. The technology is novel, and the developer wants FDA feedback before partnering with device or drug sponsors.

The sDHT is novel with no established precedent.

The developer has no sponsor partner yet and no specific therapeutic context.

AI/ML components require transparency about training data, algorithm performance, and generalizability.

✓ Contact the Digital Health Center of Excellence (digitalhealth@fda.hhs.gov) for initial orientation on novel digital health technologies.

✓ Submit a Pre-Submission (Q-Sub) to CDRH to:

Discuss device classification (likely SaMD)

Present preliminary validation evidence and seek feedback on gaps

Explore whether Early Orientation Meeting format is appropriate given early stage

✓ Document AI/ML considerations including algorithm transparency, performance across subgroups, and plans for monitoring drift.

✓ Build validation evidence that will be transferable to future partnerships, focusing initially on analytical validation that isn’t tied to a single therapeutic context.

Developers can engage FDA without a sponsor partner.

Novel technologies benefit from early orientation before committing to specific pathways.

AI/ML documentation should be built proactively, not retrofitted.

How the team reasoned their way to this engagement pathway

Because the technology is novel and the developer does not yet have a sponsor partner or a specific therapeutic development program, the team prioritized (1) confirming whether FDA would view the product as a device/SaMD, (2) establishing a credible early validation plan that is relevant for future partnerships, and (3) proactively structuring AI/ML documentation so it would not need to be rebuilt later.

Key questions the team needed to answer

Is this regulated as a device/SaMD, and what claims would trigger oversight?

The team first pressure-tested how FDA would likely view the wearable + algorithm given its intended medical purpose and claims, using FDA’s policy navigation resources (Digital Health Policy Navigator, FDA, 2022; Is the Software Function Intended for a Medical Purpose? FDA, 2022)

What does “good enough evidence” look like before a partner exists?

With no sponsor and no single trial context, the developer was interested on FDA feedback on what preliminary evidence would be persuasive and what gaps would prevent meaningful interpretation. Sponsors/developers can consider verification, validation, and usability for sDHTs used to collect data, and explore the applications for sDHT-derived endpoints that may address unmet measurement need.

What AI/ML expectations apply so the team can design for them?

Given the model-driven nature of the technology, the team identified early needs around training data characterization, generalizability, subgroup performance, and transparency. They reviewed AI/ML policy materials around transparency and lifecycle considerations for ML-enabled devices (Transparency for Machine Learning-Enabled Medical Devices: Guiding Principles, FDA, 2024), and planning for model changes through a PCCP approach.

What information the developer had before engaging

The developer assembled a package focused on items that are not dependent on a specific drug/device program:

Intended use statements and the boundaries of claims the developer wanted to support, framed using FDA’s digital health policy resources (Digital Health Policy Navigator, FDA, 2022)

A validation plan and preliminary evidence emphasizing analytical performance and reliability of the measurement approach, aligned to the expectations FDA describes for sDHTs used to generate clinical investigation data

AI/ML documentation describing training data provenance, evaluation approach, performance across clinically relevant subgroups, and transparency considerations consistent with FDA’s ML transparency principles (Transparency for Machine Learning-Enabled Medical Devices: Guiding Principles, FDA, 2024)

A forward-looking change-management outline (even if pre-market) so the team could align early on expectations for model evolution

Engagement pathways considered

Why start with DHCoE orientation
Because the developer was early-stage and wanted help mapping novelty + claims to likely oversight and next steps, they started with an orientation channel designed for digital health regulatory questions (Digital Health Frequently Asked Questions (FAQs), FDA, 2023; Digital Health Center of Excellence, FDA, 2025).

Why a Q-Sub was still necessary
Orientation alone would not provide the level of documented feedback needed to de-risk future development and partnership discussions. The team therefore planned a Pre-Submission under FDA’s device engagement framework, which is explicitly intended for early feedback on planned approaches and evidence strategy.

Where “Early Orientation Meetings” fit (and why they were treated as conditional)
The team considered whether an “Early Orientation Meeting” format was relevant. FDA describes these as an optional interactive review mechanism to help reviewers understand software-heavy devices, often including demonstrations, and particularly helpful for novel software functions (Best Practices for Early Orientation Meetings for Marketing Submissions for Medical Device Software, FDA, 2025). Because the developer was not yet at a marketing-submission stage, the team treated this as a later option rather than the primary near-term mechanism.

Why this pathway was selected

The developer chose a DHCoE orientation → Q-Sub sequence because it provided:

Early “navigation” support for a novel digital technology and claims framing

A structured path to feedback on classification and evidence expectations

An explicit way to incorporate AI/ML transparency and change-management considerations from the start

Why this scenario is plausible

Early engagement for novel digital health technologies, including AI-enabled software and wearable systems, is encouraged, particularly when there is no established predicate and uncertainty around classification or evidence expectations. The Digital Health Center of Excellence (DHCoE) can support early orientation and navigation for developers working on emerging digital technologies.

Developers do not need a sponsor partner or an active clinical program to seek feedback through the Q-Submission program. The Q-Sub pathway can support early discussions about classification, validation strategy, and planned evidence.

Drug/Biologic Trial Illustrative Scenarios

These scenarios involve sDHTs used to capture endpoint data in drug or biologic development programs.

Scenario D: Digital endpoint in Parkinson's disease trial

A pharmaceutical company is developing a therapy for Parkinson’s disease and plans to use a wearable sDHT to assess gait-related outcomes (e.g., walking speed, step variability, turning metrics) that have been widely used in prior PD studies. In this trial, however, the sponsor proposes to apply the gait endpoint in a new context of use, focusing on a later-stage PD population, whereas much of the existing evidence has been generated in earlier stages of disease. The study is conducted under an active IND, and the gait measure is proposed as a secondary or supportive endpoint, rather than an exploratory endpoint.

The sDHT-derived gait endpoint is well established in Parkinson’s disease, but is being applied in a new context of use, requiring careful consideration of whether existing evidence can be appropriately extrapolated.

The measure must remain interpretable and meaningfully linked to aspects of health that matter to patients with later-stage Parkinson’s disease, such as mobility, independence, and safety, given increased variability and functional heterogeneity.

Validation evidence must be fit-for-purpose for the proposed context of use, including disease stage, endpoint role, and real-world deployment, rather than relying solely on evidence generated in earlier-stage populations.

✓ Email the DHT Steering Committee (DHTsforDrugDevelopment@fda.hhs.gov) to:

Describe the planned use of the wearable-derived gait endpoint, with emphasis on how the proposed context of use (later-stage PD population and endpoint role) differs from prior applications

Ask for suggestions on appropriate engagement mechanisms

Request confirmation of the appropriate review division and meeting pathway for discussing evidentiary expectations

✓ Request a PDUFA meeting to:

Present the rationale for using the established gait endpoint in a later-stage PD population, including how changes in disease stage and setting may affect interpretation

Share validation evidence to date, with emphasis on which elements remain applicable and where additional support may be needed for the proposed context of use (V3+ summary)

Ask targeted questions about evidentiary expectations and endpoint positioning (secondary or supportive), including whether additional analyses or data are needed to support use in this population

✓ Integrate patient input to demonstrate the measure captures what matters to patients (see Section 2.1: Patient-informed endpoints).

✓ Align internal teams (clinical, regulatory, biostatistics, digital) on how the endpoint fits the statistical analysis plan.

The DHT Steering Committee is a valuable first touchpoint for drug sponsors even when using well-established sDHT-derived endpoints, to help align on engagement pathways when the context of use changes.

Patient-centeredness isn’t optional; link the endpoint to aspects of health that are meaningful to patients in the specific context of use, including disease stage.

How the team reasoned their way to this engagement pathway

Because the sponsor already has an active IND and is planning a Phase 2 trial, the team prioritized early FDA dialogue to (1) clarify whether the proposed sDHT-derived endpoint is acceptable in principle, (2) align on what evidence is needed to support the endpoint in the specific context of use (early PD; disease modification; Phase 2), and (3) ensure the endpoint is clearly linked to outcomes that are meaningful to patients.

FDA explicitly encourages early engagement when sponsors are considering sDHTs in drug development, particularly when endpoints or approaches are novel (External Engagement with FDA, FDA, 2024).

Key questions the team needed to answer

Endpoint acceptability and role in Phase 2

Given that wearable-derived gait and mobility measures are well established in Parkinson’s disease, do regulators agree that continuous gait data from a wrist-worn accelerometer remain appropriate for use in a Phase 2 trial when applied in a later-stage PD population and real-world setting?

Is the proposed endpoint role (secondary or supportive) appropriate given the trial objectives, disease stage, and expected sources of variability, or would regulators recommend a different positioning at this stage of development?

Sponsors should justify endpoints derived from sDHTs and how the sDHT will be fit-for-purpose for the investigation.

“Meaningful to patients” linkage

How should the sponsor justify that the sDHT-derived mobility endpoint reflects meaningful aspects of health for people with Parkinson’s (e.g., function, independence, real-world mobility), rather than only technical sensitivity?

What evidence is needed to support interpretation (e.g., meaningful change thresholds, anchoring to patient experience or COAs)?

Patient experience data and clinical outcome assessments can inform endpoint selection and interpretation, including expectations related to meaningful change and interpretability.

Evidence expectations for validation in this context of use

Which elements of existing verification, analytical validation, and usability evidence remain applicable when the gait endpoint is deployed in a later-stage PD population, and where might additional analyses or data be needed?

How should validation be scoped to remain fit-for-purpose for this context of use, including considerations related to real-world deployment, assistive device use, increased variability, adherence, and missingness?

Verification and validation evidence should align with the specific context of use or intended use, rather than relying solely on prior evidence generated under different conditions.

What information the team assembled before engaging

The sponsor prepared a concise package that separated the conceptual rationale for using an established gait endpoint in a later-stage PD population from the evidence generated to date, including:

Proposed endpoint definition (what gait/mobility features; windowing; aggregation; missing data rules) and role in the statistical analysis plan

Evidence summary across verification/analytical validation/usability and any clinical validation signals

Patient-centered justification plan (e.g., qualitative work, anchoring strategy, and/or COA mapping) consistent with PFDD methods for endpoint interpretability

A focused list of questions tied to near-term Phase 2 decisions (endpoint positioning, evidence gaps, acceptability thresholds)

Engagement pathways considered

Why start with the DHT Steering Committee?
Although the sDHT-derived gait endpoint itself was well established, the sponsor’s initial challenge was determining how best to engage FDA given the change in context of use, including disease stage and endpoint role. The team therefore started by contacting the DHT Steering Committee at DHTsforDrugDevelopment@fda.hhs.gov to describe the proposed use of the gait endpoint and request guidance on appropriate engagement mechanisms.

Why a formal meeting was still necessary (Type C or Type B)?
Initial routing would not substitute for documented feedback on how existing evidence should be interpreted in the proposed context of use. The sponsor therefore planned to use FDA’s formal meeting process, either in a Type C meeting focused on the sDHT endpoint strategy, or inclusion in an upcoming Type B milestone meeting (e.g., EOP1 or EOP2), depending on development timing and agenda fit.

Why this pathway was selected

The team chose DHT Steering Committee outreach → formal meeting because it matched what they needed at each step:

The Steering Committee contact provided an entry point for drug sponsors using sDHTs, including help identifying appropriate engagement mechanisms.

A formal meeting provided an appropriate forum for documented feedback on (a) endpoint rationale and role, (b) validation evidence expectations and gaps, and (c) interpretation and patient meaningfulness.

Because Phase 2 planning is the stage at which endpoint roles and evidence plans are finalized, FDA’s emphasis on early engagement supported addressing these questions before progression to later-phase trials (External Engagement with FDA, FDA, 2024).

Why this scenario is plausible

FDA encourages early engagement for sDHT use in drug development. FDA also provides a clear mechanism for sponsors to obtain documented feedback on development questions through formal meetings (Type B/Type C) under PDUFA.

FDA guidance discusses the evidentiary expectations for using sDHTs to collect data in clinical investigations and the need for fit-for-purpose verification, validation, and usability aligned to the proposed context of use.

FDA guidance indicates that endpoints intended to support regulatory decision-making should be interpretable and grounded in what is meaningful to patients.

Scenario E: Internal misalignment delays digital endpoint adoption (cautionary tale)

A large pharmaceutical company’s digital health team identified a promising sDHT-derived endpoint for a respiratory indication. They proceeded to pilot the technology in an exploratory substudy without involving the regulatory affairs, biostatistics, or clinical outcome assessment teams. When results were shared internally, the regulatory team raised concerns that the validation approach wouldn’t meet FDA expectations. The biostatistics team noted the data format was incompatible with their analysis pipelines. The opportunity to use the endpoint in the upcoming Phase 3 trial was lost.

What went wrong?

The digital team operated in a silo, without cross-functional alignment.

No early regulatory engagement occurred to calibrate expectations.

Data and statistical considerations were addressed too late.

What should have happened?

✓ Cross-functional alignment (Section 2.3: Stakeholder alignment, Section 3.1: Preparing for effective regulator engagement) before piloting the technology

✓ Early internal consensus on the endpoint’s intended role (exploratory, secondary, or primary)

✓ DHT Steering Committee outreach to confirm the validation approach was on track

✓ Coordinated planning to ensure data formats, SAP integration, and regulatory positioning were addressed in parallel

Internal silos are a leading cause of failed sDHT adoption.

Early cross-functional alignment is not bureaucratic overhead—it’s risk mitigation.

Exploratory substudies still require strategic planning if results are intended to inform future registration.

How the team reasoned their way to this engagement pathway

Because the digital endpoint was intended to inform a future Phase 3 strategy, the “pilot” needed to be treated as strategic evidence generation, not just a feasibility experiment. sDHT use in clinical investigations hinges on fit-for-purpose planning, quality verification and validation evidence, and reliable data handling, regardless of whether the use is exploratory.

What went wrong?

1) They piloted without defining the endpoint’s intended role and interpretation

If the endpoint might later influence confirmatory development, the team needed early agreement on its intended role (whether it would remain exploratory, function as a secondary endpoint supporting interpretation of the primary outcome, or potentially evolve toward a primary endpoint) and what “success” would mean in each case (e.g., interpretability, meaningful change). FDA’s PFDD methods guidance discusses fit-for-purpose selection/development of outcome assessments and the importance of interpretability for regulatory decision-making.

2) They didn’t calibrate expectations with FDA early enough

The team could have avoided “we collected the wrong evidence” by engaging FDA early, especially because novel DHT-derived endpoints often raise questions about evidentiary sufficiency. FDA encourages early engagement for sponsors considering sDHTs in drug development. (External Engagement with FDA, FDA, 2024).

3) They treated data and statistics as an afterthought

The biostatistics concern (“incompatible format”) is a predictable failure mode when data standards and pipelines aren’t planned up front. There are clear expectations for standardized study data submissions and technical conformance, and those expectations should shape how data are structured, documented, and transferred from the start.

Relatedly, guidance on electronic source data discusses traceability, data integrity, and reliable capture processes—issues that often intersect with sDHT data flows and metadata.

What should have happened

Step 1 — Cross-functional alignment before any pilot

The team should have aligned clinical/regulatory/COA/biostats/digital on:

Endpoint intent (exploratory vs secondary vs primary),

Context of use (population, setting, duration),

Interpretability plan (what constitutes meaningful change),

Data standards and analysis pipeline requirements.

Step 2 — Early FDA orientation/routing for DHT endpoint questions

Before investing in a pilot intended to influence Phase 3, the sponsor should have contacted FDA to describe the proposed endpoint.

Step 3 — Formal FDA discussion timed to Phase 2/Phase 3 planning

The sponsor should have used a formal meeting to obtain documented feedback on:

Evidentiary expectations for the endpoint (verification/validation/usability),

Endpoint positioning (exploratory vs secondary),

How the endpoint would be interpreted and tied to meaningful aspects of health.

Why this scenario is plausible

This failure mode is plausible because expectations for sDHT-derived endpoints (fit-for-purpose planning; verification/validation/usability; reliable data handling) shape whether a dataset can be interpreted and used to support downstream decisions.

It is also plausible because the loss of Phase 3 opportunity can follow from missing early engagement when novel approaches are being considered and early alignment on data standards and submission readiness when data may later support regulatory decisions.

Scenario F: Consortium-led biomarker for respiratory function

Multiple pharmaceutical companies, academic researchers, and a patient advocacy group have formed a consortium to develop and validate a digital biomarker for respiratory function in a rare pulmonary disease. No single sponsor can justify the investment alone, but collectively they can generate evidence that would benefit the entire field. They want to pursue DDT qualification so the biomarker can be used across multiple development programs.

Consortium structure requires governance and data-sharing agreements.

The biomarker pathway is appropriate since the measure indicates physiological status.

Qualification requires substantial evidence and multi-year commitment.

✓ Establish consortium governance including IP agreements, data sharing protocols, and decision-making processes.

✓ Submit a Letter of Intent (LOI) to FDA’s Biomarker Qualification Program describing the proposed biomarker and context of use or intended use.

✓ Develop a Qualification Plan (QP) based on FDA feedback, outlining planned validation studies.

✓ Execute validation studies across consortium members, pooling data to build a robust evidence package.

✓ Submit Full Qualification Package (FQP) when evidence is complete.

✓ Consider parallel MDDT qualification if the biomarker could also support medical device development.

Precompetitive collaboration makes qualification feasible when no single sponsor can bear the cost.

Governance and data-sharing agreements must be established early.

FDA encourages consortium-led qualification efforts.

How the team reasoned their way to this engagement pathway

Because no single sponsor could justify the investment to develop and validate the digital biomarker alone—and because the goal was reuse across multiple drug/biologic programs—the consortium chose FDA’s Drug Development Tool (DDT) qualification framework.

Key questions the consortium needed to answer

Is “biomarker” (not COA) the right evidentiary framing?

The consortium explicitly defined the measure as a biomarker because it indicates physiological status (i.e., a defined characteristic measured as an indicator of normal/pathogenic biological processes or responses), rather than an assessment of how a person feels, functions, or survives. (About Biomarkers and Qualification, FDA, 2021).

What is the exact context of use, and can it be standardized across programs?

Because qualification is tied to a specific context of use, the consortium needed to define: disease population, setting, endpoint role (e.g., monitoring/response), and how the biomarker would be interpreted across trials.

What evidence is required—and how will the consortium generate it credibly?

Qualification is evidence-intensive and typically multi-year. The consortium needed a plan for analytic validity, clinical validation/interpretation, and generalizability, including pooling data across members with consistent protocols. FDA’s Biomarker Qualification Program resources define the process (e.g., letter of intent, qualification packages) expected at each stage. (Resources for Biomarker Requestors, FDA, 2025)

What governance is needed to make pooled evidence possible?

Because their submission depends on an integrated evidence package, the consortium needed up-front agreements covering IP, data standards, data sharing, and decision rights so that evidence generation could proceed on a stable footing.

What the consortium assembled before engaging

To support an actionable FDA discussion at the earliest stage, the consortium prepared:

A draft biomarker definition and measurement specification (inputs, algorithms, outputs, quality controls).

A proposed context of use statement suitable for qualification, with intended application across multiple development programs.

A governance summary (membership, data-sharing principles, study harmonization approach), to demonstrate feasibility of pooled evidence generation

Engagement pathways considered (and why this one was selected)

Why the consortium pursued DDT/Biomarker qualification (vs program-specific meetings)
Program-specific engagement would not achieve the consortium’s goal: a biomarker that can be used across multiple programs without needing acceptability review each time. FDA’s DDT qualification framework exists specifically for tools intended for use “over time, in multiple drug development programs.”

Why parallel MDDT qualification was considered

The consortium also considered whether the same measure could support medical device development, in which case a separate qualification pathway may be relevant. FDA’s MDDT program is a voluntary mechanism to qualify tools that device sponsors can use in the development and evaluation of medical devices.

Why this pathway was selected

The consortium selected the Biomarker Qualification Program under FDA’s DDT framework in order to:

Support precompetitive development of a biomarker intended to benefit the broader field, rather than a single product development program

Pursue formal qualification of the biomarker for a clearly defined context of use, with structured FDA interaction across staged submissions

Support pooled evidence generation across multiple contributors, consistent with consortium-based governance, shared data standards, and harmonized study designs

Why this scenario is plausible

FDA has an established method for qualification of drug development tools—explicitly including biomarkers—built around staged submissions (LOI, QP, FQP) and iterative FDA interaction to guide evidence generation toward a prospectively specified context of use.

It is plausible that a consortium would pursue qualification because the program is intended for tools used across multiple development programs and typically requires substantial evidence that is difficult for any single sponsor to generate alone.

Finally, the scenario’s emphasis on governance and data-sharing is plausible because qualification can leverage pooled, coherent evidence and a stable context of use, conditions that can require formal agreements and harmonized protocols across contributors.

Scenario G: Combination product with sDHT component

A company is developing an integrated system that combines a drug delivery device with an sDHT that monitors patient response and adjusts dosing recommendations. The system involves both drug and device components, and the company is unsure which FDA center has primary jurisdiction.

Combination products require clarity on lead center before engagement strategy can be determined.

The sDHT component may need both device-focused (Q-Sub) and drug-focused (PDUFA) engagement.

Cross-center coordination is essential.

✓ Contact the Office of Combination Products (combination@fda.gov) or submit a Request for Designation (RFD) to clarify which center has primary jurisdiction.

If CDER/CBER leads: Use PDUFA meetings for drug-related questions; Q-Subs for device-specific questions

If CDRH leads: Use Q-Subs as primary mechanism; coordinate with CDER/CBER on drug components

✓ Email the DHT Steering Committee to ensure cross-center coordination on the sDHT aspects.

✓ Develop a unified regulatory strategy that addresses both drug and device evidentiary requirements.

Combination products require upfront jurisdictional clarity.

The DHT Steering Committee can help coordinate when sDHTs span regulatory ecosystems.

How the team reasoned their way to this engagement pathway

Because the product combines drug and device elements, and the sDHT informs dosing recommendations, the team’s first step was to determine which FDA Center would lead the review. Jurisdiction is determined through established combination product processes, including, where appropriate, Requests for Designation, and that clarifying the lead Center early is foundational to an efficient engagement strategy (Office of Combination Products, FDA, 2024).

Key questions the team needed to answer

Lead Center and primary mode of action

Is the system’s primary mode of action primarily attributable to the drug (e.g., pharmacologic effect) or the device/digital function (e.g., algorithm-driven control/recommendation logic that meaningfully drives dosing decisions)?

Given that the primary mode of action drives jurisdiction, what Center is likely to be designated as lead?

RFD guidance describes how sponsors should present information needed for FDA to determine product classification and assignment, including primary mode of action considerations (How to Write a Request for Designation (RFD), FDA, 2018).

What questions are “drug” questions vs “device/software” questions

Which issues require drug-focused discussions (e.g., clinical pharmacology, dosing rationale, exposure–response, efficacy/safety endpoints)?

Which issues require device/software-focused discussions (e.g., software performance, verification/validation, cybersecurity, human factors, algorithm behavior and change control)?

How to manage cross-Center alignment for the sDHT component

How will the team ensure FDA receives a coherent picture of how the sDHT is used, validated, and controlled across the system lifecycle—especially if different Centers weigh different evidentiary considerations?

What information the team assembled before engaging

To make jurisdiction and engagement discussions efficient, the team prepared:

A concise description of the integrated system and each constituent part (drug, delivery device, sDHT)

A proposed intended use and explanation of how the system produces its primary therapeutic effect consistent with what FDA requests in an RFD (How to Write a Request for Designation (RFD), FDA, 2018)

A high-level evidence map that separates:
- drug development questions likely to be addressed via PDUFA meeting mechanisms, and
- device/software validation questions appropriate for device engagement mechanisms

Engagement pathways considered

Why start with the Office of Combination Products (OCP)

Because the product combines drug and device elements, the team could not select an engagement pathway until understanding which FDA Center would lead the review. FDA’s Office of Combination Products (OCP) is responsible for jurisdictional determinations for combination products and provides mechanisms for sponsors to clarify lead Center assignment. FDA provides Pre-Request for Designation (Pre-RFD) and Request for Designation (RFD) processes to address jurisdictional uncertainty and provides explicit instructions and contact points for these submissions (Jurisdictional Information, FDA, 2020; RFD Process, FDA, 2020).

Why involve the DHT Steering Committee

Because the sDHT component bridges drug-development and device/software concerns, the team also reached out to the DHT Steering Committee to support cross-Center alignment on the DHT aspects and to ensure appropriate routing of questions (Digital Health Technologies (DHTs) for Drug Development, FDA, 2025; External Engagement with FDA, FDA, 2024).

Why an RFD vs a Pre-RFD (and when each makes sense)

If the team needed a preliminary assessment to inform planning, a Pre-RFD is designed for that purpose (How to Prepare a Pre-Request for Designation (Pre-RFD), FDA, 2025).

If the team needed a formal jurisdictional determination, an RFD is the established pathway (How to Write a Request for Designation (RFD), FDA, 2018).

The pathway branches after lead Center is clarified
Once the lead Center is known, the engagement plan can be structured coherently:

If CDER/CBER leads: use drug/biologic meeting mechanisms for drug-led questions while using device-focused mechanisms for the sDHT/device-specific questions as appropriate.

If CDRH leads: use the Q-Submission program as the primary mechanism for device/software topics and coordinate drug questions with CDER/CBER as needed per combination product expectations.

The team selected OCP jurisdiction → Center-appropriate meetings (PDUFA and/or Q-Sub) with explicit cross-Center coordination because:

FDA’s combination product framework requires lead Center clarity before an engagement strategy can be efficiently planned.

FDA provides distinct, well-defined engagement mechanisms for drug/biologic questions versus device/software questions.

FDA encourages early engagement for sDHT use in drug development and provides a dedicated entry point (the DHT Steering Committee) that can help sponsors navigate sDHT-related questions spanning regulatory ecosystems.

Why this scenario is plausible

FDA has a formal process for resolving uncertainty about combination product jurisdiction, including RFD and Pre-RFD mechanisms managed through the Office of Combination Products.

It is plausible that the sponsor would need both drug-focused and device-focused interactions, because FDA provides distinct engagement frameworks for each domain, and combination products can require cross-Center coordination.

Real-world proof points

Apple atrial fibrillation history feature (MDDT qualification)

In December 2023, FDA qualified the Apple Atrial Fibrillation History feature as a Medical Device Development Tool—the first digital health technology to achieve MDDT qualification.

Significance:

Demonstrates that MDDT qualification for sDHTs is achievable

The qualified context of use or indicated use is specific: monitoring AFib burden in individuals with diagnosed atrial fibrillation

Key success factors:

✓ Clear, focused context of use or intended use

✓ Robust analytical validation against clinical reference standards

✓ Demonstrated relevance for device development decisions

Stride velocity 95th centile in Duchenne Muscular Dystrophy (EMA qualification)

In 2023, the European Medicines Agency (EMA) qualified stride velocity 95th centile (SV95C)—a measure derived from wearable sensors worn during daily life—as an acceptable secondary endpoint in Duchenne muscular dystrophy trials.

Significance:

First qualification of a sensor-derived endpoint for a neuromuscular disease

Addressed a clear unmet need: existing endpoints like the 6-minute walk test were inadequate for younger or non-ambulatory patients

Built on over a decade of collaborative work across industry, academia, regulators, and patient groups

Key success factors:

✓ Strong patient-centered rationale: the measure captures real-world ambulatory function meaningful to patients and families

✓ Extensive validation across multiple studies and sites

✓ Precompetitive collaboration that pooled resources and data

Relevance for FDA: While this qualification occurred through EMA, the evidentiary principles translate. A similar measure would likely pursue DDT qualification (COA pathway) with FDA, potentially alongside MDDT qualification for device applications.

Critical Path for Parkinson's (CPP) 3DT initiative

The Critical Path for Parkinson’s Consortium launched the Digital Drug Development Tools (3DT) initiative to advance regulatory acceptance of digital measures in Parkinson’s disease trials. The initiative engaged FDA through a Critical Path Innovation Meeting (CPIM) to discuss digital biomarker development.

Significance:

Demonstrates how consortia can use CPIMs for early, product-agnostic regulatory dialogue

The initiative is building shared evidence and tools that multiple sponsors can leverage

FDA engagement helped align validation approaches across the consortium

Key success factors:

✓ Precompetitive structure with multiple industry, academic, and patient partners

✓ Clear focus on a specific therapeutic area with strong patient advocacy support

✓ Proactive regulatory engagement before individual sponsors committed resources

DATAcc by DiMe collaborative community

key takeaways

These examples further demonstrate that strategic sDHT adoption requires matching your technology to the correct regulatory pathway while ensuring validation evidence is fit-for-purpose.

1. Identify your primary regulatory target.
Determine if the sDHT is the medical device itself (CDRH lead) or a measurement tool for a drug/biologic (CDER/CBER lead) to select the right engagement channel.

2. Prioritize “Context of Use” (COU).
Clearly define who the technology is for and what it measures. Regulatory success, like the Apple AFib qualification, depends on a narrow, well-supported COU.

3. Break down internal silos.
Align digital, clinical, and regulatory teams early. Internal misalignment on data formats or validation standards is a leading cause of failed digital endpoint adoption.

4. Leverage precompetitive collaboration.
Use consortia and “product-agnostic” meetings to share the burden of evidence for novel biomarkers and build industry-wide precedent.

1. Why digital?

2. Your core strategy

3. Engage regulators

4. Your validation strategy

5. Operationalize your tech

6. Refine your strategy

3.4 Examples in practice

Scenarios and success stories

Overview

Mapping your journey through examples

Hypothetical scenarios

Real-world proof points

How to use the illustrative scenarios

in practice

Medical device trial illustrative scenarios

Scenario A: SaMD for arrhythmia detection

How the team reasoned their way to this engagement pathway

Key questions the team needed to answer

Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program

What information the team had available

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

Engagement pathways considered

Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program

Qualification of Medical Device Development Tools

Why a Q-Submission was selected

Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

Artificial Intelligence and Machine Learning in Software as a Medical Device

Why this scenario is plausible

Scenario B: Wearable sensor for pulmonary function monitoring

How the team reasoned their way to this engagement pathway

Key questions the team needed to answer

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

What information the team had available

Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program

Engagement pathways considered

Why a coordinated Q-Submission strategy was selected

Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

Why this scenario is plausible

Scenario C: AI-Enabled sDHT for neurological assessment

How the team reasoned their way to this engagement pathway

Key questions the team needed to answer

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions

What information the developer had before engaging

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions

Engagement pathways considered

Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program

Why this pathway was selected

Why this scenario is plausible

Drug/Biologic Trial Illustrative Scenarios

Scenario D: Digital endpoint in Parkinson's disease trial

How the team reasoned their way to this engagement pathway

Key questions the team needed to answer

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

Patient-Focused Drug Development: Incorporating Clinical Outcome Assessments Into Endpoints for Regulatory Decision-Making

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

What information the team assembled before engaging

Engagement pathways considered

Formal Meetings Between the FDA and Sponsors or Applicants of PDUFA Products Guidance for Industry

Why this pathway was selected

Why this scenario is plausible

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

Patient-Focused Drug Development: Incorporating Clinical Outcome Assessments Into Endpoints for Regulatory Decision-Making

Scenario E: Internal misalignment delays digital endpoint adoption (cautionary tale)

How the team reasoned their way to this engagement pathway

Digital Health Technologies for Remote Data Acquisition in Clinical Investigations

What went wrong?

Patient-Focused Drug Development: Selecting, Developing, or Modifying Fit-for-Purpose Clinical Outcome Assessments

Providing Regulatory Submissions in Electronic Format — Standardized Study Data

Electronic Source Data in Clinical Investigations

What should have happened

Why this scenario is plausible

Scenario F: Consortium-led biomarker for respiratory function

Patient-Focused Drug Development: Selecting, Developing, or Modifying Fit-for-Purpose Clinical Outcome Assessments

How the team reasoned their way to this engagement pathway

Drug Development Tool (DDT) Qualification Programs

Key questions the consortium needed to answer