MICKAI
Article · 10 June 2026

The NHS clinical-coding decision a regulator can verify without trusting the vendor

SNOMED CT and ICD-10 coding are moving into AI assistance across UK trusts. The structural test is whether an MHRA inspector or an Information Commissioner can verify the coding decision end to end, against an audit record signed under the trust's own key, without trusting the model vendor.

The NHS clinical-coding decision a regulator can verify without trusting the vendor
Author
Micky Irons
Published
10 June 2026
Follow Micky Irons
LinkedInX
NHSClinical CodingMHRASovereign AIMickai

Clinical coding in England runs on SNOMED CT for the clinical narrative and on the ICD-10 4th Edition for the statutory submission. The 2025 NHS England guidance pushed AI assistance for coders out of pilot and into deployment, with several trusts already using vendor-supplied models to suggest codes against discharge summaries, theatre lists, and outpatient letters. The clinical case for assistance is real. The structural problem with the way vendors are shipping it is that the audit record proving the coding decision sits inside the vendor's perimeter.

That is not, by construction, evidence a regulator can verify.

What the regulator actually has to do

The MHRA classifies a clinical-coding AI as a medical device where it influences a treatment, billing, or population-health decision. The 2024 Software and AI as a Medical Device Change Programme set out the post-market surveillance expectation: the manufacturer must retain a record sufficient to reproduce the decision, the data the decision was made against, and the version of the model that made it.

The Information Commissioner's Office adds the data-protection layer. Where the coding decision touches identifiable patient information, the trust is the data controller. The trust, not the vendor, owes the lawful-basis evidence, the retention evidence, and the right-of-erasure evidence.

The trust cannot answer either obligation on the strength of a vendor-side log. The trust answers only when the trust holds the audit record.

Vendor-side audit is structurally the wrong place

Most clinical-AI vendors ship a logging tier that lives on vendor infrastructure or on a shared cloud tenancy the vendor controls. The contractual basis is usually that the vendor will provide the log on request for investigation. The structural problem is not whether the vendor is trustworthy. The structural problem is that the regulator is being asked to trust the party under investigation to produce the evidence about themselves.

This is the same failure mode the Open Audit Record primitive was filed to close.

The substrate the inspector can verify

Mickai is a Sovereign Intelligence Operating System. The clinical-coding scenario maps to the SIOS in the following way.

A coder opens a discharge summary on the trust's deployment of the SIOS. The Router brain in the Chronus kernel decomposes the request: parse the narrative, retrieve relevant prior coding, run the SNOMED specialist, run the ICD-10 specialist, present a quorum-checked candidate code to the coder. Each step writes a structured action record. The Audit Ledger brain signs each record under FIPS 204 ML-DSA-65 with the trust's own private key, held in TPM 2.0 hardware on the trust's deployment. The Permissions brain records that the action was within the coder's clearance. The Retrieval brain records the precise prior-coding context the candidate code was derived from. The Function brain records the compensating inverse, the action that would reverse the coding if it were retracted.

What the inspector or the Information Commissioner then receives, on a single recovery, is a record that contains the discharge summary excerpt the decision was made against, the retrieval set the decision was conditioned on, the candidate code and its quorum margin, the coder's signed acceptance, the time, the hardware identity of the workstation, the trust key under which the record was sealed, and the inverse action available if the coding is later retracted.

The verification happens against the trust's published verification key, in a browser, offline if needed. The vendor of the underlying model is no longer the trust party in the verification step.

Two operator scenarios

A coder at a Greater Manchester trust receives a candidate ICD-10 code with a 0.83 quorum margin and accepts it. Eighteen months later a Care Quality Commission inspector questions whether the discharge summary supported the code. The trust's audit officer recovers the signed record, the discharge summary excerpt as held at the moment of coding, the prior coding the candidate was retrieved against, and the quorum margin at acceptance. The inspector verifies the signature against the trust's public key. The reconstruction takes minutes and does not involve the vendor.

A researcher at NHS Digital queries whether a cohort coded between two dates includes any patients who later exercised the right to erasure. The Audit Ledger contains a sealed proof of erasure for every patient who withdrew, signed under the same trust key. The researcher excludes them with a verifiable certificate, not a vendor assertion.

Policy alignment, not policy promises

The Information Commissioner's 2024 AI and data protection risk toolkit explicitly names the gap between vendor-held telemetry and controller-accountable audit. The MHRA Change Programme names the gap between training-time documentation and post-market surveillance evidence. The NHS England Long Term Plan names the gap between AI adoption and population-health audit. The Open Audit Record is the engineering primitive each of those papers implies.

The Open Audit Record is filed at the UK IPO under reference GB2610413.3, with the wider Mickai portfolio filed under one named inventor between 30 March 2026 and 10 June 2026. The post-quantum signing scheme used in the audit ledger is FIPS 204 ML-DSA-65, the NIST standard the NCSC has set a migration path to by 2031 and a deadline of 2035. The substrate that satisfies the NHS, the MHRA, and the Information Commissioner together is filed and on the public register.

What a trust should ask for in the next coding-AI procurement

The structural test is simple. The trust holds the audit key. The audit record is signed at the moment of decision under a post-quantum scheme. The verification is performed against the trust's published key, not the vendor's. The inverse action is held alongside the action. The federation across regional cooperation is operator-attested. The clinical-coding AI sits as a tenant inside the SIOS, not as a separate vendor product the trust trusts on contract.

A clinical-coding AI a regulator can verify without trusting the vendor is the version of the technology a trust can put into production and defend at inspection. The substrate to ship that version exists.

The Mickai SIOS is the operating system. Each of the 101 filed UK patent applications is on the public register.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/nhs-clinical-coding-the-regulator-can-verify. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles