How Digital Health Startups Can Integrate with the NHS Faster: A Practical Integration Guide

You closed the pilot. A Trust signed, a clinical lead is championing you internally, and the product does exactly what you promised in the demo. Then someone forwards you a DSPT requirement, asks which integration route you're using for PDS, and wants to know who your Clinical Safety Officer is. The momentum you spent eighteen months building starts leaking out of the deal one email at a time.

This is the part nobody warns founders about. The hard part of selling to the NHS isn't the sale. It's everything between the signature and the first live patient record flowing through your system. Most digital health startups underestimate it by a factor of three, and the cost isn't just time. It's runway, it's the champion losing political capital while they wait, and it's the second Trust asking your first Trust how the rollout went before you've finished the first one.

This NHS integration guide is for the founder, CTO, or digital lead who has cleared the commercial hurdle and now has to make the technology actually connect. Not a glossary of acronyms, you already know what Spine and ESR are. A map of where the time goes, and how to get it back.

The pilot you won is not the deal you think it is

A signed pilot feels like the finish line. Operationally, it's the moment the real work starts, and the gap between those two framings is where most timelines slip.

Here's the pattern. The commercial team and the clinical champion agree to proceed. Everyone assumes integration is a technical detail to be handled later. Later arrives, and it turns out the Trust's Information Governance lead has not been in the room, the DSPT submission is mid-renewal, the integration engine team has a six week backlog, and nobody has produced a DCB 0129 clinical safety case because nobody decided whose job that was.

None of these are product problems. They're sequencing problems. The startups that integrate fast aren't the ones with better engineers. They're the ones who started the compliance and governance work in parallel with the sales process, so that when the pilot signs, the integration is already half-built rather than half-imagined.

What NHS integration actually involves

Strip away the jargon and NHS integration is three separate problems that founders tend to collapse into one.

The first is identity and demographics. If your product touches patients, you almost certainly need PDS for verified demographics and NHS number matching. This is rarely optional and rarely as simple as a single API call, because access is gated behind assurance.

The second is clinical and operational data exchange. This is the HL7v2 and FHIR R4 work: receiving ADT feeds, reading or writing to the EPR, exchanging messages over MESH, or connecting to e-RS or EPS depending on what you do. The shape of this depends entirely on your use case, and it's where the most engineering sits.

The third is assurance and governance. DSPT, DCB 0129 and 0160 clinical safety, the connection agreements, and the IG sign off. This is not engineering work, which is exactly why engineering led startups leave it too late. It runs on committee cadences, not sprints, and you cannot compress a monthly IG meeting into a weekend.

The mistake is treating these as sequential. They're parallel tracks with different owners and different clocks, and the founders who understand that win back months.

Where startups lose the most time

In practice, the delays cluster in a small number of predictable places.

1. DSPT, started too late. The Data Security and Protection Toolkit is a precondition for most data flows, and a first submission takes real effort to evidence. Startups routinely begin it after the pilot signs, adding weeks to a critical path that was avoidable. It can be done before you have a single customer.2. Clinical safety treated as paperwork. DCB 0129 requires a named Clinical Safety Officer and a hazard log that genuinely reflects your product. Trusts increasingly ask for the safety case early, and a thin or templated one gets sent back. Building it properly the first time is faster than building it twice.3. PDS access assurance. Connecting to PDS isn't a developer self serve flow you finish in an afternoon. There's an assurance process, and the queue and evidence requirements catch teams who assumed a sandbox key was the whole story.4. The integration engine queue at the Trust. Most Trusts route external connections through their own integration engine, and that team is shared across every project in the organisation. Your urgent go live is one item on a long backlog. The fix is to make your side genuinely ready so you're never the reason the slot slips.5. One way builds with no monitoring. Startups frequently build a connection that works on the demo day and then breaks quietly when a feed format shifts or a partial failure goes unnoticed. The rework, and the credibility hit with the Trust, costs more than building it observable the first time.

Each of these is recoverable. Together, untreated, they're the difference between a six month integration and an eighteen month one.

The compliance work you can start before you have a customer

This is the single highest leverage move available to a digital health startup, and almost nobody does it early enough.

