The headline that changed nothing
Last week, How To Find Live Hospital Waiting Times Using NHS Quicker Dazio (bDmwyWM1ps) topped the health-tech feeds. Patients can now see real-time wait times on their phones. Yet the screens in the waiting areas, the ones that actually display those times, still run on servers inside the hospital. The same goes for the emergency alerts that override them: a cardiac arrest in Resus, a fire alarm in Ward 12, a major incident declared. These systems do not rely on cloud dashboards or third-party APIs. They sit on NHS estates’ own networks. There are reasons for this, and they are not about technology being outdated.
Waiting rooms: what patients see, what staff control
A typical NHS waiting area has two jobs. The first is to keep patients informed: estimated waits, clinic delays, where to go for blood tests. The second is to stay out of the way when something urgent happens. A screen that shows a 45-minute wait one moment and a red CODE BLUE alert the next is doing both. The switch must be instant, and it must work even if the internet drops.
Most digital signage in healthcare runs on Android devices, tablets, TVs, or repurposed phones. These are not dedicated hardware; they are the same devices used for patient check-ins or staff messaging. The difference is in how they are managed. A system that polls for updates every 30 seconds, caches content locally, and can be overridden by a single command from the hospital’s own server meets the basic requirements. It also meets the NHS’s information governance rules, which are stricter than most.
Information governance: why data stays inside the building
NHS Digital’s Data Security and Protection Toolkit (DSPT) requires that patient data, or any data that could identify a patient, does not leave the organisation’s network unless there is a specific legal basis. Waiting times are not patient data in themselves, but they are derived from patient flow systems. If a screen displays a live feed from an electronic patient record (EPR), even if it only shows a number, that feed must stay on the trust’s own infrastructure. The same applies to clinical alerts. A cardiac arrest alert may not name the patient, but it names the location and the nature of the emergency. That is enough to trigger the same protections.
This is not a technical limitation. It is a legal one. A cloud-based signage system that pulls data from an EHR would need a Data Processing Agreement (DPA) with the trust, a Data Protection Impact Assessment (DPIA), and a clear audit trail. Most trusts decide it is simpler to keep the whole system on-site. The server sits in the hospital’s data centre, the screens poll it, and nothing leaves the building unless the trust chooses to put the server in a co-location facility.
Clinical alerts: the override that must always work
A fire alarm is a legal requirement. A clinical alert is a clinical requirement. Both must interrupt whatever is on the screen, and both must be acknowledged. The difference is that a fire alarm is triggered by a physical sensor. A clinical alert is triggered by a person: a nurse in Resus, a consultant in Theatre, a bed manager in the control room. That person needs a way to send the alert that does not depend on the internet, the phone network, or any third-party service.
The mechanism is simple. The hospital’s own server sends a command to every screen on the network. The screens acknowledge it and switch to the alert. If the network is down, the screens continue showing the last cached content, but the alert will appear as soon as the network is back. This is not fail-safe, nothing is, but it is fail-secure. The screens do not go blank, and the alert does not get lost.
What happens when the network fails
In a hospital, the network fails often. A switch overheats, a fibre gets cut, a contractor unplugs the wrong cable. The screens must keep working. This is why content is cached on the device. A screen that has downloaded a waiting-time template, a clinic map, and a set of emergency procedures can show them for days without contacting the server. The only thing it cannot do is update the waiting times or show a new alert. When the network comes back, the screen polls the server, gets the latest content, and carries on.
This is not the same as offline mode in a cloud system. In a cloud system, offline mode is a fallback. In a self-hosted system, offline mode is the default. The server pushes nothing; the screens pull when they can. This is why the system runs on ordinary shared hosting. There is no need for WebSockets, persistent workers, or real-time databases. The screens check in every 30 seconds, and if the server is down, they try again in 30 seconds.
The trade-offs of self-hosted signage
| Advantage | Disadvantage |
|---|---|
| Data stays on-site | Server is the trust’s responsibility |
| No third-party dependencies | Updates must be managed by the trust |
| Works through network outages | Screens must be provisioned individually |
| No per-screen licensing | No centralised support from the vendor |
| No data leaves the building | No automatic failover to a backup server |
The biggest trade-off is control. A self-hosted system gives the trust complete control over what is shown, when it is shown, and who can override it. It also gives the trust complete responsibility for keeping it running. If the server crashes, the screens keep showing the last content they downloaded, but new content will not appear until the server is back. If a screen fails, it must be replaced and reprovisioned. There is no cloud dashboard to show which screens are online and which are not.
What NHS estates actually buy
Most trusts do not buy digital signage. They buy a way to show waiting times, clinic maps, and emergency alerts on the screens they already have. The screens are usually Android TVs or tablets, often repurposed from other projects. The software is an APK installed from a USB stick or pushed via mobile device management (MDM). The server is a virtual machine in the hospital’s data centre, running on the same network as the EPR and the bed management system.
The licence is per site, not per screen. A trust with 50 screens and a trust with 500 screens pay the same. This is not a pricing trick; it is a reflection of how the system works. The server does the work, not the screens. The screens are just displays.
What to do next
If the screens in your waiting areas are still showing static PDFs or a loop of NHS videos, they are not doing their job. The first step is to list what you need them to show: waiting times, clinic delays, emergency alerts, wayfinding. The second step is to check where that data lives. If it is in the EPR, the bed management system, or the fire alarm panel, it can be pulled into a signage system. The third step is to decide where the server will live. If it is on the trust’s own network, it will meet the DSPT requirements. If it is in the cloud, you will need a DPIA and a DPA.
The fourth step is to test. Install the APK on one screen, point it at a test server, and see what happens when the network drops. Does the screen keep showing content? Does the alert override work? Does the screenshot match what is on the wall? If the answers are yes, the system is ready for a pilot. If not, find out why before you roll it out.
The fifth step is to provision the screens. This is the most time-consuming part. Each screen must be granted the Display over other apps permission, either by hand or via ADB. Once that is done, the screens will poll the server and show whatever content is sent. The final step is to train the staff who will send the alerts. A system that can override every screen in the hospital is only as good as the people who know how to use it.
