Clinical Coding vs Document Extraction: An NHS Guide

A model that reads a discharge summary and returns "community-acquired pneumonia" in a diagnoses field has done something useful. It has not coded the episode. In an NHS hospital, clinical coding is a separate, governed job: a trained coder reads the record after discharge and assigns codes from national classifications, and those codes travel into the data that commissioning, payment and national statistics depend on. Buyers who treat the two jobs as one tend to find out at audit time.

The distinction is sharp in 2026. NHS England states that all NHS healthcare providers in England must use SNOMED CT for capturing clinical information, and its page says secondary care services are in the process of adopting it. In parallel, hospitals moved to a new edition of the procedure classification on 1 April 2026, and NHS England postponed the 2026/27 local payment grouper, citing the magnitude of that change. A Head of Clinical Coding, a CIO or a Chief Data and AI Officer evaluating AI for records work needs a clear line between what a model extracts and what a coder assigns.

This guide holds that line for NHS secondary care: the coding pipeline from discharge to Hospital Episode Statistics, the 2026 classification change, the audit and training regime, and where an extraction model fits beside coders. It deliberately leaves other frames to our existing posts. Replacing vocabulary codes after the Google API change is covered in our Healthcare NL API migration guide; terminology resolution as a vendor capability sits in our John Snow Labs comparison; coded discharge data flowing into the GP record is in our discharge summary extraction guide; MedDRA coding of adverse reactions is in our pharmacovigilance intake guide; and private-sector episode coding for billing is in our private hospital referral and billing guide.

This guide is shipped by the team behind Dilr Mira, a family of small private language models that turn clinical documents into schema-valid JSON on hardware you control. Or see DATS, our five-stage method for placing AI inside regulated operations.

What is the difference between clinical coding and document extraction?

Clinical coding translates the clinical record of a hospital episode into codes from national classifications, such as ICD-10 for diagnoses and OPCS-4 for procedures, following national coding standards so the data can be counted, paid for and compared. Document extraction pulls stated facts out of a document into named fields. Extraction reports what the document says; coding decides how the episode is classified, and in NHS hospitals that decision belongs to trained clinical coders.

The difference is not cosmetic. An extracted diagnosis is an entry in a field, taken from one document. A coded diagnosis is the output of a rules-based process: a trained coder works from the episode record and applies the national clinical coding standards for the classification in force. An extraction model reading one document has no view of those rules or of the rest of the record.

There are also two kinds of code in play, and they do different work. SNOMED CT is a clinical terminology used to record care in the patient record. ICD-10 and OPCS-4 are statistical classifications used to describe an episode for secondary uses such as commissioning, payment and national statistics. A hospital can hold SNOMED CT in its electronic record and still need coders to produce ICD-10 and OPCS-4 codes for its returns.

That table is the frame for the rest of this guide. Our clinical document extraction guide covers the left-hand column in depth; this post is about how the right-hand column works in the NHS and where the two meet.

Which classifications does an NHS hospital code to in 2026?

An NHS hospital in England codes admitted care to ICD-10 5th Edition for diagnoses and, since 1 April 2026, to OPCS-4.11 for interventions and procedures, both published as information standards and applied through national clinical coding standards. Separately, NHS England requires every NHS provider to use SNOMED CT for capturing clinical information in the record. The two classifications describe the episode; SNOMED CT describes the care.

Each of the three has its own legal and operational footing, and it is worth being precise about who each one binds.

ICD-10 5th Edition. The NHS Standards Directory lists ICD-10 as an information standard that public bodies, and anyone providing publicly funded health services, must have regard to; the 5th edition superseded the 4th. The same entry says the standard also applies to NHS IT system and software suppliers who build or update software to support NHS business functions. The NHS Classifications Browser publishes the National Clinical Coding Standards for ICD-10 5th Edition, with a 2026 edition alongside earlier years.

OPCS-4.11. The standards directory entry for OPCS-4 describes it as a mandatory information standard for the clinical coding of hospital interventions and procedures, published under section 250 of the Health and Social Care Act 2012 and effective from 1 April 2026 for all providers of NHS funded hospital services. The same entry records "5114 amendments proposed" to OPCS-4.11, and notes that the release moved from two paper volumes to the online NHS Classifications Browser only. The duty sits with the health care providers that submit admitted patient care data; system suppliers are named as impacted, because their software has to carry the new codes.

