Building for the NHS: What HealthTech Startups Need Before They Apply

The NHS is the world's largest single-payer healthcare system and one of the most significant buyers of digital health technology in the world. For HealthTech founders, that represents a clear and substantial opportunity.

But NHS procurement is not like selling to a private hospital group or a clinic chain. It operates within a structured compliance and assurance framework that exists for a specific reason: the NHS serves tens of millions of patients, and every piece of technology connected to that system is held to a standard that reflects that responsibility.

According to NHS England's Digital Technology Assessment Centre, over 60% of digital health products that enter NHS procurement processes do not complete them successfully on their first attempt. The most commonly cited reasons are not that the product does not work. They are that the product does not meet the technical, clinical safety, or data compliance requirements that NHS procurement teams check before anything else.

This guide covers exactly what those requirements are.

Understanding the NHS Procurement Landscape in 2026

Before getting into specific requirements, it helps to understand how NHS procurement actually works. There is no single "NHS door" you knock on. The NHS is made up of NHS England (the national body), 42 Integrated Care Boards (ICBs), hundreds of NHS trusts, and thousands of GP practices and primary care networks, each with varying degrees of procurement autonomy.

The most common pathways for HealthTech startups are:

Most early-stage startups begin with a local trust or ICB pilot and work toward broader NHS England frameworks. For any of these pathways, DTAC is the common prerequisite. Understanding DTAC is where every NHS-focused founder should start.

What Is DTAC and Why It Is the Starting Point

DTAC stands for Digital Technology Assessment Criteria. It is the NHS's standard assessment framework for any digital health product seeking to be adopted across NHS organisations. It was introduced by NHS England in 2021 and has become the accepted baseline for NHS procurement readiness.

DTAC is not a certification you receive. It is an evidence-based assessment across five domains. NHS procurement teams and individual trusts will ask you to complete a DTAC self-assessment and provide supporting evidence before they move forward with any formal engagement.

A few things are worth understanding clearly about DTAC:

• It is evidence-based. Saying "we are DTAC compliant" means nothing. You need documents that prove it.
• It takes time. With all documentation in good order, expect 8 to 12 weeks for the assessment process. With gaps in documentation, it pauses until you provide what is missing.
• It is not a one-time exercise. NHS organisations will ask you to maintain and update your DTAC evidence. It reflects your ongoing compliance posture, not a point-in-time snapshot.

Clinical Safety Requirement Most Startups Miss Entirely

Of all the DTAC domains, clinical safety documentation is the one that catches the most founders off guard. Many technically strong products fail NHS assessment at this stage not because their product is unsafe, but because they have no clinical safety documentation at all.

The NHS operates under two clinical safety standards for health IT:

DCB0129: This applies to the manufacturer of a health IT system. It requires you to have a clinical risk management process, a Clinical Safety Case, a Hazard Log, and a named Clinical Safety Officer (CSO) for your product.

DCB0160: This applies to the organisation deploying or using the health IT system, typically the NHS trust. Your product must support the trust in meeting its own DCB0160 obligations, which means your documentation needs to be complete enough for the deploying organisation to conduct their own clinical risk assessment.

What a Clinical Safety Officer (CSO) actually is: A CSO is an individual with relevant clinical knowledge and training in clinical risk management for health IT. They do not need to be a full-time employee but must be formally appointed. For non-clinical founding teams, this typically means engaging a qualified independent CSO consultant. This is not optional under DTAC and is consistently one of the requirements that non-clinical founders are most surprised by.

What a Clinical Safety Case must include:

• A description of the system and its intended clinical use
• A list of identified hazards and their potential clinical impact
• Evidence that each hazard has been assessed and mitigated
• A statement of clinical safety signed off by the CSO

If your product does not have this documentation, DTAC assessment cannot be completed. Full stop.

Data Protection: UK GDPR Is Not the Same as HIPAA

If you have built your product for the US market and achieved HIPAA compliance, you have a useful foundation. But UK GDPR is a separate legal framework with meaningful differences, and NHS procurement teams will ask specifically about UK GDPR compliance.

Key differences that matter for your product architecture and documentation:

Beyond legal compliance, NHS procurement will also check your Data Security and Protection (DSP) Toolkit alignment. NHS organisations complete the DSP Toolkit annually, and your product must support their ability to do so. That means your data handling, access controls, and audit logging must be documentable in the format the DSP Toolkit requires.

If your product stores or processes NHS patient data in a cloud environment, that environment must meet NHS Cloud Security Principles. AWS UK (London region), Azure UK South, and Google Cloud UK regions all support NHS-eligible workloads. Using a US cloud region for UK NHS patient data creates a compliance failure that NHS information governance teams will identify during due diligence.

