N3 was the backbone of NHS connectivity for over a decade before being replaced by the HSCN in 2017. Here is the history, how the HSCN works today, and what the shift to cloud means for health organisations connecting to it.
The Health and Social Care Network (HSCN) is the private network that connects NHS organisations, social care providers, and the technology companies that serve them. Understanding how it came to exist, and why it replaced N3, helps explain both how it works and what organisations connecting to it today should expect.
N3 was the NHS’s dedicated broadband network, operated by BT from 2004. It replaced NHS Net, which had been running since around 1995, and was designed to give NHS staff high-speed connectivity across the country, linking hospitals, GP practices, pharmacies, and care settings over a single private network.
At its peak, N3 connected over a million NHS users and carried patient records, clinical system traffic, and NHS application data that was far too sensitive to route over the public internet. For its time, it was a significant infrastructure achievement.
The problems that emerged over the following decade were structural. As a single-supplier contract with BT, N3 had no competitive dynamic to drive performance or cost down. The network was not designed for cloud-era working. It struggled to keep pace with the growing volume and variety of data flowing across the NHS, and its architecture was poorly suited to the kind of flexible, multi-site working that modern healthcare delivery increasingly required. Security and performance concerns mounted. Cost remained high.
The decision to replace N3 was made well before the transition actually happened. The phased migration from N3 to HSCN ran from 2015 through to late 2020.
The HSCN launched in 2015 and was designed to address the specific limitations of N3. Rather than a single-supplier arrangement, the HSCN operates as a multi-supplier marketplace. NHS England sets the standards and governs the Connection Agreement that organisations must sign before connecting. Multiple accredited suppliers, known as Consumer Network Service Providers (CN-SPs), compete to deliver connectivity to organisations that need it.
There are currently around 20 CN-SPs in the UK market. Cloud Gateway is one of them.
The HSCN carries the data and applications that health and care organisations depend on: NHS Mail, national clinical systems including Spine, EMIS and SystmOne, and the growing range of digital health services and cloud-hosted applications that are now part of everyday clinical and operational life. For most NHS organisations, a connection to the HSCN is a prerequisite for their services to function.
The multi-supplier model introduced genuine competition on price and service quality, and the architecture was designed with cloud connectivity in mind from the outset. Healthtech companies hosting products in AWS, Azure, or Google Cloud can now deliver those products over HSCN to NHS customers through a compliant cloud-to-network connection, something that was not straightforward under N3.
Organisations connecting to the HSCN go through a four-step process. They choose an accredited CN-SP, select the connectivity services they need, sign the HSCN Connection Agreement with NHS England – which only needs to be signed once regardless of the number of sites being connected – and then work with their CN-SP to provision the connection.
The Connection Agreement replaced the legacy N3 IGSoC process. It is simpler in structure but still carries compliance obligations that organisations need to understand and evidence.
For organisations connecting multiple sites, or for healthtech companies connecting cloud environments to HSCN, the architecture of the connection matters as much as the connection itself. Resilience requirements differ between a single GP practice and a regional acute trust. Cloud connectivity patterns differ between an ISV hosting a clinical application and an ICB consolidating data flows across a system.
NHS England’s Internet First policy states that new digital health services should be accessible over the public internet wherever possible, rather than requiring HSCN connectivity. The intent is to reduce the cost and complexity of access for smaller providers and to support the broader shift toward cloud-hosted services.
This has led some to question the long-term future of the HSCN. The more accurate picture is that HSCN and internet-based access are likely to coexist for the foreseeable future. Some services have moved to internet delivery; others carry data sensitivity or latency requirements that make private network connectivity the appropriate choice. Most organisations running significant clinical infrastructure will maintain an HSCN connection for the services that need it, while also making cloud-hosted services accessible over the internet for those that do not.
The practical question for most health organisations is not whether to connect to the HSCN, but how to structure a connectivity estate that serves both requirements under a coherent operating model.
The connection itself is the foundation. What sits over it determines whether it is a managed, evidenced service or simply a pipe.
Organisations evaluating CN-SPs should look for governance and compliance support built into the service: Connection Agreement navigation, DSPT-aligned evidence, ITHC readiness, and change records generated as the service runs. Resilience options that match the criticality of the services being carried. Visibility of performance and SLA delivery through a portal or API integration. And the ability to extend the connection to cloud, remote access, and managed security under one operating model as requirements evolve.
Cloud Gateway delivers HSCN connectivity as part of a wider managed platform, with the governance, resilience and audit evidence built into the service. For more on how we work with health organisations, see our Healthcare sector page, or explore Business Connect: HSCN for the specifics of how we deliver the connection.