SNOMED CT. NHS England's clinical coding page describes SNOMED CT as a national information standard that must be adhered to as part of the Health and Social Care Act 2012, binding NHS healthcare providers in every care setting. The same page says primary care system suppliers have enabled SNOMED CT since 2018 and that the UK edition is released every six months or more often when needed. It is a terminology of concepts, descriptions and relationships, grouped into 19 hierarchies, and it is the language of the record rather than of the statistical return.

For a team evaluating AI, the practical point is that "coding" can mean any of three things. A tool that helps a clinician pick a SNOMED CT concept at the point of care is doing different work from a tool that helps a coder assign ICD-10 and OPCS-4 codes after discharge, and both are different from a model that extracts text fields from a document already on file. The safety case for each is different too, which our DCB0129 and DCB0160 guide works through for extraction.

Where does coding sit in the path from discharge to national data?

In NHS hospitals, coding normally happens after discharge. Coders read the episode record and assign ICD-10 and OPCS-4 codes; the provider submits them in the Commissioning Data Sets through the Secondary Uses Service; the coded episodes feed Hospital Episode Statistics and the grouper that derives Healthcare Resource Groups for payment. An extraction model only touches the first step, reading documents that coders already read.

NHS England Digital describes Hospital Episode Statistics as a curated data product covering admissions, outpatient appointments and historical A&E attendances, with each record carrying clinical information about diagnoses and operations alongside administrative details. HES data comes from routine provider submissions made for the purposes of payment and commissioning, and the same page notes that an amendment may be needed to an earlier record "as clinical coding takes place on discharge". Coding is not a side activity: it produces the diagnoses and operations that HES carries for payment and commissioning.

Read the diagram from left to right and the boundary is plain. An extraction model can sit in the first box, turning a stack of documents into a structured draft a coder can scan faster. The second box is governed by the classification, the national standards and the provider's own coding policy, and the last two run on national submission and grouping rules. A model output that skipped the coder and flowed straight into commissioning data would not be "faster coding"; it would be uncoded data with codes attached.

This is the same reasoning our approach to AI placement applies to any regulated workflow: find the step where reading time is the constraint, and keep the step where judgement is regulated with the people who are trained and audited for it.

What did the OPCS-4.11 change do to grouping and payment in 2026?

The move to OPCS-4.11 on 1 April 2026 was large enough that NHS England postponed the HRG4+ 2026/27 Local Payment Grouper, citing financial volatility concerns given the magnitude of change. Instead, new OPCS-4.11 codes are mapped to OPCS-4.10 equivalents so activity can still be grouped with the 2025/26 logic. For data teams, the codes submitted and the codes grouped for payment were not always the same.

The detail is set out on the NHS England Digital grouper update page. The SUS+ Autogrouper was modified to accept OPCS-4.11 codes and translate them to OPCS-4.10 codes before deriving Healthcare Resource Groups, and a one-to-one pricing table was published for providers that group locally. The page warns that presenting OPCS-4.11 codes to the 2025/26 grouper without the translation returns an HRG of UZ01Z, invalid for grouping, and that in some cases the dominant procedure returned will be the mapped code rather than the original.

The same page restates the conformance requirement under DAPB0084, which the Data Assurance Board approved on 29 October 2025: admitted care episodes and day cases containing interventions must be recorded to OPCS-4.11 on or after 1 April 2026, to support the Admitted Patient Care Commissioning Data Sets and other central returns.

Three lessons follow for anyone putting AI near this work:

1. Classifications change on a fixed date, and every downstream tool has to know which edition it is producing. A model whose training data reflects an older edition will not know about new codes, retirements or description changes, so an edition change belongs in the risk plan of any DATS-style AI deployment.
2. The code a coder assigns is not always the code the payment system groups on. In 2026 a translation layer sits between them, which is exactly the kind of rule a document model has no view of.
3. Volatility is managed centrally. NHS England chose to postpone the grouper to manage financial volatility. A local tool that tried to be clever about codes would be working against that decision.

None of this is a reason to keep AI out of the records office. It is a reason to keep AI on the reading side of the line, where its output is a draft for a coder rather than an input to a return, and to write that boundary into a governed AI operating model.

