In our first blog, we introduced the recently published paper and policy briefing on the barriers stopping risk prediction tools from reaching primary care, and the four structural conditions needed to overcome them. In this blog, we look more closely at the second condition, a shared deployment infrastructure.
Why don’t current deployment infrastructures work for scaling risk prediction tools?
A risk prediction tool can be well designed and well validated and still be unusable in primary care. At the moment, there is no shared technical infrastructure such as a unified electronic health / patient record system through which a validated tool can reach primary care at scale.
Individual trusts buy their own patient record systems from a list of approximately 40 approved third-party suppliers, some of which are bespoke systems for individual trusts. Hence, to implement a risk prediction tool into practice in primary care, every deployment pathway needs to be built from scratch, tailored to the specific tool and a specific electronic health record system that a trust uses. This is slow, expensive and does not scale beyond a single pilot. A tool that works in one trust’s system has to be rebuilt, tested and re-approved before it can run in another trust’s system, even if the underlying model does not change at all.
Part of the problem is the state of the data itself. A risk prediction tool depends on structured, standardised information to run reliably. If most of the data it needs is not recorded that way, the tool cannot function consistently across different practices, even if the underlying model is sound. Only around 30% of primary care electronic patient/ health record system data is recorded in a structured form
How can risk prediction tools be deployed at scale?
The paper sets out a range of ways risk prediction tools could be deployed at scale, running from one extreme to the other. At one end, electronic patient / health record system vendors build each risk prediction algorithm directly into their own software, one tool at a time. There was clear concern about approaches that increase reliance on electronic patient/ health record system vendors this way, since it tends to concentrate control over which tools actually reach GPs and slows things down.
At the other end sits an option seen by some as the ideal. A single, centrally hosted library of tools, run by the NHS. This raised real questions of its own, though, about who would own it, how it would be governed, and whether the NHS could deliver something at that scale.
The option with the most support sat between these two poles. A distributed architecture, where a library of tools is built collaboratively by developers and clinicians to a common standard, and each tool links to electronic patient/ health record system software through a common interface. It aims for the same outcome as a centrally hosted library, without needing one central authority to build and run it.
Why common technical infrastructure matters
This links to one of the fifteen recommendations in the paper: that the development of common standards should be prioritised, alongside the interfaces needed to deploy tools into practice. These are easy to treat as a technical footnote, but they underpin almost everything else.
Common standards mean that a tool built by one developer, using agreed data formats and terminologies, does not need to be rebuilt from scratch to work with a different Electronic patient/ health record system. Interfaces for deployment mean that a validated tool has an actual route into a GP’s software, rather than requiring a bespoke integration built by hand each time.
Without both of these in place, every developer keeps building one-off solutions, electronic patient/ health record system vendors keep controlling access to primary care on their own terms, and funders keep paying for pilots that cannot be reused or scaled elsewhere. Getting them right is what turns a set of individually validated tools into something that can actually reach patients.
The pieces to build this infrastructural foundation are already in place
No single organisation can build this foundation alone. NHS England and DHSC are best placed to lead, and already hold some of the tools needed to do so. The Data (Use and Access) Act 2025 gives the Secretary of State powers to set binding information standards for NHS IT suppliers, though these powers have not yet been applied to risk prediction tools specifically.
Electronic patient/ health record system vendors have an active role too, and arguably more freedom to move quickly than any legislative process allows, since shifting toward shared interfaces is a choice they can make without waiting for a mandate. HDR UK’s existing work on data standards, including support for the Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM), is already a practical building block for this kind of shared infrastructure.
What is striking about this condition is how tractable it is in principle. Unlike other conditions identified during the workshop, which need ministerial and Treasury-level decisions, this one does not require a new political settlement. It requires the organisations that already hold the relevant powers to use them, and it requires ring-fenced capital investment in primary care IT so that practices can actually run these tools once they exist.
In our next blog, we will explore what a fit-for-purpose regulatory pathway would need to look like, and why evidence standards for real-world evaluation are central to that.
