When Your Case Counts Don't Match Lab Results: A 5-Minute Reconciliation Checklist

You pull the weekly line list. Cases: 847. Lab positives: 912. That's 65 ghost cases—or maybe you're missing 65? Depends on how you read it. This isn't a bug; it's the norm. Every surveillance system leaks. The question is: does the leak matter?

Here's a 5-minute checklist built from chasing mismatches at state health departments and hospital systems. No theory. Just what you check first, second, and third when the numbers don't dance.

Where This Bites You in Real Work

Surveillance vs. lab data in weekly sitreps

Monday morning. The Epi team pulls the line list. Lab has 142 positives for influenza A. Surveillance case count? 89. That gap is not a rounding error — it's a four-hour argument that kills your morning. I have seen this play out across three different health departments: someone from comms demands one number for the press release, the epidemiologist defends the clinical case definition, and the lab director shrugs because both counts are technically correct. The result? A sitrep that hedges so aggressively nobody trusts it. That hurts.

The real bite comes Tuesday. A school cluster investigation opens, and now you need a single source of truth. Lab says 15 students positive. Surveillance says 11 meet the probable case definition. Which number drives the closure decision? Wrong order here — picking the lab number without checking the symptom onset dates — and you might close a classroom while viral shedding is still humming. I have fixed this exactly once: we forced a Monday 9 AM reconciliation window, no exceptions, with a shared column for "reason for discrepancy." It worked for six weeks. Then staffing changed and the column went blank.

Hospital outbreak reconstructions

A foodborne illness cluster lands in the ICU. Three patients, same restaurant, same stool culture result. But the hospital's internal case log shows zero Salmonella entries for that week — because one patient's chart was coded as "gastroenteritis, unspecified." The epidemiologist reconstructing the outbreak finds this mess two months later, during a federal audit. The odd part is: the lab results were there the whole time. A mismatch between a hospital's syndromic surveillance and its microbiology database creates a phantom gap that looks, to an outsider, like a data quality failure. It's not. It's a codebook failure.

Most teams skip this: verifying that the case definitions used by the lab and the hospital's infection control team actually align. That mismatch alone cost one facility fourteen hours of manual chart review. They found the missing cases, sure. But they also found a second cluster nobody had noticed — because the lab's serotyping flagged it, and the surveillance system never saw it. So the reconciliation wasn't just a cleanup. It was an early warning that had been sitting in the database for forty-three days. Not yet. That comes later.

The catch is that outbreak reconstruction depends on timing. If you reconcile too late, the epidemiological curve looks flat. If you reconcile too early, you miss delayed lab confirmations. I have watched teams reconcile on a Thursday only to have seventy new lab results roll in Friday afternoon — and nobody reopens the reconciliation until the next sitrep. That seam blows out.

Cross-jurisdiction case transfers

Patient lives in County A, works in County B, tested at a clinic in County C. The lab result goes to County C's system. County A's surveillance team never sees it. County B assumes someone else has it. Three weeks later, the state health department notices a case count mismatch of nearly forty percent for that region. The reconciliation checklist? Empty. Because nobody owns the handoff.

'The hardest part isn't the data — it's deciding whose data gets to be right today.'

— state epi manager, after a six-week cross-jurisdictional audit

What usually breaks first is the case transfer protocol. Some jurisdictions use a shared server. Others rely on email attachments with Excel timestamps. A few — and I mean this — still fax hard copies. The lab result moves fast; the case adjudication moves at the speed of a committee. That gap is where your weekly count falls apart. One county I worked with reduced their mismatch rate from twenty-three percent to six percent simply by adding an automated query that cross-walked lab zip codes against residence zip codes every night. A six-line script. No new staff. No budget request. Just a willingness to admit that the old workflow was silently eating cases.

The trade-off: automated cross-walking catches duplicates but also introduces false matches — a person with the same name and DOB as a sibling, for example. You gain speed, then you lose an hour untangling the false positives. That's the rhythm. It never goes away. You just decide which kind of headache you can tolerate this quarter.

Why They Confuse: The Usual Suspects

Case definitions vs. lab criteria

The most seductive trap in reconciliation is assuming a case definition and a lab criterion measure the same thing. They don't. A case definition is a human decision—a composite of symptoms, exposure history, and sometimes lab confirmation. A lab criterion is a machine result: a Ct value, a serological cutoff, a CFU count. I have seen teams spend six hours chasing a 12% gap that boiled down to one simple fact: the clinical team classified a probable case based on radiographic findings, while the lab system only accepted PCR-positive records.

