Why exposure notification apps rose or fell on the back office

The week

On April 10, 2020, Apple and Google, the two companies whose software runs almost every smartphone in the United States, announced a joint effort to enable Bluetooth-based contact tracing on iOS and Android. That spring, public health officials faced an old problem at a new speed.

Contact tracing, the practice of finding the people an infected person may have exposed and warning them before they spread the disease further, has been around for well over a century. It traditionally relies on interviews: a trained investigator calls a patient and asks who they have seen. With COVID-19 spreading fast, often before people had symptoms, and with many contacts being strangers on a bus or in a shop, interviews alone could not keep up. Many people wondered whether the phone in nearly everyone’s pocket could help.

The human side of tracing was already under strain. Around the same time, a widely cited plan from Johns Hopkins researchers and state health officials estimated that the United States needed on the order of 100,000 additional contact tracers. State and local health departments, many of them thinly staffed after years of tight budgets, were hiring and training people as fast as they could. Any tool that could reach contacts faster than a phone call looked attractive.

Bluetooth is the short-range radio that phones use to talk to wireless earbuds and car stereos. Because its signal fades quickly with distance, it can serve as a rough measure of whether two phones, and therefore two people, were close to each other.

The plan would come first through application programming interfaces for apps built by public health authorities, and later through capability built into the operating systems. An application programming interface, or API, is a defined set of instructions that lets one piece of software ask another to do something. Here, it meant a health agency’s app could ask the phone to handle the Bluetooth work on its behalf, using features ordinary apps were not allowed to use.

The announcement set out two steps. In May, the companies would release interfaces that let public health authorities’ apps work across both iPhone and Android phones. In the following months, they would build a broader Bluetooth-based capability into the operating systems themselves, so more people could take part by opting in. Alongside the announcement they published draft technical documents covering the Bluetooth specification, the cryptography and the software framework, and committed to publishing their work openly so others could analyze it.

The privacy design was the headline. Phones would exchange rotating random identifiers, strings of meaningless characters that changed regularly so that no one could track a particular phone over time. Exposure matching would be done on the device itself, with no central collection of location data or identities. In effect, your phone would keep a private diary of the random codes it had heard nearby. If someone later tested positive and chose to share their codes, your phone would check its own diary for a match. No government server would ever learn who had been near whom, or where.

Other countries had already shown how hard the problem was. Singapore had launched its TraceTogether app on March 20, using a design in which the health ministry could decode contact records when a user tested positive. Because iPhones restricted Bluetooth for apps running in the background, the app worked best when it was open on screen, which few people could manage all day. The operating system rule was a practical barrier that no public health authority could remove on its own.

Closer to home, a few US states, North Dakota among them, were rolling out apps that relied on phone location data rather than Bluetooth proximity. Location trails could show where an infected person had been, but they were a poor measure of who had been within a few feet of whom. They also asked residents to share far more about their movements than many were willing to. The Apple and Google offer arrived as a different bargain: less information for health departments, in exchange for a design residents might trust and phones would support.

In Europe, the argument over design was turning sharp. One consortium was promoting an approach in which a central server would do much of the work. A group of academics had published a decentralized protocol, known as DP-3T, which kept matching on the phone. Later in April, hundreds of researchers signed an open letter warning governments against centralized designs. European Union bodies were also issuing common guidance on how such apps should protect data.

During the week of April 13, governments and public health agencies around the world were weighing whether to use the framework or build their own centralized apps. In those, a central server would hold contact data and do the matching. The choice involved real trade-offs between privacy, public health insight and technical practicality. Within about two weeks of the announcement, the companies had revised the specifications and begun calling the effort exposure notification rather than contact tracing. The new name signaled what the system would and would not do. The companies released the interface to public health authorities on May 20, 2020. The design argument would soon settle. The harder work, as it turned out, lay elsewhere.

