A Camera Can Estimate a Pulse. Clinical Readiness Is a Different System.

The number is 72.

It appears in green on a phone screen after the front camera watches a face for 30 seconds. A second device shows 73. The waveform looks periodic. The demo works.

That result is technically meaningful. A camera has captured enough variation in reflected light for software to recover a pulse-related signal and estimate a rate. It is also the point where product teams are most tempted to make a category error.

The demo answered one question: can this pipeline produce a plausible estimate under these conditions?

The green number quietly encourages much larger assumptions. Is it reliable on another phone? In another room? With motion, makeup, facial hair, darker or lighter skin, compression, dropped frames, an irregular pulse, or poor circulation? Does the system know when the signal is unusable? Who is expected to act on the result? What harm follows if it is wrong, delayed, or absent? Is the claim a wellness observation, a clinical measurement, a screening signal, or an input to treatment?

None of those questions is answered by 72.

A camera pulse algorithm can be real without the product being clinically ready. Clinical readiness is not a more accurate model added to the same demo. It is a different system built around a precise intended use, a controlled measurement chain, appropriate analytical and clinical evidence, honest failure behavior, usable workflow, lifecycle governance, and claims that do not outrun any of them.

The signal is one component. The claim belongs to the whole system.

The camera never sees a pulse

Remote photoplethysmography (rPPG) estimates cardiovascular activity from video without a contact sensor. As blood volume changes with the cardiac cycle, it produces small changes in how skin absorbs and reflects light. A camera records pixels, not physiology. Software attempts to isolate the physiological component from everything else changing in those pixels.

A typical pipeline detects and tracks a face, selects one or more skin regions, reduces their red, green, and blue values into temporal traces, suppresses noise, extracts a pulse-related waveform, and estimates a rate. A major 2026 rPPG clinical-translation roadmap in npj Digital Medicine describes that pipeline and the field's progress across data, camera configuration, region selection, algorithms, filtering, and evaluation.

The physics is credible. The measurement problem is still difficult.

Motion changes far more pixels than pulsatile blood flow does. Automatic exposure and white balance alter the signal the algorithm receives. Illumination can change in color, direction, and intensity. Video compression removes information. Nominal frame rate can hide uneven frame timing and dropped frames. Face tracking can move the region of interest between tissue, hair, shadows, and background. The camera model, operating system, browser, capture API, resolution, and preprocessing path all become part of the instrument.

This is the first systems consequence: the model does not receive “a face.” It receives the output of an acquisition stack with its own state, timing, transformations, and failure modes.

A clean waveform proves that the stack can work. It does not establish where it works reliably.

A demonstration establishes feasibility, not readiness

Technical feasibility is a legitimate milestone. It can show that the optical signal is present, the implementation can recover it, and a product concept deserves further investment. The mistake is allowing that milestone to inherit meanings it never tested.

Suppose a prototype estimates pulse rate within a few beats per minute of a reference monitor for ten still colleagues under office lighting. That result may justify a larger experiment. It does not justify a claim about accuracy across the intended population. The participants were convenient, the setting was narrow, difficult samples may have been excluded, and the team that built the system also knew how to make the capture succeed.

Even a strong public benchmark does not close the gap. A held-out test set can measure generalization within the distributions and labels represented by that dataset. It cannot establish performance for camera pipelines, patient characteristics, workflows, or failure consequences the dataset does not contain.

The 2026 roadmap is useful precisely because it does not reduce translation to a leaderboard. It identifies motion, illumination, compression, frame-rate variability, data scarcity, skin-region selection, skin-tone diversity, and device configuration as linked concerns. Its clinic-acquired demonstration reports strong signal agreement under motion-stable, well-controlled conditions, using several complementary metrics. That is valuable proof of feasibility. The conditions are part of the result, not a footnote to be removed from it.

Clinical readiness begins when conditions stop being incidental and become part of the product definition.

Intended use comes before the validation plan

Teams often begin with an algorithm, calculate its accuracy, and write the product claim afterward. In health technology, that order is backwards.

