How to use this case study
This example separates technical correctness from clinical usefulness. Follow one risk-score output from input eligibility through calculation, presentation and clinical action, and challenge every assumption that could change its meaning.
Case at a glance
A web-based application uses routinely collected adult-patient observations to calculate a deterioration risk category for use by trained hospital clinicians. It supports prioritisation of review but does not diagnose a condition, prescribe treatment or replace local escalation procedures.
Clinical value
Consistent prioritisation of patients who may benefit from earlier professional review.
Software boundary
Input validation, calculation, user interface, records, integration and deployment configuration.
Principal uncertainty
Whether performance generalises across populations, workflows and data-quality conditions.
Human decision
A qualified clinician interprets the output with the complete clinical picture.
Control the clinical claim
The software is intended to calculate and display a predefined deterioration risk category from specified observations for adult inpatients, to support prioritisation of assessment by trained healthcare professionals. It is not intended to diagnose, recommend treatment or provide the sole basis for clinical action.
The intended population, setting, input window, user and action determine both validation and risk. Extending to children, community care or autonomous alerts would materially change the device. Use MTL-119 — Clinical and Performance Evaluation.
Treat input data as a controlled interface
Interface testing must demonstrate clinical meaning, not only successful message transport. Apply MTL-111 — Data, Connectivity and Interoperability.
Specify behaviour at the clinical boundaries
- The software shall calculate only when the patient and input data satisfy the approved eligibility and completeness rules.
- The displayed output shall identify its calculation time, input window and applicable limitations.
- Missing, stale, implausible or incompatible inputs shall produce a defined response rather than an unqualified score.
- The implemented calculation and thresholds shall be uniquely versioned and reproducible.
- Users shall be able to inspect the observations contributing to the output.
- Corrections to source observations shall trigger defined recalculation and audit behaviour.
- The software shall present escalation guidance without implying autonomous diagnosis or treatment.
Consider false reassurance and alarm burden together
False low category
A deteriorating patient receives delayed review. Control eligibility, data quality, validated thresholds, presentation and clinical fallback.
False high category
Excessive alerts divert resources and reduce trust. Validate specificity and monitor workload and overrides.
Stale calculation
An old output appears current after new observations arrive. Display time and state; define refresh and invalidation.
Population shift
Performance changes in a site or subgroup not represented in validation. Define applicability and monitor stratified outcomes.
Risk controls may include clinical workflow and information presentation as well as code. Apply MTL-114 — Medical-device Risk Management.
Make the algorithm a controlled software item
The architecture separates input adapters, clinical eligibility, calculation, presentation, records and audit. The approved algorithm artefact includes formulae, thresholds, units, missing-data rules and version. Automated tests use locked clinical examples and boundary cases. Build, dependency and deployment records link the released service to that artefact.
The software lifecycle follows MTL-108 — Software Lifecycle, including anomaly evaluation and configuration control.
Layer analytical and clinical evidence
Clinical association
Why the selected observations and calculated category relate to the target clinical state.
Technical performance
Correct implementation, input handling, repeatability, boundary behaviour and reproducibility.
Clinical performance
Sensitivity, specificity, calibration, subgroups, setting, workflow and comparison against reference outcomes.
Human interpretation
Whether intended users understand output, limitations, contributing data and required actions.
Follow one false-reassurance thread
Release evidence and operations together
Release approval identifies source, algorithm, data contract, dependencies, infrastructure, clinical evidence, known anomalies, monitoring thresholds, rollback and user communication. A technically successful deployment is not a released medical-device configuration until those elements agree.
Use a new hospital population to test change control
A new customer has a larger oncology population and different observation frequency. Before deployment, the manufacturer must determine whether the intended population and evidence apply, assess subgroup performance and workflow, validate interface semantics, define monitoring and decide whether new clinical evidence, labelling or regulatory action is required.
Local configuration cannot be used to disguise expansion beyond the validated intended purpose.
Questions to challenge the case
- What exact clinical action is the output intended to support?
- When should the software refuse to calculate?
- Can a clinician see why an output was produced?
- Which subgroups require separate performance analysis?
- What constitutes a new algorithm version?
- Which post-market measures reveal performance drift or poor workflow fit?