The gap widens when case definitions change mid-outbreak.

Health departments update their criteria in real time — adding loss of smell one week, removing fever thresholds the next. Labs don't adjust retroactively. So your line list shows 300 confirmed cases; your lab information system shows 190 PCR-positives. That's not a data error — it's a definitional wedge. The fix is not cleaner matching; it's a documented translation layer that maps each case classification to its constituent lab evidence.

Most teams skip this.

They write a SQL join on patient ID and call it reconciliation. Then they wonder why the numbers diverge every Wednesday. The root cause: one system says "probable," the other only knows "positive." You need a crosswalk — not a better query.

Reporting lag and right-censoring

Your Monday morning situation report shows 78 cases. The lab system says 112 results were finalized that same day. Panic ensues. But the real pattern is simpler: the lab reports by test completion date, while the case surveillance system reports by diagnosis date. A patient tested Thursday, confirmed Friday, and diagnosed Saturday will appear in different buckets depending on which timestamp you trust. The mismatch is not error — it's temporal friction.

Right-censoring makes this worse.

Patients tested in the last 48 hours have not yet been assigned a case classification, so they vanish from the epi curve but sit visible in lab results. I fixed one city's dashboards by adding a simple rule: never compare counts from windows shorter than three incubation periods. Before that threshold, the lag is just noise. After it, you get signal. That sounds obvious, but I have watched epidemiology teams burn two weeks building automated alerts that fired every time Tuesday's lab total exceeded Monday's case total. Wrong comparison. Every time.

Reality check: name the epidemiology owner or stop.

Reality check: name the epidemiology owner or stop.

The odd part is—many software tools encourage this error by default. They show "Results in the last 7 days" without flagging that case investigation takes 2–5 days to complete. The dashboard says reconciliation is failing. The truth: you're just looking too early.

'We spent a month trying to explain away a 30% gap. Turned out the lab counted by specimen collection date; we counted by report date. The gap was exactly 48 hours of lag, repeated every day.'

— surveillance manager, state health department

Duplicate records across systems

Duplicate records are not random. They follow predictable patterns: hospital A sends a patient to hospital B for a second opinion — both labs run the same test. Or a private lab reports a positive directly to the health department while also sending it through the hospital's laboratory information system. Two records, one person, same result — but your reconciliation logic double-counts it.

What usually breaks first is the deduplication logic itself.

Match on name and date of birth? A John Smith born 4/15/1981 appears in three separate labs with identical results. Your merger keeps all three because the system sees different submitting facilities. That's not a merge failure — it's a design gap. You need a unique person identifier, not probabilistic matching on demographics. Until you have that, expect the duplicate count to hover around 5–8% of any weekly reconciliation.

Not yet at the identifier stage? Then impose a hard rule: for any reconciliation period, flag all records that share a name, a test type, and a result value within a 24-hour window. Flag them as potential duplicates and exclude them from the raw comparison. Then count them separately. It won't fix the seam — but it stops the seam from blowing out your weekly report.

Start there. Fix the crosswalk tomorrow.

Patterns That Usually Work

The 24-hour rule

Most mismatches die within a single calendar day. I have watched teams chase phantom duplicates for hours only to discover that case A was entered at 11:47 PM and the lab result posted at 12:03 AM the next morning — different dates, identical infection, zero discrepancy. The rule is boring and effective: if the case date and the lab result date are within 24 hours of each other, flag them as a probable match and move on.

The catch is time zones. A nasal swab collected at 4 PM Pacific gets a result timestamp stamped in Eastern — suddenly your 24-hour window looks like 27 hours. So adjust the rule: use the lab collection date, not the result date, and compare the patient’s local calendar. That shrinks the false-positive seam.

You still miss some. But you save 80% of the manual lookups. Good enough for Monday morning triage.

Dedup by name+DOB vs. identifier

SSN-based matching sounds clean until a patient transposes two digits or a registrar fat-fingers the entry. Then you have two records for the same person, each carrying a positive lab, and your case count inflates by one. The fix: run a name+DateOfBirth match before you touch the identifier.

Most teams skip this. They go straight to the medical record number because it feels precise — but precision without tolerance is brittle. Name+DOB gives you a soft cluster. Then, within that cluster, the identifier confirms the tie. Wrong order.

