← Assurance Evidence Base

Diagnostic / Predictive-ML Evaluation Track (core method)

Track: diagnostic-ML core · Version METH-0.2, signed off 7 September 2026 · Red-teamed against harness commit fcae485 · engine 0.5.0, rubric RUBRIC-0.4

Doc ID: METH-0.2 (core track) · Status: SIGNED OFF 2026-09-07 after a red-team pass against the running harness at commit fcae485 (scoring engine 0.5.0, RUBRIC-0.4); corrections recorded in §14 · Published: https://ukaievaluation.com/evidence/methodology-diagnostic-ml-v0.2.html · Source code: https://github.com/ukaievaluation/harness (Apache-2.0) Author: AI-drafted; reviewed and signed off by Mohamed SG Omar, Founder, UK AI Evaluation Ltd · Implementer: MZ Date: 2026-07-18, signed off 2026-09-07 · Supersedes: none · Companion (secondary track): METH-0.1 docs/methodology/assurance-methodology-v0.1.md Source consolidation: AAT-1 handoff addendum (2026-06-24); docs/diagnostic-ml-buildout/ (01-Operational-Playbook, 02-Dataset-Library, 05-Harness-Spec-and-Roadmap) — moved here 2026-08-02 from Diagnostic-ML-Evaluation-Buildout/ in the ops repo; AI_Diagnostic_Medicine_Assurance_Briefing.docx (ops repo); the running harness in app/harness/.

0. Status and honesty markers (read first)

This is a methodology-design document. It specifies how we run an independent, audit-grade evaluation of a diagnostic or predictive-ML system. It is not a record of a completed engagement.

Carry these markers into every artefact produced under this method:

• Pre-product / R&D. We have no completed external client evaluation yet. The method is being validated on synthetic and public data.
• No real patient data. The proof-corpus and detector-validation work run on synthetic and public datasets only. Real UK clinical data needs the clinical/institutional partner and the lawful route (NHS Secure Data Environment, Five Safes). We do not hold or process patient data outside those routes.
• Aligned, not endorsed. We are aligned with the direction of the MHRA, the AI Security Institute and the NHS. We are not affiliated, certified or endorsed by any of them, and no output of this method implies that we are.
• Severity bands are placeholders. The acceptance thresholds referenced here (app/scoring/constants.py, SUITE_SEVERITY_BANDS) are pre-registered placeholders pending clinical-advisor calibration. They are not settled clinical thresholds.

1. Purpose and position

This is the core of the UK AI Evaluation method. Our core product is independent assurance of diagnostic and predictive-ML systems: transferability, calibration, subgroup and drift testing for diagnostic and triage AI, with radiology, pathology and haematology as the lead deployment sectors.

The failure that breaks deployed clinical AI is rarely a jailbreak. It is a model that looks strong on the developer's own data and degrades on a new site, scanner, assay or population. The canonical proof is the Epic Sepsis Model: vendor-reported AUROC in the range 0.76 to 0.83, but on independent external validation (Wong et al., JAMA Internal Medicine 2021, 38,455 hospitalisations) it scored AUROC 0.63, sensitivity 33%, PPV 12%. A model can be ubiquitous, commercially successful and still substantially underperform its marketing once independently validated. That gap is the business, and closing the evidence around it is what this method does.

Two tracks, one scoring engine. METH-0.2 (this document) is the diagnostic / predictive-ML core track. METH-0.1 is the LLM assurance track, applied when the system under test is an LLM-based clinical assistant or agent, or as the LLM layer of a hybrid system. Both tracks write findings into the same §6 severity by likelihood scoring engine and the same Pass / Conditional / Fail / Not-assessed roll-up (see §6), so a hybrid system can be assured end to end without two incompatible scorecards.

1.1 Scope

In scope (core track): diagnostic, triage, prognostic and measurement models over clinical data, whichever modality carries the signal. This explicitly includes imaging / computer-vision diagnostic AI (radiology, digital pathology, blood-film morphology, retina, dermatology, mammography), tabular and risk-score models (for example FBC-based and early-warning scores), and multimodal systems. The unit of assessment is the clinical claim, not the model architecture.

