The problem Eagle Assist solves

Often in hospitals, we have a certain nurse to bed ratio set by the medical association of that country. It is almost never followed by hospitals as they aim to reduce employment costs. This decreases the ratio to a dangerous level where emergency patients, who need immediate attention, do not get it on time and in many cases, die out of improper time management of the hospital staff. In all hospitals, we have several kinds of beds, for general ward and maternity ward, also for special ICUs and ICCUs. Each sector of the hospital has some or the other designated nursing stations where the nurses' house and then go to beds from there. In big hospitals chains, there exists some resemblance of a monitoring system, but systems like these tend to be very costly and cannot be afforded by smaller hospitals that cater to the larger chunk of the public.

Eagle Assist brings in almost nothing new to the table. We "repurpose" the already existing infrastructure in a hospital to serve our needs. Hardware that monitors vitals of patients is already existent in a majority of the hospitals. We tap into that same data and consolidate it to a single, centralised server for faster, and more efficient response to a situation. We save on wiring costs (the system is 99% wireless), we provide scalability (almost like plug and play) and we are secure (WPA2/PSK).

This system can be modified and extended further into patients who stay at home, with almost negligible code configuration. We can scale from 1 to 100 in mere minutes because the adding of a new bed is almost as simple as plugging in a new blub to the holder.

This system can also be modified with ease and can be allowed to communicate over a secured internet connection to help in cases where trained nurses are not available to accompany patients travelling in ambulances. While in transit, the hospital will get hold of a general condition of the patient, and doing the necessary actions as the situation calls.

Challenges we ran into

Setting up the root Node in the WiFi mesh. After a lot of research and tinkering, the issue was resolved in the Arduino IDE.
Sending properly formatted data to the server proved to be a bit of hindrance. ArduinoJSON finally saved the day and we could properly establish communication between the server and the hardware.

The more pressing issues on the lines of server communication were also encountered. The speed of input had to match with the I/O operations between the server and the database(s). Express Rate Limit middleware helped not to overload the API.
We prevented a bottleneck situation on either side by carefully measuring the performance impact on both ends.

The dynamic nature of the dashboard proved to be a bit difficult to implement as well. We had to ensure we do not waste storage space, lest the performance would be degraded. We finalised on array as our preferred data structures due to its fixed size and easy manipulation. We ensured we should get proper data everywhere, by ensuring we use the same index to access data everywhere.