Take a resident of a mid-sized state in the autumn of 2020. She has heard about the state’s new exposure notification app, read that it does not track her location, and switched it on. One evening her phone tells her she may have been exposed to someone with COVID-19. She reads the message twice, unsure whether to stay home from work tomorrow, get tested and if so where, or call someone. The app says to follow public health guidance. She calls the hotline, waits on hold, and is eventually told by someone who has not been briefed on the app that she should probably talk to her doctor.

The Bluetooth and the cryptography in that story worked. What failed were the systems around the app.

For state and local health agencies, the Apple and Google framework arrived as a technical offer with a policy attached. Building on it meant accepting a decentralized design in which agencies never saw who had been near whom. Building against it meant fighting operating system limits on background Bluetooth, the restrictions phones place on apps using the radio in the background when they are not open on screen. Most US agencies that built apps accepted the framework, which settled the protocol and the privacy model. Three back-office systems remained in their hands. They were the verification step that let a positive case send alerts, the public health response an alert set in motion, and the adoption effort that determined how many phones took part. Those three, far more than the protocol, decided whether an app helped.

The analysis below starts with how the system worked, step by step, because the division of labor between platform and agency is visible only at that level. It then takes the three back-office systems in turn: verification, response and adoption. A final section weighs what rode on them, including the strongest case that the platform design itself was the problem.

Six steps, two of them the agency’s

Each step of the cycle shows where agencies had work to do.

1. Broadcasting. Every participating phone sends out a random identifier over Bluetooth every few minutes, and changes it regularly.
2. Listening. Every participating phone also notes the identifiers it hears nearby, along with roughly how strong the signal was and for how long. That list stays on the phone.
3. Testing positive. When a user tests positive, they can choose to share the keys from which their recent identifiers were generated. To stop pranks and false alarms, they first need a verification code from the health agency proving the positive test is real.
4. Publishing. The shared keys go to a server, which publishes them. The server receives no names, locations or contact lists.
5. Matching. Every participating phone regularly downloads the published keys and checks them against its own private list. If it finds a match that meets the agency’s rules for closeness and duration, it shows an alert.
6. Responding. The person who receives the alert decides what to do, guided by the agency’s message.

A few terms recur. Decentralized means the matching happens on individual phones, not on a central computer. Centralized designs, which some countries considered, send contact data to a government server to do the matching, which gives health officials more information but asks citizens for more trust. Privacy by design means building privacy protections into the structure of a system from the start, rather than adding policies on top.

Notice what the list says about who owns what. Steps one, two, four and five were largely handled by the framework. Step three, the verification code, and step six, the response, belonged to the health agency. And none of it works unless enough people do step zero: install the app or turn the feature on.

Why the operating system mattered

The platforms held the one thing no agency could build: permission to run Bluetooth reliably in the background on every phone without draining the battery. They attached conditions. Access went to apps from government public health authorities, and those apps could not collect location. Agencies that wanted the working radio had to accept the rules that came with it, which is why the design debate in the United States ended almost as soon as the interface shipped.

Inside the cryptography, briefly

The mechanics explain both the privacy and the limits. Each phone generated a new random key every day. From that daily key it derived the short identifiers it broadcast, which changed every few minutes along with the phone’s Bluetooth address, so no single identifier could be followed for long. Phones kept the identifiers they heard for about two weeks, then discarded them.

When a user tested positive and consented, the app uploaded only the daily keys covering the period when they might have been infectious. Other phones downloaded those keys, regenerated the identifiers each key would have produced and compared them with their own list. A match revealed that the two phones had been near each other on a particular day, but nothing about who the other person was or where it happened.

What the agency held, and what it did not

The design also shaped the agency’s records. The key server held anonymous daily keys that residents had chosen to upload, and published them. The verification system held records of codes issued, which could be tied to a positive case. Nobody held a list of contacts. That limited what a breach could expose, and it limited what a public records request or a subpoena could reach. Agencies still needed retention rules for the code records, and the shortest defensible period was the safest choice.

