On 13 August 2026 NHS England published 21 networks and connectivity standards for every NHS organisation in England. Each organisation is asked to assess itself against them every year. Where a standard cannot yet be met, the organisation should keep a plan setting out the risks, the interim mitigations and a timeline. Each site should have a diverse backup connection, with failover in no more than 10 seconds, tested every quarter. Core network equipment should run on an uninterruptible power supply, and traffic should be segmented by user group and device type.

The standards address each site and its network as a whole. Where a central station is hosted off site, a hospital meeting the standards may still route remote cardiac alarms through the same router, firewall and perimeter as its electronic patient record (EPR) traffic, whichever circuit is in use. Duplicated routers or firewalls strengthen that shared infrastructure, but do not always give the alarm pathway a separate route.

The pathway may also share core switches and depend on the comms room’s power and cooling. A failure in these shared dependencies can interrupt both EPR access and alarm transmission. Staff generally notice an EPR outage; an individual alarm’s delivery can be harder to establish. Connection supervision indicates whether the link is available, while an acknowledgement or delivery record from the receiving platform provides evidence that a particular alarm arrived.

The briefing sets out five questions for assessing each clinical alarm or telemetry pathway: what it shares with the site’s clinical IT, which comms room infrastructure it depends on, whether its second path is independent, how delivery failures are detected, and who owns the pathway. A pathway here is the route that carries a medical device alarm, a telemetry feed, a nurse call or a lift alarm call to the receiving system or the people who respond. Each question identifies the NHS England standards relevant to assessing that part of the pathway.

“Count the dependencies a pathway shares with clinical IT, from the core switches to the clinical wide area network (WAN), not only the number of suppliers it uses.”

What's inside

The 16-page briefing includes:

  • how a shared upstream failure can affect clinical IT, medical technology, life-safety signalling and estates systems, with different consequences, owners and recovery arrangements for each
  • two recent NHS incidents showing how disruption can affect several services at once: the June 2024 ransomware attack on a pathology provider serving south-east London, and the failure of several chiller units at an acute hospital during the June 2026 heatwave
  • how NHS England’s 21 standards address site-wide connectivity, with a table showing what each group covers and which dependencies still need to be assessed for individual clinical alarm and telemetry pathways
  • five questions for each pathway, covering shared site infrastructure, comms room dependencies, independence across access networks and operator cores, evidence of alarm delivery, and ownership
  • how to turn the self-assessment into a practical plan, with six implementation steps, three priority pathway types, a pathway record and specification requirements, plus planning considerations for the Openreach analogue line (PSTN) migration date of 31 January 2027
  • where rSIM®, the CSL DualSIM® Router and CSL Outpost fit across device, ward and site deployments, including the configurations and dependencies relevant to each

Who should read this

  • chief information officers and chief clinical information officers
  • network and connectivity leads preparing the annual self-assessment
  • clinical safety officers
  • clinical engineering and medical device leads
  • estates teams responsible for lift alarms and critical estates monitoring
  • procurement teams

A separate route off site for alarm pathways, without replacing the ward network

Where the ward local area network (LAN) and Wi-Fi are suitable, they can remain in place. Standard 5.1 expects Wi-Fi at NHS sites to use shared physical infrastructure wherever practicable. For pathways that leave the site, such as remote cardiac alarms, infusion alerting and lift alarm calls, a separate upstream connection can provide resilience appropriate to the service.

CSL Group provides connectivity at the device, gateway or site level. In the configuration CSL specifies, rSIM and the CSL DualSIM Router implement CSL DualCore® architecture. CSL Outpost provides managed multi-bearer connectivity that complements this architecture. At a ward gateway, CSL Outpost bonds up to four mobile connections into one link. The connections can use independent operator cores to avoid reliance on a single core, with the configuration confirmed for each deployment. CSL recommends separate links for alarm pathways and site backup.

At device level, rSIM carries two paths on one SIM. At an outlying site, a CSL DualSIM Router configured for core independence uses two SIMs, both supplied by CSL. In both cases, the two paths use independent operator cores. In the configuration CSL specifies, each path also uses CSL’s private access point name (APN) routing, with an encrypted connection to the receiving platform.