How is NHS clinical coding audited, and who is trained to do it?

One assurance route for NHS clinical coding is the Data Security and Protection Toolkit. Its independent assessment framework includes a clinical coding outcome, under which assessors inspect the coding policy against national standards for ICD-10 and OPCS-4, coding practice, clinical coding audit documentation and training records. Coders attend a national standards course, and the trust being assessed holds that outcome.

The outcome is principle E4.b in the independent assessment and audit framework, and its description is short:

"You are committed to regularly evaluating and improving your organisation's coded clinical data."

The suggested testing approach under it is specific, though assessors adapt it with professional judgement. The assessor obtains and inspects the clinical coding policy to see whether it aligns with current national clinical coding standards for the ICD-10 and OPCS-4 classifications; obtains and inspects evidence that coding practice follows that policy; inspects clinical coding audit documentation; and inspects evidence that staff who need clinical coding training have completed it within the expected timeframes. That outcome is assessed against the coding policy and coders of the organisation whose records are coded. A supplier with NHS data access may have its own toolkit to complete, but it does not take over the trust's clinical coding outcome by providing a tool.

The training regime is equally defined. The DSPT training annex for clinical coding says the Clinical Coding Standards Course runs for no less than 23 days for an acute trust coder and 3 days for a mental health trust coder. Attendance must start within 6 months of starting work as a clinical coder, and relevant staff attend a refresher course every 3 years thereafter. The annex also says organisations should support coders in gaining Accredited Clinical Coder status through the National Clinical Coding Qualification, as a marker of good practice, and that it is essential that all staff, including clinicians, who code using ICD-10 codes are trained in the basics.

Set that against an AI model and the gap is obvious. A coder has attended a national standards course, works to a written policy, is audited against it and is retrained on a cycle. A model has a training set and an evaluation. That is why the sensible use of AI here is to make the coder's reading faster, not to replace the coder's decision, and why an AI operating model for a records function should name the coder, not the model, as the owner of every code.

What can Mira-Q2 contribute to a coding workflow, and where does it stop?

Mira-Q2 can read a clinical document already on file and return ten required JSON fields, including a list of diagnoses and a list of procedures, as a draft for a person to review. Its live page describes those fields as lists and does not describe code output. In a coding workflow, Mira-Q2 can prepare the reading for a coder; assigning, sequencing and auditing codes stays with the coder.

The facts on the Dilr Mira models page set the scope. Mira-Q2 is a 120 MB QLoRA adapter on Qwen2.5-3B-Instruct that reads a lab report or discharge summary on hardware the customer controls and returns the same ten required fields every time; our response schema versus fine-tuning guide explains why a fixed schema matters. The diagnoses field is described as "a list of diagnoses", and the page says the training data drew on 71,000 real ICD-10 codes. That sentence describes the training data. The page does not say the diagnoses field returns ICD-10 codes, and a buyer should not assume it does. The procedures field is likewise described as a list of the procedures a document mentions, with no mention of OPCS-4.

Three further limits matter for a records office:

• English only, strongest on familiar document types. The page says Mira-Q2 is strongest on lab reports, discharge summaries and medication lists, and weaker on types it never saw in training, such as operative notes and physical examinations. A coding team that wants help with procedure-heavy records should measure that weakness on its own operative notes before relying on it.
• A published gap on real documents. Mira-Q2 produced valid JSON on 100% of 200 held-out documents and 85.8% of 282 real physician notes across 39 specialties, and the drop is published rather than hidden. Our 782-document evaluation write-up explains how to read those numbers.
• Two licences. The adapter DILR publishes is Apache-2.0; the Qwen base model it runs on is licensed for non-commercial use, and commercial users need to check the base terms.

What does a sensible use look like? A worklist where each discharged episode arrives with a structured draft beside the source documents: diagnoses and procedures as lists, medications, results and the notes field, each traceable to the text. The coder still reads the record, still applies the national standards and still assigns every code. The time saved is in finding the facts, not in deciding the codes. The same design logic runs through our AI execution office, which keeps the human owner of each decision named while the work around it is automated.