The settings the agency controlled

The agency did not write the cryptography, but it did choose the rules that turned a match into an alert. Bluetooth signal strength was grouped into bands that stood in for distance. The agency decided how much weight each band carried, how long an encounter had to last and how far before the positive test an encounter could count. Those settings decided how many alerts the system produced.

Every choice was a trade-off. Bluetooth signal strength is a noisy measure of distance. A phone in a back pocket, a body between two phones, a wall or a different phone model can all change the reading. Sensitive settings caught more real exposures and produced more alerts for people on the other side of a wall. Strict settings produced fewer false alarms and missed more real contacts. Agencies had to choose, usually with little local data, and ideally revisit the choice as evidence came in.

The verification step

To prevent false alarms, a user could only notify contacts after a positive test was verified. The agency issued a one-time code, and the user entered it in the app. That sounds simple. In practice it required a link between laboratory results and the people who issued codes. Some agencies sent codes by text message as soon as a positive result reached the state system. Others relied on case investigators to read codes out during interview calls, days later.

Timing was everything. An exposure alert is useful only while the contact can still avoid infecting others. Every day between a test result and a code reduced the value of the notification. Where laboratory reporting was slow, used fax, or lacked phone numbers, codes arrived late or never.

The fax machines were no exaggeration. Public health reporting in many places still depended on laboratories sending results by fax or in formats that had to be retyped. A result without a phone number cannot trigger a text message. A result that arrives three days late produces a code three days late, and an alert that may arrive after the window for preventing further spread has largely closed.

The numbers that mattered

The metrics that mattered were time from result to code, the share of positive cases offered a code, and the share who used it. Few agencies published them, and some did not track them at all. Without them, an agency could not tell whether its app was underperforming because people did not have it, because codes came too late, or because people who received codes chose not to use them. Each cause has a very different fix.

Privacy at the one point of contact

The verification step also carried privacy weight. The code system was the one point where the decentralized design touched identified health data, because issuing a code requires knowing that a particular person has tested positive. Agencies had to keep it minimal: no storage of who received alerts, short code expiry, and clear separation from case records. The code system should know just enough to confirm a test and then forget.

How the code systems worked

Google released open-source software for a verification server, and many US agencies used it or a hosted version. A staff member or an automated process requested a short code for a positive case. The resident entered it in the app, which exchanged it for a signed statement that the key server would accept. Codes expired quickly, so a code read out on a phone call and written on a scrap of paper could lapse before it was used.

Later designs sent residents a text message with a link that carried the code into the app directly, removing the typing step. Each design choice changed the share of residents who completed the process. Fewer steps meant more uploads, which meant more alerts for the people who had actually been exposed.

Securing the code portal

The code system had a security risk of its own. Anyone who could issue codes could trigger alerts, and a flood of false alerts would destroy trust in the system within days. The portal therefore needed the controls of any sensitive government system: named accounts for each staff member, multifactor authentication, limits on how many codes one user could issue, and logs reviewed for unusual patterns. Those controls had to be in place on launch day, when the pressure to get investigators issuing codes was greatest.

Measuring the code funnel

The verification step can be measured as a funnel with five stages: positive results received, results with a usable phone number, codes issued, codes used to upload keys, and alerts generated on other phones. The last stage is visible only in aggregate, if at all. Each drop between stages has a different owner. Missing phone numbers belong to the laboratory reporting team. Codes not issued belong to the case investigation managers. Codes not used belong to the communications team, which shapes how residents feel about sharing.

A health commissioner shown that funnel weekly can direct effort where it matters. One shown only the number of app downloads cannot.

The laboratory data problem

The verification step could only be as fast as laboratory reporting. Electronic laboratory reporting, in which labs send results to health departments in structured messages, was well established for many labs but uneven for the flood of new testing sites in 2020. Test orders often lacked a patient phone number, because nobody had needed one for reporting before. As home testing spread in 2021 and 2022, more positive results never reached a laboratory reporting system at all, and some states added ways for residents to report a positive home test themselves. Each new path for a positive result had to be connected to the code system, or it produced no alerts.

