With the present threat of COVID-19, having quality exposure data is an invaluable asset that will keep the population safe and enable decisive response. Current technology based efforts focus primarily on contact tracing protocols to help warn individuals of exposure. One of such efforts includes the privacy-preserving, Bluetooth-based contract tracing exposure notification system: GAEN.
In an effort to make the system privacy-preserving, GAEN prohibits the use of location services such as GPS tracking. This is a major drawback for any health authority planning to implement this system, since it fails to provide the end user and decision makers location context regarding the exposure. To address this, we introduce a privacy-preserving, complimentary system: Checkpo!nt.
Our system works by placing stationary Bluetooth enabled devices, checkpoints, strategically around Indiana. Then whenever a user is in proximity to a checkpoint, the checkpoint ID is sent and stored locally on the user’s phones. Only when the user tests positive or shows COVID like symptoms the user has the option to report it, and the data is stored anonymously in the central database. This way our system provides valuable location context on exposures without being privacy compromising.
Isaac (Go Squad Member, Junior Chemistry Major @ Wabash College) Isaac worked alongside Ally to complete the environmental analysis, business model, and other go-to-market pieces. He is very grateful for this opportunity.
Ally (Go Squad Member and Project Manager, Junior Information Systems Major @ Indiana University) Ally worked with Isaac to complete the go-to-market pieces of the project. She coordinated weekly meetings, filled out the weekly Project Manager document, and edited the final video.
Prakrit (Pro Squad Member, Computer Science Major @ Purdue) Prakrit worked with Ethan to specify the Check!point architecture and implement the backend. Specifically, this included the API development and database management, as well as the data wrangling and visualization for the dashboard.
Ethan (Pro Squad Member, Senior Computer Science and Applied Mathematics Major, Physics Minor @ IUPUI) Ethan worked with Prakrit to specify the Check!point architecture and implement the backend. Specifically, this included the API development and database management, as well as the data wrangling and visualization for the dashboard.
Christian (Pro Squad Member, Senior Computer Science and Economics Major @ Rose-Hulman) Christian assisted Ryan in creating the front end of the system using React Native and its libraries. He also wrote the overview for this document.
Ryan (Pro Squad Member, Senior Computer Science Major @ Valparaiso University) Ryan developed the front-end of the Check!point application through React Native and libraries within React. He also demonstrated the front-end application.
How did you decide on this customer segment, problem, and solution?
Tasked with finding a solution to reliably monitor citizens of Indiana for COVID outbreaks, our team wanted to initially focus on developing a framework that would allow developers to build safe, secure, privacy-oriented technology solutions for their respective organizations. Whether that would be private business or state government, we thought this would be an interesting way to differentiate ourselves from other applications that focused on direct contact-tracing. However, with more research into what this framework would look like, we discovered the Google-Apple-Exposure Notification (GAEN) protocol, which looked extremely similar to our initial idea.
Armed with this knowledge, we started looking into a customer segment that might benefit from use of the GAEN protocol and landed on two key customers: state governments and small business owners. If we could build a solution that allowed effective contact tracing, the government could better manage COVID outbreaks and ultimately benefit small business owners as the pandemic comes to an end.
We realized the GAEN API lacked one key aspect of contact tracing: location monitoring. We hesitated to use GPS data, as it might not be as accurate as necessary while maintaining the privacy requirements we desired to have in our application.
So with these things in mind, we decided on a singular solution: a location-guided contact tracing system that identifies high-risk transmission areas without the use of GPS, that is intended to complement existing contact tracing solutions such as mobile proximity tracing applications, symptom tracking, or predictive data analytics.
How did your team build and iterate on the solution?
Most of our time was spent researching existing contact tracing protocols, finding ways to contribute to the current contact tracing efforts without being redundant and introducing fragmentation. We analyzed existing approaches and identified a niche where they were lacking, while keeping in the spirit of providing a secure and privacy-preserving system.
Afterwards, we decided on building a complementary system on top of the Bluetooth-based contact tracing protocols. The system should have a user-facing part where users can interact, and a backend part where the actual contact tracing happens. We divided up the team into two sub-teams: frontend and backend.
While the backend side designed the communication architecture, the frontend side developed a mobile application that would eventually connect with the backend. After a week, we shared the implementation details and connected the two sides together.
We then focused on getting the most use out of the system we developed, adding a heat map feature to it, while refining the security and communication issues present in our protocol. We wrote up a whitepaper for it, and put the demo to the test.
Please read the Checkpo!nt Whitepaper.
Checkpo!nt models a common structure used for Bluetooth-based contact tracing systems, in which devices communicate via Bluetooth packets and report to a backend server upon infection. Bluetooth packets contain device identifiers that rotate for every set period of time for privacy and security reasons.
Our system consists of three entities:
- Checkpoint: a stationary, offline device (initially planned to be a Raspberry Pi)
- Phone: a modern smartphone equipped with our Checkpo!nt application
- Server: a secure, public backend database
For clarity, we will divide how Checkpo!nt works into 3 main phases:
User discovery: Each checkpoint broadcasts Bluetooth packets to nearby users. Users collect the packets when they approach the vicinity of a checkpoint and store the packets locally on their phones.
Reporting infection: Once a user is tested positive for the virus, the user uploads all (exposed) Bluetooth packets collected to the server.
Exposure Notification: All users periodically download new (exposed) packets from the server and check if any of them match what they have stored locally.
If they match, that means the user has potentially been exposed. A notification will be generated on the user's device, along with further instructions.
At the same time, the server processes the uploaded packets for heat map generation.
Refer to the Whitepaper for technical specifications and more information.
Key Tools, Libraries, and Frameworks
- Flask: a Python library used for web app development.
- We decided to use Flask as our main development framework because of its ease of use and fast prototyping capabilities. We used Flask to build our backend API and the corresponding dashboard web app.
- Plotly/Dash: a library used for Interactive Data Visualization.
- We decided to use Plotly because of its interactive data visualization capabilities. We used it to build our Interactive Checkpoint heatmap, and then used Dash to integrate it with our Flask web app.
- Heroku: Hosting service.
- We decided deploy to Heroku since it was relatively easy, affordable, and appropriate for the current phase of our project.
- React Native
- We decided to use React Native because it was a simple method to develop a frontend for both android and ios with minimal compatibility issues.
- For final release, this library was found the most helpful to find other bluetooth devices and determine what type of device they were (Checkpoint, User Phone, other devices).
If you had another 5 weeks to work on this, what would you do next?
Another five weeks of intensive work on this product would allow us to accomplish the following:
- Interview small business owners within the state of Indiana to see what features would be most effective for them in managing their business in times of Covid.
- Further develop a method of generating revenue for the State of Indiana.
- Create a system to allow users to register stationary devices as checkpoints.
- More analytical tools and visualization capabilities:
- History Heat Map Slider: Our current application dashboard consists of a checkpoint heat map measuring proximity interactions with individuals who tested positive for COVID-19. To build upon this heat map, we would like to add sliders to help visualize the heat map at different 14 day windows. That is to provide users a visual heat map history of COVID-19 to help gauge its activity and spread.
- Region-Specific Exposure Time Series Plots: We would like to be able to group checkpoints together to provide data on specific regions (i.e county or group of city blocks) and provide time series plots on those regions. Then users would be able to compare the number of exposed interactions in one region compared to another within a time frame.
- Implementation of Machine Learning models to identify trends.
- Region-Specific Outbreak Detection and Forecasting: We have read promising research papers aimed at the detection and forecasting of outbreaks. Among them was an algorithm based on eigenspace factorization techniques. We would like to implement a variation of this to help predict regions where exposure activity might spike and help prevent them before they happen.
- Machine Learning Based User Exposure Warnings: Our current naive approach to notifications is to notify users if they have interacted with a checkpoint that has previously interacted with several infected individuals. However, we would like to make this component more sophisticated and implement machine learning models native to the user’s device, so that we can provide them with warnings to get tested based on their activity without compromising their anonymity.
- Improve upon the security and cryptography loopholes present in the current iteration of Checkpo!nt
- Figure out a way for Checkpo!nt to scale globally across multiple servers in multiple countries
We would like to thank TechPoint for this great opportunity this summer, and all those who gave up their valuable time to teach us during the weekly sprints and the other meetings that were held. We would especially like to thank our coaches, Kiki Liggett and Chris Riley, for their patience with us throughout the idea generation, and answering any questions we had, as well as keeping as focused. Hope everyone is staying safe!