GlucoCzech

Problem: A problem was presented when tracking multiple patients' live glycemic index as Dexcom software had a monopoly on their hardware with a closed-loop system: raw data was inaccessible. Although the current solution with Nightscout retrieved data every 5 minutes, usage was not intuitive, user-friendly or compatible with the patients' range of devices. Dexcom API restricts with a 3-hour delay of data, and hacking via interception would be unethical through breach of patient confidentiality.

Solution: The aim is to make raw, live data available for healthcare professionals at IKEM and beyond. Free access to raw data would have applications in statistics and research, the first in the field of live CGM. Our solution includes the ability to expand beyond just the G6 sensor, as observability over the data from previous and future generations and even other companies' sensors would work with it via FIHR. With our end goal, we can also reduce the workload burden on nurses and overall burnout.

Impact: Research would accelerate the science around CGM - diabetic tracking - which may open doors to a cure in the future (diabetes with no medical cure yet). We will act as the established community’s open source for people trying to gather this data, hoping to be the beacon of light they needed to implement their solution in different contexts using our workaround. From the patient’s POV, we would also be saving them from the long-term mechanical damage endured by constant needle pricks.

Feasibility & financials: Baseline had hospitals like IKEM resort to manual reading via glucometer and handwritten, inputted data - eating up the nurses’ time that could have been used for higher yield tasks - something a system could automatically do. Our solution would save 11.6 hours of labour a day, quantified in € terms gives an estimated saving of €120 per nurse at €10/hour, per day from time wasted on manual glucometer readings alone; calculated with 6x readings a day per patient, with 29 patients in the ward.

What is new about your solution?: https://docs.google.com/document/d/e/2PACX-1vQwjQtYfzTw-SHLLmqAqsakBkmgG_BYOrjYRa-sjTOrN0r8-zBUqC1ibXri7o5Qv5f96k45cmjeuhE9/pub

What you have built at the hackathon - text explanation + code (e.g. GitHub link): We built a service that collects metrics from each configured Dexcom sensor every 5 seconds and records the measurements in a database. For the benefit of the community, we have decided to open-source this code. The codebase can be found here -> github.com/roshaan/glucose-tracker We also built the front-end application that will utilize the database to which the scraper sends data by developing domain knowledge of what will be an intuitive workflow for nurses and doctors to operate on a ward.

What you had before the hackathon, please mention open source as well: Before the hackathon, we looked at open-source repositories including Nighscout repositories. After trying out the current solutions, we identified and realized how all of these solutions are created to monitor a single sensor and not a fleet of sensors that hospitals could utilize effectively. So, we reverse-engineered how Nightscout retrieves data in real time and created a service that lets us scrape data from multiple sensors and give us a good data model to manage such a system in a ward.

What comes next and what you wish to achieve: This solution is sensor agnostic meaning that the hospital can configure multiple sensors (different versions or different brands) and have all of this data available in a single place to monitor and use for data analysis purposes. We would also like to show that alerts are easily configurable with this approach. Also, we would like to replace the phones with a hardware device that collects the measurements from the transmitter and allows our scraper to collect that information.

Video: https://www.youtube.com/embed/qJZkZ_NrhLI