Who issues the codes

Staffing the step was a workforce decision as much as a technical one. Where codes depended on investigators, every investigator needed training, a script and access to the code portal. When case volumes surged, interviews were triaged and code issuance slipped first, because it looked optional next to clinical questions. Agencies that automated issuance protected the step from exactly that pressure. Those that could not automate it needed a rule that every positive case reached by phone was offered a code, with compliance checked weekly.

Suppose a county health department starts by having investigators read out codes at the end of interview calls. When cases spike, investigators shorten calls to the clinical essentials and the code gets dropped. The app’s usefulness falls just when it is needed most. A better app would not help. The fix is an automatic text message triggered by the laboratory result, or, failing that, a firm rule and a weekly check.

The public health response

An alert told a resident they might have been exposed. What happened next depended on decisions the agency made: whether the resident should quarantine, test or call a hotline, where they could get a test quickly, and whether a contact tracer would reach out. Alerts with vague advice and no route to testing produced anxiety without action, and undermined trust in both the app and the agency.

This is the part of the system most easily overlooked, because it does not look like technology. But the alert is only the first sentence of a conversation. If the rest of the conversation is missing, residents learn that the app makes them worried and nothing more, and they switch it off.

Measuring the response

Agencies also needed some way to see whether alerts led to action. Direct tracking was ruled out by design. Indirect measures were available. Hotlines could ask callers whether an alert had prompted the call. Testing sites could ask, without recording identity, whether the person had received a notification. Neither measure was precise, but both showed whether the response chain was being used, and both cost almost nothing to add.

Fitting alongside human tracing

The app also had to fit alongside human contact tracing, which remained the main response. Messages from the two programs needed to agree. Call centers needed scripts for residents who had received an alert and wanted advice. Testing sites needed to accept people who arrived because of a notification. Each of these was an operational commitment owned by a different team, and each had to be ready before launch.

That last sentence describes a classic coordination problem. The app team, the call center, the testing program and the contact tracing team often reported to different managers and worked from different plans. A launch that is a success for the app team can be a surprise for the hotline. Someone senior has to own the whole journey from alert to action.

Across state lines

Residents who live near state lines raised another question. A person exposed in a neighboring state might receive an alert based on that state’s settings and advice. Agencies needed to agree which guidance an alert carried, and their hotlines needed to handle callers from elsewhere without turning them away. Small inconsistencies of this kind were exactly what eroded confidence in the system.

Writing the alert, and keeping it current

A useful alert answered a short list of things. It gave the date of the possible exposure, what to do now and for how long, where to get a test, and who to call. It also explained, briefly, why the resident could trust it without knowing who the other person was. Each element depended on policy that changed. The CDC revised its quarantine guidance more than once, including in December 2020, when it offered options to shorten quarantine with testing. Vaccination later changed the advice again for many people.

Every revision meant updating the alert text, the hotline scripts and the website at the same time. Agencies that kept the alert text under the same change control as their public guidance avoided contradicting themselves. Those that treated the alert as part of the app, changed only when the app was updated, could end up telling residents something the agency no longer advised.

What the agency did not control

Whether a resident acted on an alert also depended on things outside the agency’s reach. A worker without paid leave, or whose employer did not accept an anonymous alert as a reason to stay home, faced a real cost in following the advice. Agencies could not fix that alone. They could brief large employers, schools and unions on what an alert meant and what the agency recommended. That made it more likely that the resident’s next conversation, with a manager or a school nurse, went the same way as the alert.

The adoption effort

Exposure notification works only if both people in an encounter have it switched on. Adoption is therefore the critical variable, and it depends on trust, ease of setup and perceived benefit. The arithmetic is unforgiving. If only a small fraction of residents take part, the chance that both people in any given encounter do is much smaller still, because the two fractions multiply.

