The Clinical Maturity Lens.
Clinical maturity is the ability of a digital care system to remain safe and coherent under real-world user variability. The Lens is the method for evaluating it — before regulators or procurers force the question, and before real patients arrive and the product finds out what it does not know.
The question most evaluations don't ask.
Most clinical evaluations of digital health products ask a single question: does it work? That question is answered inside a trial, with a defined population, under conditions the product controls.
The Clinical Maturity Lens asks a different question: does it hold up when patients don't follow the plan? Real patients deviate. They push through pain. They stop at the first discomfort. They tell the product what they think it wants to hear. They arrive with conditions the product was not designed for, at moments the product was not designed for, saying things the product was not designed to hear.
Every digital health product has a designed population and a deployed population. When those drift, the product has to know. Clinical maturity is the discipline of making sure it does.
The non-diagnostic use principle.
Every product decision inside the Lens is taken within a single boundary: the product supports users functionally, without making medical decisions or replacing clinical care. Inside that boundary, three foundation questions have to be answered before any evaluation dimension applies.
Can this user safely benefit — or should they be redirected before they start? Assessment is the gate at the door. It asks whether the user arriving at the product is someone the product was designed for, and what the product does when the answer is no.
Should this user continue — and is the product itself behaving safely? Screening is the continuation check. It asks whether the user's situation has changed since they started, and whether the product itself is still operating inside its designed scope.
Present always. Managed continuously at user level and product level. Risk is not a stage. It runs throughout, at both levels. A product can be low-risk for the user while being high-risk for the system operating it, and vice versa.
Products that fail the foundation questions do not get further into the Lens. The evaluation dimensions assume the foundation is in place.
Eight dimensions, across three phases.
The Lens organises clinical logic across three phases — Define, Test, and When Things Go Wrong — containing eight evaluation dimensions in total. A ninth continuous layer, Signal Integrity, runs underneath all three phases.
Establishing what the product is for, who it is for, and whether its clinical reasoning can be followed from the first interaction onwards.
Who benefits from this product — and who could be harmed by it if the boundaries aren't clear?
The problem a product is built to solve is usually documented somewhere. The question is whether that definition is enforced in the product itself, or whether it lives only on record. When the deployed population drifts from the designed population, a poorly defined problem becomes a source of harm.
Who should NOT use this — and does the product know that and act on it?
Exclusion criteria are not about the edge cases a team knows about. They are about whether the product acts on the ones the team knows about. A product that lists its exclusions in the documentation, but has no mechanism to detect or redirect an excluded user, has not addressed edge cases — it has only described them.
From the first interaction, does every recommendation build on what came before — and can that chain be explained to a clinician?
Traceability is the clinical reasoning equivalent of an audit log. It asks whether a product's outputs can be reconstructed, step by step, back to the inputs and the logic that produced them. Without traceability, a clinician reviewing a product's recommendation has no basis to trust it, and no basis to disagree with it.
Pressure-testing clinical logic against real-world user variability, not against the idealised user the product was designed around.
How does your product respond to the user who pushes through pain, the one who stops at the first discomfort, and the one who tells you what they think you want to hear?
Variability tolerance evaluates whether the product's logic holds up when user behaviour does not match the textbook. The three archetypes — the pusher, the avoider, the pleaser — are not edge cases. They are the baseline population in any real deployment.
Does your product progress users based on time passing — or on how they're actually responding?
Time-based pathway logic is the most common failure mode in digital care products. Week 2 content arrives in week 2 regardless of whether the user completed week 1 meaningfully, missed it, or went backwards. Pathway flexibility asks whether the product adapts to actual user response, or whether it simply advances on the clock.
Evaluating what the product does at the edge of its competence, how it detects that it has arrived there, and what limits the damage when it gets something wrong.
Can a user flag that something feels wrong — and what happens when they do?
User-initiated escalation is the visible half of the escalation layer. It asks whether the product provides a clear route for a user to say something is wrong, whether that route produces a meaningful response, and whether the response is timely enough to matter.
What signals tell the product that a user is in trouble — and what does it do without waiting to be told?
Product-initiated escalation is the harder half. It asks whether the product has a perceptual layer that recognises when a user's state has changed, and whether it acts on that recognition without waiting for the user to raise the alarm. Users in clinical trouble often cannot or do not flag it themselves.
If your product has been quietly wrong for two weeks — what limits the damage?
Failure containment asks what happens during the time between something going wrong and someone noticing. It evaluates the rate at which undetected failure propagates, the mechanisms that limit the spread, and the scale of harm that is possible before the failure surfaces.
When a user's situation exceeds what the product can handle — who takes over, and how does that handoff actually happen?
Clinician override defines where the product ends. Without it, every user who arrives outside the product's competence remains inside the product anyway, because there is nowhere else to go. A documented handoff that does not exist operationally is not a handoff.
Does the system know when its inputs have become unreliable — when a user has stopped accurately communicating their state?
Signal Integrity runs underneath all three phases, continuously. It is not a stage the product passes through. It is the perceptual layer that asks whether the information the product is acting on still means what the product thinks it means.
Signal Integrity collapses quietly. A user who has been accurately reporting their state for weeks can stop doing so without the product ever knowing. A sensor that has been calibrated correctly can drift. A population of users can shift from the one the product was designed for to one it was not, while every individual input looks normal. Without Signal Integrity, the product carries on as if nothing has changed, because nothing visible has.
Three levels of clinical readiness.
Each level represents a distinct stage of a product's ability to handle real-world user variability safely and coherently. The Lens is used to locate a product on the spectrum and to identify what has to change to move up.
Suitable for learning, iteration, and demonstrating value. Not for user-facing clinical decisions.
Clinical logic is present but has not been pressure-tested against real-world variability. Foundation questions may be partly answered. Edge cases are documented but not acted on. Legitimate as a research or pilot tool, not as a deployed clinical system.
Some clinical logic in place. Known gaps. Not yet safe at scale.
Foundation questions are answered. Core dimensions function, but with named weaknesses. Escalation paths exist but are incomplete. Signal Integrity is partial. Deployable in contained settings with defined scope — not yet able to handle the full population arriving at the door.
Risk evaluated. Boundaries defined. Accountability clear. Monitoring continuous.
Foundation questions are answered and enforced, not just documented. All eight dimensions function inside the product's scope. Signal Integrity holds. Handoffs are operational, not theoretical. The product knows where its competence ends, and what happens when a user arrives at that edge.
Where the Lens sits in the product lifecycle.
The Clinical Maturity Lens operates upstream of regulatory compliance work, not in place of it. It is designed to be used before the safety case is written, before the clinical evaluation report is drafted, and before the product reaches a procurement gate. The output of a Lens engagement becomes an input to the work those functions do next.
- Asks whether the clinical logic behind the product is coherent
- Used at product definition and throughout design
- Output is a clinical reasoning review with named gaps
- Documents the hazard log, owns the safety case, signs the regulatory artefact
- Engaged when the DCB0129/0160 safety case is being built
- Output is a compliant safety case under the DCB standards
- Produces clinical evaluation reports, manages CE marking, handles MDR submission
- Engaged when the regulatory submission is being prepared
- Output is a submission-ready regulatory dossier
The Lens does not replace any of these functions. It makes them easier to do.
What the Lens is not.
The Lens does not produce DCB0129/0160 safety cases, MDR clinical evaluation reports, or CE marking documentation. Those are the work of Clinical Safety Officers and regulatory consultants. The Lens operates upstream of both.
The framework applies across therapy areas wherever a product supports clinical decisions or patient behaviour. Embedded clinical depth is strongest in MSK, respiratory, and paediatric rehabilitation. The framework itself is not specialty-specific.
The output of a Lens engagement is a clinical reasoning review, not a pass-fail certificate. It names what is working, what is not, and what has to change to move up the maturity spectrum. The next decision is the team's.
The first published read applies the Lens to the Tessa / NEDA chatbot incident of May 2023 — a case where the clinical reasoning behind the product was sound, and the gap between designed clinical scope and deployed clinical scope produced harm within days.
Read the Tessa case note →To read a product through the Clinical Maturity Lens, start with a short intake.