The intended use defines what the system is for. It identifies the output, user, population, setting, workflow, and medical purpose, if any. It also determines which errors matter. The U.S. Food and Drug Administration's Digital Health Policy Navigator tells developers to identify each software function and its intended use, including any disease or condition and patient population, when considering whether a function may be a medical device.

Compare two proposed uses of the same pulse-estimation algorithm.

One gives a seated adult a nonmedical fitness observation when capture quality is high. The result is not used to diagnose a condition, direct care, or trigger an urgent action.

The other supplies a pulse measurement to a clinician during remote triage. A missing or biased result could alter whether the clinician escalates the encounter.

The underlying signal code might be identical. The products are not. Their users, consequences, evidence needs, interface behavior, oversight, and regulatory analysis differ.

“Camera-based vital signs” is therefore not an intended use. It is a technology category. “Accurate pulse” is not an intended use either. Accuracy has no adequate meaning until the team specifies for whom, within which operating range, on what hardware, under which conditions, against which reference, and for what decision.

The label cannot be the final copywriting step because it defines the validation problem.

The evidence layers answer different questions

The 2017 IMDRF N41 clinical-evaluation framework separates valid clinical association, analytical or technical validation, and clinical validation. FDA issued the IMDRF document as guidance in 2017, but withdrew that guidance on January 6, 2026. Withdrawn guidance no longer represents FDA's current thinking.

I use clinical readiness and the expanded table below as an engineering framework, not as a formal FDA status or an IMDRF taxonomy. Technical feasibility is an earlier engineering milestone. Regulatory status is a separate, jurisdiction-specific determination tied to a particular product and claim.

These layers are related, but none substitutes for another.

Evidence layer	Question it answers	What credible evidence must be tied to
Technical feasibility	Can the proposed pipeline recover a pulse-related signal under defined conditions?	Prototype, capture conditions, reference, and observed result
Analytical validation	Does the complete system generate an accurate, reliable, and precise technical output?	Intended devices, population, operating envelope, reference method, failure rules, and version
Valid clinical association	Is the output scientifically connected to the targeted physiological or clinical state?	Exact output and exact healthcare situation claimed
Clinical validation	Does the output achieve the intended clinically meaningful use in the target setting and population?	Intended user, workflow, population, setting, and patient-relevant purpose
Operational safety	Can people use, interpret, reject, escalate, and maintain the system safely?	Human factors, quality controls, monitoring, security, privacy, and change management
Regulatory status	May this particular product be marketed for this particular use in this jurisdiction?	Submitted device, indications, labeling, pathway, and authorized configuration

This is not a ladder that an algorithm climbs by accumulating accuracy points. Each layer needs evidence designed for its own question.

An excellent pulse-rate comparison cannot validate a downstream claim about a disease. A valid clinical association cannot prove that a particular camera implementation measures the input reliably. Regulatory clearance for one bounded device does not transfer to another implementation using the same general technique.

The distinctions prevent evidence from being spent twice.

Validate the measurement system, not only the estimator

An rPPG product has at least four interacting cadences: camera acquisition, region tracking, physiological analysis, and user-interface updates. Treating them as one frame-rate number hides important failure modes.

Acquisition needs actual timestamps, not the assumption that a nominal 30-frame-per-second stream arrived evenly. Region tracking may need to react quickly to movement while signal analysis requires a longer stable window. The interface may update more slowly to avoid turning transient noise into a false sense of precision. Faster visual refresh is not the same as better physiological measurement.

Analytical validation must cover the complete path from photons to displayed result. That includes supported cameras and optics, capture resolution, exposure behavior, distance, angle, lighting, motion, occlusion, video transforms, frame timing, region selection, filtering, estimator logic, quality thresholds, and display rules. If cloud processing is involved, the transmitted representation, server version, latency, and failure behavior join the validated configuration.

Reference design matters just as much. The comparator must be appropriate for the claimed output, synchronized well enough for the analysis, and operated correctly. A timing offset can make two valid signals appear different. A weak reference can make the camera appear better or worse than it is. “Ground truth” is not a property granted by a file name.