The illustration is simple. If one resident in five has notifications switched on, only about one encounter in twenty-five involves two participating phones. If half of residents take part, the share rises to one in four. Doubling participation roughly quadruples the share of encounters the system can see. That is why adoption, rather than the precision of any single setting, dominated outcomes.

The privacy design helped with trust, but trust also depended on the agency’s own credibility and communication. Residents without compatible smartphones were excluded entirely, which raised equity concerns for communities facing some of the highest exposure risks. Older residents, people on older or basic phones and people who distrusted government for long-standing reasons were among those hardest to reach.

Setup mattered as well. Every extra screen, permission request or confusing choice between installing an app and turning on a phone setting lost some residents along the way. Clear, short instructions, tested on real people of different ages and languages before launch, were part of the adoption effort, not an afterthought. So was a simple answer to the question every cautious resident asked first: what exactly does this know about me?

Keeping people switched on

Participation did not stay where launch day left it. Residents switched notifications off after an alert they thought was a false alarm, when cases fell and the risk felt distant, or when they replaced a phone and did not set it up again. Each was predictable. Agencies that published regular, plain updates on how the system was doing, and reminded residents through other channels when cases rose, gave people a reason to keep it on. Agencies that went silent after launch watched participation drift down without knowing why.

Reaching residents the app could not

Equity was a design problem as well as a communication one. Residents without compatible phones could not take part at all, and many of them worked in jobs with high exposure and little ability to work from home. Agencies that kept human tracing and community health workers focused on those groups, rather than treating the app as a replacement, kept the overall system fair. Messaging in the languages residents actually spoke, through trusted community organizations, reached people that a statewide launch campaign did not. The app worked best as one channel among several, with the others funded on purpose.

Interoperability across state lines

Residents cross state lines to work, shop and visit family, so a state system that recognized only its own keys missed many encounters. A national key server, operated through the Association of Public Health Laboratories, let participating states’ systems share keys. A resident of one state could then be alerted about an exposure to a resident of another. Joining it was a technical step, and also a policy one, because it meant agreeing on how far a state’s settings and messages had to align with its neighbors’.

Different roles for different governments

• State health departments owned the apps, the settings and the key server connection, and usually the laboratory reporting system that fed codes.
• Large city and county health departments ran much of the human contact tracing. Their role in exposure notification was mostly codes and response: making sure their investigators issued codes and their hotlines knew the app.
• Universities and large employers did not run apps, but they could do much of the persuading, because they reached people the state’s advertising missed.
• The federal government did not build a national app. The platform and the states did that work, which left gaps in some states and duplication across others.

Running a consumer product

Agencies rarely run consumer products that rely on voluntary mass use. Marketing, translation, accessibility and user support needed budgets and named owners, just as the technology did. Partnerships with employers, universities and community organizations could reach groups that general advertising missed.

A private company launching an app would never assume that building it was the hard part. It would plan campaigns, test messages with different audiences, fix confusing setup screens and staff a help line. Public agencies, used to services people must use, such as filing taxes or renewing a license, did not always have that muscle.

Measuring what matters

Measurement also needed care. Download counts overstate participation, because they include phones where notifications were later switched off. Active-user estimates, where the platform made them available, were the better guide. A leader shown a big download number should always ask how many of those phones are still taking part.

What rode on the back office

For a governor’s office, a health commissioner or a city manager, the stakes were broad:

• Public health. Alerts that arrive fast and lead to clear action can help interrupt transmission. Late or vague ones do little.
• Trust. A tool that worries people without helping them damages confidence in the agency for future campaigns.
• Privacy and legal risk. The verification system is the one place identified health data meets the app; it must be tightly limited.
• Equity. A smartphone-only tool leaves some of the most exposed residents out, so other channels must remain strong.
• Money. Funding the app without funding verification, response and adoption buys a product that cannot deliver its purpose.

