AI clinical decision support (CDS) software is regulated in the UK as a medical device whenever it interprets, calculates or makes a recommendation about a specific patient, rather than simply displaying reference information. Under the Medical Devices Regulations 2002, most diagnostic and risk-scoring AI CDS tools fall into Class IIa or higher and need a UKCA mark assessed through the MHRA and a UK Approved Body. Before any NHS deployment, the tool must clear the Digital Technology Assessment Criteria (DTAC), carry a DCB0129 supplier clinical safety case with a hazard log, and the local trust must produce its own DCB0160 safety case. Adoption is accelerating: the MHRA ran a Call for Evidence from 18 December 2025 to 2 February 2026 and a new AI medical device framework is due during 2026, alongside the AI Airlock regulatory sandbox. Done well, AI CDS releases clinician time worth tens of thousands of pounds per site each year.
Last updated: June 2026
Clinical decision support is software that helps a clinician make a decision about a patient, and the regulatory line is drawn by what the software actually does, not by what its marketing claims. The honest rule is simple: if the tool only displays, stores or signposts reference information that a clinician then interprets themselves, it usually sits outside medical device regulation. The moment the tool interprets data, calculates a result, scores a risk, triages, or recommends a specific action for a specific patient, it becomes a regulated medical device. Most AI CDS tools fall on the regulated side because the whole point of the AI is to interpret.
That distinction matters because it decides whether you face a UKCA conformity assessment, a clinical safety case and post-market surveillance, or merely a privacy notice. Vendors who pitch an AI symptom checker as "just information" are usually wrong, and the MHRA has been explicit that intended use governs classification.
Here is how the categories typically split:
| Software behaviour | Example | Regulated device? |
|---|---|---|
| Displays reference text only | Drug formulary lookup, guideline library | Usually no |
| Stores or transmits patient data | EPR record viewer | Usually no (data tool) |
| Calculates a clinical value | eGFR or dosing calculator | Yes |
| Interprets images or signals | AI chest X-ray triage | Yes, often higher class |
| Scores or predicts patient risk | Sepsis or deterioration alert | Yes |
| Recommends a specific action | Treatment recommendation engine | Yes |
Our view: assume your AI CDS tool is a medical device until a regulatory assessment proves otherwise. Building on that assumption is far cheaper than retrofitting a clinical safety case after a trust has already piloted your product and found a gap. The boundary cases (ambient scribing that drafts a clinical note, or a chatbot that "suggests" a pathway) are exactly where teams get caught, because a draft that a clinician edits can still meet the definition of a device if it influences the decision.
If your software has a medical purpose and works on individual patient data to inform diagnosis, prevention, monitoring or treatment, it is almost certainly software as a medical device (SaMD), and the AI element makes it AIaMD (AI as a medical device). Under the UK Medical Devices Regulations 2002, you cannot place an AIaMD product on the GB market without a UKCA mark, and the risk class drives how much scrutiny that involves. Class I products can self-declare for now, but the overwhelming majority of AI CDS sits in Class IIa or above and needs a UK Approved Body to assess your technical documentation, quality system and clinical evidence.
The practical way to answer the title question is to walk a short decision sequence. Run each step in order and stop at the first "yes".
Classification rules (in particular Rule 11 for decision software) tend to push diagnostic and monitoring software up to Class IIa, IIb or even III where outputs could cause death or irreversible deterioration. The table below is a working guide, not a substitute for a formal assessment.
| Class | Typical AI CDS example | Conformity route | Indicative assessment cost |
|---|---|---|---|
| Class I | Low-risk wellbeing prompt | Self-declaration | £2,000 - £6,000 internal |
| Class IIa | Risk score informing routine care | Approved Body audit | £25,000 - £60,000 |
| Class IIb | Imaging triage, deterioration alerts | Approved Body, deeper evidence | £50,000 - £120,000 |
| Class III | Software that could directly cause death if wrong | Full design dossier review | £100,000+ |
Be sceptical if a supplier tells you their imaging or triage AI is Class I. It is a red flag that suggests they have either misread Rule 11 or are hoping no one checks. Registration with the MHRA is also required once you have your conformity assessment, and you must appoint a UK Responsible Person if you are based outside the UK.
The regulatory ground is moving in 2026, and the direction is towards a dedicated, proportionate framework for AI as a medical device rather than forcing AI into rules written for static software. The MHRA ran a Call for Evidence from 18 December 2025 to 2 February 2026 to gather views on how AIaMD should be regulated, and a new AI medical device framework is expected to follow during 2026 as part of the wider Life Sciences Sector Plan. A National Commission into the Regulation of AI in Healthcare has also been established to look at the bigger structural questions, including liability and accountability when an AI system contributes to a clinical decision.
The most practically useful development for vendors is the AI Airlock, the MHRA regulatory sandbox. It lets selected manufacturers test how their AIaMD would be regulated in a controlled, monitored environment, working through real-world challenges like adaptive (self-learning) models, generative AI outputs and performance drift before full market entry. For a London health-tech startup, the Airlock is a route to de-risk a novel product and build regulatory evidence in partnership with the regulator rather than guessing.
Here is what is changing and what it means for your planning:
Our stance: do not wait for the final framework before you start. The core obligations (a quality management system, clinical evidence, a safety case and post-market surveillance) are not going to disappear, and teams that build these foundations now will simply slot into the new rules. The organisations that struggle in 2026 will be those treating regulation as a launch-day formality.
Even a fully UKCA-marked AI CDS tool cannot simply be switched on inside an NHS organisation, because the NHS applies its own procurement and clinical-safety gates on top of medical device regulation. The three you must know are DTAC, DCB0129 and DCB0160, and they answer different questions. DTAC asks "is this product fit to be bought by the NHS at all?". DCB0129 asks "has the supplier proven the product is clinically safe by design?". DCB0160 asks "has this specific trust deployed it safely in its specific workflow?".
DTAC is the national baseline assessment used across NHS procurement. It bundles five pillars: clinical safety, data protection, technical security, interoperability and usability and accessibility. You complete it once as a supplier and reuse it across buyers, which is why getting it right early pays off repeatedly. Crucially, DTAC does not replace clinical risk management; it points to it.
| Gate | Who owns it | What it produces | When |
|---|---|---|---|
| DTAC | Supplier completes, buyer reviews | Completed assessment across 5 pillars | Pre-procurement |
| DCB0129 | Manufacturer / supplier | Clinical safety case + hazard log + CSO sign-off | During development |
| DCB0160 | Deploying NHS organisation | Local safety case for its own workflow | Before go-live |
| DSPT | Organisation handling data | Data Security and Protection Toolkit submission | Annual |
DCB0129 and DCB0160 are mandatory clinical risk management standards under the Health and Social Care Act. Both require a named Clinical Safety Officer (a suitably qualified clinician) to own and sign the safety case and maintain a living hazard log that records each hazard, its severity, likelihood, controls and residual risk. The Data Security and Protection Toolkit (DSPT) sits alongside, evidencing that the organisation meets the national data security standards.
The recurring failure we see is suppliers who write the DCB0129 case but assume the trust will somehow inherit it. It will not. The trust must do its own DCB0160 work, and if your documentation is thin the trust's Clinical Safety Officer cannot complete theirs, which stalls the whole deployment. Help your buyers by handing over a clean, well-structured hazard log and a deployment guide that maps directly onto their DCB0160 obligations. For organisations building the connective tissue between an AI tool and existing systems, our business process automation services in London are often where these integration and safety-mapping problems get solved in practice.
NICE assessment is the gate that decides whether the NHS should pay for your AI CDS tool and at what value, and for early-stage AI products the most relevant route is the Early Value Assessment (EVA). EVA exists precisely because promising digital health technologies often reach the market before they have a full evidence base. It offers a time-limited, conditional recommendation that allows adoption in the NHS while real-world evidence is generated, after which NICE reviews the data and decides whether to recommend the technology routinely, with conditions, or not at all.
This matters because the old model (full health technology assessment before any adoption) was a poor fit for software that improves with use and accumulates evidence in deployment. EVA gives a structured way to say "this looks valuable, let us use it carefully and prove it". The trade-off is that you sign up to generate evidence to an agreed plan, and weak data at the review point can end the recommendation.
The evidence NICE looks for typically includes:
| Route | Best for | Outcome | Typical horizon |
|---|---|---|---|
| Early Value Assessment | Promising tools, incomplete evidence | Conditional, time-limited adoption | Months to a few years |
| Full HealthTech evaluation | Mature evidence base | Routine recommendation | Longer, more rigorous |
| Local validation only | Single-site pilots | Local use, no national steer | Fastest, narrowest |
Our honest take: build your evidence-generation capability into the product from day one. Log the right outcome metrics, capture demographics, and instrument the tool so that when NICE or a trust asks for real-world data you can produce it in weeks, not invent it under pressure. Treating evidence as a feature, not an afterthought, is what separates the AI CDS tools that scale across the NHS from the ones that stall after a single friendly pilot site.
The clearest value from AI CDS today comes from tasks that are high-volume, pattern-heavy and time-consuming for clinicians, where the AI assists rather than replaces judgement. Across UK deployments, the strongest verticals are radiology and imaging triage, ambient documentation, predictive risk scoring, medicines and pharmacy support, and mental health screening. The common thread is that the tool releases clinician time or surfaces something a human might miss under workload pressure, while a clinician retains the decision.
Quantifying the benefit is where most competitor articles go quiet, so here is a concrete view. Ambient AI scribing, which drafts a clinical note from the consultation, can save a GP or consultant several minutes per appointment. At even three minutes saved across twenty appointments a day, that is an hour of clinician time released daily. Cost that at a conservative blended clinician rate and the annual time-released value per clinician runs comfortably into five figures.
| Vertical | What the AI does | Primary benefit | Indicative annual value per site |
|---|---|---|---|
| Imaging triage | Flags suspected abnormalities, prioritises worklist | Faster reporting, earlier detection | £40,000 - £150,000 time released |
| Ambient scribing | Drafts consultation notes | Clinician time, less burnout | £12,000 - £30,000 per clinician |
| Deterioration alerts | Predicts sepsis or decline | Earlier intervention, fewer escalations | Outcome-driven, high |
| Pharmacy support | Checks interactions, optimises dosing | Fewer medication errors | Risk reduction |
| Mental health triage | Screens and routes referrals | Shorter waits, better prioritisation | Capacity gains |
NHS England has published specific guidance on AI-enabled ambient scribing, which signals that this category is maturing from experiment to mainstream. The opportunity is real, but our view is firm: chase the assistive use cases first. Patients and clinicians broadly support AI that assists a human, and are far more ambivalent about AI that appears to make the judgement itself. A tool that "helps the radiologist clear the worklist faster" wins trust and adoption far quicker than one positioned as "the AI that diagnoses". For organisations building the patient-facing layer around these systems, our AI chatbot development service and AI voice agent development work handles the safe triage and signposting front end, while clinical interpretation stays firmly with regulated tools and qualified staff.
The non-clinical wins matter too. A large share of NHS friction is administrative: booking, reminders, referral routing, follow-up. Automating that with well-governed workflow tools frees capacity without touching the regulated clinical boundary at all, which is often the fastest route to measurable savings while a regulated CDS product works through its longer approval path.
The three risks that derail AI CDS deployments are biased performance across patient groups, opacity that clinicians cannot interrogate, and cybersecurity exposure, and all three must be managed before go-live rather than discovered afterwards. Bias is the most insidious because an AI model trained on a narrow dataset can perform brilliantly on average while quietly underperforming for a specific ethnic group, age band or comorbidity profile. If your evidence does not break performance down by subgroup, you do not actually know whether the tool is safe for your population.
Explainability is the second pillar. A clinician who cannot understand why the model flagged a patient cannot sensibly accept or override it, and accountability becomes murky when something goes wrong. The transparency principles published by UK regulators stress that intended use, training data, limitations and known failure modes should be communicated clearly. A model that is a sealed black box is a clinical governance problem, not just a technical preference.
Use this checklist before any deployment:
| Risk area | Question to answer | Evidence required |
|---|---|---|
| Bias and equity | Does performance hold across subgroups? | Subgroup validation, equality impact assessment |
| Explainability | Can clinicians understand and challenge outputs? | Model cards, output rationale, training data notes |
| Failure modes | What happens when the model is wrong or unsure? | Hazard log, fallback workflow, human override |
| Cybersecurity | Is patient data and model integrity protected? | DSPT, penetration testing, NCSC alignment |
| Performance drift | Will accuracy degrade over time? | Monitoring plan, retraining and change control |
On cybersecurity, AI CDS systems are attractive targets because they sit close to clinical data and clinical workflow. The National Cyber Security Centre's guidance for healthcare and the secure-by-design principles for AI systems should anchor your approach, and the DSPT submission is the minimum bar, not the finish line. Model integrity matters too: an attacker who can poison training data or manipulate inputs can degrade clinical safety without ever stealing a record.
Our stance is uncompromising here. If a vendor cannot show you subgroup performance data, a clear account of failure modes, and a monitoring plan for drift, do not deploy, regardless of how impressive the headline accuracy looks. The headline number is the easy part. The safety engineering around the edges is what protects patients, and it is exactly where corners get cut under commercial pressure.
Softomate Solutions helps UK health-tech companies and NHS-adjacent organisations build, integrate and govern AI-driven software through a structured five-stage process, with fixed-quote pricing agreed up front so there are no surprise invoices. We are a London-based software and automation agency in Stanmore (HA7), and while clinical interpretation always stays with regulated tools and qualified clinicians, we build the surrounding architecture: the integrations, the workflow automation, the data plumbing, the patient-facing interfaces and the documentation scaffolding that deployment depends on. Engagements typically start from £6,500 for a discovery and architecture sprint, with full build projects scoped to a fixed price after stage one.
Our five stages are deliberately sequenced so that compliance and safety thinking happen before code, not after.
| Stage | Typical duration | Key deliverable | Indicative price |
|---|---|---|---|
| Discovery and classification | 2 - 3 weeks | Classification memo, gate roadmap | From £6,500 |
| Architecture and safety design | 3 - 4 weeks | System design + hazard register | From £9,000 |
| Build and integration | 8 - 16 weeks | Working, integrated software | Fixed quote, from £28,000 |
| Validation and documentation | 3 - 5 weeks | DTAC pack, DCB0129 inputs | From £7,500 |
| Launch and monitoring | Ongoing | Live system + monitoring | Retainer from £1,800/month |
Because we fix the quote after discovery, you know the full cost before the build begins. Most clients also engage us for the surrounding AI automation and custom CRM development work that turns a single clinical tool into a joined-up operational system. If you are scoping an AI CDS or health-tech build and want a clear, compliance-aware plan, start with a conversation through our contact page.
No, but most of it is. If the software only displays reference information that a clinician interprets, it is usually not a device. The moment it interprets, calculates, scores or recommends something about an individual patient, it becomes software as a medical device under UK rules and needs a UKCA mark.
SaMD is software as a medical device: software with a medical purpose that is not part of a hardware device. AIaMD is the subset that uses artificial intelligence or machine learning. AIaMD attracts extra scrutiny around training data, explainability, performance drift and change control because the model can behave less predictably than fixed code.
DTAC is the Digital Technology Assessment Criteria, the NHS national baseline for procuring digital health products. It covers clinical safety, data protection, technical security, interoperability, and usability and accessibility. It is the standard buyers expect before purchase. It does not replace medical device regulation or clinical risk standards; it sits alongside them.
The deploying NHS organisation owns its DCB0160 local clinical safety case, signed by its own named Clinical Safety Officer. The supplier owns the DCB0129 supplier safety case. Suppliers should hand over a clean hazard log and deployment guidance so the trust can complete its DCB0160 work, but they cannot do it for them.
The AI Airlock is the MHRA regulatory sandbox for AI as a medical device. It lets selected manufacturers test how their product would be regulated in a controlled, monitored setting, working through challenges like adaptive models, generative AI outputs and performance drift before full market entry, in partnership with the regulator.
It varies widely. UKCA conformity assessment for a Class IIa or IIb device can take several months to over a year depending on evidence readiness and Approved Body capacity. Add DTAC, DCB0129 and per-site DCB0160 work. Realistically, plan for twelve to twenty-four months from concept to first scaled NHS deployment.
Early Value Assessment is a NICE route giving promising digital health technologies a time-limited, conditional recommendation so they can be used in the NHS while real-world evidence is generated. After the evidence period NICE reviews the data and decides whether to recommend routine use, continue with conditions, or stop the recommendation.
No. The strongest and most accepted use cases are assistive: the AI surfaces findings, drafts notes or prioritises work, while a qualified clinician retains the decision and accountability. Patients broadly support AI that assists a human and are more cautious about AI that appears to make clinical judgements on its own.
Through layered controls: completing the Data Security and Protection Toolkit, aligning with NCSC and secure-by-design principles, encrypting data in transit and at rest, penetration testing, and protecting model integrity against data poisoning. UK GDPR and the data protection requirements within DTAC also apply throughout the system lifecycle.
Costs vary by scope and risk class. A discovery and architecture sprint with Softomate starts from £6,500, with full integrated builds fixed-quoted from around £28,000. Add separate UKCA conformity assessment costs, which range from roughly £25,000 for Class IIa to over £100,000 for Class III products.
AI clinical decision support is one of the highest-value opportunities in UK healthcare, but the path runs through real gates, not around them. If your tool interprets, calculates, scores or recommends for an individual patient, treat it as a medical device, expect Class IIa or higher, and budget for a UKCA assessment from roughly £25,000 upward. Before any NHS go-live you will clear DTAC, hold a DCB0129 supplier safety case, support each trust's DCB0160 work, and submit the DSPT. NICE Early Value Assessment offers a conditional adoption route while you generate evidence, and the 2026 MHRA framework plus the AI Airlock sandbox are making the regulatory route clearer, not harder. The biggest wins today are assistive: imaging triage, ambient scribing and risk alerts that release clinician time worth tens of thousands of pounds per site. Build evidence, safety and explainability in from day one, and the rest follows.
Ready to scope a compliance-aware AI healthcare build? Talk to our team through our software development service in London and we will map your classification, gates and a fixed-quote plan.
Written by Deen Dayal Yadav, Founder of Softomate Solutions, a London-based AI automation and software development agency in Stanmore (HA7). With over 12 years building software and automation systems for UK businesses, including health-tech integrations and regulated workflow tools, I help organisations turn AI opportunities into safe, deployable systems. Softomate Solutions is a UK company registered at Companies House. Learn more about our team and approach.
We protect the real names of all clients featured in examples and case studies. Every testimonial is from a real client.
More from the blog
Work with us
Book a free 30-minute discovery call with DD and get a personalised automation roadmap.
Softomate Solutions Limited
Deen Dayal Yadav
Online
We use essential cookies to keep the site running. With your permission, we also use analytics cookies to understand how visitors use our site so we can improve it. No data is sold. Privacy Policy