You do not need a signed Trust to start your DSPT submission. You do not need a customer to appoint a Clinical Safety Officer, stand up a hazard log, and draft your DCB 0129 clinical safety case. You can begin the PDS assurance conversation and understand the evidence you'll need to produce. You can document your data flows and your information governance position so that when an IG lead asks, you answer in a day instead of a fortnight.

Doing this early changes the conversation with a prospective Trust entirely. Instead of "we'll need a few months to get compliant," you arrive with a current DSPT, a real safety case, and a clear integration plan. The champion you've been working with stops having to defend a vague timeline to their own governance committee. You become the easy yes.

The work is unglamorous and it competes with feature development for attention. Do it anyway. It is the cheapest time you will ever buy back.

Choosing how you connect: direct, via a TIE, or via an integration platform

There are broadly three ways to connect, and the right answer depends on how many Trusts you intend to serve.

Direct integration, where you build and maintain every connection yourself, gives you full control and makes sense if you're serving one or two Trusts with a narrow data need. The hidden cost arrives at Trust number three, when you discover every Trust's environment is configured slightly differently and you're now maintaining a growing pile of bespoke connections, each one a thing that can break at 2am.

The Trust's own integration engine, the traditional interface engine route, works because it's the Trust's established path and the integration team knows it. The constraint is that you're dependent on their backlog and their priorities for every change, and you inherit whatever limitations their engine has. It's their clock, not yours.

A healthcare integration platform sits between your product and the NHS systems, normalising the connection so you build once against a consistent model rather than once per Trust. This is the route that scales, because the cost of adding the next Trust drops sharply, and monitoring, reconciliation, and audit trails come as part of the pattern rather than as things you bolt on later. It's the right answer when integration is core to your business rather than a one off.

The decision isn't really technical. It's about how many times you intend to do this. If the answer is "many," building a bespoke connection per Trust is a decision you'll regret by the third one.

A realistic sequence from signed pilot to production

A workable sequence, assuming you started the compliance track early, looks like this.

1. Before any pilot signs: DSPT submission underway, Clinical Safety Officer appointed, draft DCB 0129 safety case and hazard log in place, data flows documented.2. At signature: confirm the integration route with the Trust's IT and integration team, get IG into the room in week one rather than week ten, and agree what data flows in which direction.3. Build and test against a normalised model so that Trust specific configuration is a parameter, not a rebuild. Validate transforms, handle partial failures explicitly, and instrument everything.4. Run reconciliation before go live, comparing what you send against what the Trust system received, so the first discrepancy surfaces in a test, not in a clinician's workflow.5. Go live with monitoring in place, with field level logging that lets you answer "why is this record different now?" in minutes. This is also what makes your DSPT and IG conversations short rather than painful.

The Trusts that move fast aren't skipping steps. They're running the governance steps in parallel with the build, so the critical path is the longest single track rather than the sum of all of them.

How WeHub shortens the path

WeHub is an NHS native integration platform built for exactly this problem: getting a digital health product from signed pilot to live connection without the eighteen month tail.

The core idea is build once, connect many. Instead of writing a bespoke integration per Trust, you build against a normalised model, and WeHub handles the connection to Spine, PDS, ESR, e-RS, EPS, and the HL7v2 and FHIR R4 exchange underneath. Adding the next Trust becomes configuration, not a fresh engineering project. Monitoring, field level audit trails, and reconciliation are part of the workflow design rather than things you remember to add after the first incident, which is also what keeps your DSPT and IG conversations short.

It won't write your clinical safety case for you, and it won't sit in your IG committee. But it removes the part of the timeline that is pure integration engineering, the part where most startups spend the months they can least afford, and it gives the Trust's own integration team something observable and well behaved to connect to.

If you're mapping the path from pilot to production right now, that's the conversation worth having: talk to the WeHub integration team.

The bottom line

Most digital health startups don't lose NHS deals on product quality. They lose them on an integration timeline that outlasts the patience of the champion and the runway of the company.

The fix is sequencing, not heroics. Start the compliance track, DSPT, clinical safety, PDS assurance, before you have a customer, so that integration is a parallel build rather than a serial one. Choose a connection route that matches how many Trusts you actually intend to serve. And build the connection observable from day one, so the first problem shows up in a test instead of a payslip or a patient record.

If you do one thing this week, start your DSPT submission. It's the cheapest month you'll ever buy back, and it's the difference between being the easy yes and the deal that quietly stalls.