The Measure Comes First: Rethinking Validation for Digital Health Technology

Start with the measure, not the digital health tool (DHT)

Define the measure first: its Context of Use (the population, the concept of interest, and the decision it must support) dictates what each validation has to prove, clinical validation most of all, and how one evidence base serves both regulatory approval and HTA reimbursement.

Verification, analytical validation, clinical validation, and usability validation are often run as a checklist, bottom-up from the DHT. In practice the order is reversed. The measure’s Context of Use is defined first, and it dictates what each validation must prove. Clinical validation is shaped most directly: the decision, the population, and the comparator come straight from the measure, not from the sensor.

The Digital Medicine Society named the first three questions the V3 framework, since extended to V3+ with usability validation as a fourth (Goldsack et al., 2020; Bakker et al., 2025). It remains the cleanest way to organise the foundational evidence behind a digital measure. At DEEP we treat V3+ as a foundation and build on it with the further layers a measure needs to reach regulatory acceptance and real-world use.

Figure 1. The foundation of the DEEP evidence stack. Each layer answers a separate question, runs in a different setting, and is owned by a different team.

Verification: does the DHT capture the signal it claims to?

Verification is the engineering step. It confirms that the DHT produces sample-level output matching a calibrated reference under defined operating conditions. The work happens in computer models (in silico) and on the bench, before anyone wears the DHT. A wearable integrates several sensors with firmware and a housing, and verification covers the whole DHT, not one sensor. Two things sit outside this view: an algorithm running in a companion app or the cloud is verified in its own right, as are the non-analytical requirements of cybersecurity, privacy, latency, and reliability. Verification is the technology vendor’s evidence to produce. It tells you the DHT behaves to specification; it says nothing yet about whether the measure is useful.

Analytical validation: does the algorithm produce the right metric?

Analytical validation sits where the sensor stream meets the algorithm. The data-processing pipeline converts sample-level signals into a physiological metric, such as steps per minute, and that conversion is benchmarked against a reference method applied in people. It also tests whether performance holds across the conditions the DHT is likely to encounter, including movement, lighting, and skin tone. The reference stands in for ground truth; the aim is to get as close as the science allows. That is straightforward for step count and harder for a construct such as sleep stage, where no absolute ground truth exists. A disappointing result may reflect a weak reference, not a weak measure.

Clinical validation: does the measure support the decision you need to make?

Clinical validation asks the question that ultimately matters: in the population, condition, and use case you care about, does the measure identify, measure, or predict something that supports a real decision? The most common gap here is not statistical; it is a lack of clarity about the decision itself. A disciplined approach writes the interpretation claims out in advance, then designs the study to produce the evidence each needs. The measure must be sensitive enough to detect change, and the study must run where change is expected. The sponsor usually leads this step, because they know the decisions the measure must serve.

Usability validation: can the intended users use it at scale?

V3+ adds a fourth question: can the people who will actually use the DHT operate it correctly and consistently in the setting where it will be deployed? The first three layers can all succeed in controlled conditions and still leave a measure that fails in the field, because users cannot operate it as instructed, or because performance differs across users. Usability validation examines human factors, accessibility, and adherence across intended users; it is what lets a measure scale beyond a single well-supported study, and is usually shared between vendor and sponsor (Bakker et al., 2025).

One DHT, four layers

The four questions are easiest to see on a single DHT. For a wrist-worn step counter in a heart-failure trial: verification checks the accelerometer output against a calibrated reference on a vibration table; analytical validation benchmarks the step-detection algorithm against video-observed steps; clinical validation shows that daily step count discriminates New York Heart Association (NYHA) class II from III against the 6-minute walk test; and usability validation confirms representative patients can fit, charge, and wear it correctly. The signal travels the pipeline in Figure 2.

Figure 2. From sensor to physiological data. Verification covers the DHT and the raw signal; analytical validation covers the conversion of that signal into a physiological metric.

One evidence base, read many times

The V3+ layers do not replace the formal regulatory terms; they map onto them, and knowing the translation lets a single evidence base serve more than one submission (Table 1). Under the EU Medical Device Regulation (2017/745) the manufacturer carries out a clinical evaluation on clinical data (Article 61, Annex XIV). The In Vitro Diagnostic Regulation (2017/746) uses performance evaluation: scientific validity, analytical performance, and clinical performance (Article 56). The FDA, following the framework from the International Medical Device Regulators Forum (IMDRF) for software as a medical device, frames the same evidence as analytical validation and clinical performance. The science does not change; the document structure does.

One distinction is worth getting right. In the EU a DHT that is a medical device reaches the market through conformity assessment by a notified body, not the European Medicines Agency (EMA), and the notified body issues the certificate behind the CE mark. The FDA reviews DHTs and software directly.

Table 1. The same evidence under three regulatory vocabularies. The science is constant; the labels and document structure differ.

From approval to reimbursement

A second question waits on the other side of validation. Regulators must first accept the measure before it can reach patients. For the clinical outcome assessment (COA), acceptance from the EMA or the FDA can be sought through different qualification pathways. For the DHT itself, if it qualifies as a medical device, certification turns on whether it is safe and performs as intended: under the EU Medical Device Regulation (2017/745) this means validation evidence, a conformity assessment, and CE marking through a notified body. Reimbursement is a separate question. A health technology assessment (HTA) body advises the payers who decide what is funded, and asks for relative effect over standard of care, not absolute performance, so the question lands on clinical validation plus a comparator. For the measure, the HTA body must accept the COA as the right outcome measure; for a DHT intended for reimbursement in clinical practice, the EU Joint Clinical Assessment (Regulation (EU) 2021/2282) scopes this with a PICO (population, intervention, comparator, outcomes), with high-risk medical devices phased in from 2026.

Table 2. One finding, three readings. The same clinical-validation result is read by each decision-maker in its own language; only the HTA reading adds a comparator.

Where DEEP comes in

The four questions are a starting point, not the whole submission. On their own they do not demonstrate clinical effectiveness, real-world adoption and integration, or sustained performance after launch (Gomis-Pastor et al., 2024). Much of the evidence is generated most efficiently when pharma and technology partners work together early: the technology partner brings the DHT and algorithms, the sponsor brings the therapeutic context and the decisions the measure must serve. Neither side builds the full stack alone, and the handovers between them are a frequent point of failure. DEEP works at the intersection of measures, technologies, and use cases. If you would like a second look at your evidence stack, we can run a gap assessment and give specific guidance for your context of use.

References

Goldsack JC, Coravos A, Bakker JP, et al. Verification, analytical validation, and clinical validation (V3): the foundation of determining fit-for-purpose for Biometric Monitoring Technologies (BioMeTs). npj Digit Med. 2020;3:55.

Bakker JP, Barge R, Centra J, et al. V3+ extends the V3 framework to ensure user-centricity and scalability of sensor-based digital health technologies. npj Digit Med. 2025;8:51.

Gomis-Pastor M, Berdun J, Borras-Santos A, et al. Clinical validation of digital healthcare solutions: state of the art, challenges and opportunities. Healthcare (Basel). 2024;12(11):1057.

Regulation (EU) 2017/745 (Medical Device Regulation), Article 61 and Annex XIV.

Regulation (EU) 2017/746 (In Vitro Diagnostic Regulation), Article 56 and Annex XIII.

IMDRF Software as a Medical Device Working Group. Software as a Medical Device (SaMD): Clinical Evaluation. 2017.

Regulation (EU) 2021/2282 on health technology assessment.