How Color Built our COVID-19 Intake Product in a Week

In March, Color quickly mobilized our diagnostic genetics testing infrastructure to respond to the COVID-19 pandemic. While Color’s lab was developing our lab tests and validation, the product and engineering teams started to untangle what testing flows are needed in a pandemic of this magnitude. The speed and scale required to keep people safe is truly unprecedented in the diagnostic world.

For our first major launch, we first enabled provider ordering flows to support the new COVID-19 tests, but it quickly became clear this approach would not translate well to community COVID-19 testing sites. These flows were designed for use on a computer in a doctor’s office when seeing one patient at a time. To enable a more flexible approach, we opted to use a paper requisition form for each participant. With this approach, the clinician at the testing site writes down a patient’s information and contact details, and attaches a sticker with the sample’s barcode. This barcode is the essential link between the patient’s nasal swab and the patient. 

It’s important to note that at Color we focus on the simplest solution to the problem, which means only building products when we need to – and we soon encountered obstacles we didn’t anticipate in our second week of testing at San Francisco’s Embarcadero testing site. 

We were projecting to process hundreds of tests a day – the kind of volume that was sure to overwhelm our manual intake process. On Monday, April 6, we decided to digitize the information needed for sample collection based on our core genomics experience and existing technology designed for scaled testing at central sites.

Today, our intake application is a small but vital part of community COVID-19 testing, as patients only need to show their ID and clinicians simply point their barcode scanner after sample collection.

Why we built the app

Infectious disease testing is different from genetics testing – speed is paramount. The number of hours it takes to return infectious disease results can result in the crucial difference between an individual successfully quarantining or instigating an outbreak. 

With paper requisitions, our lab must wait until the sample is associated with a patient that provided consent and has physician approval. Waiting for piles of paper to process before processing samples would likely introduce massive delays.

In addition, manually filling out forms takes significant time and the transcription process is prone to errors. Our system relies on having accurate email addresses and phone numbers to return results to patients, but even the smallest typo meant patients wouldn’t get this extremely important information as soon as their results were ready.

We knew that the digital intake app would better equip our onsite clinical teams across all of our community testing sites. The web app, used by clinicians on an iPad, is preloaded with information provided by patients during the scheduling process. This enables clinicians at different testing stations across the site to rapidly check in an individual, review and edit information as needed, and scan the sample’s barcode.

There’s nothing overtly complex about what we built – it leverages our modern Django/React code base and uses restful APIs tied to our existing data models. However, this clean, seamless app has managed to have a large impact on our testing efforts.

How we built the app

Five engineers built the app in a single week. On Monday, April 6 at 12:30 PM, we made the decision to build the app and by 3:30 PM the initial design document had been drafted and circulated to the relevant teams. Critical decisions addressed how data flowed to our existing infrastructure, the core new APIs needed, and major separable components that had to be built. Our design team provided mock ups of the app less than an hour later and we got to work.

On Tuesday, we focused on authentication, which required a new permissioning system for the onsite clinical teams. We also developed the basic skeleton of the entire app, including the core new data model and new React routes. By Wednesday, we were fleshing out the front-end screens and constructing the APIs, which put us in a strong enough place to launch internal QA testing on Thursday.

After testing the app all morning, we made the decision at 1 PM on Thursday to refactor our internal data model. A few use cases – like patients who may be tested multiple times – made the existing model difficult to work with. We needed to think about the core model as appointments, instead of just per-patient data. Rather than hack on top of a less than perfect design, we decided to rewrite all of the models with the more suitable design. On Friday, our lab team tested the new version, allowing us to polish the UI and fix any remaining bugs on Saturday.

By the morning of Monday, April 13, our intake app launched at the Embarcadero testing site. It was just in time – we were averaging 600 tests a day only three weeks later, a number that would not have been possible with paper requisition forms.

What we learned

In this pandemic, there is an incredible amount of urgency, which isn’t an ideal environment in which to build a product. Software that has significant impact typically isn’t built in seven days. Traditionally, building a new product or experience requires space and time. We didn’t have ample time, but we did have a team that could be thoughtful, nimble, and quick to respond. Our team found three things that made the process more manageable and led to game-changing results:

– A strong and extremely detailed design document to start is paramount to a solid final product. Normally, this document is used just to flesh out the big concepts. However, in tight timelines, specifically outlining how the data, APIs, and front-end interface connect front-loads a lot of the work. This step is crucial to effectively breaking apart problems in tightly parallelizable work-streams.

– Working in tight pull request cycles helps keep the code as up to date as possible. Rather than working on large features all at once, we chose to work on smaller pieces of code and submit them more frequently. This enabled more engineers to work collaboratively and prevent constant code conflicts.

– Be in constant communication with the entire team. There is no such thing as over-communication for projects that have a tight timeline, particularly if the entire team is working from home. This means messaging before starting a task, messaging before merging, and messaging if something is missing. This consistent stream of communication keeps the coordination of the project on track, even when the team is physically separated — because of course we are all working remotely.

What it means for our work

Today, thousands of people stream through Color sites across the Bay Area each day to get tested, using Color’s consistent, seamless experience and the tool is now used by universities and businesses across the country. Over the last few months, the app has been deployed at our sites nationally and the feature set has greatly expanded.

Patients who are tested at a Color site might not even notice the app and just barely glimpse at the iPad it runs on. However, this app has allowed us to improve the throughput of sample collection, which means Color can help more people get the test results they need to stay safe. This small feature of Color testing sites, built in just a week, allows us to address public health challenges at larger and larger scales.

About Color

Color is a leader in distributed healthcare and clinical testing. Color makes population-scale healthcare programs accessible, convenient, and cost-effective for everyone. Color works with health systems, employers, and national health initiatives around the world including the million-person All of Us Research Program by the National Institutes of Health. For more information about Color and its response to COVID-19, visit www.color.com.