Technical Assurance: What NHS Security Reviews Actually Check

NHS procurement includes a technical assurance review that covers your architecture, security controls, and interoperability capability. Here is what reviewers specifically look for:

Security Controls

• Penetration testing by a CREST-approved provider within the last 12 months
• Cyber Essentials or Cyber Essentials Plus certification
• Multi-factor authentication (MFA) enforced for all access to systems containing patient data
• Audit logging covering all access to patient data, with tamper protection
• Patch management process documented and active

Architecture

• Data encrypted at rest (AES-256) and in transit (TLS 1.2 or above)
• Role-based access control (RBAC) implemented
• Patient data separated from operational metadata at the database level
• No patient data in application logs, error tracking tools, or analytics platforms

Interoperability

The NHS has mandated FHIR R4 as its health data exchange standard. NHS England's Interoperability Strategy requires all new digital health tools procured through NHS frameworks from 2024 onward to demonstrate FHIR R4 capability. Products that cannot show this are increasingly excluded from procurement shortlists before they reach the assessment stage.

If your product requires connectivity to NHS systems (GP systems, secondary care EHRs, or national platforms like NHS App or NHS login), your FHIR R4 implementation will be reviewed against NHS-specific profiles, not just base FHIR R4 spec.

Read more: UK Digital Health 2026: DTAC, MHRA, NHS Digital — What Founders Get Wrong

Does Your Product Qualify as a Medical Device?

This is a question many founders avoid asking until a hospital trust's legal team forces the issue. If your product qualifies as a medical device under UK law, you need MHRA registration before NHS procurement can proceed. Without it, you cannot legally place your product on the UK market for its intended clinical use.

The MHRA defines software as a medical device when it is intended to be used for the purpose of diagnosis, prevention, monitoring, treatment, or alleviation of disease. The key word is "intended." Your intended use claims, including how you describe the product in marketing materials, your app store listing, and any clinical documentation, determine whether the MHRA definition applies.

Product type guidance:

If your product is a medical device, you need UKCA marking (the UK equivalent of CE marking post-Brexit). CE marking no longer grants UK market access for Great Britain. This is a requirement that a significant number of EU-registered products entering the UK market are unaware of until procurement review surfaces it.

Most Common Mistakes Founders Make Before Applying

Mistake 1: Applying to NHS procurement before DTAC evidence is complete

DTAC evidence takes months to prepare properly. Founders who begin NHS conversations before documentation is ready end up in extended procurement cycles that damage their credibility with NHS partners.

Mistake 2: Assuming HIPAA compliance covers UK requirements

HIPAA and UK GDPR are different frameworks. A HIPAA-compliant product built for the US market needs meaningful additional work to meet UK GDPR, DSP Toolkit, and NHS Cloud Security Principle requirements.

Mistake 3: No Clinical Safety Officer in place

This is the most frequently overlooked DTAC requirement for non-clinical founding teams. Without a formally appointed CSO, DTAC assessment cannot be completed. This is not a documentation gap you can paper over.

Mistake 4: No FHIR R4 capability

NHS trusts asking about your integration capability want FHIR R4. HL7 v2 feeds or proprietary APIs are not equivalent for NHS procurement purposes in 2026. If your product cannot demonstrate FHIR R4, you will be excluded from an increasing number of NHS procurement conversations.

Mistake 5: Claiming MHRA compliance without formal registration

Some founders describe their product as "MHRA compliant" based on a self-assessment or a legal opinion. If your product is a medical device, formal registration with the MHRA and UKCA marking through an Approved Body is required. Self-declaration is only available for Class I devices. AI-assisted clinical tools are almost always Class IIa or above.

Read more: Why Most HealthTech MVPs Fail Before Launch and How to Build One That Does Not

Pre-Application Readiness Checklist

Before approaching any NHS organisation, ICB, or NHS England framework, work through these:

Conclusion

The NHS is a serious buyer of digital health technology and a genuine route to scale for UK HealthTech founders. But it is a structured buyer that operates within a compliance framework it takes seriously, because it serves patients at a scale that demands it.

The founders who succeed with NHS adoption are the ones who treated the preparation stage as a real workstream, not a box-checking exercise done quickly before a sales conversation. DTAC evidence, clinical safety documentation, UK GDPR compliance, and interoperability capability each take real time to build properly.

Build to the standard from the start, and NHS entry becomes a straightforward conversation rather than a prolonged obstacle course.