No single metric can describe agreement. Correlation shows whether values move together, but a system can correlate strongly while remaining systematically biased. Mean absolute error and root mean square error quantify magnitude in different ways. Bland-Altman analysis exposes bias and dispersion across the operating range. The npj Digital Medicine roadmap recommends a multi-metric view for exactly this reason.

Subgroup and condition results must remain visible. An overall average can conceal poor performance in a population or environment that the intended use includes. If sample quality differs systematically with skin tone, movement, age, device, or setting, the product cannot average those differences away and still claim a general operating envelope.

The system also needs a defined no-result behavior. An estimator that emits a number from every video may look robust while converting corrupted input into false confidence. A safer design may reject poor captures, request another attempt, or route the user to another measurement method.

That creates a second measurement problem: coverage. Teams must evaluate both error when the system reports and the share of intended encounters in which it can report safely. They must also inspect inappropriate reporting, when a number is emitted despite inadequate signal quality.

Accuracy conditional on success can hide a product that fails the people or conditions it finds difficult.

Rejection is not outside performance. It is one of the outputs being validated.

Clinical validation is not a larger test set

Analytical validation asks whether the system produces the technical output correctly. Clinical validation asks whether that output is clinically meaningful for the intended use in the target healthcare situation.

The distinction becomes clear when the claim extends beyond a pulse-rate number. A pulse-related waveform does not automatically validate a conclusion derived from it. If a product uses the measurement to screen, prioritize, predict, diagnose, or guide a clinical action, the connection between output and intended purpose needs its own evidence. The strength and design of that evidence should follow the risk and claim.

A defensible clinical study should resemble the use being claimed in the dimensions that can affect safety and performance. The intended population should be represented, and intended users should follow realistic instructions. The environment and supported hardware should match the product configuration. Exclusions, failed captures, protocol deviations, and missing outputs should be reported rather than disappearing during dataset cleanup. The analysis should be specified before results invite convenient thresholds.

Clinical validation also includes workflow consequences. Can the user understand what the number represents? Does the interface distinguish a current measurement from an estimate based on an earlier window? Are confidence and capture quality communicated in a way that improves decisions rather than decorates the screen? Is there a clear response when the product cannot measure? Can the user recognize that the output is outside the intended use?

A clinically meaningful output lives inside a workflow. Removing the workflow from validation removes part of the claim.

A clearance shows what bounded readiness looks like

FDA-cleared camera-based pulse products make these distinctions concrete.

On May 21, 2026, the FDA issued a substantially equivalent decision for PanopticAI Vital Signs, K260066, a Class II software device under product code QME. Its 510(k) summary says the product uses facial video from specified iPhone or iPad hardware and rPPG to estimate pulse rate. It also uses upper-torso motion to estimate respiratory rate.

The interesting part is not merely that the product was cleared. It is how narrowly the use is described.

The device is intended for noninvasive spot measurement while the subject is still. It is for healthcare professionals and adults ages 18 to 60 who do not require critical care or continuous vital-sign monitoring. It is not intended for continuous monitoring, apnea detection, independently directing therapy, or serving as the sole method for assessing physical condition.

Those constraints are not embarrassment around the technology. They are part of the safety and evidence argument. Stillness reduces a major source of optical noise. Specified hardware limits acquisition variability. A spot check is a different problem from continuous monitoring. A professional user and a complementary role create a different workflow from autonomous consumer diagnosis.

The clearance means the FDA found that submitted device substantially equivalent for its stated use through the 510(k) pathway. It does not mean the FDA approved rPPG as a technology category. It does not validate every webcam implementation, every population, every environment, or every inference someone might derive from a pulse signal.

Regulatory status attaches to a bounded product. Borrowing the word “cleared” from a neighboring product while discarding its boundaries is not clinical translation.

Clinical readiness continues after the study

Even a well-validated system can drift when its environment changes. Consumer camera stacks are not static laboratory instruments. A phone model changes its sensor and optics. An operating-system update changes exposure or video processing. A browser modifies capture behavior. A cloud service updates preprocessing. A model is retrained on new data. A team lowers the quality threshold to reduce user retries.