One concrete example: a 62-year-old woman with a hyphenated last name had three separate case records because the lab system and the surveillance system handled the hyphen differently. The identifier was missing on one record. Name+DOB caught all three in under a second. That single fix cut our weekly reconciliation time from 90 minutes to 12.

The trade-off? Name variants still slip — nicknames, typoed middle initials, a kid who aged into a different DOB format. So flag the cluster, don’t auto-merge. Let a human review the top 5% of suspicious hits. That hurts less than a full manual line-by-line.

Using lab collection date not result date

What usually breaks first is the timestamp everyone sees first. The lab result date is the one that prints on the report, the one the doctor clicks, the one that lands in the surveillance feed at midnight. But the collection date — the moment the swab actually touched the patient — is the epidemiologically meaningful anchor. Using result date shifts cases into a later bucket, and suddenly your Monday case count is empty while Tuesday overflows.

We reconciled by result date for three months before someone noticed our outbreak curve lagged the clinical picture by two days. Swapping to collection date fixed the delay overnight.

— Senior epidemiologist, county health department debrief

How to implement: pull the collection date from the lab HL7 message or the electronic lab report field OBX-14. If that field is empty, fall back to the specimen receipt timestamp — still better than result date. Then build a simple decision tree: if case onset date and collection date differ by more than 48 hours, escalate for review; otherwise treat them as a single episode.
A rhetorical question that matters: does your team even have access to the collection date? If not, that's your next configuration change.

None of these patterns are perfect. The 24-hour rule will false-match a patient with two genuine illnesses 36 hours apart. Name+DOB will still miss the kid who goes by his middle name. And collection dates can be missing in batch uploads from old fax-based labs. But perfect is the enemy of done — apply the heuristic, review the edge, ship the reconciliation. You can tighten later.

Anti-Patterns: How Teams Make It Worse

Aggressive dedup that kills true matches

I once watched a state team run a deterministic dedup across two surveillance systems — same last name, same DOB, same ZIP — and then quietly delete 14% of their records. The problem? One system truncated names at 15 characters. Another used the patient's address at time of specimen collection, not residence. So "Washington" vs "Washingt" plus a ZIP that differed by one digit meant the algorithm declared them duplicates and dropped the lab-confirmed case. The team celebrated a cleaner dataset. They actually lost 200 true positives. That hurts.

Flag this for epidemiology: shortcuts cost a day.

Flag this for epidemiology: shortcuts cost a day.

The odd part is — they never checked the discard log. Most health departments don't. They assume dedup logic is symmetric, that if system A matches system B then system B matches system A the same way. It isn't. Sensitivity swaps when you join on different fields. A fuzzy match that works in one direction can vaporize matches in reverse. And when you dedup aggressively — requiring exact match on three fields — you throw away the cases that matter most: people who moved mid-outbreak, or got tested under a temporary ID. The catch is that exact-match dedup feels safe. It feels rigorous. But it introduces a systematic bias against mobile populations, which are exactly the groups outbreaks hit hardest.

"We deduped away the entire homeless shelter cluster because their addresses changed each week."

— Epidemiologist, county health department, after a norovirus investigation

Stop doing that. Instead, run a probabilistic match that logs discards. Then spot-check one percent of the dropped records. You will find your own 14%.

Ignoring lab test characteristics (sensitivity and specificity)

Most teams reconcile case counts as if every lab result is equally trustworthy. It isn't. A PCR test with 99% specificity sounds great — until you run 10,000 tests. Then 100 false positives leak into your case line list. Your reconciliation blindly counts them, your suspect cases jump, and suddenly your attack rate looks like a crisis. But it's just noise.

What usually breaks first is the assumption that a positive lab result = a true case. That holds only when prevalence is high. In low-prevalence settings, even a 98% specific test generates more false positives than true positives. I have seen teams spend three weeks reconciling a "cluster" of 40 cases that turned out to be 38 false positives from a single reagent lot. The real signal? Two actual cases, buried. They missed the outbreak window.

The fix is low-tech: stratify your reconciliation by test type and date. Flag any sudden jump in positives from a single lab batch. Run a quick positive predictive value calculation — PPV = (prevalence × sensitivity) / (prevalence × sensitivity + (1−prevalence) × (1−specificity)). That equation is not optional. If your PPV drops below 0.7, stop reconciling and investigate the testing pipeline first. You're chasing ghosts.

