Query Aging & Backlog Playbook

Why this matters

In every study, open, aging queries are the clearest signal of data cleanliness and lock risk. If you do not measure aging correctly and you do not assign work to the right owner (the person or group with the next action), teams waste effort on the wrong items, while critical issues linger. A simple, segmented burndown turns a messy backlog into a daily plan that actually finishes.

Metrics & segmentation

Plain‑English definitions

• Query = a request to clarify, correct, or supply missing data.
• Abbreviations: EDC = electronic data capture; DM = data management; CRA = clinical research associate; CRO = contract research organization; ECG = electrocardiogram; PK = pharmacokinetics; IP = investigational product; SOP = standard operating procedure.
• Open query = any query not yet closed in the EDC (for example: New, Answered by site, Requires follow‑up).
• Owner = the party with the next action (site, external vendor, or internal team). An answered query waiting for review belongs to whoever must review and close it (usually DM; the CRA for its own monitoring queries), not to the site.

Core metrics

• Median age (days) of open queries: line up all open queries by age and take the middle value (with an even count, average the two middle values). Median is preferred over average because a few very old queries will not distort it.
• %>14d: the percentage of open queries older than your threshold (often 14 calendar days). Count how many open queries are older than the threshold, divide by the total open count and multiply by 100; a query exactly 14 days old is not older than 14 days. Example: six open queries aged 3, 8, 14, 15, 22 and 40 days have a median of 14.5 days ((14 + 15) ÷ 2) and %>14d = 3 of 6 = 50%. If the median is above the threshold, at least half of open queries are older than it.
• Critical backlog: number of open queries on critical data, as the Data Management Plan (DMP) defines them (for example, safety, primary endpoints, eligibility/randomization, investigational product). It must be zero before an interim cut; at lock, every query, critical or not, must be closed.
• New queries per day: recent daily creation rate. You need this to set net burndown targets (closing more than you create).

Counting rules that avoid arguments

• Use calendar days unless your SOP explicitly says business days; be consistent in reports and labels.
• Measure age from the date the query was first opened; do not restart the clock when a query is answered or reopened, because that hides queries that bounce between site and DM. Time since the last reopen, if tracked, is a separate view.
• Only count open queries in aging metrics. Closed queries are not part of aging.
• Label the threshold clearly (e.g., “% of open queries older than 14 calendar days”).

Meaningful segmentation

Segment your metrics by:

• Owner: Site, Vendor (e.g., central lab, ECG), Internal (data management or programming).
• Data domain: e.g., Demographics, Concomitant Meds, Labs, ECG, PK.
• Query type: data discrepancy (a value looks wrong) vs presence (expected data is missing or overdue).

This segmentation tells you who needs to act and where process gaps live. Example: if “%>14d” is high for central lab presence queries, calling sites is the wrong fix; partner with the lab vendor.

Burndown planning

A burndown converts backlog into a daily, owner‑specific plan.

1. Snapshot the baseline. Export open queries with fields: ID, Open date (first opened), Age (days), Owner, Domain, Type, Priority/Criticality.
2. Fix the horizon. Choose your end date (e.g., database lock at Week 0) and count business days remaining.
3. Account for inflow. Estimate new queries per business day using the last two weeks. Multiply it by the business days remaining and add the result to the backlog to get the total you must close.
4. Allocate by owner. Distribute the total closes across owners roughly in proportion to their share of the backlog (adjust for capacity).
5. Set daily targets. Convert each owner’s total into a per‑day closure target (for site‑ and vendor‑owned queries, the answers or corrected transfers that DM then reviews and closes). Publish it.
6. Sequence work. Always take critical and oldest first. Enforce single‑issue queries (one topic per thread) so the audit trail and closure are clear.
7. Track accomplishment daily. Show each owner’s target vs. actual and keep a short “reason for miss” note so you can remove blockers.
8. Stabilize inflow. If new queries spike from a form or vendor feed, fix the source (spec, mapping, training) so the burndown doesn’t become a treadmill.

Capacity tip: Targets must fit real capacity (people × average closures per person per day). Short‑term support (temporary full‑time equivalent (FTE) staff, weekend surge) pays off most once inflow is stabilized; if you add it earlier, fix the source in parallel so the extra effort is not spent on a treadmill. Extra DM staff speed review, routing and closure, not site answers: site staff answer and correct their own data. Temporary staff are trained and given personal accounts with only the access their role needs before they start.

Escalation & governance

Use objective triggers so escalation is predictable and fair:

• Trending trigger: %>14d worsens for two consecutive weekly snapshots for the same owner or domain.
• Critical trigger: any critical backlog > 0 persists beyond 5 business days.
• Throughput trigger: an owner misses ≥3 days in a week against the agreed daily target without a documented blocker.
• Systemic trigger: repeated root cause (e.g., same form or same vendor feed) generates the majority of new queries.
• Milestone trigger: at the current net closure rate, the burndown no longer reaches its target by the milestone date (zero open critical queries by an interim cut; zero open queries by lock).

Path & documentation

• Route site issues through the site management line (the CRA, then the clinical operations lead); vendor issues through CRO/vendor leadership as per contract.
• If that route does not clear the trigger by the agreed date, or a milestone is at risk, take it to the study governance forum named in the DMP (e.g., study team → sponsor DM lead → governance committee) with a clear ask: added resources, a contract action, or a re‑planned milestone.
• Open a CAPA (Corrective and Preventive Action) when the cause is systemic. Document the fix and an effectiveness check (what metric will prove it worked within a set time).
• Keep the escalation log simple: trigger, owner, ask, due date, outcome. Inspectors love clarity.

