How can we reduce the burden of contact tracing on our school nurses?
R2i2 is pleased to be a semifinalist in the 2021 Samsung Solve for Tomorrow competition! Our hybrid team consists of students from Next Energy Engineering, Computer Programming, and Mechanical Design classes. The following is a brief description of our team's progress in developing our Covid Contact Tracer (CCT). Due to the levels of community spread of COVID-19 in our area, we were only able to meet in-person on Fridays starting in February. Despite that short time frame, we were able to create a working prototype, thanks to careful project management and the contributions of our mentors.
Refining the Problem, Criteria, and Constraints Based on Research
Before in-person learning resumed on February 5th, we were hard at work, reviewing our initial problem submission, and identifying the deliverables we wanted to create during the project timeframe. For each deliverable, we brainstormed the criteria and constraints for our CCT to be useful in a school setting. We interviewed, the school district's lead nurse, Dawn MacAdams, to learn more about the specific challenges school nurses face when determining close contacts of a positive case. Specifically, we learned that identification of close contacts is heavily dependent on the infected individual remembering who they were in contact with in the past two days (prior to testing positive for COVID), and their memory of how close and for how long they were around that contact. Our conversation reinforced to us that our planned automation of the contact tracers with ESP32s could make a significant improvement to the contact tracing process.
We also researched existing technologies, such as contact tracing apps and Smart Watch extensions. What we discovered is that in addition to numerous technical challenges with use of individual phones (different operating systems don't always communicate distances consistently), cost and privacy challenges did not make those applications feasible for a school setting. After brainstorming potential workarounds, we revised our original constraints to include the limitation that the CCT can only operate on school grounds, and to use a secure database to protect student and staff health matters.
Prototyping the Solar Battery Charger and Wearable Case for CCT
Solar Battery Charger: The ESP32s we used for our CCT can operate with a rechargeable drone battery (3.7 V) as a power source. We created two solar battery chargers from repurposed materials to reduce the carbon footprint of our project, and to ensure that there were always charged batteries in the classroom, so users can swap them out as needed to keep the contract tracer operational at all times. We had battery hubs that would charge 5-6 3.7 volt batteries at one time, but we didn't know what types of internal circuits were inside, so we had to experiment to determine the amount of power needed. We tried several different solar cells with different power ratings, and found that the 6 volt panel with a step-up transformer in the USB port could charge both the 5 and 6 battery hubs. We predict that the hubs are wired in parallel series of two batteries, leading to a voltage requirement of 7.4 V.
3D Printed Wearable Case: To make the CCT mobile, the Mechanical Design team used Onshape to design and print a wearable case for both the ESP-32 and its battery. Initially, their plan was to incorporate a student's ID into the case, but as the students took measurements, they determined it would be more practical to create a separate holder that could be attached to a lanyard:
Setting up the IDE (Visual Studio Code) for Programming the CCT
With help from our technical mentor, Mr. Bullington, we identified libraries we would need from projects with microcontrollers doing similar tasks, which he graciously translated to Micropython and assembled on Github for our project. We set up Visual Studio Code as our IDE and flashed the firmware onto our ESP32s. We ran into some problems with deploying code onto the CCT, but eventually got our libraries on the devices. From our criteria and constraints, we determined that we needed the CCT to perform three basic tasks:
1. Connect to the district WiFi: The CCT needed to connect to WiFi in order to transmit information to a database. By limiting the device to only connecting to the district's guest network, we ensured that the device would only operate on school grounds, adding a layer of privacy to the operations.
2. Authenticate to Google Firebase: Once connected to WiFi, the ESP32 had to authenticate to Google Firebase, where our contact tracing data are stored in the cloud for the district nurse to access. Using a paired keys approach, we installed a keyfile on each of our CCTs to add an additional layer of security. Only devices with the keyfile can write to the Firebase.
3. Activate Bluetooth to Scan and Advertise to other CCTs: We used Bluetooth signal strengths to estimate the proximity distance of six feet. When Bluetooth is activated, the CCT scans for other ESP32s, and when one is detected within six feet, it transmits that interaction, and the time it occurs, as a tuple to Firebase.
Troubleshooting the CCT
We had to test different Bluetooth signal strengths (RSSI) to approximate six feet, so that the CCT would only callback to the Firebase when it had encountered another within range. (Note: since testing our prototype, the CDC has revised their guidance for elementary schools to allow for 3 feet of distance. Should that change who is defined as a close contact, we can easily reset the signal strength threshold for that approximate distance.)
We encountered some issues with the amount of data for both the Firebase and ESP-32. The ESP-32 model we were using only had 4MB of memory, so it would frequently stop working as that limit was reached. We had initially intended to set the reporting interval to the Firebase at 1 minute, but the slowest Bluetooth scanning speed for the ESP-32 was 20 seconds. Instead, we used a counter and modulus division to limit the callbacks to once every six times, which reduced the number of data entries being written to the Firebase, and made for easier interpretation on the nurse's interface. We wanted to leave the data in that minute form so that the nurse (or other contact tracing professional) could use his or her clinical judgment as to whether a person should quarantine.
The memory issue also led to the entire timestamp not being written to the Firebase at all times. However, when we used a different ESP-32 model with 16 MB, a lot of those timestamp issues were eliminated. We will use the newer models with more memory in our beta testing in April.