An Indian clinical-monitoring health-tech venture: reading vitals from the monitors hospitals already own
Continuous ward monitoring normally means buying hardware for every bed. This platform reads the monitors already there, which changes both the economics and the privacy model.
A concise view of impact and engineering focus.
Device-agnostic — works with existing monitors
No patient imagery retained; vitals only
On-premise deployment, hospital-held data
The constraint was procurement, not accuracy
General wards are where deterioration goes unnoticed longest, and they are also where continuous monitoring is hardest to justify. Both established approaches — under-mattress sensor mats and body-worn wearables — price coverage per bed, so extending monitoring to a whole ward means a hardware purchase proportional to the ward. Hospitals that already own perfectly good bedside monitors are asked to buy a second sensing layer on top of them. We rejected both and took the reading from the display that already exists: the vitals are on the screen, so the problem is extraction, not sensing.
The monitors were never the missing piece. What was missing was anything watching them continuously.
Extraction is a segmentation problem before it is an OCR problem
A ward contains monitors from different manufacturers, different generations and different screen layouts, so a pipeline that assumes a fixed field position fails on the second model it meets. The platform segments the screen first, classifies the layout, then reads the numeric regions — heart rate, SpO2, systolic and diastolic pressure, respiration rate and pulse. Layout classification is what makes the system device-agnostic in practice rather than in the brochure: a new monitor model is a layout to learn, not an integration to build. Readings sync on a five-second interval, which is frequent enough to show a trend and sparse enough to run comfortably on ward wifi.
Device-agnostic is a claim about the layout classifier. Everything downstream depends on it generalising.
Retention scoped to events, not to the ward
A camera pointed at a hospital bed is a privacy problem before it is a product, and the architecture answers it by not keeping the frames. Images are processed for extraction and discarded; what persists is the numeric vital-sign record. Where an alert fires, a short clip is retained with it so a clinician can see the context behind the number rather than trusting a threshold breach on its own — retention is therefore scoped to clinical events rather than running continuously across the ward. Deployment is on-premise, so the data stays inside the hospital's own estate, and the design is built to India's DPDP consent requirements with HIPAA-aligned encryption in transit.
Continuous surveillance and continuous retention are separable. Only the first one is the product.
An alert nobody acknowledges is not an alert
Threshold alerting is the easy half. The platform routes to the clinician actually on duty across dashboard, SMS and messaging, carries the context clip with the notification, and escalates automatically when an alert goes unacknowledged — which is the failure mode that makes ward alarms ignorable in the first place. Thresholds are set per patient rather than per ward, because a resting heart rate that is unremarkable in one bed is a deterioration signal in the next. Extracted vitals flow into the hospital's existing EMR rather than living in a parallel record, so the monitoring history is where the clinical team already looks.
Alert fatigue is an architecture problem: it is what happens when routing, escalation and per-patient thresholds are left out.
What to carry into the next sprint
Takeaway
Reading existing monitors removes the per-bed hardware cost that keeps continuous monitoring confined to critical care.
Takeaway
Screen segmentation and layout classification are what make a vision pipeline survive a mixed-vendor ward.
Takeaway
Discarding frames after extraction lets a camera-based system hold a defensible privacy position rather than an apologetic one.
Frequently asked questions
- Does this replace the hospital's existing monitors?
- No — it depends on them. The platform reads the displays of the monitors already in place, which is why coverage does not require a per-bed hardware purchase. A hospital that later replaces its monitors keeps the monitoring layer; the new model becomes a layout for the classifier to learn.
- Are patient images stored?
- Frames are processed to extract the numbers and then discarded; the persistent record is vital-sign data. Where an alert fires, a short context clip is retained alongside it so the clinical decision can be reviewed. Retention is tied to events rather than running continuously.
- Where does the data live?
- On-premise, inside the hospital's own infrastructure. That was a design constraint rather than a deployment option: clinical data sovereignty is difficult to argue for when the processing happens somewhere the hospital does not control.
- How does it handle monitors from different manufacturers?
- By classifying the screen layout before reading it, rather than assuming fixed field positions. This is the part of the system that determines whether 'device-agnostic' holds up in a real ward, where monitor models are rarely uniform.
- What stops it from adding to alert fatigue?
- Per-patient thresholds rather than ward-wide ones, routing to the clinician on duty, a context clip attached to the alert so the number can be judged rather than merely received, and automatic escalation when an alert is not acknowledged.
Applied AI where the constraint is the estate you already have
Most applied-AI work in regulated environments is decided by what you are allowed to install, retain and move — not by model choice. We will map the sensing, retention and integration constraints you are actually operating under, and design to them rather than around them.
Book an Applied AI Review