Each change may be reasonable. Each can alter the measurement system that produced the evidence.

Clinical readiness therefore requires configuration control and traceability. The team needs to know which software, model, camera, operating system, capture settings, and decision thresholds produced a result. It needs a change process that determines what must be retested and whether the intended use, risk analysis, labeling, or regulatory submission is affected.

It also needs post-deployment visibility. Aggregate accuracy is not enough. Teams need to see capture failure, no-result rates, inappropriate result rates, subgroup behavior, device-specific shifts, latency, user retries, and complaints. A monitoring program should be able to distinguish a weaker model from a changed camera pipeline or a new user population.

Privacy and security belong inside this system too. Facial video and physiological estimates are sensitive data even when the product does not retain raw frames. Data minimization, transport, processing location, retention, access, and incident response affect whether the system can be used responsibly in its intended setting.

The FDA's device software policy is function-specific and risk-based. The fact that software runs on a general-purpose phone does not settle its status. What the function does, how it is intended to be used, and what happens if it fails matter more than the familiarity of the hardware.

Build the claim and evidence together

A team can expose the real program before committing to a clinical claim by producing six linked artifacts in order:

1. Write the intended-use statement with output, user, population, setting, supported hardware, decision role, and explicit exclusions.
2. Map every proposed claim to the evidence needed to support it. Remove claims that rely on evidence from a different layer.
3. Specify the measurement system from acquisition through display, including timing, quality assessment, no-result behavior, and version boundaries.
4. Design the validation protocol before tuning against its results. Include the operating envelope, reference, metrics, subgroup analysis, coverage, and failure accounting.
5. Test the output inside the intended workflow, including interpretation, retries, escalation, and foreseeable misuse.
6. Define change control and post-deployment monitoring before routine updates begin.

This sequence may reveal that the intended claim is too broad for the available evidence. Narrowing it is not failure. A smaller honest claim can become a usable product and a stable base for later studies. A broad unsupported claim is a liability disguised as ambition.

The process also tells engineers what to improve. If low light causes appropriate rejection, the problem may be acquisition coverage. If the rate is biased within accepted captures, the problem may be analytical performance. If the measurement is accurate but users act on it incorrectly, the problem may be workflow or labeling. If the system measures pulse well but the proposed clinical conclusion lacks evidence, the gap is clinical association or validation.

“Improve the AI” is too vague to solve any of those failures.

Not every pulse estimator needs a clinical claim

There is a genuine boundary to this argument. A camera pulse experiment can be worthwhile without becoming a medical device. Research tools, educational demonstrations, fitness experiences, and low-risk general-wellness functions can have narrower purposes. In the United States, a function without an intended medical purpose may fall outside the device definition, while specific claims and circumstances still require careful analysis.

Clinical rigor should not be used as theater around every interesting signal-processing project. The correct standard follows the intended use and risk.

But teams cannot evade a clinical claim by calling the product “wellness” while its design, marketing, and workflow encourage people to use it for diagnosis, treatment, or urgent decisions. Intended use is reflected by more than one disclaimer. Product behavior communicates purpose too.

The practical boundary is simple: do not demand clinical evidence for a claim the product does not make, and do not make a clinical claim using evidence that only proves technical feasibility.

This is a product-engineering framework, not medical or legal advice. Regulatory requirements differ by jurisdiction, device, and use.

The green number is the beginning

The 72 on the screen remains impressive. Commodity cameras were not designed as clinical pulse instruments, yet careful engineering can recover physiological information from their video. The field has advanced from laboratory demonstrations toward bounded, cleared products.

Respecting that progress requires precision about what has been achieved.

The algorithm participates in every layer. It owns none of them alone.

Clinical readiness begins when the team stops asking only whether a camera can estimate a pulse and starts asking the complete question: reliable for whom, under which conditions, on which system, for what decision, with what evidence, and what happens when the camera should not speak?