Other services, such as managed print and staff Wi-Fi, can continue to share an upstream connection where that arrangement is appropriate and the shared dependencies have been assessed and accepted.

The table below shows the upstream connectivity options for each device or site, the relevant CSL product and the dependencies to assess.
Device or site Upstream path CSL product What it depends on
Medical device with a cellular module The device’s own module, with two multi-network profiles on one rSIM, each on an independent operator core rSIM The device manufacturer’s approval of the device and modem configuration, and mobile coverage where the device is used
Medical device on the ward LAN A gateway on the ward network with its own upstream connections CSL Outpost The ward LAN between the device and gateway remains a shared dependency and should be recorded. The device manufacturer must also support routing alarms through the gateway to the receiving platform
Small site where full fibre is unavailable or not cost-effective A link bonded across several mobile operators, with satellite where needed, as the primary connection CSL Outpost Confirmation that the mobile or satellite service meets standard 1.1 for the site’s intended use: performance comparable to full fibre, suitable resilience, reliability and latency, and capacity to scale with demand. New contracts should allow full fibre to be introduced as soon as it becomes viable and cost-effective, integrating it with CSL Outpost as part of the site’s managed, multi-path connectivity.
Outlying site with one broadband circuit A cellular second path with access to independent operator cores. Where both cellular paths use the same operator core, that core remains a shared dependency CSL DualSIM Router, configured for core independence The router’s configuration and confirmation that its two SIMs use independent operator cores

Recording each alarm pathway for the self-assessment

The briefing provides an eight-entry record for each clinical alarm or telemetry pathway, to be kept with the annual self-assessment:

  • The pathway: the device or system that generates the alarm or telemetry, its destination on site or off site, and the people responsible for monitoring or responding
  • Shared with clinical IT on the site: any site router, firewall or perimeter used by the pathway, and whether it uses the clinical WAN
  • Shared in the comms room: the core switches it passes through, the uninterruptible power supply (UPS) and its runtime, and the comms room’s cooling
  • The second path: the access network and operator core used by each path, the maximum acceptable failover time, and the date and result of the last core failover test. For pathways that remain on site, record the resilience of the local network, receivers and servers instead
  • How delivery failures are detected: whether individual alarm delivery is acknowledged or recorded, or whether monitoring covers only the connection; what the device and receiving system show when connectivity is lost; and who receives alerts about connection loss or failed alarm delivery
  • The owner: the person or team accountable for the pathway, alongside the network lead
  • The decision: whether an independent path is required or a shared dependency is accepted, with any interim mitigation and a timeline for planned changes
  • Contract and renewal: the contract covering the pathway, the team responsible for it, and the expiry date of the contract or relevant national agreement

For pathways requiring an independent path, the record can inform a specification that sets the maximum acceptable failover time and requires it to be demonstrated in both a core failover test and an end-to-end delivery test where the radio remains registered but alarms are not delivered. Each test should record whether switching occurred without intervention and whether a test alarm reached the receiving platform. The specification can also require an acknowledgement or delivery record for each alarm from the receiving platform and identify who receives the alert when delivery fails.

IT, estates and clinical engineering may procure connectivity separately, so contracts do not always capture the dependencies of individual pathways. Contract renewals and changes to national agreements between September 2026 and July 2027 provide an opportunity to make those requirements explicit. The Government Commercial Agency’s Mobile Voice and Data Services 2 (RM6391) launched in September 2026, and Mobile Voice and Data Services (RM6261) ends in December 2026; Network Services 4 (RM6377) is expected to replace Network Services 3 (RM6116) in 2027. A Trust procuring services during this period can specify which pathways require an independent path and how that independence must be demonstrated.

To discuss how CSL Group can support clinical alarm and telemetry pathways across your Trust’s estate, email sales@csl-group.com.

Related white papers

Published on: 2nd November, 2026
Sectors: Healthcare & Telecare, Public Sector
Applications: Healthcare Infrastructure