THE PROBLEM
The coronavirus pandemic has brought the world to its knees. The only reason is the highly contagious nature of the virus. Healthcare systems worldwide are not competent enough to deal with this due to several reasons like-
- Lack of equipment 
- Lack of doctors
- Lack of protective equipment
Our last line of defence - the doctors, put in every effort to treat their patients. However, more often than not they contract this deadly disease in the bargain. Their exists no method to directly treat patients without coming in contact with them even for the treatment of coronavirus, which is not very complicated except in extreme cases. The key interactions of the medical staff with the patients include - 
- Cleaning of wards
- Giving food and medicines
- Body temperature monitoring
- Collecting blood samples
- Giving instructions 
- Essential equipment monitoring
While solutions to the first two problems exist already as hospitals at many places have incorporated ground robots for this task. Taking temperature samples can easily be done by medical staff from a safe distance and there is no scope for innovation on that front.
No viable solutions exist for the other three problems, which is why everyday hundreds of doctors are getting affected. In areas where the number of doctors is less, this is a really serious issue. Due to the multitudes of patients turning up at hospitals, doctors are being forced to work overtime which is extremely stressful for them. Cases of suicide by such doctors have been reported.

THE SOLUTION
I propose a connected hospital consisting of nodes in the form of modules mounted on patient beds that are able to log and control essential equipment data, collect blood samples, monitor patient health and raise alarms when necessary. The beds would form a BLE mesh network and connect to a central station that would send notifications to medical staff over a WiFi network.
The beds would be equipped with microphones and speakers for the doctor-patient interaction. The nodes would have a panel of buttons for the patients to ask for certain essentials like food or water. The panel would also include a button for  summoning hospital staff in case of an emergency. There would be a provision for the monitoring essential devices like the ventilator, the ECG, the EKG etc. The data from all these devices would be sent to the central station where it would be analysed using complex data analysis techniques based on the TensorflowLite library and if a problem arises the central system publishes the anomaly along with the patient ID to the AWS IoT cloud. Important notifications are directly sent to the doctor incharge in the form of in-app notifications, text messages or calls. The doctor may then take preventive measures autonomously by changing settings on the life-support devices through the app that connects to AWS cloud. If the assigned doctor is not available, the web service automatically sends notifications to doctors connected to the network who can then volunteer and take life-saving decisions, everything autonomously.
This might sound far-fetched but the impact such a system can have is enormous. A web application would enable the doctors full control over life-support devices of the patient. The data can be collected on demand and collected for medical research. The doctor may also use the cloud dashboard for manual analysis of critical patient data and intervene life-support devices remotely.
The beds would also have a provision for the attachment of a non-intrusive sample collector and drug injector that has to be installed manually but can be operated remotely by means of robotic arms controlled by servo motors. This would definitely  improve the condition of medical staff, keeping them safe, reducing their workload, allowing real-time monitoring, allowing control of life support devices remotely and saving many unnecessarily lost lives by taking quick decisions remotely.

