Primary Care Modules, not Monoliths
- Tom Cronin
- Jul 18
- 7 min read
Welcome to Hippo's third instalment of our 'Navigating Primary Care Tech' blog series! Be sure to check out our first 2 posts below: 1. AI in Healthcare - Fads & Fantasies
The current GPTech landscape is shaped by a small number of longstanding providers. These systems have been established for over two decades, gaining prominence through frameworks like GP Systems of Choice, and continue to hold a dominant position in managing core medical records. This has led to two major problems:
No Incentives for Innovation – Long-standing control and central funding frameworks have removed competitive pressure, minimising any need to internally improve/innovate.
Not Allowing Others to Innovate – If longstanding platers have such a tight grip on the market, there’s not much motivation for them to open the doors to new players. Letting others strengthen their dominant position. So instead, they keep their systems closed off, which makes it tough for new tools or ideas to integrate.
While the former remains the case, the latter is gradually being unpicked. Through pressure from NHS England, both Core Clinical Systems have, in recent years, built basic API interfaces. More recently, NHSE have enabled wider access to some of these interfaces through their IM1 programme, which allows new software vendors to integrate for free. This shift has been the key enabler of new GPTech innovation over the last 5-7 years.
To avoid similar situations from occurring in future and to create an environment where innovation thrives, we must address four key systemic factors:
1️⃣ Adopt a Modular System Architecture
Rather than relying on single, monolithic systems, a modular approach enables vendors to thrive, creates a more competitive specialised environment, fostering better technology and better patient outcomes.
Functions within Core Clinical Systems can be separated
Key functions within the Core Clinical Systems, like medical records, consultation views, and appointment management, could be separated, allowing vendors to build best-in-class solutions for each area. By integrating these different components together through modern APIs and interoperability standards, you would create the same output functionally, but with vastly better component parts.
A central backbone system (e.g. the medical record itself, or the consultation view) would be helpful as a single place to hold these different components together. This backbone could either be developed centrally or become its own functional part of the ecosystem (with development either led by incumbents or driven by new entrants).
This has worked before
Most modern software ecosystems - from cross-industry software in hiring and sales to whole verticals like e-commerce and fintech - have naturally moved to a modular ecosystem environment with multiple specialist players combining to form an outcome that is greater than the sum of its parts. This approach leads to:
Faster, better innovation through market competition
Flexibility for buyers (GPs) to procure components that fit their operating model/needs
Easier upgrades - swapping one component is simpler than replacing an entire system
Aiming to simply build more Monolithic Systems is a mistake
Pushing for new all-in-one platforms is unrealistic and undesirable:
The investment and risk involved in building these systems is significant - most entrants will go bust in pursuit of this white whale, as there is minimal income until you have a full system. To do this may require significant NHS funding with no guaranteed outcomes.
Creates more huge, slow-moving companies with high levels of friction to change and low levels of innovation (as we have now).
Loses the opportunity to create a vibrant ecosystem of high-quality, specialist providers producing excellent competitive tech, as hard to compete against monoliths with control.
🎯 Adopting a modular architecture - separating core functions and linking them through modern APIs and backbone platforms - enables innovation, competition, and better patient outcomes, avoiding the pitfalls of inflexible monolithic systems.
2️⃣ Build backbone software centrally, not point solutions
The NHS has demonstrated a significant appetite for developing software centrally (e.g. NHS App, Federated Data Platform, GP Registrations). However, it must carefully choose which technologies to build centrally and which to leave to private suppliers to create an optimal ecosystem in terms of patient outcomes, provider effectiveness, and taxpayer value.
Backbone technology vs. point solutions
Our view is that the NHS can and should build solutions, but these should be focused primarily on ‘backbone’ technologies rather than ‘point solutions’:
Backbone technologies are foundational systems or infrastructure that support multiple functions across the healthcare system. Examples include a national electronic patient record or the NHS App for patient messaging. These act as platforms enabling external innovation, rather than solving every individual problem directly.
Point solutions address specific healthcare challenges or functionalities, such as GP appointment booking or diabetes monitoring tools. These require continual innovation, rapid adaptability, and deep specialisation aligned with user needs.
Why should central design avoid point solutions?
History shows that nationally developed, centralised software struggles to keep pace with user needs. For example, NHS Digital’s efforts to build bespoke patient-facing tools have often lagged behind private alternatives. While the NHS App succeeded as a backbone platform, earlier attempts at point solutions (e.g., Choose and Book, initial patient record systems) faced challenges such as limited usability, poor user engagement, and slow iteration. Similar patterns appear across other sectors (e.g., taxis vs. Uber, NASA vs. SpaceX).
The NHS is unlikely to match the pace, adaptability, and specialisation of private sector innovators in point solutions. Successful digital ecosystems (e.g. smartphones, banking apps) thrive when core infrastructure is stable and open, allowing multiple providers to build and compete on specific use cases.
Worse still, if the NHS attempts to build its own point solutions, it may be able to force adoption but risks pushing out private providers and stifling innovation. Once the government becomes both the primary provider and commissioner, few businesses will invest in that space. The long-term impact? Less innovation, fewer new entrants, and ultimately fewer high-quality solutions available to the NHS.
Examples of beneficial central backbone technologies
By developing foundational digital infrastructure, NHS England can enable innovation rather than replace it. For example:
A unified patient record system would enable a modular ecosystem, breaking the current duopoly that restricts meaningful competition. Nationalising this system would provide equitable access for innovators to develop effective point solutions. Unified records would also serve to reduce frictions and improve NHS-wide communication, removing the manual handling of patient data, facilitating accurate/complete patient histories, and enhancing the interface between hospitals and GP practices.
Leveraging the NHS App as a backbone platform is already creating a streamlined patient experience and providing vendors with a clear, unified interaction channel.
In the absence of national backbone technologies, local ICBs are attempting to step in. For example, multiple ICBs are individually attempting to build and deploy Shared Care Records, often employing expensive consultants or technology companies. These are huge undertakings, and the fragmented efforts are costly, slow, and frequently produce duplicative or suboptimal results.
🎯 By prioritising backbone technologies over point solutions, the NHS can create an environment that encourages innovation without taking on the unrealistic burden of becoming an innovator itself.
3️⃣ Avoid prescriptive frameworks for Primary Care
While centrally funded frameworks seem like a helpful way to drive change nationally, they are inherently flawed for two key reasons:
Conventional frameworks set effective limits on tech functionality. Framework specifications are usually highly prescriptive and are typically defined by existing market standards and functionality. This causes suppliers to conform and align around the standard and its rules rather than innovating on solutions that are better for patients.
Conventional frameworks eliminate incentives for innovation. Once vendors are established on a framework, competition and pricing are effectively frozen in place for multiple years. This reduces vendor motivation to enhance their offerings or compete on price.
Frameworks are often intended as a way of simplifying purchasing decisions for practices or commissioners, but the natural adoption process occurs organically when truly beneficial innovations emerge.
A more effective alternative might be open, ringfenced funding pots, allowing practices to draw down and invest funds according to a set of high-level, flexible guidelines (e.g., spend this money on technology that can improve your practice). Implementing a 'use it or lose it' structure would encourage rapid and meaningful investment. This approach mirrors the successful ARRS scheme, which has very rapidly driven positive change. Unlike frameworks, the open market is ‘fast and ruthless’ at deciding on the most impactful solutions.
🎯 Prescriptive frameworks stifle innovation by limiting functionality and removing market incentives. Open, ringfenced funding pots encourage rapid adoption and genuine competition.
4️⃣ Interoperability must be mandated and enhanced
Effective interoperability within the existing system is critical, especially if developing national backbone systems is not currently feasible or would take significant time due to the scale and complexity.
The existing IM1 Partner Programme, although a step forward, suffers from substantial limitations:
Slow and cumbersome onboarding processes - NHSE integration procedures are overly bureaucratic and time-consuming.
Lack of incentives for cooperation - Incumbents face minimal consequences for delaying integration processes, slowing down progress significantly.
Limited technical platforms - Core suppliers have little incentive to offer comprehensive integration options, limiting the potential for new tech or meaningful advancement.
Exclusion of updated integration tools - IM1 supports older products like ‘bulk extract’, neglecting newer solutions such as ‘EMIS X Analytics’.
England-specific limitations - The IM1 programme does not extend beyond England, restricting broader market penetration for new tech in other devolved nations.
NHSE must leverage its influential position to mandate and enforce higher interoperability standards. Doing so will enable faster and deeper integrations, encouraging market innovation while bridging the gap until a robust national system can be established.
🎯 Current interoperability (IM1) programmes are good but have limits. NHSE should mandate and enforce robust interoperability standards to accelerate innovation and integration.
Comments