The 11-Day Lag: Fixing Patient-Data Reporting for a Multi-Site Healthcare Provider
A healthcare network's leadership was making staffing and supply decisions on data that was 11 days old. Here is how we rebuilt the reporting pipeline to run in near real time.
The provider ran seven clinical sites and a central administrative office, and every one of those sites maintained its own patient intake and records workflow, layered on top of a shared but aging electronic health records system. Leadership's complaint, when they first reached out, was not about patient care directly. It was about the monthly operations report: by the time it reached the executive team, the data inside it described a network that no longer existed.
Staffing decisions, supply orders, and site-level budget adjustments were all being made on a rolling 11-day lag between an event happening at a clinic and that event appearing in a report anyone could act on. A site experiencing a patient volume spike would not show up as a staffing problem in the data until the spike was, in practice, already over.
What We Found
The lag was not one bottleneck — it was five, stacked. Each site exported records manually once a week, on a schedule that varied by site. Those exports were emailed, not transmitted through any system, to a single administrator at head office who consolidated them by hand in a spreadsheet before compliance review. Compliance review added another two to four days depending on volume. Only after that review was the data cleared to enter the reporting pipeline that generated the leadership dashboard.
None of this was negligence. It was a workflow that had been assembled piece by piece as the network grew from two sites to seven, with each new site bolted onto a process designed for a much smaller operation. Nobody had gone back and redesigned the pipeline end to end, because nobody had been given the mandate to. We asked, and the honest answer from three different site administrators was some version of: this is how we've always sent it.
What We Did
We treated this as a data engineering problem before it became a dashboard problem. We built a secure, automated extraction layer that connected directly to each site's records system on a nightly schedule, replacing the manual weekly export entirely. Compliance review was redesigned as an automated rules-based pre-check — flagging only the records that actually needed a human's attention, rather than requiring a human to look at everything. That alone eliminated roughly 70% of the manual review workload.
The consolidated, reviewed data then fed a live operations dashboard, rebuilt from scratch, that updated automatically each morning rather than once a month. Site directors got their own view scoped to their location; the executive team got a network-wide rollup. Both were looking at data that was, at most, a day old.
We used to find out about a staffing problem after the week that caused it was already history. Now we see it building in real time and we can move a nurse before the shortage becomes a patient-facing issue.— Director of Clinical Operations, post-engagement retrospective
The Outcome
The reporting lag dropped from 11 days to under 24 hours across all seven sites. Staffing adjustments that used to be reactive — made after a shortage had already affected patients — became predictive, based on same-week volume trends. The compliance team, freed from manually reviewing every record, redirected that time toward the small number of genuinely flagged cases that warranted scrutiny, which the provider's own audit team noted improved review quality rather than just review speed.
A reporting delay is rarely one broken step. It is usually several reasonable workarounds, added over years, that nobody has been asked to look at together. Data engineering for growing organizations means auditing the full pipeline, not patching the step that happens to be visible.