The three systems connect. Fast verification and a clear response make the app worth using, and higher use makes each alert more likely to reach the right people. Agencies that funded all three, with metrics for each, got more from the same protocol than agencies that funded the app alone. The skills involved, defining a data purpose, wiring a citizen-facing tool to slow back-office systems, and earning voluntary participation, recur in almost every digital public service.

The case for centralization, reconsidered

The strongest objection to this article’s argument is that the decentralized design itself was the problem. Because agencies never saw who had been near whom, they could not detect clusters, measure how well alerts worked or link an alert to a later positive test. Epidemiologists made this case in 2020, and it has force. A system that cannot measure its own effect is hard to improve and hard to defend at budget time.

The evidence still favors the back-office explanation. Countries that tried centralized designs ran into the same operating system limits and, often, weaker public trust. The United Kingdom tested a centralized app in May 2020 and switched to the Apple and Google framework in June. Meanwhile, the slow codes, vague alerts and low participation that hampered US systems would have hampered a centralized app just as much. Centralization would have given agencies more data, but not faster laboratory feeds or better-staffed hotlines.

Governance without a statute

Bills introduced in the Senate in the spring of 2020 to set privacy rules for contact tracing and exposure notification apps did not become law. In their absence, the platform rules, state privacy law and each agency’s own policies did the work. Some agencies wrote a short, public data statement for the app, covering what was collected, who could see it and when it would be deleted. That gave residents a concrete answer to the question that most affected their decision to take part.

How the contracts were shaped

Many states hired vendors to build their apps on the framework. A contract scoped to “deliver an exposure notification app” could be met in full while the back office went unbuilt. Laboratory integration for codes, hotline scripts, translation and marketing often sat with different teams and different budgets, or nowhere. A better scope described outcomes across the whole chain: time from result to code, completion of uploads, and participation, with named owners on the agency side for the pieces a vendor could not deliver.

Procurement speed mattered too. Emergency procurement let agencies move in weeks, which was essential. It also tended to produce short contracts focused on the visible product, with little room for the iteration that settings, alert text and onboarding screens needed once real residents used them.

A pattern that outlived the pandemic

The split between a platform that owns the front end and an agency that owns the back office did not end with exposure notification. States adding mobile driver’s licenses to phone wallets, and agencies offering benefits or payments through consumer platforms, face the same division. The platform supplies the secure, familiar interface. The agency still owns whether the data behind it is fast and correct, what happens when a resident acts on it, and whether residents trust it enough to use it.

An agency entering such a partnership needs the same three answers that exposure notification demanded. It needs a written split of which steps the platform owns and which the agency owns. It needs a measured time for its own data to arrive where the resident needs it. And it needs a named team ready for the resident’s next call. Leaders who worked through those answers in 2020 have carried an advantage into every platform partnership since.

The contract and the budget should follow the same split. Platform features arrive on the platform’s schedule and at little cost to the agency. The back-office pieces arrive only if the agency funds and staffs them, and they are where most of the work, and most of the risk, will be.

Two launches, one protocol

Suppose two state health departments launch on the same framework in the same month, with the same app design and similar populations.

The first treated the launch as a program rather than a product. Before going live, it wired its laboratory reporting system to send a verification code by text message to every positive case with a phone number on file, and it tracked how many hours that took. It wrote alert text that told residents in plain words to stay home, get tested and where to book a free test, with a hotline number staffed by people who had been briefed on the app. It funded a campaign in several languages, worked with large employers and universities to encourage staff and students to switch notifications on, and published a weekly dashboard of active users, codes issued and codes used.

The second put its effort into the app itself. It was polished and accessible. But codes were issued by investigators during interviews, often days after the result. The alert text said to follow public health guidance and linked to a general web page. The hotline had no script for app users. Its launch announcement reported downloads, and no one tracked how many phones were still taking part a few months later.