THE IMPLEMENTATION
I would make nodes based on the NRF52832 boards which support BLE. The node would have connectors for inputs from various life-support devices. A robotic arm with 6DOF from a previous project would serve for control of  sample collector devices. The central station would be made using the Cypress PSoC 6 Pioneer Development kit and act as a gateway between the nodes and the cloud. 
Patient logs are sent directly to the central station which uploads everything to the cloud over the hospital`s WiFi network. Temperature and humidity would also be monitored and windows  opened and closed automatically.
The data sent to the central station would be monitored  and analysed based on predefined parameters on a per patient basis using the TensorflowLite library. If an anomaly is found, the concerned medical staff is immediately informed and the doctor takes control of life-support equipment. If any instruction is to be given, the doctor speaks to the patient through a speaker on the bed. The doctor can then interact with the patient via voice over the cloud. The many interactions would create some latency but time is not of the essence in this case.
The patient can key in certain instructions to the hospital staff with the help of a panel of buttons with pre-defined functions. An alert button is also present for the patient to call out for help. These functions would be implemented as interrupts in the control station code. If an injection is to be given or a sample is to be collected, hospital staff would fix the device on the robotic arm. It would then be controlled by the doctor remotely by means of the app which connects to cloud.
The webservice is made on NodeRed and acts as a link between the central station, the doctors and Amazon Web services. The doctors are able to interact with the network with the help of an app made on the MIT App Inventor. It provides a panel for monitoring of patients directly using AWS IoT Things Graph and to control the sample collector and other life-support devices via AWS IoT Events. It also has the option to interact with the patient by voice over the cloud. The webservice also sends notifications directly to doctors and other medical staff which can be received on their copy of the application. If the assigned doctor is not available, the web service automatically sends notifications to doctors connected to the network who can then volunteer and take life-saving decisions, everything autonomously. The triggering is done using AWS IoT Events. 
AWS IoT Greengrass Core services are hosted on the central stations to communicate amongst each other and for data analysis on the cloud and at the edge. If a station loses connectivity it relays the data to another station which then sends it to the cloud offering end-to-end data security. Using AWS IoT Device Management the central station would be maintained and OTA updates would be pushed when necessary. IoT Analytics over the cloud help manage a large number of patients and decide future treatment plans and can even help with medical resaearch.

BENEFITS
The chief benefits the concept has are-
- Improved quality of life for doctors
- Medical staff would need to come in minimal contact with infected wards
- Remote and timely treatment
- Life-saving treatment can be done remotely
- Availability of patient data for medical research
- Reduced stress and work-time for medical staff

HARDWARE
- 3D Printed node attachment
- NRF52832 dev board
- Servo motor(SG90)
- Keypad
- Microphone
- Speaker
- Cypress PSoC 6 Pioneer Development kit
- Temperature and Humidity Sensor (DHT11)

SOFTWARE
- NRF Connect SDK
- Segger Embedded Studio
- ModBus Toolbox
- WICED Studio
- AWS IoT cloud
- Arduino IDE
- NodeRed
- MIT App Inventor 2

CHOICE OF HARDWARE
Pioneer kit v/s prototyping kit
The only advantages of the Prototyping Kit over the Pioneer Kit are the larger number of GPIO, The SD card slot and the amount of SRAM. I decided on the Pioneer Kit because-
- My project does not require that many GPIO(and I think none of my future projects will)
- The SD card slot compatibility might not be present for faster versions rolled out in future and hence may cripple the scalability of my product. I would prefer to use an external SPI SD card module instead. In this prototype, I am sending data directly to the cloud without logging.
- 512MB NOR flash is already a decent amount and the only heavy processing application I can think of are data analysis, machine learning or image processing which I plan to do in the cloud. Hence more RAM would not be required in general for any application. I the need arises SPI RAM chips can be interfaced with some effort(many tutorials on Hackaday for that).
The advantages of the Pioneer kit are-
- Screen to display important parameters and debugging on the edge
- Audio capabilities
- Extra sensors on the board for environmental monitoring
- Arduino compatibility to mount a variety of shields
 NRF52832 boards
Honestly, I do not own any other BLE boards right now. TO demonstrate my idea I only have these. We can very well use the PSoC dev kit or any other BLE boards for the nodes.
Amazon Web Sevices v/s custom webservice
Healthcare systems are critical to the life of a patient. A webservice on NodeRed may alone be sufficient, but AWS provides multi-level real-time authentication which would make the concept agreeable to hospitals the world over. AWS IoT Greengrass handles data in the event of network loss for a particular station. AWS IoT things graph provides an easy interface for doctors to monitor patients. AWS IoT Core provides authentication and control efficiency with seamless integration with other web services and mobile applications communicating via MQTT or IFTT(for texts or emails). AWS DynamoDB for data logs that can be used for medical research or drug discovery - the need of the hour.
I think there is no all-in-one solution that can handle so many complex interactions. If I start making all this from scratch the time to market would render the product useless. I doubt I alone can do this much.

WHO AM I?
I am an IoT enthusiast pursuing an undergraduate degree focussed on Electrical and Electronics Engineering and a minor in Computer Science at the Indian Institute of Technology, Kharagpur. Currently I am remotely interning at a robotics firm as an Industrial IoT engineer. I spend my time at home making home automation projects based on WiFi, BLE or LoRa. I regularly take part in online hardware contests like this one and love to explore new technologies.
 I am part of TeamKart, my college`s Formula Student team where I was part of the datalogging and telemetry team which was adjudged the best at the contest. I worked on the design of the telemetry unit and was able to acquire data from a racecar in realtime and visualise it with an app made on Matlab. I have worked with a variety of MCUs like STM, NXP, Atmega, PIC and NRF and have considerable experience with FPGA too.
At KRSSG, my college`s Robocup team, I am part of the embedded team that designs and implements all electronic systems in a four wheeled FPGA based, soccer playing robot. This year, we were the ONLY UNDERGRADUATE and ONLY INDIAN team to qualify for the prestigious finals at Bordeaux. We re-designed the STM based control systems and implemented fuzzy PID with a Xilinx Spartan 6 FPGA. 
My interests lie in communication systems, electric vehicles, control systems and reconfigurable FPGA systems. I am an active member of the element14 and Hackster.io community and have completed many projects and roadtests successfully. I am new to Hackaday and this is my first submission. I really like the website and the amazing projects and wonder why I didn`t know about this earlier. I would love to be a part of this community and bring quality stuff to it.