Working prototype — verified end-to-end demo
Smart Ambulance Device-Interoperability Gateway
An ESP32 edge gateway that auto-detects medical-device protocols with zero manual configuration, and decides what survives a bandwidth drop.
Inside the work
Keep the vital signal moving.
Conceptual device-to-gateway-to-hospital flow, using illustrative telemetry.
Discover
Identify a device from its BLE service profile and parse its readings.
Prioritize
Normalize observations and keep alerts ahead of less urgent streams.
Deliver
Buffer data when the connection drops and forward it when the link returns.
Overview
Built for an Indian engineering PBL course (ME305, Pune Vidyarthi Griha COE) around a patent-oriented claim: auto-detecting a connected medical device's protocol without manual configuration, and prioritizing which data streams survive a bandwidth drop. The system has three clearly separated interfaces — a laptop-side Project Command Center for creating patients and injecting clinical/network scenarios, background Python simulators that generate realistic BLE GATT telemetry for three real Health Device Profiles, and a Hospital Triage Dashboard served either from the ESP32 itself or locally.
The ESP32 parses `GATT_SVC:<uuid>` discovery lines and fixed-size binary frames over TCP or USB serial, normalizes readings into FHIR-style JSON observations with real LOINC codes, and applies offline-resilient store-and-forward with bandwidth-adaptive prioritization: waveform data drops first, then vitals, alerts survive last.
Architecture
| Stage | Status | Detail |
|---|---|---|
| Medical devices (simulated) | Implemented | Real BLE GATT profiles: Heart Rate (0x180D), Pulse Oximeter (0x1822), Blood Pressure (0x1810). |
| Edge gateway — auto-detect + parse | Implemented | ESP32 firmware + a Python software mirror, both parsing the same wire protocol. |
| Normalization (FHIR-style, LOINC) | Implemented | Maps raw readings to observations with real LOINC codes (8867-4, 59408-5, 8480-6, 8462-4, 9279-1) and evaluates alert thresholds. |
| Transmission — store-and-forward | Implemented (simulated egress) | Priority queue drops waveform → vitals → alert in that order when full; "transmits" via a logged TX event with a 5% simulated failure rate. |
| Hospital dashboard | Implemented | Two renderings: embedded HTML served directly from the ESP32, and a FastAPI-rendered local copy. |
Key Findings
What the work shows
A full end-to-end demo was verified on 2026-08-29: a patient created in the Command Center → simulators streamed live GATT telemetry over the LAN → the ESP32 parsed, normalized, and evaluated alerts → the dashboard reflected live values, with an injected tachycardia scenario correctly flashing a critical alert.
The ESP32 firmware includes a hand-rolled captive-portal Wi-Fi provisioning flow: it joins a saved network on boot, or falls back to its own access point with a `/setup` page.
The one gap from a production system: transmission to a hospital backend is currently simulated (a logged TX event), not a real HTTP egress — everything upstream of that (detection, parsing, normalization, prioritization, dashboard) runs on real hardware.