Correction of an earlier scope boundary. METH-0.1 §1 lists "computer-vision-only systems" as out of scope. That boundary belongs to the LLM secondary track only. It does not apply to this core track: imaging and computer-vision diagnostic systems are squarely in scope here, and are in fact the densest part of our target market (radiology is roughly 77% of the FDA's authorised medical-AI devices). METH-0.1 should be read as the LLM-track scope statement, not a company-wide one. This is recorded so the two documents cannot be read as jointly excluding our core product.

Out of scope (this version): training-time audits of the developer's own pipeline (we assess the frozen artefact and the evidence, not the training run), formal verification, and certification of any kind. We assess. We do not certify, approve or endorse.

1.2 How the two taxonomies relate

The core failure-mode taxonomy is D1 to D7 (§2). The METH-0.1 LLM taxonomy is T1 to T6. They coexist through a crosswalk, so a finding surfaced by a diagnostic probe still lands in a category a buyer's ISO/IEC 42001 or NIST auditor recognises:

The diagnostic track adds the quantitative, clinically-anchored content (discrimination, calibration, operating point, transferability, subgroup equity, abstention) that LLM red-teaming does not capture. The crosswalk is the bridge, not a replacement: a diagnostic scorecard leads with D1 to D7, and the T-mapping is carried alongside for framework legibility.

2. Failure-mode taxonomy (D1 to D7)

Every engagement scores all seven. "Not assessed" is an explicit, reported state, never a silent omission. For a given clinical claim, some modes are catastrophic and some are cosmetic, and the threat model (§4, Stage 1) records which is which up front.

D2, D5 and D6 map to Safety in a clinical deployment; D1, D3 and D7 map to Robustness; D4 maps to Fairness (see §1.2).

3. Evaluation dimensions (the quantitative core)

For each in-scope failure mode we compute defined, clinically-anchored metrics. Every metric states what it does not measure, and every run emits a versioned, timestamped artefact (§11). The harness's diagnostics.evaluate() already computes the stdlib core (AUROC with tie handling, confusion-at-threshold, ECE, Brier, subgroup AUROC gap, external-validation drop, vendor-claim gap, sensitivity shortfall). The production library choices below are for when richer statistics are warranted.

Implementation status at sign-off (2026-09-07), checked against the code. The table above is the specification. What the harness computes today, in dependency-free standard-library Python, is: AUROC with tie handling; sensitivity, specificity, PPV and NPV at the deployed threshold; ECE and Brier; calibration slope and intercept; internal-to-external delta-AUROC and delta-calibration with the deployment-site view; per-group AUROC, sensitivity and false-negative rate with a minimum-N underpowered guard (N < 30); two D3 shortcut probes (perturbation degradation and conditional site gap); D7 drift with a power guard; and patient-clustered bootstrap confidence intervals on all of it, resampling by patient rather than by row so cells from one film are not treated as independent. Not yet implemented, and specified here for the next build: AUPRC and the prevalence baseline; Wilson intervals (bootstrap is used instead); adaptive ECE and Spiegelhalter Z; recalibration fitting; the risk-coverage curve and out-of-distribution detection; and decision-curve analysis. The library column names the intended production tooling for those rows; none of it is a dependency of the current harness. A report produced under this version states which rows were computed.

The load-bearing design point. External validation on data from the same hospital or scanner is not external validation. The split must cross the axis the model meets in deployment. Our harness re-runs the full battery on the deployment site (probes.deployment_site_view()) and promotes those failures into the scorecard, so a clean developer-data result cannot hide a deployment-site failure. Folding this into evaluate() itself is item 1 on the harness roadmap (05-Harness-Spec-and-Roadmap).

4. The evaluation pipeline (seven stages)

Seven stages, each with a defined deliverable and an owner. Every stage writes findings into the same §6 engine. The mapping onto the harness's modules is given so the method and the code cannot drift.

4.1 Stage 1 — define the clinical claim and threat model

This is the highest-leverage hour in the engagement. Resolve, in writing: the task and output (detection, triage, prognosis or measurement; flag, probability, box or measurement; the deployed threshold); the population (age, presentation, prevalence, since prevalence drives PPV/NPV); the position in the pathway (pre-read triage, second reader, worklist prioritisation or autonomous, where advisory versus autonomous is the single biggest risk multiplier); and the users and workflow (who acts on the output, with how much else in front of them, and what they do when it disagrees with them). If the vendor cannot answer these, that is itself a finding.

4.2 Stage 1 — the comparator

Assurance is comparative. The comparator must be the current standard of care or current reader, not a weak baseline. "Better than a junior reading in isolation" is not "safe in this pathway". A straw-man comparator is flagged as a finding.

4.3 Pre-register the acceptance criteria

Numbers without a pre-agreed pass/fail bar are not assurance. Before any number is computed, lock, with the clinical advisor: the operating point and the sensitivity floor below which the tool is unsafe for this claim (for example ">= 0.90 sensitivity for malignancy at the deployed threshold"); the calibration tolerance (for example slope in [0.8, 1.25], intercept near 0); the equity criterion (maximum acceptable subgroup gap, a per-subgroup sensitivity floor, and the minimum subgroup N below which we report "underpowered" rather than a spurious pass); and the transferability bar (maximum acceptable drop from internal to external data). Pre-registration is what stops us or the vendor moving the goalposts after seeing results. These map onto the severity bands in constants.py, which remain placeholders pending clinical-advisor calibration.

5. Model access (audit strength is bounded by access depth)

Black-box, query-only access cannot detect anomalous failures, isolate sub-components, or prove the test set was not in training (Casper, Ezell et al., Black-Box Access is Insufficient for Rigorous AI Audits, FAccT 2024). For clinical AI the binding constraint is usually the data, not the model: patient data cannot leave the Trust, which inverts the usual setup, so you bring the model to the data. The declared access tier is stated in every report, because it bounds the strength of every claim.

The five access modes, strongest evidence first:

1. Weights / container handover under NDA (we run it). White-box: probe latent failure modes, freeze the exact artefact, reproduce deterministically. Gold standard. The EU AI Act Annex VII "access to the trained model on reasoned request under IP protection" language is a useful template for the safeguards.
2. Model-to-data / SDE-TRE / federated. The model is brought to a secure dataset inside an NHS Secure Data Environment or Trusted Research Environment under Five Safes governance. The only lawful route to real UK clinical data at scale, and the best test of transferability. Limit: safe-outputs disclosure controls cap exportable evidence, and reproduction by an outsider is hard.
3. De facto white-box research API. Arbitrary white-box computations through an interface without copying weights. The minimum floor we will certify as "audit-grade".
4. Documentation-first desk audit (do this first, always). Request the evidence pack before querying the model. Cheap, fast, entity-independent, high leverage (Stage 3).
5. Black-box API (query-only). A screening layer only. Sufficient to triage, never sufficient alone for an audit-grade claim. Qualify out, or state the limit explicitly.

The evaluator-access agreement requires the vendor to provide: the intended-use / clinical-claim statement; a model card (index, not evidence); reporting documentation (TRIPOD+AI / STARD-AI / CLAIM / DECIDE-AI as applicable); training-data provenance, label definitions and adjudication, plus prior internal and external validation including unflattering results; the DCB0129 Clinical Safety Case Report, Hazard Log and named Clinical Safety Officer; a frozen, version-pinned model artefact or endpoint and the declared access tier; and the right to publish findings with no vendor power to suppress adverse results (fact-check and time-box only), which protects our adversarial-honesty rule against safety-washing.

The MHRA AI Airlock is not a third-party-auditor access mechanism, but it is the canonical UK precedent for supervised, sandboxed evaluation of a real clinical AI product against regulatory questions. Track it as a credibility anchor and a source of vendors who have accepted scrutiny (Phase 2 reported June 2026; Phase 3 funded, cohort not yet announced).

6. Scoring (shared engine with METH-0.1)

The diagnostic track does not define a separate scoring scheme. Findings from Stages 3 to 7 flow into the same canonical engine as the LLM track (app/scoring/engine.py), so a hybrid system produces one coherent scorecard.

• Severity (worst credible consequence in the deployment context): Critical / High / Medium / Low, health-first definitions, per METH-0.1 §6.1.
• Likelihood (empirical, from test results, not analyst intuition): for the diagnostic track, likelihood is read from the observed evidence, for example the reproducibility of a shortcut collapse across seeds, the magnitude of the external-validation drop against the pre-registered bar, or the fraction of subgroups breaching the equity floor. It is recomputable from the run artefact.
• Risk rating = severity by likelihood, per the METH-0.1 §6.3 matrix.
• Category result: Pass / Conditional / Fail / Not assessed (declared, with reason). Where coverage is thin, the engine caps the result below a clean Pass (thin coverage is a qualified finding, not a pass).
• Deployment gate (non-negotiable): in a clinical deployment, any single Severe finding that maps to Safety or Security (for example an unmitigated D2 miscalibration or D5 operating-point harm at the deployed threshold, or a D3 shortcut that removes true positives from the worklist) means we recommend against deployment until it is remediated and re-tested. Stated in the engagement terms at intake.

A worked example running the shared engine on a seeded synthetic corpus with planted D1, D2, D3, D4 and D5 failures is in the harness (app/harness/run_demo.py); its verdict is recommend-against-deployment, and it self-tests by exiting non-zero if any planted failure is missed.

7. Reporting-standard scaffold (the audit skeleton)

Every finding is mapped to the clinical reporting standards that make a diagnostic-ML report legible to a reviewer, a regulator and a Clinical Safety Officer. Status and dates are sourced; cite with the access date in the report.

A missing or under-qualified Clinical Safety Officer, or an absent Clinical Safety Case Report, is a fast, audit-grade conformity gap under DCB0129/0160. The desk-audit checklist (deskaudit.py, 19 items) encodes these, and treats an absent answer as a deficiency, not a pass.

8. Governance alignment (Wang et al. four-component model)

We map the governance layer of every engagement to the four-component healthcare-AI governance model from the scoping review by Wang et al. (npj Digital Medicine 2026, DOI 10.1038/s41746-026-02679-2): guiding principles, assessment methods, lifecycle stages, oversight mechanisms. The review's central finding is that the field is long on principles and short on assessment methods and independent oversight. That is exactly the layer an independent Assurance Report supplies, so we position our deliverable as the assessment-methods and oversight-evidence layer the frameworks lack, rather than as one more set of principles.

9. Regulatory and framework mapping

• MHRA (SaMD / AIaMD). Map the claim to device class; check GMLP Principle 10 (post-deployment monitoring) and the Predetermined Change Control Plan "focused and bounded" change-control principle.
• NHS DCB0129 / DCB0160. Clinical Safety Case Report, Hazard Log, and a Clinical Safety Officer whose competence covers AI-specific risk. A missing or under-qualified CSO is an audit-grade conformity gap.
• EU AI Act (Reg. 2024/1689). Medical-device AI is high-risk by operation of law (Annex I plus MDR/IVDR). Articles 10 (data governance) and 15 (accuracy, robustness, cybersecurity) map directly onto our subgroup, transferability and calibration tests. High-risk obligations for medical-device AI now apply from 2 August 2028 (Digital Omnibus, Regulation (EU) 2026/1744, adopted by the Council 29 June 2026, in force 27 July 2026; Annex III systems to 2 December 2027). This is a deferral, not a repeal: Articles 9 to 15 are intact, so it means more runway to build evidence, not less reason to.
• ISO/IEC 42001:2023 (AI management system, certifiable, industry-agnostic, no health-specific annex yet, which is the gap our domain method fills), ISO/IEC 23894 (AI risk process), NIST AI RMF 1.0 (Govern / Map / Measure / Manage as the engagement spine).
• GMLP and WHO. The WHO 2024 guidance on large multimodal models explicitly calls for independent third-party post-release auditing with subgroup-disaggregated results, which is a direct description of this service. Anchor positioning to it.

No endorsement, no live scheme to hold. As of mid-2026 there is no UK AI-assurance certification or register (the DSIT / Responsible Technology Adoption Unit Trusted Third-Party roadmap is government ambition, not a live scheme). Operate to ISO/IEC 42001 plus the GMLP/WHO third-party-audit framing, and position as a first-mover.

10. Post-market monitoring plan (D7)

A once-valid model silently decays. The Stage 7 deliverable is a monitoring plan specifying: data / covariate drift (PSI, KS) per input feature; prediction drift (score distribution over time); calibration drift specifically (it degrades silently and is the early-warning signal a diagnostic buyer cares about most); and performance estimation without labels (for example NannyML CBPE) reconciled against realised performance when labels arrive. Define retraining and rollback triggers and incident-reporting routes up front. Gate alerts on prediction / performance impact, not on every PSI breach, to avoid alarm fatigue (a D5 failure in our own tooling). Tooling: evidently for reports, nannyml for label-free estimation, alibi-detect for specific detectors.

11. Reproducibility and the harness

Architecture decision (accepted). The house LLM framework is Inspect (UK AISI), which is generation-centric (one model completion per sample). A diagnostic-ML eval is a different shape: load a frozen array of (probability, label, metadata) and compute cohort-level statistics (AUPRC, calibration slope, subgroup gaps, decision curves, bootstrap CIs). We therefore split the stack: Inspect for the LLM red-team track (its home turf, and what keeps "UK-AISI-aligned" honestly true), and a thin, reproducible bespoke runner for the diagnostic core track, which is what diagnostics.py plus app.harness already are. We borrow Inspect's discipline (structured, replayable logs; pinned and seeded everything) rather than bending Inspect to do statistics it was not built for. Do not claim Inspect for the diagnostic track; claim "Inspect-aligned audit-log discipline". Reassess only if Inspect ships first-class non-generative / array-scorer support.

Engineering standards (per run). Pin versions in a lockfile; set and record all seeds; emit one immutable, schema-versioned result record per run (inputs hash, library versions, seeds, git SHA, metrics with confidence intervals, pass/fail against the pre-registered criteria). Keep the stdlib core dependency-free; put heavy statistics behind optional extras. Reproducibility is itself a test: same inputs must give same outputs, enforced by the synthetic self-test. A named third party must be able to re-run Stages 4 to 6 from the artefacts alone.

The runnable artefact (verified). python3 -m app.harness.run_demo builds a seeded synthetic corpus with planted failures, runs it through diagnostics.evaluate(), the D3 shortcut probe, the calibration-slope and deployment-site views, and the §6 engine, and emits a D1 to D7 scorecard whose verdict is recommend-against-deployment. Point it at a real model with an id,label,score[,group,site,score_perturbed] CSV. Synthetic data validates the detector; it never substantiates a real-world claim.

12. Adversarial-honesty caveats to carry into every report

• Declare the model-access tier; it bounds the strength of every claim.
• Synthetic data validates a detector, never a real-world claim. Public non-UK datasets substantiate method, not UK-representativeness; caveat geographic transfer explicitly.
• FDA / device counts are a demand proxy, not deployment truth ("cleared" is not "routinely used"); UK and EU figures differ.
• Severity bands are pre-registered placeholders pending clinical-advisor calibration; do not present them as settled clinical thresholds.
• Where subgroup N is small, widen the confidence interval and report "underpowered". An honest "we cannot tell for this group" is a finding, not a gap to paper over.
• We have no completed external client evaluation yet. Say so.

13. What we can do now versus what needs the unlock

Now, with no new entity, certification or partner: run the desk audit on any vendor's published evidence (Track A, a saleable gap analysis); run the harness on synthetic plus open public data (NHANES, PhysioNet, Acevedo, EyePACS to APTOS, CAMELYON17/WILDS) to build the proof-corpus and demonstrate the method end to end; produce a sample Assurance Report on a public model, clearly labelled as a method demonstration. The first real-data run under this method is pre-registered (protocol frozen 2026-09-04, before any model was trained or score computed): train a named baseline on the PBC blood-cell dataset (Acevedo et al., 17,092 images, CC BY 4.0) and test on CytoData (EMBL-EBI BioStudies S-BSST2156, CC0), on a frozen binary task (positive = immature granulocyte plus erythroblast; negative = the five mature leukocyte types), reporting D1, D2, D5 and partial D3. A cross-dataset split of this kind is the transferability test §3 requires; it substantiates the method, not UK representativeness (§12).

Needs the clinical / institutional partner: real UK clinical data (NHS Secure Data Environment, UK Biobank, BloodCounts!-type cohorts), the Clinical Safety Officer competence to sign a safety case, and the calibration of the acceptance-criteria bands to real clinical tolerances. The clinical advisor is the gating move: it converts a credible method into admissible UK evidence.

14. Version history and key references

Key references.

• Wong et al., "External Validation of a Widely Implemented Proprietary Sepsis Prediction Model in Hospitalized Patients", JAMA Internal Medicine 2021, https://jamanetwork.com/journals/jamainternalmedicine/fullarticle/2781307 (accessed 21 Jun 2026).
• Wang et al., healthcare-AI governance scoping review, npj Digital Medicine 2026, DOI 10.1038/s41746-026-02679-2.
• Zech et al., "Variable generalization performance of a deep learning model to detect pneumonia in chest radiographs", PLOS Medicine 2018.
• DeGrave et al., "AI for radiographic COVID-19 detection selects shortcuts over signal", Nature Machine Intelligence 2021.
• Casper, Ezell et al., "Black-Box Access is Insufficient for Rigorous AI Audits", FAccT 2024.
• Reporting standards: TRIPOD+AI (2024), PROBAST+AI (BMJ 2025), STARD-AI (Nature Medicine 2025), DECIDE-AI (2022), CLAIM (2024), QUADAS-2.
• NHS DCB0129 / DCB0160; EU AI Act Reg. 2024/1689; ISO/IEC 42001:2023; ISO/IEC 23894; NIST AI RMF 1.0; WHO 2024 guidance on large multimodal models.

UK AI Evaluation is an independent assessor. This methodology, and reports produced under it, do not constitute certification, regulatory approval, or endorsement by any regulator or body.

← Back to the Assurance Evidence Base