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.

One caveat before the table: reacting to historical data does not by itself make logic adaptive. A fixed, disclosed threshold rule applied over a window of the user's history remains on the configurable side, as the lookback section below works through; adaptive means the rules or thresholds themselves move with the individual user.

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, and its Note 1 sets six conditions that must all be met before the category is available at all: information about intended use and limitations, about development and validation, about how the tool works; presentation that makes it easily verifiable; signposting; and user studies evidencing that a typical user can reliably detect an incorrect score without additional aids such as a calculator. Note the consequence: evidence is constitutive, not decorative.

A task claimed as Category D without the user studies does not hold the category with a weak file; it fails Note 1 and is assessed as E, F or G. The test below organises the six conditions into two working layers for assessment.

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.