Worked examples (CV trial)

Scenario. Cardiovascular outcomes trial, target database lock in 6 weeks (30 business days). Baseline at Week ‑6:

• Open queries: 820
• Median age: 15 days
• %>14d: 52% (426 of 820; with the median above 14 days, at least half of open queries must be older than 14 days)
• Critical backlog: 7

Segmentation at baseline (by owner)

Inflow assumption. New queries are appearing at ~6 per business day (measured over the past two weeks). Over 30 business days, that is ~180 new queries. To reach zero by lock, the study must close about 1,000 queries over the horizon (the 820 open now plus ~180 new).

Burndown targets

• Study‑level daily target: ~33 closures per business day (1,000 over 30 days).

• Owner‑level daily targets (each owner’s share of the backlog × 33, rounded up; together 35/day, a small buffer above 33):

  • Site B: 9/day
  • Site A: 7/day
  • Central Lab Vendor: 6/day
  • ECG Vendor: 4/day
  • Other Sites (aggregate): 9/day

Execution highlights

• Day 1–3: Clear all critical items first (7 total) with focused outreach and two same‑day data corrections by the lab vendor.
• Week ‑5 to ‑4: Site B’s CRA coaches the site to answer critical and oldest queries first, with one complete answer per query; add 1 temporary FTE to screen and route presence queries to the correct owner.
• Source‑fix: A lab mapping error generating spurious out‑of‑range queries is corrected mid‑Week ‑4, cutting new lab queries by ~60%.

Checkpoint at Week ‑3

• Open queries: ~400
• Median age: about 25 days (every query still open from the Week ‑6 baseline is now at least 21 days old)
• %>14d: about 85% (only the ~60 queries raised in the last two weeks are 14 days old or younger)
• Critical backlog: 0
• Owners are tracking near daily targets, and the open count is on the burndown line. Aging lags the burndown: because the oldest queries close first, median age and %>14d stay high until the last baseline queries close (about Week ‑1), then fall to the age of new inflow. Remaining work focuses on older site discrepancy queries and a small tail of lab presence items.

This example is self‑contained: if you follow the same steps—baseline, inflow, owner targets, oldest‑first sequencing, and escalation—you can expect a similar shape of improvement.

Pitfalls & misconceptions

• Focusing on “queries resolved last month.” Historical activity says nothing about current risk. Lock risk lives in today’s open, aged queries.
• Assigning to the wrong owner. A result missing from the lab feed is vendor‑owned, not site‑owned; sending it to sites delays closure and creates noisy audit trails. (A result in the feed with no matching EDC collection page is a site gap: the site enters the missing page.)
• Kitchen‑sink queries. One query with multiple topics leads to partial answers and rework. Use one issue per query.
• Ignoring inflow. If you set targets without accounting for new queries, your backlog will not shrink.
• Resetting age when a query is reopened. A reopened query is the same unresolved issue; restarting the clock hides queries that bounce between site and DM. Keep the first open date and state the rule in your SOP and report labels.
• Unclear criticality. If critical data are not flagged, your team cannot prioritize. Define and tag critical queries early.

Practice checklist

• Publish median age and %>14d for open queries, segmented by owner, weekly (or more often near lock).
• Estimate new queries per day and include them in your burndown math.
• Set and track daily closure targets by owner; review target vs actual each day.
• Work critical and oldest first; enforce single‑issue queries.
• Use clear escalation triggers; open CAPA for systemic causes and verify effectiveness.
• Keep an escalation log with trigger, owner, ask, due date, and outcome.

Key points to remember

• Measure aging correctly. Count only open queries; measure age from the date the query was first opened (no reset on reopen); use calendar days unless your SOP specifies business days; state the threshold clearly (e.g., “% of open queries >14 days”). Use median age for stability, and compute %>14d on today’s open items, not past closures.
• Assign work to the true owner. The owner is the party with the next action (site, external vendor, or internal team). Presence gaps originating in external feeds (e.g., labs, ECG) are typically vendor‑owned, not site‑owned.
• Segment to find the fix. Publish aging metrics segmented by owner, data domain (e.g., Labs, ECG, PK), and query type (presence vs discrepancy) so you can target coaching and source fixes.
• Plan a realistic burndown. Baseline the backlog, add expected inflow (new queries/day) to get total closures needed, allocate by owner (capacity‑aware), and set daily closure targets that you publish and defend.
• Execute with discipline. Work critical and then oldest first; enforce single‑issue queries to avoid partial answers; track target vs actual daily and note blockers so they can be removed.
• Stabilize the source. Fix upstream causes (form rules, specifications, mappings, training, vendor feed issues) so today’s closures don’t regenerate tomorrow’s backlog.
• Zero critical backlog first. Identify and tag critical data early (safety, endpoints, eligibility/IP). Critical open = 0 is the interim gate and the first lock priority; lock itself needs every query closed.
• Escalate via governance. Use objective triggers (e.g., a burndown that no longer reaches its milestone target, worsening %>14d trend, critical >0 beyond 5 business days, repeated misses against daily targets, systemic root cause). Route site issues through site management and vendor issues through the contract line, and take what they cannot fix to the study governance forum; open a CAPA with an effectiveness check and keep a simple escalation log (trigger, owner, ask, due date, outcome).
• Maintain a steady reporting rhythm. Share median age and %>14d for open queries (owner‑segmented) at least weekly—more often near lock—and include the new‑queries/day rate so stakeholders see both backlog and inflow.