What is a Healthtech Platform? UK Guide for Buyers.
A healthtech platform serves several organisations at once and carries clinical safety duties. Here is what NHS use asks of one.
What is a Healthtech Platform? UK Guide for Buyers.
Key Takeaways
- A healthtech platform serves several organisations and several kinds of user at once, exchanges data with clinical systems of record, and carries clinical safety obligations.
- If a clinician acts on what your software displays, the software is part of the care pathway and a set of legal obligations follows.
- The UK standards are better read as a sequence than as a list, because each one gates the next.
- FHIR is where new work should go, and it is not what you will find in most existing NHS estates.
- Building the platform is one project and selling it into the NHS is another, usually the longer of the two.
What is a healthtech platform, in practice? It is software used by more than one health organisation and more than one type of user, joined to the clinical systems that hold the record, and subject to clinical safety law because people make care decisions on what it shows.
An app for one clinic can avoid most of that. A platform rarely can.
So the question of what is a healthtech platform matters before anything is designed, because the answer decides which standards apply and in what order. If you already know it is a platform and want to talk about the build, our healthcare software development page covers how we deliver one. This post stays with the definition and what it commits you to.
Seven tenants, seven heights, one bridge. Two of them have not quite reached it yet.
A Platform Against an App
People use the two words interchangeably. The difference matters commercially, because it changes what has to exist before anyone can use the thing.
App | Platform | |
|---|---|---|
Tenants | One organisation | Many, isolated from each other |
Roles | Usually two or three | Clinician, admin, patient, commissioner |
Systems of record | Often none | Integration is the point |
Configuration | Fixed | Per tenant, without code changes |
Clinical safety | Depends on use | Almost always in scope |
Onboarding | Install it | A process, with data and training |
What makes something a platform rather than an application.
Multi-tenancy is the row that adds the most unplanned work. Each organisation wants slightly different terminology, pathways and reporting, and the choice is between configuring that per tenant or building a product that forces everyone to conform.
Getting that wrong early is expensive. A platform that needs code changes for each new customer has a growth ceiling built into its architecture, which is the same trap that catches enterprise application development generally.
Building a Healthtech Platform in the UK: The Regulatory Journey
Most guides cover these standards one at a time. They make more sense as a sequence, because each one gates something.
Requirement | What it is | When it applies |
|---|---|---|
UK GDPR and DPIA | Lawful basis, minimisation, a completed assessment | Any personal data, from design |
DSPT | Data Security and Protection Toolkit self-assessment | Before handling NHS data |
DCB0129 | Clinical risk management by the manufacturer | You build health IT |
DCB0160 | Clinical risk management by the deploying organisation | Your customer deploys it |
DTAC | Digital Technology Assessment Criteria | NHS organisations assess you |
MHRA SaMD | Software as a medical device registration | You diagnose, treat or calculate |
Compliance with DCB0129 and DCB0160 is mandatory under the Health and Social Care Act 2012 for health IT systems used in NHS care. That is a legal duty rather than a procurement preference, and it is the one most often discovered late.
Six requirements, in the order they bite.
The MHRA question changes a project's shape the most. Software that informs a clinical decision may be a medical device, and that classification brings registration, technical documentation and post-market surveillance. Our post on software that counts as a medical device goes through the test in more detail.
Answer it before you design. A product that turns out to be a medical device halfway through the build is a different project from the one that was costed.
What DCB0129 and DCB0160 Mean for a Build Team
The build team's side is a named clinical safety officer, a hazard log and a safety case, and we set out how we run those in our approach to compliant healthcare software. What changes on a platform is the other half of the pair.
DCB0160 falls on each organisation that deploys the software. An app for one clinic has one deployer, so one assessment. A platform with seven tenants has seven, each run by that tenant's clinical safety officer against how they intend to use it.
So your hazard log will be read by people you have never met, on whatever timetable their governance sets. Write it for them in plain hazards and clear controls, and say which configuration options change the risk.
Teams tend to miss that last point. If a tenant can switch a feature on, their assessment has to cover it, so the configuration screen is a clinical safety surface as well as an admin one.
A shield, a heartbeat and a stack of paperwork, which is a fair summary of DCB0129.
Interoperability, and Why FHIR is Not the Whole Story
Interoperability is the part buyers most underestimate. FHIR is the modern standard and it is where new work should go. It is also not what you will find when you connect to an existing trust.
HL7 v2 is still widely deployed, and a platform working with real NHS estates usually has to speak both. A supplier promising a FHIR-only integration has either not looked at the systems in question or is planning to build an adapter and not mention it.
The national services a UK healthtech platform usually has to talk to.
Beyond message formats, most platforms also join national services such as NHS Login, the Personal Demographics Service and GP Connect, each with an onboarding timeline outside your control. NHS England sets out that digital products must reduce duplication, improve patient access, support staff and connect care settings so information flows between them, which is the principle these services exist to serve.
The planning point is that interoperability between clinical systems is the part of the schedule you control least. Put the integration investigation into discovery rather than assuming connection dates.
What NHS Adoption Actually Requires
Building the platform is one project and selling it into the NHS is another, and the second usually takes longer.
DTAC is the assessment NHS organisations use to evaluate a product, and it draws on every artefact above. For a platform, expect to complete it more than once, because each buying organisation may run a separate assessment.
Framework agreements and the Buying Catalogue decide how an NHS organisation can purchase at all. A product without a suitable route needs a procurement process the buyer may have no appetite to run.
Fund compliance and procurement as part of the product. Found after launch, they turn into a sales cost nobody budgeted.
Where the Money is Going
The money is committed. Two of these figures come via trade press rather than a statistical release, so they are cited with their provenance.
DSIT reported the UK healthtech sector at 34 billion pounds annual turnover in 2022, employing more than 150,000 people.
Committed UK health technology investment, with the provenance of every figure.
Digital Health News reported that the DHSC and NHS England have pledged 7.4 billion pounds in technology, digital and data investment to 2030. The Register reported that the NHS 10 Year Health Plan committed up to 10 billion pounds to NHS technology and digital transformation by 2028 and 2029.
Treat the second and third as reported commitments, not spend. Pledged budgets in this sector are restated and rephased often, so the direction is the useful signal and the precise figure is not.
Building for Private Healthtech Against Building for the NHS
The same software can face very different requirements depending on who buys it.
Private healthtech | NHS | |
|---|---|---|
Procurement | Commercial sale | Framework, Buying Catalogue, DTAC |
Integration surface | Whatever the customer runs | National services, on their timeline |
Evidence expected | Commercial references | Clinical safety documentation |
Timeline to first customer | Months | Frequently a year or more |
Clinical safety | Depends on the use case | Mandatory where used in NHS care |
Private first is a legitimate strategy, provided you do not design yourself out of the NHS later. Retrofitting a clinical safety process is far harder than running a light version of it from the beginning.
Sector products carry their variants of this. Digital mental health and remote monitoring technology both add particular safety and data considerations to the general picture.
Arch builds NHS-facing health technology and holds Cyber Essentials Plus, with delivered work including Turning Point and Coeliac UK. You can see our work across the health sector for the detail.
What to Settle Before the First Line of Code
Four questions decide the shape of a healthtech platform, and all four are cheaper to answer now than to discover later.
Is it a medical device? This one changes the budget, the timeline and the documentation burden more than any other decision, and you can answer it from the intended use alone.
Who is the clinical safety officer? They must be a suitably qualified clinician, and they need to be involved while design decisions are still open, not brought in to sign a document.
Which systems must it integrate with, by name? Not "NHS systems", but the specific trusts, GP systems and national services. Each carries an onboarding timeline you do not control.
How many tenants in year one, and how different are they? The answer decides whether configuration lives in data or in code, and that is an architectural decision you make once.
Four questions to answer before design begins.
Teams often defer all four because none of them blocks the first sprint. Answered late, each one invalidates work already done, and the medical device question can invalidate the whole approach.
Frequently Asked Questions
What is a Healthtech Platform?
Software used by several organisations and several types of user, exchanging data with clinical systems of record, and carrying clinical safety obligations because care decisions are made on what it shows.
The clinical safety element is the real dividing line. Software that only administers, such as a booking tool with no clinical content, sits in a lighter regime than software a clinician reads before acting.
What is Healthtech, and Where Does a Platform Fit?
Healthtech is the broad use of technology to deliver, support or manage health and care, from a symptom checker to a hospital records system. A platform is one shape within it: the shared layer that several services, organisations and roles run on.
Most of the regulation follows the clinical use rather than the shape, so a small app and a large platform can face the same safety duties.
How is Building a Healthtech Platform Different From Ordinary App Development?
The engineering is similar and the surrounding obligations are not. You need a clinical safety officer, a hazard log and a safety case, a DPIA, DSPT completion, and an answer to whether the software is a medical device.
Those add time before launch rather than difficulty during the build, which is why schedules built on engineering estimates alone tend to slip.
What Are the NHS Interoperability Standards?
FHIR for new integrations, with HL7 v2 still in wide use across existing estates. Alongside those sit national services including NHS Login, the Personal Demographics Service and GP Connect, each with its onboarding and assurance process.
Plan for both message standards. A platform that speaks only FHIR will meet systems that do not.
Do We Need MHRA Registration?
It depends on intended use, and on a platform it can differ by module. A scheduling module may sit outside the regime while a risk score in the same product sits inside it.
Settle it per module, early. Our post on when software becomes a medical device works through the test itself.
How Long Before a Healthtech Platform Reaches First NHS Use?
The build is often the shorter half. Clinical safety documentation, DSPT, DTAC, integration onboarding and procurement commonly add months, and national service connections run to their schedules.
A year from start to first live NHS deployment is unremarkable. Anyone promising much faster is usually describing the build alone.
Can We Start Private and Move to the NHS Later?
Yes, if you keep the door open in the architecture. Run a proportionate clinical risk process from the start, keep the data model compatible with NHS identifiers, and avoid decisions that assume a single tenant.
The alternative is a retrofit that touches identity, audit and data structure at once. A healthcare app development company should raise this at design stage, before you try to sell into a trust.
About the Author
Hamish Kerry is the Marketing Manager at Arch, where he's spent the past six years shaping how digital products are positioned, launched, and understood. With over eight years in the tech industry, Hamish brings a deep understanding of accessible design and user-centred development, with a focus on delivering real impact to end users. His interests span AI, app and web development, and the potential of emerging technologies. When he's not strategising the next big campaign, he's keeping a close eye on how tech can drive meaningful change.
You can catch up with Hamish on LinkedIn
Sources
- NHS England Digital, Clinical risk management standards (DCB0129 and DCB0160), 2018. https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
- NHS England, Interoperability, 2026. https://www.england.nhs.uk/digitaltechnology/connecteddigitalsystems/interoperability/
- Department for Science, Innovation and Technology, Unlocking the potential of UK healthtech, September 2024. https://assets.publishing.service.gov.uk/media/66f691c7a31f45a9c765edc5/unlocking_the_potential_of_uk_healthtech.pdf
- Digital Health News, DHSC and NHSE internal plan pledges £7.4bn digital investment, 18 March 2026. https://www.digitalhealth.net/2026/03/dhsc-and-nhse-internal-plan-pledges-7-4bn-digital-investment/
- The Register, NHS tech spending review, 12 June 2025. https://www.theregister.com/2025/06/12/nhs_tech_spending_review/
- Arch, Health sector, 2026. https://wearearch.com/sectors/health