An NHS team that wants a small language model to read discharge summaries, lab reports or referral letters can arrive at the clinical safety conversation late. The model has been tested, the information governance work is under way, and then the Clinical Safety Officer asks for the hazard log. At that point the team discovers that two information standards, written for health IT in general, now have to describe a model that reads free text and writes structured fields.
Those two standards are DCB0129, which NHS England describes as designed to help manufacturers of health IT software evidence the clinical safety of their products, and DCB0160, designed to help health and care organisations assure the clinical safety of the health IT they deploy. Both are published under section 250 of the Health and Social Care Act 2012, both carry a current release dated 7 June 2018, and NHS England has started a review of both. This guide is for the CIO, Head of Digital or Clinical Safety Officer who has to apply them to an AI document extraction model.
The scope is deliberately narrow. It covers which duties apply, who carries them when a team adapts and runs a model itself, what an extraction hazard log should record, and how a published evaluation feeds the safety case. It cedes the migration sequence from a retired cloud API to our Google Healthcare NL API alternative guide, the NHS contract duties around discharge documents to our discharge summary extraction post, the data residency argument to our clinical document extraction pillar, and ambient scribing procurement to our South West London scribing analysis.
This guide is shipped by the team behind Dilr Mira, a class of private clinical small language models that return schema-valid JSON on hardware you control. Or see DATS, our five-stage method for placing AI inside regulated organisations.
Do DCB0129 and DCB0160 apply to an AI document extraction model?
DCB0129 and DCB0160 apply to an AI document extraction model when the model is part of a publicly funded digital product that influences real-time or near-real-time direct care in England. An extraction model whose output lands in a patient record or a clinician's worklist usually meets that test. A model that only builds statistical datasets falls outside the mandatory scope, although the NHS applicability guide still strongly recommends adopting both standards.
The test comes from the NHS applicability guide, published on 27 May 2022, which sets out a six-step decision path. Step 1 asks whether any development or deployment is publicly funded. The guide is explicit that a product developed with private funding but deployed in a publicly commissioned care service falls within section 250(6), while a product that is privately funded end to end falls outside it, with adoption still strongly recommended. For a private hospital group running NHS-funded activity, that distinction is worth settling in writing before the first scoping call, not after.
Step 3 is where extraction projects divide. The guide says the standards apply only to products that influence real-time or near-real-time direct care, and that population health products used for statistical reporting fall out of scope. The same extraction model can sit on either side of that line depending on where its output goes:
- a model that populates medication and allergy fields a clinician will read at the next encounter is influencing direct care;
- a model that turns ten thousand historical discharge summaries into a de-identified research table sits closer to the population and statistical uses the guide places out of scope;
- a model that pre-fills a coding or claims queue sits in between, and in our view it is safer to treat it as in scope, because a coding error can flow back into a patient's record.
Steps 4 to 6 deal with medical devices, which we return to below. The practical point for now is that applicability is a property of the deployed system and its intended use, not of the model weights. Our UK AI risk management guide maps the wider sector regulator expectations that sit alongside these two standards.
Who is the manufacturer when a team fine-tunes and runs an open model itself?
The manufacturer under DCB0129 is whoever designs, assembles or adapts the health IT system before it is put into service, so a trust or provider that fine-tunes an open model and wires it into a clinical workflow will usually hold manufacturer duties for that pipeline. It then also holds DCB0160 duties as the deploying organisation. Using a supplier's finished product moves the manufacturer role to that supplier instead.
The definition in the DCB0129 specification is broader than many digital teams expect. It covers a person or organisation responsible for design, manufacture, packaging or labelling, "assembling a system, or adapting a Health IT System before it is placed on the market and/or put into service", whether the work is done in-house or by a third party on its behalf. Downloading an adapter, writing the prompt and schema, connecting it to the electronic patient record and putting it live reads, on any plain reading, as assembly and adaptation. Our Google Healthcare NL API alternative guide states the headline version of this split for a migration; the detail that matters here is what the in-house team then has to produce.
Three configurations are common:
| Configuration | DCB0129 duties sit with | DCB0160 duties sit with | What the deploying team must obtain |
|---|---|---|---|
| Team downloads open weights, adapts and runs them | The team's own organisation | The same organisation | Its own full clinical risk management file |
| Supplier builds and hosts or installs a finished extraction product | The supplier | The deploying organisation | The supplier's Clinical Safety Case Reports, plus its own deployment file |
| Supplier adapts an open model on site to the trust's schema | The supplier, for its build | The deploying organisation | Both, with the local schema treated as a customisation |
The third row is where responsibility is easiest to leave unassigned. DCB0160 places a clear obligation on the buyer in that situation. The DCB0160 specification states at requirement 2.5.1: "In the procurement of a Health IT System the Health Organisation MUST ensure that the Manufacturer and the Health IT System complies with DCB0129." The accompanying note says the manufacturer will be required to make its Clinical Safety Case Reports available to aid the deploying organisation's own risk analysis. If a supplier cannot produce them, the procurement has a gap that no amount of model evaluation fills.
There is a further layer that open-weight extraction models add. DCB0129 defines a third party product as one produced by another organisation, with library code among its examples, and requirement 2.5.1 says the manufacturer must assess any third party product included within a release, while 2.5.2 requires the nature of that assessment to be included in the Clinical Safety Case Reports. The standard does not mention models, but in our reading a base model published by another organisation fits the definition, and an adapter from a further supplier would be a second one. Mira-Q2, for example, is a 120 MB QLoRA adapter that runs on Qwen2.5-3B-Instruct, and the Dilr Mira page sets out that the adapter and the base model carry different licences. A safety case report that names only "the model" has skipped the assessment the standard asks for. DCB0160 requirement 2.6.1 repeats the same duty for the deploying organisation.
What hazards belong in the hazard log for an extraction model?
A hazard log for an AI extraction model should record each way a wrong, missing or late field could reach a clinician, rated for severity and likelihood against the risk acceptability criteria in the clinical risk management plan. The core hazards are omitted findings, incorrect values, lost context such as negation or history, documents outside the model's intended scope, malformed output, and delays to the record a clinician relies on.
DCB0129 defines the hazard log as a mechanism for recording and communicating the ongoing identification and resolution of hazards, and section 3.3 requires the manufacturer to establish and maintain one, a Clinical Safety Officer to approve each version, and an issued copy to accompany each Clinical Safety Case Report. Section 4.3 asks for known and foreseeable hazards in both normal and fault conditions, and section 4.4 asks for severity, likelihood and the resulting clinical risk for each. DATS, our five-stage method, is where we scope this work with clients.
We have not found NHS England hazard templates written for extraction models; its ambient scribing guidance says templates for hazard logs and safety cases are being developed for that product type. The closest official wording comes from its guidance on AI-enabled ambient scribing products, first published on 27 April 2025 and last updated on 29 July 2026, which notes that clinical hazards "may include missing critical information, incorrect information or context, or delayed outputs". That guidance is written for ambient scribing, not document extraction, so treat it as an analogy; our ambient scribing analysis covers that guidance's own territory. Translated into extraction terms, a starting hazard list looks like this:
| Hazard | Extraction example | Typical control |
|---|---|---|
| Missing critical information | An allergy present in the letter is absent from the allergies field | Reviewer checks source against output for high-severity fields |
| Incorrect information | A dose or unit is transcribed wrongly | Field-level review rule; reject values without source support |
| Incorrect context | A ruled-out diagnosis or family history is extracted as a current diagnosis | Reviewer guidance on negation; notes field flags uncertainty |
| Out-of-scope document | An operative note is processed by a model trained on other types | Intended use restricted to named document types; route others to manual |
| Malformed output | Output fails schema validation | Fail closed: invalid output never reaches the record |
| Delayed output | Queue backlog leaves fields empty at the point of care | Service level and fallback to the source document |
Two things about this table matter more than its exact rows. First, every row is rated in the context of intended use: an omitted allergy in a field a prescriber relies on is severe, the same omission in a research extract is not a direct care hazard at all. Second, the controls column creates obligations of its own, which is the subject of the next question. Identifier exposure belongs in the data protection impact assessment rather than the clinical hazard log, since health data is special category data under UK GDPR and the ICO's special category guidance sets the conditions; it helps to cross-reference the two documents so neither silently assumes the other covers it, a habit our approach builds in from the first workshop.
The same lifecycle is what an AI operating model has to staff: someone owns the intended use statement, someone owns the log, and the Clinical Safety Officer approves the log and the plan that sets its acceptance criteria.
How does a published evaluation feed the clinical safety case?
A published evaluation feeds the clinical safety case as evidence about the model's behaviour on documents like yours, not as proof the deployed system is safe. DCB0129 defines the safety case report as arguing that a system is safe for a given application in a given environment, so a vendor or open-model scorecard is one input that local testing on the organisation's own documents and workflow has to complete.
The distinction is easiest to see with real numbers. DILR publishes the Mira-Q2 scorecard on Hugging Face, and the Dilr Mira page summarises it: 782 documents across four test sets, an identifier leak rate of 0.0% across all of them, and JSON validity of 100.0% on 200 held-out documents drawn from the same distribution as training, 94.7% on 150 real physician documents that match its schema, and 85.8% on 282 real physician documents across 39 specialties. Field-F1 was 1.000 on the held-out set. Our Mira-Q2 evaluation breakdown walks through each set in more depth.
For a safety case, those figures answer some questions and leave others open:
- What they support. The schema is followed reliably on familiar documents, and the output design does not carry names or record numbers. The first is relevant to the malformed output hazard in the log, the second to the identifier risk in the data protection impact assessment.
- What they do not settle. JSON validity measures shape, not correctness. A valid allergies field can still miss an allergy. Field-F1 is reported for the held-out set, which shares the training distribution, so it says little about a trust's own letters.
- What the gap tells you. The drop from 100.0% to 85.8% on real physician prose is published on the model card, and the page attributes it to training on synthetic data. A hazard log should treat that gap as a likelihood input for any document type the model was not trained on.
The safety case therefore needs a local evidence layer: a de-identified sample of the organisation's own documents, a field-by-field comparison against a clinician's reading, and acceptance thresholds agreed in the clinical risk management plan before testing starts. DCB0160 requirement 7.1.1 adds that the deploying organisation must assess any local customisations before deployment, which for an extraction model we would read as including the schema, the prompt and any routing rules. The same principle applies outside the NHS, as our pharmacovigilance extraction post discusses for a different regulatory setting.
What controls reduce extraction risk to an acceptable level?
The controls that reduce AI extraction risk are a narrow intended use, human review of every output before it enters the record, fail-closed handling of invalid output, and field-level review rules for high-severity fields such as allergies and medications. DCB0129 also requires the manufacturer to verify each control and its effectiveness, and to check whether a control introduces a new hazard of its own.
Requirement 6.1.2 is the one easiest to overlook. It asks whether a proposed control will introduce new hazards. Human review is the obvious example. Dilr Mira states that every output is a draft for a person to check and that Mira does not make clinical decisions, which is the right design, but there is a risk that a reviewer who sees correct output hundreds of times stops reading the source. That is a new hazard created by the control, and it belongs in the log with its own control, such as periodic seeded errors or audit sampling of reviewed records.
Requirements 6.3.2 and 6.3.3 then ask the manufacturer to verify each control and verify that it works, and DCB0160 places the same duties (6.1.2, 6.3.2 and 6.3.3) on the deploying organisation. For an extraction pipeline, a practical set looks like this:
- Restrict intended use by document type. Mira-Q2 is strongest on lab reports, medication lists and discharge summaries, the types it was trained on, and weaker on operative notes and physical examinations. Write the strong types into the intended use and route everything else to manual handling. Verify by testing that an out-of-scope document is actually routed.
- Fail closed on invalid output. Output that fails schema validation never reaches the record. Verify by feeding malformed cases and confirming nothing is written.
- Make the reviewer's job specific. Mira-Q2 returns an extraction_notes field for the reviewer to read alongside the extracted fields. Define which fields need source comparison every time and which can be spot-checked. Verify with a timed review exercise on real documents.
- Keep the source one click away. A reviewer who has to search for the original letter will not check it. Verify in usability testing with the clinicians who will do the work.
The same diagnostic logic underpins our AI execution office, embedded long-term delivery for keeping controls like these running after go-live.
What counts as a modification when the model changes?
Any change to the adapter, the base model, the schema, the prompt or the routing rules should be treated as a modification under DCB0129 section 7.3, and the clinical risk management process has to be applied to it in proportion to the change. A modification that changes clinical risk needs a new Clinical Safety Case Report, and the manufacturer must keep an audit trail of every version released for deployment.
Models change more often than most health IT. A new adapter, a quantisation change or a swap of base model can alter behaviour on exactly the documents the hazard log was written around, while the interface looks identical. DCB0129 requirement 7.3.4 asks the manufacturer to maintain an audit trail of all versions and patches released for deployment, and DCB0160 section 7.3 places the matching maintenance duty on the deploying organisation, including a new safety case report for any change that alters clinical risk. Section 7.4 of DCB0160 goes further for decommissioning, requiring the organisation to consider the succeeding system and the migration of data between the two.
In practice that means pinning the exact adapter and base model versions in the configuration recorded in the safety case report, re-running the local evaluation set on every candidate version, and treating a schema change as a clinical change even when no weights move. Dilr Mira's roadmap is a useful illustration: Mira-3 is in development, with more languages and any schema without setup among its aims, and moving to it would be a modification to assess, not a routine upgrade. Teams that want this cadence designed once rather than argued every release can build it into an AI operating model with named owners.
How should a deploying organisation monitor an extraction model after go-live?
A deploying organisation should monitor an extraction model by collecting and reviewing reported safety concerns and incidents, keeping a Safety Incident Management Log, and checking whether new evidence undermines the clinical safety case. DCB0160 section 7.2 places this duty on the deploying organisation, DCB0129 section 7.2 places the same duty on the manufacturer, and corrective action has to follow the clinical risk management plan and be documented in the safety case report.
For an extraction model, incident reports alone will under-count problems, because a missing field rarely announces itself. Three monitoring sources make the picture complete:
- Reviewer corrections. Every field a reviewer changes is a data point. Track correction rates by field and document type, and set thresholds that trigger a hazard log review.
- Sampled audit. Periodically take reviewed records and re-check them against the source, which is also the control for reviewer fatigue described above.
- Volume and mix. A change in the document types arriving, such as a new referral template from a neighbouring trust, can move the model outside its tested distribution without any change to the model itself.
NHS England's ambient scribing guidance adds a principle that transfers well: the deploying organisation's monitoring data should be collected and analysed independently of the manufacturer's. For a team that is both manufacturer and deployer, the practical version is separating the people who built the pipeline from the people who measure it. Our MHRA AI Airlock analysis covers how the MHRA is testing AI in clinical settings more broadly.
Is an AI document extraction model a medical device?
Whether an AI document extraction model is a medical device depends on the intended purpose its manufacturer defines in its instructions for use, labelling and promotional materials, not on the model architecture. DILR describes Dilr Mira as an extraction tool whose outputs are drafts for human review, but the device question has to be answered by whoever defines the intended use of the deployed system.
NHS England's ambient scribing guidance makes the intended purpose point directly, and the MHRA's Software and AI as a Medical Device Change Programme, first published on 16 September 2021 and last updated on 14 June 2023, is the place to track how that boundary is evolving. The applicability guide adds two points. Its recommendation chapter says DCB0129 and DCB0160 never supersede or replace medical device regulatory requirements, so clinical safety work is additional, not a substitute. And its Step 4 notes in-house products that qualify as medical devices but are manufactured and used within a health institution, which would matter if a trust's own pipeline were ever judged to qualify as a device.
The practical consequence for an extraction project is that the intended use statement does double duty. Wording such as "extracts fields for clinician review" and wording such as "identifies drug interactions" can describe the same model and land in different regulatory places. Write it carefully, keep it consistent across the hazard log, the user guidance and anything the team says about the system internally, and take advice where it moves towards supporting a decision. Our overview of Dilr Mira sets out the extraction-only scope in more detail.
What is the best way to evidence clinical safety for an extraction model in 2026?
The best way to evidence clinical safety for an AI extraction model in 2026 is to define a narrow intended use, write a hazard log specific to extraction failure modes, test on your own documents against agreed thresholds, and pin every model version in the safety case. Buying a finished product with existing DCB0129 documentation can suit teams with limited clinical safety capacity, though the deployer still needs its own Clinical Safety Officer.
Four criteria separate a defensible approach from a fragile one:
- Ownership is explicit. The organisation knows whether it is the manufacturer, the deployer or both, the split our migration guide also flags, and has nominated a Clinical Safety Officer who meets the DCB0129 requirements of a registered, experienced clinician with risk management knowledge.
- Evidence is local. Published scorecards, including our own, are inputs. The safety case rests on testing with the organisation's own document mix.
- Controls are verified. Each control in the log has a test that shows it works, and controls that create new hazards are logged as such.
- Change is governed. Version pinning, re-testing and a new safety case report for clinically significant changes are routine, not exceptional.
Where a competitor wins is worth stating plainly. A supplier that sells a finished extraction product with its own DCB0129 safety case relieves the trust of the manufacturer file, leaving it the DCB0160 deployment file and its own Clinical Safety Officer. For an organisation with limited clinical safety capacity, that can be the faster and safer route. An open model such as Mira-Q2 suits teams that need the data to stay on their own hardware and are prepared to carry the manufacturer duties that come with building the pipeline. Our comparison with general biomedical models covers the model choice itself.
Does DCB0129 apply to a privately funded clinic using AI extraction?
DCB0129 is not mandatory for a digital product that is privately funded in both development and deployment, according to the NHS applicability guide, but the guide strongly recommends adopting it anyway. The position changes when a privately developed product is deployed in a publicly commissioned service, such as NHS-funded activity in a private hospital, because that use falls within section 250(6) of the Health and Social Care Act 2012.
A private provider weighing this should also check its contracts, since the same guide notes that compliance may be contractually required regardless of funding. Our healthcare industry overview sets out where AI pays across NHS and private settings.
Who approves the hazard log for an AI extraction model?
A Clinical Safety Officer approves each version of the hazard log for an AI extraction model under DCB0129, and the same officer approves the clinical risk management plan and each Clinical Safety Case Report. The standard requires that person to be a suitably qualified and experienced clinician with current professional registration and knowledge of risk management, nominated by the organisation's top management.
Data scientists and engineers contribute the technical hazards and test evidence, but the sign-off is clinical. Teams scoping who does what can start from our services overview or book a scoping call.
Want to see this in production? Read about private clinical extraction models, book an AI placement diagnostic, see the problems we solve, or read about our approach to placing AI inside regulated systems. More guidance sits in our compliance articles and on who we are.
Scope clinical extraction with the safety case in view.
30-min scoping call · No deck · Confidential. We will tell you whether a private model fits, and what your Clinical Safety Officer will need to see.
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.