Building HealthTech software in the UK means clearing three gates before you ship: regulation, data security and NHS integration. If your product diagnoses, treats or monitors patients it is likely Software as a Medical Device (SaMD) under UK MDR 2002, requiring UKCA marking and, for most clinical tools, DCB0129 clinical risk management with a named Clinical Safety Officer. Selling into the NHS needs a DTAC assessment across five domains, UK GDPR compliance, completion of the Data Security and Protection Toolkit, and usually Cyber Essentials Plus. Integration typically uses HL7 FHIR R4 and SNOMED CT. Realistic budgets run £40,000 to £70,000 for an MVP, £80,000 to £180,000 for mid-level products, and £250,000 to £400,000-plus for enterprise EPR-integrated systems. The UK digital health market sits near £12bn in 2026 and is forecast to roughly triple by 2031, backed by an NHS technology fund of up to £10bn confirmed in the 2025 Spending Review.
Last updated: June 2026
The UK digital health market is worth roughly £12bn in 2026 and is forecast to grow at close to 19% a year, reaching an estimated £34bn-plus by 2031. That growth is not speculative venture froth: it is underwritten by direct government spending. The 2024 Spring Budget committed £3.4bn to NHS technology for 2025/26, and the 2025 Spending Review effectively doubled the NHS technology fund to as much as £10bn over the cycle, with a further £300m in capital confirmed in November 2025. When a single buyer the size of the NHS publicly commits that much to digitisation, the addressable market for compliant software vendors expands accordingly.
The international signal is just as telling. French scheduling and EPR vendor Doctolib announced a £100m UK investment, 150 new hires and the acquisition of Medicus, betting that the UK becomes one of its largest markets. That is a strong vote of confidence in the regulatory and commercial environment, even if it also raises the competitive bar for domestic founders.
Our honest view: the opportunity is real but the barriers to entry are higher than in almost any other software vertical. The market rewards teams that treat regulation as a first-class engineering concern rather than a box-ticking afterthought. The founders who lose money are the ones who build a slick product, then discover at month nine that it is a Class IIa medical device with no clinical safety case, no UKCA route and no realistic path onto an NHS network.
| Metric | 2025/26 position | Forecast / context |
|---|---|---|
| UK digital health market value | ~£12bn | ~£34bn by 2031 (~19% CAGR) |
| NHS technology fund | Up to £10bn (2025 Spending Review) | Roughly doubled vs prior cycle |
| Dedicated NHS tech budget 2025/26 | £3.4bn (2024 Spring Budget) | Plus £300m capital (Nov 2025) |
| Notable inward investment | Doctolib £100m, 150 hires | Medicus acquisition |
| Average healthcare data breach cost | ~£8.5m ($10.93m) | Highest of any sector globally |
The breach figure in that table matters as much as the funding figures. Healthcare carries the highest average breach cost of any industry, which is precisely why the NHS gates entry so tightly. Every compliance hurdle below exists because patient data is the most sensitive and most expensive data to lose.
Your product is a medical device if it is intended for a medical purpose such as diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease. In UK software terms this is Software as a Medical Device (SaMD), regulated under the UK Medical Devices Regulations 2002, overseen by the MHRA, and evidenced by UKCA marking. The honest rule: if your software influences a clinical decision, assume it is a medical device until you can prove otherwise. A booking system, a staff rota tool or a pure patient information leaflet is generally not a device. A symptom checker that triages, an app that calculates an insulin dose, or an algorithm that flags a scan as suspicious almost certainly is.
Classification drives everything that follows, because it determines whether you can self-certify or must involve an Approved Body. Use this decision sequence:
| Class | Risk level | Worked example | Conformity route |
|---|---|---|---|
| Class I | Low | Wellness logbook, simple appointment reminder with no clinical decision support | Self-declaration, register with MHRA |
| Class IIa | Medium | Software that provides information to support a diagnosis or monitoring decision | Approved Body assessment |
| Class IIb | Medium-high | Closed-loop monitoring driving therapy, dosage-influencing algorithms | Approved Body assessment, deeper scrutiny |
| Class III | High | Software whose failure could cause death or irreversible harm, some diagnostic AI | Approved Body, full technical documentation and clinical evidence |
Be sceptical of any developer who tells you classification is a formality. Getting it wrong in either direction is costly: under-classify and the MHRA can pull your product and require a recall; over-classify and you burn six figures on an Approved Body route you never needed. We recommend a formal classification assessment, documented and dated, before you write a line of clinical logic. It is the cheapest insurance you will ever buy. The MHRA also runs a dedicated software and AI as a medical device change programme, so the boundaries continue to shift, particularly for adaptive AI, and your classification should be revisited at each major release.
Any software deployed in NHS clinical settings in England must comply with two clinical risk management standards: DCB0129, which applies to you as the manufacturer, and DCB0160, which applies to the organisation deploying it. These are mandatory under the Health and Social Care Act, not optional best practice. DCB0129 requires you to operate a clinical risk management system, appoint a suitably qualified and registered Clinical Safety Officer (CSO), maintain a Hazard Log, and produce a Clinical Safety Case Report that argues, with evidence, that your software is safe to use as intended.
This is the standard most first-time HealthTech founders underestimate. It is not a document you write the week before launch. The Hazard Log is a living register of every way your software could contribute to patient harm, the controls you have put in place, and the residual risk after those controls. It must be built alongside the product and maintained for its entire life. When you change a feature, you reassess the hazards. When the NHS deploys your product, their own clinical safety team produces a DCB0160 case that depends on the artefacts you supply.
The CSO role is frequently misunderstood. The CSO must be a clinician (or have appropriate clinical knowledge), hold current registration, and have completed recognised clinical safety training. They sign off the safety case. You cannot have a developer wear this hat as a side duty, and you cannot outsource the accountability entirely, though a fractional or contracted CSO is a common and legitimate model for early-stage companies.
Our stance: treat DCB0129 as a design constraint, not a deliverable. Teams that run hazard workshops at the start of each sprint ship faster in the long run, because they design out clinical risk early rather than retrofitting controls under deadline pressure. The teams that bolt it on at the end almost always slip their launch by months.
The Digital Technology Assessment Criteria (DTAC) is the national baseline the NHS uses to decide whether a digital product is safe, secure and usable enough to adopt. In practice it is the single most common gateway document an NHS buyer will ask you to complete before any meaningful conversation about procurement. DTAC does not replace medical device regulation or clinical safety standards; it aggregates them into one assessment across five domains, plus a usability and accessibility component.
Completing DTAC well is partly an exercise in having your house in order. If you have already done the regulatory and security work, DTAC becomes a collation task. If you have not, DTAC exposes every gap at once, in front of a buyer. That is why we advise clients to draft their DTAC response early, even before a buyer asks, and use the gaps it reveals as a compliance roadmap.
| DTAC domain | What it assesses | Evidence you will need |
|---|---|---|
| Clinical safety | DCB0129 compliance | Clinical Safety Case, Hazard Log, named CSO |
| Data protection | UK GDPR, DSPT | DPIA, DSPT completion, lawful basis |
| Technical security | Cyber resilience | Cyber Essentials Plus, penetration test, ISO 27001 where applicable |
| Interoperability | Standards adherence | FHIR/SNOMED conformance, Internet First posture |
| Usability and accessibility | Design quality | WCAG 2.1 AA testing, user research evidence |
The usability and accessibility domain is the one founders most often treat lightly and most often fail. The NHS expects WCAG 2.1 AA conformance and genuine evidence of user research with the clinicians or patients who will use the product. A polished consumer-grade interface is not the same thing as an accessible one, and assessors can tell the difference. Build accessibility testing into your QA from the first sprint and you will pass this domain without drama.
One more honest point: DTAC is a baseline, not a certificate. Passing it does not guarantee a sale, and different trusts and integrated care boards may layer additional local requirements on top. Treat a strong DTAC response as the price of entry to the conversation, not the close.
Health data is special category data under UK GDPR, which means the legal and security bar is the highest the regime sets. You must identify a lawful basis under Article 6 and a separate condition for processing special category data under Article 9, complete a Data Protection Impact Assessment before processing, and apply data minimisation rigorously. The average healthcare breach now costs around £8.5m, and the Information Commissioner's Office treats health data failures severely, so this is not an area to approximate.
On top of UK GDPR sit the Caldicott principles, the NHS-specific framework for handling confidential patient information. The eighth principle, that there is a duty to share information for individual care just as there is a duty to protect it, is one founders often miss: privacy by design does not mean making clinically useful data inaccessible to the clinicians who need it. Good health software balances protection and appropriate sharing, and your Caldicott Guardian conversations should shape your access control model.
| Requirement | What it is | When it is needed |
|---|---|---|
| UK GDPR (special category) | Article 6 + Article 9 lawful basis, DPIA | Always, before any processing |
| Caldicott principles | NHS framework for confidential patient information | Any NHS or patient-identifiable data |
| Data Security and Protection Toolkit | Annual NHS self-assessment of data standards | To connect to NHS systems or hold NHS data |
| Cyber Essentials Plus | Independently verified cyber baseline | Most NHS contracts and DTAC |
| ISO 27001 | Information security management system | Enterprise deals, larger trusts |
| ISO 13485 / ISO 14971 | Medical device QMS / risk management | If you are a regulated device manufacturer |
The Data Security and Protection Toolkit (DSPT) deserves specific attention. It is an annual self-assessment against the National Data Guardian standards, and completing it to at least the standards-met level is effectively a prerequisite for connecting to NHS infrastructure or holding NHS patient data. Plan for it as a recurring obligation, not a one-off.
Our recommendation on security certifications is pragmatic: get Cyber Essentials Plus early because it is the cheapest credential that unlocks the most doors, pursue ISO 27001 when you are chasing enterprise trust deals, and only invest in the full ISO 13485 quality management system and ISO 14971 risk management framework if you are genuinely a regulated device manufacturer. Sequencing these correctly can save a young company tens of thousands of pounds and several months. Where AI components process patient data, an automation partner with health-sector experience, such as an AI automation agency in London that understands DSPT and clinical governance, can keep your security posture aligned as the model evolves.
NHS integration in 2026 is built on HL7 FHIR R4 as the data exchange standard and SNOMED CT as the clinical terminology, with NHS England's Internet First policy meaning new services should be accessible over the public internet with appropriate security rather than legacy private networks. If you are exchanging clinical data with NHS systems, you will be producing and consuming FHIR resources, coding observations and conditions in SNOMED CT, and authenticating against national services. Getting this architecture right from the start is the difference between a six-week integration and a six-month one.
A typical integration walkthrough looks like this. First, model your clinical data as FHIR resources: a patient becomes a Patient resource, a blood pressure reading an Observation, a diagnosis a Condition. Second, code the clinical content with SNOMED CT concepts rather than free text, so the data is computable and interoperable. Third, connect to the relevant national services for identity and record access. Fourth, handle the realities of legacy Electronic Patient Record (EPR) systems, which is where most projects actually lose time.
The honest warning here is about legacy EPRs. National standards say FHIR R4; the EPR in a given trust may implement an older version, support only a subset of resources, or wrap everything in proprietary extensions. Budget engineering time for this reality. We have seen integrations where 80% of the effort went into the last 20% of edge cases in a single trust's EPR configuration. A custom integration layer, often built as a dedicated web application or middleware service, is usually the cleanest way to insulate your core product from each trust's quirks. For products that also need automated data flows between systems, structured business process automation can orchestrate the FHIR exchanges, retries and error handling that integrations live or die on.
Our stance: do not build your own FHIR stack from scratch unless you must. Mature FHIR server implementations and terminology services exist, and reinventing them rarely adds value. Spend your engineering creativity on the clinical workflow, not on re-implementing a standard that thousands of engineers have already hardened.
A compliant UK HealthTech build costs between £40,000 and £400,000-plus depending on scope, with a clinical-grade MVP realistically landing at £40,000 to £70,000, a mid-level product at £80,000 to £180,000, and an enterprise EPR-integrated or AI-driven system at £250,000 to £400,000 and up. Those are development figures. The mistake almost every first-time founder makes is forgetting the regulatory and assurance costs that sit on top, which can add 20% to 50% to the total and which competitors rarely itemise.
| Tier | Development cost | Typical timeline | What you get |
|---|---|---|---|
| Clinical MVP | £40,000 - £70,000 | 3 - 5 months | Core workflow, Class I or light IIa, DCB0129 foundations |
| Mid-level product | £80,000 - £180,000 | 6 - 9 months | Multi-role app, FHIR integration, full clinical safety case |
| Enterprise / AI | £250,000 - £400,000+ | 9 - 18 months | EPR integration, AI/ML, higher device class, deep assurance |
Now the costs nobody puts on their pricing page. These are real and you must budget for them:
Our blunt advice: be sceptical of any quote that gives you a single development figure with no line for clinical safety, conformity assessment or post-market surveillance. A £60,000 quote that ignores a £40,000 regulatory pathway is not cheaper, it is incomplete. The teams that succeed plan the full cost of compliant operation, not just the cost of writing code.
You sell into the NHS primarily through national procurement frameworks that pre-qualify suppliers, because most trusts will not buy off-framework for anything material. The frameworks do the heavy lifting of due diligence once, so a trust can buy from you with confidence and minimal procurement overhead. Getting onto the right framework is therefore a commercial milestone as important as any product feature, and it is a process in its own right with its own application windows and evidence requirements.
The routes you will hear about most often:
| Route | Best for | What it gives you |
|---|---|---|
| G-Cloud (Digital Marketplace) | Cloud software and hosting | Pre-qualified catalogue listing public bodies can buy from directly |
| Health Systems Support Framework | Digital and transformation services | Access to ICBs and trusts for support and software services |
| NHS clinical and digital frameworks (e.g. CDHS-type lots) | Clinical digital products | Compliant route for clinical software into trusts |
| NHS SBS / LPP and similar buying organisations | Broad NHS supply | Aggregated purchasing power across many trusts |
| Direct trust pilot | Early traction and evidence | Real-world deployment data to strengthen later framework bids |
Our honest view on go-to-market: do not wait for a framework to start selling. The fastest credible path for most early-stage HealthTech companies is to land one or two clinical pilots with a forward-thinking trust or integrated care board, generate real outcome evidence and a completed DTAC, and then use that evidence to win a framework place and scale. The pilot proves the product works in a live clinical environment; the framework lets you sell it at volume. Trying to do framework-first with no deployment evidence is the slow road.
One stance worth stating plainly: NHS sales cycles are long, and you should capitalise your business accordingly. A nine to eighteen-month sales cycle is normal for clinical software. Founders who model NHS revenue arriving in quarter two of year one almost always run out of runway. Plan for the long cycle, and consider parallel revenue from private healthcare, occupational health or international markets to bridge the gap. A well-built custom CRM that tracks every trust, framework deadline and pilot stakeholder is genuinely useful here, because losing a procurement window to a missed date is a painfully avoidable way to lose a deal.
Softomate builds compliant UK HealthTech software through a five-stage process that runs regulation, security and engineering in parallel rather than in sequence, on fixed-quote terms agreed before development starts. We are a London-based software and AI agency in Stanmore (HA7), and our model is deliberately built around the reality that in health, the compliance work is the project, not an addendum to it. We do not start coding clinical logic until classification and the clinical risk approach are agreed, because that is how budgets blow out.
Our five stages:
| Stage | Typical duration | Key output |
|---|---|---|
| Discovery and classification | 2 - 4 weeks | Classification, roadmap, fixed quote |
| Clinical safety and architecture | 3 - 5 weeks | Hazard Log, CSO plan, technical design |
| Build and integration | 3 - 6 months | Working product, FHIR integration |
| Assurance and DTAC | 4 - 8 weeks | DTAC pack, safety case, security evidence |
| Launch and maintenance | Ongoing | Live product, post-market surveillance |
Engagements typically start from £45,000 for a clinical MVP and scale with device class and integration depth. Because we quote fixed against an agreed scope after discovery, you are not exposed to open-ended time-and-materials risk on the compliance work, which is exactly where health projects usually overrun. Where the product needs conversational patient-facing components, our AI chatbot development service and AI voice agent development teams build them with clinical safety and accessibility designed in from the first sprint rather than retrofitted. To scope your build and get a fixed quote, talk to our team.
If your software is used in an NHS clinical setting in England, yes, DCB0129 is mandatory. It requires a clinical risk management system, a named Clinical Safety Officer, a Hazard Log and a Clinical Safety Case Report. Even non-NHS clinical software benefits from following it, as buyers increasingly expect it.
A clinical MVP typically costs £40,000 to £70,000 in development, mid-level products £80,000 to £180,000, and enterprise EPR-integrated systems £250,000 to £400,000-plus. Add 20% to 50% for regulatory work: Approved Body assessment, Clinical Safety Officer, Cyber Essentials Plus and ongoing safety case maintenance.
Plan for three to five months for a clinical MVP, six to nine months for a mid-level product, and nine to eighteen months for enterprise systems. Class I self-certification adds one to three months; the Approved Body route for Class IIa and above adds six to twelve months and should run in parallel with development.
If it is intended for a medical purpose such as diagnosis, monitoring, prediction or treatment, it is a medical device under UK MDR 2002 and needs UKCA marking. Booking, rota and pure information tools usually are not. If your software influences a clinical decision, assume it is a device until a documented assessment proves otherwise.
The Digital Technology Assessment Criteria is the NHS baseline for adopting digital products, covering clinical safety, data protection, technical security, interoperability and usability. It is not law, but in practice most NHS buyers require a completed DTAC before serious procurement discussions, so treat it as a mandatory gateway.
If you exchange clinical data with NHS systems, yes. HL7 FHIR R4 is the standard data exchange format and SNOMED CT the clinical terminology. NHS England's Internet First policy means new services should run over the public internet with appropriate security. Expect legacy EPR systems to support FHIR only partially.
The DSPT is an annual NHS self-assessment against the National Data Guardian standards. Completing it to at least the standards-met level is effectively required to connect to NHS infrastructure or hold NHS patient data. The toolkit is free, but evidence gathering and remediation take real staff time each year.
Yes, but adaptive AI faces extra scrutiny. The MHRA runs a software and AI as a medical device programme addressing how learning algorithms are regulated. AI that supports diagnosis or treatment is typically a higher-class device, needs strong clinical evidence, and must show that model changes are controlled and validated, not silently self-updating in production.
Yes, if your software is used in clinical settings. The CSO must be clinically qualified, registered and trained in clinical safety. Early-stage companies commonly use a fractional or contracted CSO at around £600 to £1,200 per day rather than a full-time hire, which keeps the role properly filled without the full salary cost.
Most NHS sales run through procurement frameworks such as G-Cloud and health-specific frameworks that pre-qualify suppliers. The fastest credible route is to land one or two clinical pilots, generate outcome evidence and a completed DTAC, then use that to win a framework place and scale. Expect a nine to eighteen-month sales cycle.
Building HealthTech software in the UK is less about code and more about clearing three gates in the right order: decide whether you are a medical device and which SaMD class applies, build clinical safety in through DCB0129 with a real Clinical Safety Officer, and architect for NHS integration with FHIR R4 and SNOMED CT from day one. Budget honestly: £40,000 to £70,000 for a clinical MVP, six figures for mid-level, and £250,000-plus for enterprise, with another 20% to 50% for regulatory and assurance work most quotes omit. Pass DTAC, complete the DSPT, get Cyber Essentials Plus, and plan for a nine to eighteen-month NHS sales cycle with pilots first and frameworks second. The market is worth £12bn and growing fast on the back of an NHS technology fund of up to £10bn. The opportunity is genuine; the discipline to earn it is what separates the products that ship from the ones that stall.
If you are scoping a clinical product and want a fixed-quote path through classification, clinical safety and NHS integration, explore our software development service in London or book a discovery call to map your compliance roadmap before you build.
Written by Deen Dayal Yadav, Founder of Softomate Solutions, a London-based software development and AI automation agency in Stanmore (HA7). With over 12 years building software, integrations and automation systems for UK businesses, including regulated and data-sensitive sectors, he advises founders on compliant HealthTech architecture, NHS integration and the realistic cost of getting a clinical product to market. Softomate Solutions is 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
Every project we take on has a measurable outcome. Talk to our London team and we will show you exactly how we would approach your challenge.
Softomate Solutions Limited
Deen Dayal Yadav
Online
