While the Glucosystem works well in simulation, it is necessary to test it as a hardware on real components in order for the Glucosystem to one day materialize as a medical device. Building the hardware itself would require reprogramming Glytec’s Glucommander IV™ so that it runs our modified Glucommander algorithm, which is able to input glucose data and output IV fluid data at per second intervals. We would also need to reverse engineer Glucommander IV™ so that the blood glucose values are being directly supplied by the Glucoset™ device, which will continuously monitor blood glucose levels. We would then need to attach the device to something like the Raspberry Pi in one of its many interfaces in order to access the data, process it, and send to the appropriate parties (patients and medical personnel) via wireless communication. The Raspberry Pi will also allow us to alter the data, based on incoming information by medical personnel or patients. For example, if the patient clicks ‘IV Disconnect’, the data for IV infusion fluid suddenly becomes 0 to end any fluid drip, thereby allowing the patient to safely disconnect from the device.
Due to regulations and safety, it would probably be best to test our hardware on moving artificial fluids having typical blood contents. Then we would manually alter the fluid’s glucose concentration to mimic a patient’s daily blood glucose fluctuations.
Since the Glucosystem is aimed to be a smart intravenous glucose monitoring and insulin infusion system for continuous patient care, one necessary requirement is for there to be a reliable and secure wireless communication. A failure in wireless communication could easily turn into a fatal situation. For example, a patient realizing that the Glucosystem device is malfunctioning and providing excessive insulin infusions would have to click ‘IV Disconnect’ in order to safely disconnect. An inability for the machine to receive the ‘IV Disconnect’ signal can lead to the patient receiving dangerously excessive insulin.
Since Wi-Fi connection can be so prone to network failure as a result of other users or present security concerns, we would recommend Zigbee as the most appropriate wireless communication for Glucosystem.
Due to regulations and safety, it would probably be best to test our hardware on moving artificial fluids having typical blood contents. Then we would manually alter the fluid’s glucose concentration to mimic a patient’s daily blood glucose fluctuations.
Since the Glucosystem is aimed to be a smart intravenous glucose monitoring and insulin infusion system for continuous patient care, one necessary requirement is for there to be a reliable and secure wireless communication. A failure in wireless communication could easily turn into a fatal situation. For example, a patient realizing that the Glucosystem device is malfunctioning and providing excessive insulin infusions would have to click ‘IV Disconnect’ in order to safely disconnect. An inability for the machine to receive the ‘IV Disconnect’ signal can lead to the patient receiving dangerously excessive insulin.
Since Wi-Fi connection can be so prone to network failure as a result of other users or present security concerns, we would recommend Zigbee as the most appropriate wireless communication for Glucosystem.