Considerations for Coronavirus Testing Website

Posted on by mukina

On March 13th, during the White House Rose Garden address, President Trump informed us that there is a Coronavirus testing site under development. He mentioned that Google is developing such a site. It felt like a good choice. Google has US and Worldwide presence with millions of consumers (aka citizens) on its accounts (thanks to gmail and Android distributions). Definitely they can quickly whip up a few Kubernetes clusters with python and deploy to Google Cloud Platform. 

It was possible for such a site will be up and running by midnight of March 13th. It did not happen! I wondered why. There are additional issues written about in New York Times. 

Note that there are some helpful tips from CDCif someone is sick. The big challenge is how to get tested across the United States. There are security, scale, integration, and routing challenges. 15 years back I was fortunate to lead an effort with a talented set of engineers and business professionals to build a donation site for helping people affected by Hurricane Katrina. In 20 hours we built a donation site that collected nearly $13.5M in donations over the next 5 days. 

I spent some time considering additional technical challenges and issues. Below is a quick summary of some inputs in identifying building blocks to get to the final solution.

Requirements

  • Handle 300M+ users or at least 100M+ families/groups
  • Handle concurrent registration of 1000+ users registered per second
  • P99 response time for key experiences under 5 seconds
  • High security and compliance for personal information 

Data Items to Consider

Semi-Static Data

  • Symptoms and Assessment Scores
  • Sites offering Testing (mostly Drive throughs)
    • Drive Throughs to be provided by Walmart, Target, CVS, Walgreens, et al.
    • Sites that local Public Health departments offer
    • Regular clinics and hospitals

Dynamic Data

  • Load at each test site (useful for routing)
  • Wait time at each test site (reduced wait time)

Per-User Data

User data easily can be shared across 100s of data stores to reduce latency, increase availability, and performance. 

  • User Information (contact information, age, any pre-history, travel-history)
  • User Location
  • Test Status
  • Test Result
  • Fraud checks

Some key methods

  • ScoreSymptoms( userLocation, symptoms)  // can be stateless calculator 
  • IsCoronavirusTestingRequired( userInfo, userLocation, symptoms)
  • NearestSitesForTesting( userInfo, userLocation, isTestRequired)   // return sites with rank order on proximity and low wait times
  • ScheduleVisitForTest( userInfo, userLocation, testLocation) // gives a token for user to present at test site
  • CheckinForTest( userInfo, scheduleToken, testLocation) // get a testingToken for tracking purposes
  • PostResultsForTest( userInfo, testingToken, testLocation, testResults)
  • viewTestStatus( userInfo) // will provide status and when available the results as well

Actors

  • Citizen – end-user / family
  • TestSiteAdmin – dedicated admin per site (most likely a group with rotation of people)
  • TestSiteOwners – companies / individuals who offer the TestSites (ex: Walgreens for offering its drive-through locations)
  • TestProvider – who runs the tests and provides results (ex: Government Labs, LabCorp, Quest Diagnostics)

Modules

  • Website – front-end experience for each actors (role based control or dedicated website for each party)
  • Accounts – handles identity, logins, userInfo, anti-fraud, etc.
  • SymptomManager – helps with scoring symptoms for test requirement
  • SiteManager – enables TsetSiteAdmin and TestSiteOwners to manage their sites
  • TestProvider – manages test collection, routing, testing, and reporting results
  • StatusManager – per-user, per-site, and per-provider status management
  • Administration – security and compliance management, Reports, Configurations, etc.
  • TrafficManager – marketing function to ensure that this site is discoverable and linked to from all sources.
  • DataStores – sharded and scalable data store for transactional and bulk reporting purposes.

Additional APIs/Resource to Consider

  • Google Maps
  • API management service (apigee, …)
  • OpenTable style reservation system for Testing Sites
  • Sharded / Scalable User Authentication (reuse existing infrastructure at Google, Amazon, Facebook, Okta ?)
  • Sharded / Scalable User Data Store (userInfo, userLocation, profile
  • Edge Security 

Definitely there are a LOT of items pending to be discovered and built out. This is a good start and something that we can iterate from.

Leave a comment