Assuming one system is 'truth'

This is the quietest bias of all. A team decides that the electronic lab reporting system — because it's automated — holds the authoritative count. Then they "correct" the surveillance system to match. Wrong order. The surveillance system often carries context the lab never captures: symptom onset dates, exposure history, clinical severity. Replacing those fields with lab-only data strips the epidemiological signal.

I once saw a state team overwrite 400 onset dates with specimen collection dates from the lab system. Onset moved back an average of 2.3 days. The epidemic curve flattened artificially. Their outbreak response shifted two days late. Not a data error — a data choice, and a bad one. The trap is that automated data feels objective. It feels like a clean source of truth. But it only measures what it measures. It doesn't measure symptom onset. It doesn't measure exposure setting. Lab systems are not wrong — they're just narrow.

The better pattern: treat reconciliation as merging two imperfect views, not correcting one with the other. Keep both timestamps. Flag discrepancies, don't resolve them by fiat. And never, ever use one system's missing data as license to delete the other system's present data. That seam blows out your temporal accuracy, and you never get it back.

Maintenance, Drift, and Long-Term Costs

Automated reconciliation scripts that rot

The first fix most teams reach for is a SQL script or a scheduled Python job. Six months in, that script silently stops working. Why? Someone on the data team upgraded a library, the lab feed switched from HL7 v2.5 to FHIR, or a column name changed from 'specimen_type' to 'sample_type'. I have seen a perfectly good reconciliation pipeline fail because the lab vendor added a trailing space to their patient IDs. The script didn't break loudly — it just started matching 82% of rows instead of 98%. Nobody noticed for three weeks. The catch is that automated reconciliation is never fire-and-forget. You need a heartbeat monitor: a daily count of mismatches, a weekly spot-check of 20 random rows, and someone who actually reads the alerts.

That sounds fine until the person who wrote the script leaves.

Staff turnover and knowledge loss

The person who built the original reconciliation logic understood exactly which fields on the lab side were reliable and which were garbage. They knew that 'collection_date' in the EMR was actually the date the order was placed, not the draw date. They knew the lab used 'NA' instead of NULL for missing results. Then they left. The new analyst sees a mismatch report and assumes the system is broken — so they "fix" the mapping by aligning dates directly. Now your daily reconciliation rate looks perfect, but the actual clinical data is quietly wrong. We fixed this by keeping a living decision log: a one-page document, updated every time someone touches a mapping, listing every known exception and exactly why it exists. It's not glamorous work. It beats re-learning every painful lesson from scratch.

Most teams skip this. Then they repeat history.

Changing case definitions over time

Public health case definitions evolve. A COVID-19 confirmed case in 2020 required a positive PCR. By 2022, antigen tests counted. By 2023, the CDC dropped some reporting requirements entirely. Your reconciliation logic — which compares case counts from the disease registry against lab-reported positives — needs to know the date each definition was active. If your script still uses the 2020 rule for 2024 data, every count will be off by 200 cases. The hard part is that nobody sends you a memo when the definition changes. You have to subscribe to the right bulletins, set calendar reminders for annual review cycles, and treat case definitions as a configuration parameter — not hard-coded logic. I learned this the expensive way when our team spent three days digging into a "data quality problem" that was actually just us using last year's rule set.

‘Reconciliation is not a project you finish. It's a process you maintain — like changing the oil.’

— surveillance officer, state health department, after her third remapping cycle

Budget for this from day one. Set aside 10% of your analytical time for maintenance: checking feeds, re-testing scripts, updating definitions, and documenting what you changed. That seems steep until you price out the alternative — three days of fire drills every quarter, lost trust from clinicians, and the slow grind of watching your data quality decay month by month. Put a calendar reminder for the third Friday of every quarter. Name it "reconciliation checkup." Skip it once and you will never catch up.

When You Should NOT Reconcile

Deliberate sentinel surveillance vs. full case count

Sometimes the mismatch is the point. I have sat through tense meetings where a program manager insisted the lab positives and case counts must match perfectly—only to discover the surveillance system was intentionally filtering. Sentinel sites, by design, capture only a fraction of real cases. They trade completeness for depth: richer clinical data, faster turnaround, lower cost per report. Forcing a reconciliation here would destroy the very signal you built the system to catch. The catch is—your stakeholders may not know they're looking at sentinel data. The dashboard says 'confirmed cases' without the asterisk. That's a labeling failure, not a reconciliation problem. Fix the metadata, not the numbers.

