Inspiration

In an ICU, a single second separates a save from a loss. But the reality inside most intensive care units is that a nurse is watching six beds at once, a doctor is three floors away, and the only thing standing between a patient's silent deterioration and a code blue is whether someone happened to be looking at the right screen at the right moment.

We kept running into the same two dead ends. Systems that actually solve this cost more than most hospitals can justify — so they simply don't buy them. And the systems hospitals do have are stationary: vitals are tethered to a bedside box, patient history lives in a separate records system, and coordination between a doctor and a nurse happens by shouting down a corridor. On top of that, constant redundant alarms create alarm fatigue — staff become desensitized to the very warnings meant to save lives.

We wanted to know whether we could fix this without asking a hospital to replace a single piece of equipment. The bedside monitor already displays everything a clinician needs. What if the problem wasn't a missing sensor, but a missing pair of eyes?

What it does

MedMonitor 24/7 is an AI-powered, mobile-first ICU monitoring platform that turns the monitors a hospital already owns into a live, intelligent telemetry stream.

A bedside camera watches the existing patient monitor. A computer-vision OCR pipeline reads heart rate, blood pressure, SpO₂, and temperature straight off the screen — no new sensors, no wearables, no proprietary hardware attached to the patient. Those readings flow into a trained Random Forest classifier that triages every patient into one of three states — Critical, Warning, or Normal — and pushes an alert to the assigned nurse and supervising doctor the instant something breaks a safe boundary.

Around that core, we built the workflow layer that existing monitoring tools leave out:

  • Role-based access for three distinct users. Super Admins manage beds, staff, and admissions; Doctors monitor vitals remotely, review reports, and assign medication tasks; Nurses receive alerts, execute tasks, and update status at the bedside.
  • Task & medication engine — a doctor creates a task with instructions and a target nurse; the nurse gets it as a push notification and confirms execution, creating an audit trail that eliminates "I thought you gave it."
  • Integrated clinical chat and calling so a doctor and nurse can coordinate on a deteriorating patient without leaving the patient's context.
  • Centralized medical repository for history, daily reports, X-rays, and lab results, uploadable and retrievable instantly.
  • Automated hourly summaries that condense a patient's vital fluctuations and behavioral trends, so a physician catching a free moment can absorb an entire shift at a glance.
  • Live capacity dashboard tracking occupied vs. available beds, staff load, and pending admission requests.

How we built it

The system is three layers with a hard separation of concerns.

Frontend — Flutter. A single cross-platform codebase serving Android and iOS, organized into role-scoped feature modules (Doctor, Nurse, Super Admin) over a shared core. Real-time vital charts, task lists, and alert popups update over a persistent WebSocket connection rather than polling.

Backend — ASP.NET Core (.NET 8). A RESTful API with Entity Framework Core in Code-First mode over Microsoft SQL Server. Authentication is stateless via signed JWT access tokens with independent long-lived refresh tokens, and logout blacklists the active token. SignalR carries live telemetry and alert dispatch; Agora handles in-app chat and voice sessions between staff.

Intelligence — Python inference service. OpenCV handles frame acquisition and text extraction from the monitor display, with CLAHE contrast enhancement to flatten glare. Extracted vitals become an engineered 8-dimensional feature vector that includes derived hemodynamic markers — Pulse Pressure and Mean Arterial Pressure — which are far stronger predictors of cardiovascular collapse than raw readings alone.

We chose a Random Forest Classifier deliberately over an SVM or a deep net, for three reasons:

  1. Interpretability. Clinical decision-support systems need to be auditable. Random Forest gives native feature importance, extended with SHAP for per-prediction explanations. A black box is not deployable in a regulated medical setting.
  2. Latency. Tree traversal runs in O(log n), giving us 2.3 ms average inference. SVM kernels land at 50–100 ms and recurrent layers at 200 ms+ — unacceptable when your total alert budget is under 5 seconds.
  3. Imbalance resilience. class_weight='balanced' handles skewed clinical data through cost-sensitive learning, without the safety risk of synthetic oversampling.

Training ran on a 50,000-record clinical corpus with a stratified 80/20 split and 5-fold stratified cross-validation, then serialized to a persistent pipeline for production.

Hardware. A HOOD W 501 N 1080p camera at 30 FPS on a vibration-dampened arm, mounted 1.2–1.8 m perpendicular to the monitor face. Streams are compressed with H.265 at an adaptive 1.5–4 Mbps, encrypted in transit with TLS 1.3 and at rest with AES-256-GCM, with device certificate pinning and rotating API keys.

