Wireless Nurse Call and Response Time Tracker for Small Hospitals
A final year project that builds a low-cost wireless nurse call system for small hospitals, maternity homes and care homes: battery bedside buttons, a ward display, staff pagers and a dashboard of response times. It adds the accountability that cheap doorbell-style kits lack without the price of wired hospital systems.
Intermediate
A small team, or one strong student willing to learn something new.2 semesters · 3 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- Battery-powered bedside call buttons that sleep most of the time, wake on press, send a call with bed and ward ID, and report battery level daily.
- A ward gateway on a Raspberry Pi that receives calls, acknowledges them, and forwards them to a nurse station display and to wearable pagers or phones.
- A call lifecycle of raised, acknowledged and resolved, where resolution is done by the nurse pressing a presence button at the bed, not from the station.
- Escalation: an unanswered call moves to a second nurse and then the ward in-charge after configurable delays.
- A dashboard with response times per ward, shift and hour, open calls, and devices with low battery or missed heartbeats.
- A reliability test on a floor of a real building or hostel covering message delivery rate, latency and battery life estimate.
- A privacy and data retention note: no patient names on devices, only bed numbers.
If you have time left
- A different call type for bathroom pull cords that always escalates immediately.
- Voice announcement in Urdu and English on the ward speaker for the bed number calling.
- An end-of-shift summary sent to the nursing supervisor.
The problem small hospitals have with calling a nurse
In small private hospitals, maternity homes, dialysis centres and care homes, patients often have no way to call a nurse except shouting or asking a relative to walk to the station. Where a system exists, it is usually a wireless doorbell kit: press a button, a receiver beeps. Nobody knows how long the patient waited, whether the call was answered, or which ward is understaffed at night. Larger hospitals install wired nurse call systems, but these are expensive and need cabling during construction, which rules them out for buildings converted from houses or offices.
What already exists and the gap
- Entry-level wireless kits from brands such as Retekess and Synlett sell a receiver with several buttons at a low price. They beep and show a number; there is no acknowledgement, escalation or history.
- Care facility systems such as the EconomyCare+ wireless range support many buttons, pressure pads and central monitoring, priced for licensed care facilities in the US.
- Open source ESP32 nurse call projects on GitHub show the basic radio link, without response time tracking or reliability testing.
The gap is a system in between: cheap enough for a 20 to 60 bed facility, with a real call lifecycle, escalation, and response time data that the medical superintendent can use to plan staffing.
What you build
- Bed buttons: ESP32-C3 boards in small enclosures on coin or AA cells, in deep sleep until pressed.
- Presence buttons: a nurse presses it at the bed to confirm they arrived, which resolves the call.
- Ward gateway: a Raspberry Pi receiving radio messages, running the call state machine, and driving a station display.
- Staff alerts: a small wearable pager on ESP32 with a vibration motor, or a phone app.
- Dashboard: live calls and response time analytics.
The technically interesting part
This is a reliability problem on a battery budget. A call must arrive every time, quickly, from a device that spends almost all its life asleep. You will design a message protocol with sequence numbers, acknowledgements and retries, choose between ESP-NOW (fast, short range) and LoRa (long range, slower) based on measurements in a real building, and calculate battery life from measured current in sleep and transmit. The call state machine on the gateway must survive a gateway reboot without losing open calls. Evaluators will want to see delivery rate, latency and battery numbers, not just a demo.
How to evaluate it
- Delivery rate and end-to-end latency from button press to pager vibration across at least 1,000 presses at different distances and through walls.
- Battery life estimate from measured sleep and active current, validated by a two-week run.
- Gateway restart test: open calls restored after a power cycle.
- A usability walkthrough with three nurses or nursing students on a simulated ward.
Suggested plan
- Month 1: visit a small hospital, map the ward, list call types and escalation rules.
- Month 2: radio comparison and protocol with acknowledgements.
- Month 3: low-power button firmware and battery measurements.
- Month 4: gateway state machine, display and pager.
- Month 5: dashboard and analytics.
- Month 6 to 7: building-scale reliability test, user walkthrough and report.
Path to a product
The first customer is a 20 to 60 bed private hospital or maternity home that wants to improve patient experience and has no wired system. Sell per-bed hardware with installation and a small monthly fee per ward for the dashboard and support. Hospital consultants and equipment suppliers are the channel. Care homes are a second market with the same needs.
Scope warning
Do not connect to patient records, vital sign monitors or anything that makes this a regulated medical device. Do not build voice calling from the bed. Keep patient identity off the system entirely; bed numbers are enough.
Learn what you need on Sefism
- System design roadmap : acknowledgements, retries and state that survives restarts.
- Backend roadmap : the gateway service and analytics API.
- Beej's Guide to Network Programming : protocol design ideas you can reuse on a radio link.
- Operating Systems: Three Easy Pieces : concurrency and persistence concepts behind a gateway that must not lose calls.
- roadmap.sh: Linux : running the gateway as a reliable service.
Get help with this idea
Measuring reliability properly is what will set your project apart, so plan the test before the build. If you want a second opinion on scope, hardware choices or how to set up the evaluation before you commit, bring your plan and your bill of materials and we will pressure-test it together. New here? Create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.