Wrong order.

I once watched a team spend two weeks aligning a cholera surveillance dataset with hospital lab records. The mismatch was 300%—by design. The surveillance system only captured severe, culture-confirmed admissions from three sentinel hospitals. The lab records covered all suspected diarrheal cases across twelve facilities. The numbers were never meant to converge. The real fix took ten minutes: rename the variable from 'total cases' to 'sentinel surveillance cases (severe only)'. No one wants to hear that. But the cost of false reconciliation—adjusting lab denominators or backfilling phantom cases—was a data set no one trusted later.

Odd bit about epidemiology: the dull step fails first.

Odd bit about epidemiology: the dull step fails first.

Outbreak investigations where counts don't matter

In an acute outbreak, reconciliation is a distraction. Your job is not to make the line list match the lab database; your job is to find the contaminated well, the unvaccinated cluster, the single wedding reception where everyone got sick. I have seen teams burn three days trying to resolve a 12-case discrepancy while the attack rate climbed. Stop. The direction of error matters more than the exact number. Are you missing cases or double-counting? Is the lab lag masking the true peak? That's the signal. The precise total can wait until the response phase ends.

Not yet.

Here is a concrete rule of thumb: if your reconciliation takes longer than the investigation's action cycle (usually 24–48 hours in a fast-moving outbreak), shelve it. You're optimizing for precision at the cost of timeliness. The outbreak team needs a working estimate—plus a note that the numerator is likely an undercount. One team I worked with printed the reconciled total in gray font and the rough estimate in bold black. They updated the gray number once a week. No one complained. Because everyone knew: the black number drove the response.

When mismatch signals a real data quality issue (not a fix)

The odd part is—some chasms between case counts and lab results are not reconciliation problems at all. They're early warnings. A sudden, sustained gap that emerges after months of stable alignment usually means something broke: a lab reagent shortage, a change in reporting software, a clinic that stopped submitting swabs. If you rush to reconcile by adjusting denominators or applying correction factors, you mask the root cause. The gap is the message. Listen to it.

'We spent a month building a correction formula. Then we found out the lab had stopped testing on weekends. The formula just hid the schedule change.'

— Senior epidemiologist, Southeast Asia field office

That hurts. The rule I follow now: if the gap is >20% and growing, investigate before you reconcile. Trace the lab pipeline—sample collection, transport, testing, result entry. One broken ice machine in a tropical clinic can explain a 15% drop in positive results. No software fix for that. The action is not reconciliation. The action is a phone call to logistics.

So when do you walk away? When the mismatch is stable, explained by design, and the cost of alignment exceeds the value of the insight. Sentinel surveillance. Outbreak sprints. Broken specimen chains. In those cases, your job is different: document the gap, label it clearly, and tell your audience what the number actually represents. Then move on to the investigation that matters. The next outbreak won't wait for your pivot table to balance.

Open Questions and FAQ

Can we trust lab results over case reports?

Short answer: not automatically. I have seen teams assume the lab is the ground truth — then spend weeks chasing a data-entry bug in the specimen-tracking system. Lab results carry less recall bias than case reports, but they carry their own noise: batch effects, reagent lot changes, and the fact that a positive PCR can pick up non-viable fragments weeks after infection. Case reports, meanwhile, catch symptom-onset dates a lab never sees. The trade-off hits hardest when you reconcile counts for respiratory season — case reports might capture mild illness the lab misses, but they also double-count people who call two hotlines. The real question is not which source is "right." It's: which error type can you tolerate in your specific decision window? If you need high recall for outbreak detection, tolerate lab false negatives. If your resource allocation depends on precision, lean case-side and accept you will miss some early signals.

Most teams skip this nuance. That hurts.

What if the mismatch is seasonal?

Seasonal mismatch is the most common trap, and it usually looks like a systematic offset that appears every January and vanishes by March. The culprit is often denominator drift — school calendars alter health-seeking behavior, holiday staffing changes case-report timeliness, and lab surge capacity varies. We fixed this once by overlaying a 7-day moving average of submission delay onto the reconciliation table. Turned out the lab was two days slower in December but the case-reporting system kept its cadence. Match rate dropped, but the underlying disease signal was stable. The pitfall is overcorrection: if you adjust seasonal weights every month, you risk smoothing away a real outbreak. A better pattern is to flag seasonal discrepancies but hold the reconciliation threshold constant — then investigate the residual outlier weeks specifically. That forces your team to explain one bad week rather than re-jigger the whole algorithm.

