The headline that changed nothing
"Scotland's NHS is putting reputation before patient safety - officials" appeared on 20 August 2026. The details don’t matter. What matters is that every NHS trust in the UK read it, checked their own systems, and found the same gap: patient-adjacent screens that can’t be trusted to show the right message at the right time.
Waiting rooms, corridors, and nurse stations run on a mix of old PCs, consumer TVs, and cloud services that were never designed for clinical use. When the network drops, the screen freezes. When the cloud provider updates, the layout breaks. When a patient’s data might be on display, there’s no way to pull it back.
NHS estates teams have known this for years. The question isn’t whether digital signage belongs in healthcare. It’s whether it can be made to work without introducing new risks.
What healthcare screens actually do
A digital signage system in a hospital or GP surgery has three jobs:
- Waiting room information: Appointment delays, infection control notices, wayfinding. Static slides that change once a day.
- Clinical alerts: Fire drills, cardiac arrests, missing children. Messages that must interrupt whatever is showing, within seconds.
- Patient privacy: No data leaves the building. No cloud provider sees what’s on screen. No screen shows the wrong thing when the network fails.
Most systems handle one or two of these. Few handle all three without requiring new hardware, new infrastructure, or new risks.
Why Android devices are already in NHS waiting rooms
Walk into any NHS trust today and you’ll see consumer TVs running on HDMI sticks, tablets mounted on walls, and old PCs repurposed as signage players. They’re cheap, they’re already there, and they’re running Android.
An Android app installed from an APK can take over the screen using Android’s "Display over other apps" permission. It doesn’t need root, a custom ROM, or a system image. On a television, the permission is granted once at setup, either by hand or with a single ADB command during provisioning.
This isn’t a workaround. It’s how Android was designed to work for kiosks, digital signage, and emergency alerts. The only difference is that most signage systems don’t use it, because they’re built for offices, not hospitals.
The clinical alerting problem
When a cardiac arrest is called, the screen in the waiting room must show it. Not in five minutes. Not after a refresh. Immediately.
Most digital signage systems push content from the cloud. If the network is slow or down, the message doesn’t arrive. Some systems cache content, but few can interrupt what’s already on screen.
A system that polls the server every 30 seconds can show an alert within that window. If the server is on the same network as the screens, the delay is negligible. If the server is in the cloud, the delay depends on the internet connection.
NHS estates teams know this. That’s why they keep patient-adjacent systems on their own infrastructure.
Information governance: what NHS trusts actually require
NHS Digital’s Data Security and Protection Toolkit (DSPT) sets the rules. For digital signage, the key points are:
- No patient data on screen: Screens in waiting rooms and corridors must not display patient names, NHS numbers, or appointment details. Static slides with generic information are fine. Dynamic content that pulls from patient records is not.
- No data leaves the building: If the signage system uses a cloud service, the trust must be sure no data is stored or processed outside its own network. Most cloud providers can’t guarantee this.
- Audit logs: The system must record what was shown, when, and on which screen. If a screen shows the wrong message, the trust must be able to prove what happened.
A self-hosted system installed on the trust’s own server meets these requirements. A cloud-based system does not, unless the trust can prove the provider never sees or stores the data.
The trade-offs of self-hosted signage
| Pro | Con |
|---|---|
| No data leaves the building | Server must be maintained |
| No per-screen licensing fees | Initial setup takes IT time |
| Works offline | No cloud provider support |
| Full control over content | Updates must be managed manually |
Self-hosted signage isn’t simpler. It’s just more predictable. The trust owns the server, the network, and the screens. If something goes wrong, the trust fixes it. There’s no third party to blame, but also no third party to call.
Why NHS estates teams prefer per-site licensing
Most digital signage systems charge per screen. In a hospital with 200 screens, that’s 200 licences to buy, renew, and track.
A per-site licence covers every screen in the trust. There’s no limit to how many screens can be added, and no extra cost for scaling up. For estates teams managing hundreds of screens across multiple sites, this is the only model that makes sense.
What to do next
If you’re responsible for digital signage in a healthcare setting, start with these steps:
- Audit your screens: List every screen in patient-adjacent areas. Note the hardware, the software, and how it’s connected to the network.
- Check the DSPT: Confirm your current system meets NHS information governance requirements. If it doesn’t, document why and what you’ll do about it.
- Test offline behaviour: Unplug the network and see what happens. If the screens freeze or show the wrong message, you have a clinical alerting problem.
- Talk to estates and IT: Self-hosted signage needs server space and network access. Make sure both teams are on board before you commit.
- Run a pilot: Install a self-hosted system on a single ward or waiting room. Test it with real alerts, real network outages, and real staff feedback.
Digital signage in healthcare isn’t about screens. It’s about trust. The trust that the message will appear when it’s needed. The trust that patient data won’t leak. The trust that when the network fails, the system won’t.
That trust is built on infrastructure, not software. The software is just the part that makes it work.