Because Mira-Q2 runs where the documents already are, a trust can try this on its own records without sending them to a third-party API. That does not make the deployment compliant by itself; the trust's own controls, its DSPT position and its clinical safety case still decide that. The safety-case side is covered in our DCB0129 guide, linked earlier in this post.

What is the best way to use AI alongside NHS clinical coders in 2026?

The best approach in 2026 depends on the job. For speeding up how coders read long or scanned records, a private extraction model that drafts fields for review is a reasonable fit. For suggesting candidate codes, a purpose-built computer-assisted coding or terminology product is the better tool. For the code decision itself, the trained coder remains the answer under national standards and DSPT audit.

Four criteria separate the options, and they should be scored against your own documents rather than a vendor's test set, in the way our published Mira-Q2 scorecard is laid out:

1. Does the tool output codes, or text? If you need candidate codes, choose a product that is designed and validated to produce them, and test it against codes your coders have already checked.
2. Does it know the edition in force? After 1 April 2026, any code suggestion that does not reflect OPCS-4.11 creates rework.
3. Where do the documents go? A cloud service sends the record across the network; a private model keeps it inside. Both can be defensible, but the choice changes your data protection and DSPT evidence.
4. Who owns the code? In every option, the answer should be the coder, with the tool's output logged as a suggestion or a draft.

On those criteria, the alternatives each win somewhere. A licensed clinical NLP platform such as John Snow Labs lists terminology mapping and entity resolution among its capabilities, which a single small extractor does not; our John Snow Labs comparison sets the two side by side. Cloud services link extracted entities to code systems, AWS Comprehend Medical to ontologies including ICD-10-CM, RxNorm and SNOMED CT and Azure Text Analytics for health through its entity linking feature, and they win for teams already standardised on those clouds who accept the data path; the vocabulary-code trade-off is covered in our Healthcare NL API guide. Dilr Mira wins where the requirement is a fixed, private extraction record for a reviewer, on hardware the trust controls, with nothing leaving the building.

What none of them should do is remove the coder from the decision. The DSPT audit steps are written around a policy, a practice and trained staff, and an AI deployment should make each of those easier to evidence rather than harder. If you want help scoping which of these fits your records office, talk to our team or start with the DATS methodology.

The same diagnostic logic underpins our AI solutions work, which sizes each candidate use by where reading time, not regulated judgement, is the constraint.

Can Mira-Q2 output ICD-10 or OPCS-4 codes?

Mira-Q2's published fields include a list of diagnoses and a list of procedures, and the Dilr Mira page does not describe ICD-10 or OPCS-4 code output. The page says its training data drew on 71,000 real ICD-10 codes, which describes the training, not the output. Code assignment should stay with trained coders or a tool validated for coding, with Mira-Q2's draft as reading support.

A team that wants a model to propose candidate codes would need to scope, train and validate that as a separate task, against coder-checked codes and the edition in force. The Mira-Q2 model card on Hugging Face lists the published schema and evaluation, which is where that scoping starts.

Does ICD-11 change the picture for NHS coders?

ICD-11 is the World Health Organization's current revision of the international classification, and WHO reports that as of May 2024, 132 Member States and areas were at various phases of implementation. For NHS coders today, the NHS Classifications Browser publishes national coding standards for ICD-10 5th Edition, including a 2026 edition, so ICD-10 remains the working classification for admitted care.

The WHO classification page also notes that WHO has published mapping tables to support migration from ICD-10 to ICD-11. Whenever a classification change does reach NHS coding, the 2026 OPCS experience suggests it will arrive with a fixed date, mapping tables and transitional grouping, all of which sit on the coding side of the line.

Does the DSPT bind an AI supplier as well as the trust?

The clinical coding outcome under DSPT principle E4.b is assessed against the coding policy, practice, audit documentation and training of the organisation whose records are coded. A supplier with NHS data access may complete its own toolkit, but it does not take over the trust's coding outcome by providing a tool, and a trust will reasonably expect help evidencing how the tool is used.

For a records office, that means writing the tool into the coding policy: what it produces, who reviews it, how a suggestion is distinguished from an assigned code, and how outputs are audited. Our what is Dilr Mira explainer summarises the model's published limits, which belong in that policy.

Want to see this on your own records? Look at Dilr Mira for private extraction, book an AI placement diagnostic, see our approach to placing AI inside regulated systems, or browse more industry guides.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.