Both states used the same protocol, with the same privacy protections. Only one had built the three back-office systems that turn an alert into action. If the second state’s leaders asked why the app was not doing more, they would find the answer in the laboratory feed, the hotline and the marketing budget, rather than in the code on residents’ phones.

The failures are the mirror image: treating launch as the finish line, leaving code issuance to overworked investigators without a rule, writing alert text that said little, and reporting downloads as success.

The back office decides the next launch too

1. For any digital service we launch, which parts does the vendor or platform own, and which parts are ours?
2. How long does it take, from a triggering event, for the resident or customer to get what they need to act, and do we measure it?
3. When a resident follows the tool’s advice, are the call center, the service site and the human teams ready for them?
4. Are we reporting downloads or active users?
5. Who is left out by a smartphone-only approach, and how are we reaching them?

With hindsight

US states launched apps on the framework from the summer of 2020, and in September 2020 Apple and Google added a simpler option that let states offer notifications without building a full app. That option shifted even more of the technology onto the platforms, and in doing so made it clearer than ever that the agency’s job was the back office: codes, response and adoption.

Under that option, a state filled in a configuration with its name and logo, the criteria for triggering a notification and the information shown to people after an exposure. Maryland, Nevada, Virginia and the District of Columbia were among the first to work with it. Virginia had already become the first state to launch an app on the framework, in August 2020. The configuration fields were, in effect, a list of the back-office decisions this article describes.

Late in 2020 the platforms also added an optional analytics feature that gave agencies aggregate counts, such as how many notifications phones had shown, using privacy-preserving methods that did not identify anyone. It went part of the way toward answering the critique that decentralized systems could not measure themselves.

Adoption varied widely and was generally modest. Research on effectiveness produced mixed results, with some studies suggesting meaningful benefit where adoption was high. That pattern fits the arithmetic of exposure notification. The tool’s value rises steeply with participation, so modest adoption produces modest results, and the places that did better were those that persuaded more residents to take part. Most US state systems had been switched off by 2023.

The national picture stayed fragmented. Researchers later found that only 26 states released apps that made full use of the notifications, and most turned the system off after the federal public health emergency expired in May 2023. Where evaluations were done, they pointed to real benefit at higher participation. A study of Washington State’s system estimated that it prevented thousands of cases in its first four months. A peer-reviewed study of the app for England and Wales, published in Nature in 2021, estimated that it averted a substantial number of cases in late 2020, when participation there was relatively high.

The privacy design largely held up. The main flaw reported, in 2021, was in Android’s implementation, which wrote some exposure data to system logs that preinstalled apps could read; Google said it was fixing it. System logs are records a phone keeps of its own activity, mainly for troubleshooting. The episode is a useful reminder that even a sound design depends on careful implementation, and that independent scrutiny is valuable.

The harder problems were verification delays, unclear follow-up and uneven adoption, all rooted in overstretched public health systems. A better protocol could not have solved them. They were problems of data flows from laboratories, of staffing, of coordination between teams and of public communication.

The public health data modernization investments that followed the pandemic were in part a response to the weaknesses this period exposed. The CARES Act included $500 million for the CDC to modernize public health data surveillance and analytics, and the agency’s data modernization work continued in the years after. Much of that work targeted the same pipes that slowed verification codes: laboratory reporting, case reporting from health systems and the links between them.

What held up is the privacy design and the argument about the back office. What did not hold up is the early hope, common in the spring of 2020, that a well-designed app could substitute for capacity that health departments lacked. The tool amplified whatever capacity existed. Where laboratory feeds were fast, guidance was clear and trust was high, it helped. Where they were not, it could do little.

The general lesson concerns the back office. When a technology platform offers a well-designed digital front end, ready-made, the questions that decide success shift to the back office. They are how fast your data moves, what you tell people to do, who is ready to help them, and whether you have earned enough trust for people to take part.