Q5 — corrections facility platform with wearable-vitals alerts
Constraint
The box they were trapped in
Corrections facilities have a duty-of-care problem with vital signs and a workflow problem with incident reports. Wearable devices exist that can stream those vitals; what was missing was a platform that fused the device feed into a staff workflow — alerts, acknowledgements, resolutions, paperwork — without asking a custodial officer to also run a dashboard tool. The system had to handle the records side (inmate data, device assignments) and the live side (vitals telemetry) in the same product, with the security posture either job demands.
Approach
How we attacked it
A React + Material UI web app for the staff side. A Node.js API takes the live vitals feed from the wearable side, runs incoming readings through abnormality thresholds, and raises alerts into the platform when limits cross. Inmate records and wearable-device assignments live in a relational SQL store; the high-frequency telemetry stream sits in DynamoDB. AWS Lambda handles backend ops behind API Gateway; CloudWatch covers monitoring and audit logging. Staff acknowledge alerts, resolve them, or escalate to an incident report from the same screen — one workflow, not three.
Decisions
What we picked, and what we rejected
SQL for records, DynamoDB for the telemetry stream
Inmate records, device assignments, and incident reports are relational and audit-heavy — that's SQL's job. High-frequency vitals readings would melt that same database under sustained write load and offer nothing relational in return. The split costs us two data layers to operate; running everything through one would have cost us the records database under load.
Alerts, resolutions, and incident reports in one UI
A custodial officer running between three screens to acknowledge an alert, log the response, and file the incident report will skip steps under pressure. The platform collapses all three actions onto one screen with the inmate context already attached. That's the difference between a workflow people use and a workflow people work around.
AWS Lambda + API Gateway over a long-running server
The workload is bursty — vitals readings flow constantly, alerts fire occasionally, staff sessions are short and intermittent. Lambda's duty cycle matches that shape and stops us paying for an always-on EC2 box that's idle most of the time. API Gateway gives us throttling, auth, and per-endpoint metrics for free.
Material UI over a custom design system
Corrections software runs on cheap shared monitors in shift rooms and has to be readable across long sessions for staff who didn't pick the tool. MUI's defaults — type scale, contrast, hit targets — land the right baseline without spending the team's two months on a design system that nobody asked for.
Trade-off
What we didn't build
We did not design the wearable itself. The platform is the software side of a pre-existing device — the team's job was the staff workflow, the alerting layer, and the records system, not the silicon or the firmware. We also split the data layer deliberately: inmate records and device assignments in SQL, the high-frequency vitals stream in DynamoDB. Maintaining two stores costs us some operational complexity; running everything through SQL would have melted the records database under telemetry write load. The split is the cheaper version of the problem.
Outcome
What changed after we shipped
Live web platform staff use across shifts. Vitals stream in from the wearables, abnormal readings raise alerts the team can acknowledge, resolve, or escalate to an incident report inside one screen. Inmate records and device assignments live in the same system, so the paperwork side and the live-monitoring side share one workflow instead of two parallel ones.
Talk to us
Have a similar project in mind?
Tell us what you're working on. We'll let you know whether it's a fit.