Knowing which of 20,000 devices is broken

We have more than 20,000 devices deployed in hospitals across the country. They fail quietly. A unit stops reporting, a battery degrades past the point of being useful, a sensor drifts out of calibration — and none of that announces itself. It shows up later as a gap in a hospital's data, which is the worst possible moment to find out.

Before this platform, finding those devices was a manual process spread across several departments, each looking at a different slice and each with their own idea of what "broken" meant. Nobody owned the whole picture, which meant the whole picture didn't exist.

What it is

A platform that ingests telemetry from the fleet and decides, per device, whether it is healthy. Three failure classes are detected automatically: devices that have gone quiet, batteries degrading toward the end of their useful life, and units whose calibration has drifted. It is used daily by engineering and by client services, and it emails a weekly system-health report so nobody has to remember to go and look.

Python and PostgreSQL behind it, React in front.

The part that was harder than it sounds

The detection logic is not the difficult half. The difficult half is that the answer has to be the same for everyone. Several departments were previously reaching their own conclusions about the same device from their own slice of the data, so "is this device working" had more than one answer depending on who you asked. Replacing that with one automated judgement meant agreeing on the definitions first and writing the code second.

That is also why the weekly report goes out to everybody on a schedule rather than to whoever thought to request it. A monitoring system that people have to remember to consult is one more thing to forget.

What changed

A manual, multi-department monitoring process became a single automated system that engineering and client services both work from daily.