ReliaPump
▲ PEOPLE'S CHOICE @ BIOHACK
Remote programming for home tube-feeding pumps: a clinician proposes a change, the caregiver confirms it, and the pump validates it before reporting back what it delivered.
MISSION BRIEF
Built a prototype smart enteral feeding pump system for families who tube feed at home. Today those pumps are programmed by hand at the bedside, and changes from the clinic arrive by phone or on paper. With Smart Pump, a clinician proposes a new prescription, a caregiver confirms it on their phone, and the pump checks it against limits compiled into its firmware before applying it. The portal shows a change as active only after the pump itself reports the new version. I owned the hub, a FastAPI service running in Docker on a laptop that works with no internet. It bridges MQTT messages from the ESP32 pump, runs the prescription lifecycle with a publish gate so nothing reaches the pump without caregiver confirmation, streams live status to the web apps over Server-Sent Events, and keeps an append-only audit trail in SQLite. I also built the hub's alerting, staleness detection, and delivered-vs-prescribed reports, plus the first versions of the clinician portal and the family app (including Spanish). Built by a team of 4 in one weekend, alongside ESP32 firmware, a software pump simulator, and a Next.js care dashboard. Won the People's Choice award at BioHack. A prototype, not a medical device.
THE PROBLEM
Families who tube feed a child at home program the feeding pump by hand at the bedside. When the clinic changes the prescription, the new rate and volume arrive by phone or on paper, and a tired caregiver types them in, sometimes at night. Connected enteral pumps exist, but the data mostly flows one way, from the pump to the clinic. At BioHack our team of four asked what safe remote programming would look like: the clinic proposes a change, the family stays in control, and the pump itself has the final say.
APPROACH
We designed around eight safety invariants and referred to them by number in code, reviews, and the pitch. The most important: hard rate and volume limits are compiled into the pump firmware and can't be changed over the network. An out-of-range prescription is rejected and reported, never quietly clamped to the nearest allowed value. Nothing reaches the pump without a caregiver's confirmation. Prescription versions only increase, so repeated or replayed messages are harmless. Changes apply only when the pump is idle, never mid-feed. The one that shaped my work most: the portal says "Active on pump" only after the pump's own telemetry reports the new version. Sending a prescription is not the same as applying it.
ARCHITECTURE
I owned the hub, a FastAPI service with SQLite and a Mosquitto MQTT broker, running in Docker on a laptop with no internet connection. It is the only component that talks to both sides: the ESP32 pump (and a software simulator that behaves identically on the wire) speaks only MQTT, and the web apps speak only HTTP. The hub runs the prescription lifecycle (proposed, confirmed, sent, then active, rejected, or superseded) behind a single publish gate that refuses anything unconfirmed. Prescriptions are published as retained QoS 1 messages, so a pump that was offline receives the latest one when it reconnects, and the hub re-publishes on startup. Live status streams to the web apps over Server-Sent Events. Every state change goes into an audit table that database triggers make append-only, so rows can't be updated or deleted. I also built the alerting, offline and staleness detection, and the delivered-versus-prescribed reports, plus the first versions of the clinician portal and the family app, including Spanish.
RESULTS
Won the People's Choice award at BioHack. The full loop ran live on one laptop with no internet: a clinician proposed a change, a caregiver confirmed it on a phone, and the pump applied it or refused it with a reason. Pulling the wifi mid-feed didn't stop the feed. An independent safety review before each merge caught a real bug: a path where the hub could re-send a prescription that had already been replaced. We fixed it and added a regression test.
WHAT I'D DO DIFFERENTLY
This is a prototype, not a medical device, and we said so on stage. A real product would need user identity and roles instead of fixed demo users, TLS and per-device credentials on the broker, per-patient limits set through a controlled clinical process, independent flow measurement instead of motor-step estimates, and the regulatory work (IEC 60601-2-24, ENFit connectors, FDA cybersecurity expectations) that we didn't attempt in a weekend.