Challenges we ran into

The ICU is a hostile environment for a camera. This was the hardest problem by far, and none of it was visible until we tried it.

  • Glare. Monitor screens are specular. We layered anti-glare overlays, deliberate display tilt angles, and backend CLAHE enhancement to computationally flatten reflections.
  • Lighting swings. Daylight rounds run at 500–1000 lux; night shifts at 20–50 lux. We handled it with progressive signal amplification up to 40 dB plus an automatic 5500K coaxial LED panel for extreme darkness.
  • Occlusion. A nurse steps in front of the camera and the feed is gone. Rather than firing a false alarm, the system holds the last known telemetry for up to 30 seconds before flagging a read failure.
  • Motion blur. Bed vibration ruins OCR. We added Laplacian sharpness evaluation to drop unusable frames before they reach the extractor.

Severe class imbalance. Our clinical dataset was 84% Critical, 13.6% Warning, and only 2.4% Normal baselines. Naive training produced a model that essentially screamed at everything. Cost-sensitive class weighting fixed the distribution problem without fabricating synthetic patients.

Trusting a model with a life. This was the design decision we argued about most. A statistically excellent classifier can still fail on an out-of-distribution patient. Our answer was to stop treating the ML output as final: we built a hardcoded deterministic guardrail layer that sits after inference and overrides it. If SpO₂ crosses a hypoxemia threshold, the alert fires — regardless of what the model predicted. The AI is allowed to escalate, never to silence.

Latency budgeting across a distributed pipeline. Network ingestion under 10 ms, OCR pool completion under 2 s, total end-to-end under 5 s — while sustaining up to 50 concurrent camera streams. Every architectural choice had to justify itself against that budget.

Accomplishments that we're proud of

  • 95.2% overall evaluation accuracy on multi-class clinical triage, with a 3.2% clinical false-positive rate — low enough to meaningfully attack alarm fatigue rather than add to it.
  • 2.3 ms mean inference latency per patient evaluation, giving us enormous headroom inside the 5-second alert budget.
  • Zero new patient-attached hardware. The entire vitals pipeline works against monitors a hospital already owns. This is the accomplishment we care most about, because it's what makes the system affordable enough to actually reach the hospitals that need it.
  • A genuine end-to-end system, not a demo. Camera to OCR to classifier to guardrail to backend to push notification to an acknowledgment logged against a named clinician — the full accountability loop.
  • Engineered against real standards: HIPAA Security Rule, IEC 60601-1 for electrical safety in patient environments, HL7 FHIR for clinical data modeling, and IEEE 802.11ac for wireless baselines.
  • We shipped it as a team of five, coordinating Flutter, ASP.NET, ML, and hardware work in parallel.

What we learned

The biggest lesson was that in healthcare, model accuracy is not the same thing as safety. A 95% model is a great model and a terrible sole authority. Learning to design the deterministic override layer — deciding what the AI is not permitted to decide — taught us more about engineering responsibility than any accuracy metric could.

We also learned that the boring constraint usually wins. We didn't pick Random Forest because it scored best in isolation; we picked it because it was fast enough, explainable enough for a regulatory audit, and robust to the data we actually had. Choosing the interpretable model over the impressive one was the right call.

Technically, we came away with real depth in computer vision under adversarial physical conditions, cost-sensitive learning on skewed medical data, real-time bidirectional architecture with SignalR, and enforcing strict RBAC when the data at stake is protected health information.

And the non-technical lesson: talking to clinicians changed the product. Features we assumed were central turned out to matter less than the hourly summary log — because the real constraint on a doctor isn't information, it's time to absorb information.

What's next for MedMonitor 24/7

Predictive deterioration and sepsis detection. Right now the system classifies a patient's state now. The next step is forecasting it — training models on historical vital trajectories to flag clinical deterioration or septic shock several hours before it becomes visible. That's the shift from a fast reactive system to a genuinely proactive one, and it's where the largest mortality impact lives.

Deep learning for medical imaging. Integrating CNNs and Vision Transformers to analyze the X-rays, CT scans, and lab results already flowing into our attachment repository — surfacing preliminary diagnostic insights and abnormality detection to cut diagnostic workload.

Beyond that: broader camera and monitor-model compatibility so the OCR layer generalizes across manufacturers, integration with hospital enterprise EHR systems via our existing FHIR-aligned data models, Arabic localization and accessibility work for deployment across the region, and scaling validation past our prototype bed limit toward full-unit deployment.

Share this project:

Updates

Submission history