Functionality Forensics

Module 1 established gate one: whether the product has a medical purpose. This module is gate two: whether the software has sufficient functionality to be a medical device, meaning it does something with the information it handles rather than merely storing, carrying, or displaying it.

The MHRA's DMHT guidance organises functionality into categories A to G, running from passive provision and simple storage or display of information at the bottom, through transparent rule-based outputs in the middle, to adaptive, personalised, and machine-learned outputs at the top. The further up the ladder a function sits, the harder it is to keep out of SaMD scope and the higher its likely classification.

In practice, almost every contested case turns on one boundary: Category D against Category F, transparent rules against adaptive logic. That boundary is this module's subject.

The full category table is in the source below; what the guidance does not give you is a way to apply it to a real product, which is what follows.

The distinction matters for classification but is frequently misapplied because the boundary between fixed rules and adaptive logic is not always visible in a product specification. Configurable logic stays in the lower categories; adaptive logic does not.

The MHRA DMHT guidance describes Category D outputs as those where the underlying logic is transparent enough that a typical user can verify the result independently. The guidance does not define what verification requires in practice.

The test below operationalises it in two layers, and the distinction between them matters. The first layer describes what the function is, and decides whether Category D is available at all.

The second describes what you can prove, and decides whether a Category D claim survives a reviewer. A function's category does not change with the state of the manufacturer's evidence file: an undefended claim is not the same as a wrong one.

The numeric thresholds are F&G Strategy's working definitions, calibrated to what a clinically unsupervised user can reasonably be expected to do; they are not published MHRA thresholds, and they are screens, not cliff edges.

Multi-week lookback windows are one of the most common misclassification triggers in DMHT products because developers and advisors assume temporal analysis automatically implies adaptive logic, when the determining factor is what the logic does with the data window, not how large the window is. “Analyses 4 weeks of data” does not automatically imply Category F.

The question is what the logic does with that window.