The odd part is — nobody documents this seasonality drift. Then the next analyst inherits a black box.

How do we handle probabilistic matching?

Probabilistic matching sounds elegant — let a score decide if record A and record B are the same person. In practice, the threshold choice is the knife edge that either floods your queue with false links or hides true duplicates. I have watched a team set their match threshold at 0.90 "to be safe" and miss 12% of actually matching pairs because names had middle-initial variations. Two weeks later they flipped to 0.75 and matched a father and son who shared a birth year typo. The anti-pattern is treating the score as a truth value rather than a probability you can interrogate. Instead, run a weekly audit: pull a random 50 pairs just above and just below the threshold. Label them manually. That 10-minute check tells you whether your cutoff is still valid — or whether demographic shifts have quietly changed the base rates of common names. One team we worked with found that after a large workplace outbreak, their match rate suddenly spiked because dozens of employees shared the same employer-reported address. Wrong. It was the same address field on both forms, but different households.

“Probabilistic matching reduces manual work — until it confidently merges two people into one outbreak line list.”

— epidemiology informatics lead, after a 3-hour retrospective

Summary and Next Experiments

Quick reference: 5-step checklist

You started with a mismatch between case counts and lab results. Here is the condensed version — the one you paste on a Slack channel or pin to a cubicle wall. First, pull the raw case list and the raw lab extract from the same 24-hour window. Not the same business day — the same hours. Midnight to midnight. That alone kills half the phantom gaps. Second, check your deduplication rule. Most teams use patient ID; labs often use specimen ID. Those two keys drift apart when a patient has multiple draws in one episode. Third, flag any record where the event date precedes the lab collection date by more than six hours. That pattern usually means a manual data entry override — and those overrides hide real delay. Fourth, count the null fields in your lab result column. If more than 2% are blank, your ingestion pipeline dropped rows somewhere. Fifth, run a simple join on your last complete week and compute the absolute difference. Anything above 5% deserves a stop-the-line review, not a footnote.

That’s it. Five steps, maybe twelve minutes the first time. The catch? Most teams skip step one and jump straight to blaming lab staff. Wrong order. You lose a day chasing ghosts.

When to escalate to a formal data audit

The checklist catches sloppy joins and stale ETL schedules. It doesn't catch systematic surveillance drift — the kind where your case definition silently shifted three months ago because a junior analyst changed a SQL WHERE clause. I have seen this happen exactly once, and it took a week to unwind. When do you escalate? When the same mismatch pattern reappears across three consecutive weeks despite the checklist passing clean. That signal means the reconciliation itself is not the root cause — the upstream data contract between your surveillance system and the lab information system is broken. Call that a formal audit. Pull the raw source tables, compare column schemas, and look for a field that was repurposed (e.g., an old 'specimen type' column now holds a lab route code). The fix is not a script patch; the fix is a governance conversation. That hurts. But it beats running a broken reconciliation for six months and calling it stable.

One more signal: if your lab count is consistently higher than your case count by a stable margin (say 12% every week), the issue is not timing. It's likely a definitional mismatch — your surveillance system excludes probable cases that the lab still reports. That's a policy choice, not a data error. Don't waste an audit on it. Document the gap and move on.

One small change to try this week

Pick the one reconciliation step that irritates you most — probably the deduplication check — and automate the comparison, not the correction. Write a one-off script that flags mismatched rows instead of trying to fix them live. Run it Monday morning. Let the output sit for one hour before anyone touches it. Then read the flagged records. What breaks first is almost always the 3:00 AM batch of lab results that landed in the wrong date partition because the lab system clock runs on UTC and your case system runs on local time. An hour offset. That's the entire gap. You can adjust the join window by one hour and cut mismatches by 40%.

“We fixed our reconciliation by admitting we had no idea how the lab timestamp was generated. Then we looked at the raw JSON. It was a string field. Nobody had ever parsed it as a date.”

— Senior epidemiologist, public health agency (conversation, 2024)

Try the timestamp check first. If it works, you just saved everyone an hour of head-scratching per week. If it doesn't, you learned something cheaper and faster than a full audit. That's the whole point of a low-effort experiment: lose a small bet, gain a durable insight. Do it this Friday. Report back Monday. See what changed.