Aging Metrics & Performance Management

Why this matters

Aging and backlog tell you if you’ll meet interim‑analysis and database‑lock dates. “Queries resolved last month” is a rear‑view mirror metric. What matters for readiness is what’s still open today and what should be here but isn’t (missing forms/loads). Clear, plain‑language metrics let you steer resources, coach sites, and escalate vendor issues before timelines slip.

Glossary (used once, defined once):

• CRF = Case Report Form (the electronic form in the EDC).
• EDC = Electronic Data Capture system.
• DSMB = Data and Safety Monitoring Board (safety review).
• SLA = Service Level Agreement (agreed turnaround time).
• CRO = Contract Research Organization (vendor partner).
• DM = Data Management; CRA = Clinical Research Associate (the monitor); PI = Principal Investigator; SDV = Source Data Verification.

Core concepts & definitions

Aging metrics (describe the current queue): A query’s age is the number of days from the day it was opened to today.

• Median age — The “middle” number of days that open queries have been waiting. Less sensitive to one very old outlier than an average: for open queries aged 3, 6, 9, 20 and 62 days, the median is 9 and the mean is 20.
• % >14 days — The share of open queries older than your SLA (14 days here; the data management plan (DMP) sets the study’s value). This is your “stuck” signal: in the same five, 2 of 5 (40%) are over 14 days, although the median looks healthy.
• Queries per subject — Open queries divided by active/enrolled subjects. Normalizes across large vs small sites (e.g., 36 open queries ÷ 20 subjects = 1.8).
• Not an aging metric: cycle time — Average days to resolve closed queries: past performance, not what is open today.

Backlog (things blocking readiness):

• Open queries — Every query not yet closed: awaiting the owner’s response, or answered and awaiting DM review (then DM‑owned).
• Expected‑but‑missing — Forms you should have by now (per visit schedule) but do not, and external transfers missing (e.g., lab file expected but not received/loaded; each scheduled transfer is a cut). Both belong in backlog because they delay cleaning.

Segmentation (so action goes to the right place):

• By site — Pinpoint coaching or extra monitoring.
• By domain — E.g., Adverse Events (AE), Concomitant Medications (CM), Labs, Vital Signs. Shows where rules or processes need attention.
• By owner — Who has the next action? Site, vendor (e.g., lab/CRO/coder), or internal DM. Owner‑level splits prevent sending vendor issues to sites.

Trends & burn‑down:

• Plot aging and backlog weekly. In a healthy burn‑down (backlog left each week), closures outpace new inflow, so the backlog falls week on week and reaches the target before the interim/lock date.

Decide up front: use calendar days (simpler) or business days. Be consistent across the study.

The process, step‑by‑step

1. Choose the few metrics that drive decisions

   • Start with: median age, % >SLA, queries/subject, and backlog (open queries + expected‑but‑missing).
   • Set target thresholds (example below). Document them in your data management plan.

2. Segment every view

   • Site × Domain × Owner (site/vendor/internal) × Time (weekly).
   • Add filters for country, phase, and visit window where helpful.

3. Forecast readiness

   • Review backlog trend vs. work capacity (how many items the team can realistically close per week).
   • Use a simple “weeks‑to‑green” view: current backlog ÷ average weekly net burn, where net burn = items closed per week minus new items per week.
   • Example: backlog 480, 150 closed and 90 new a week: net burn 60, so 480 ÷ 60 = 8 weeks. If lock is 6 weeks away, net burn must reach 80. Zero or negative net burn never clears; escalate.
   • Backlog is not all of readiness: lock also needs coding and reconciliations complete, SDV done as the monitoring plan requires, and investigator signatures.

4. Act with a playbook

   • Coach (amber, site‑owned): DM supplies the metrics; the CRA coaches the site (e.g., a targeted email or office hour) on process and timeliness, never on what value to enter.
   • Fix: rule tuning, data load schedule change, or mapping correction when a domain drives the problem, each under change control and tested before release.
   • Escalate (red, or amber that does not improve): site‑owned breaches go through the CRA to the PI and clinical operations; vendor‑owned or systemic ones go to the vendor line (CRO/lab/coding). A sponsor DM overseeing a CRO escalates to the CRO’s lead data manager and project leader, not to sites.
   • Never: DM does not answer queries for a site or edit site data to hit a date.

5. Re‑baseline after action

   • Record a new baseline (a dated snapshot of the metrics; thresholds stay) the week you intervene; track improvement within 2–3 weeks.
   • Keep the history to prove control during audits/inspections.

Example threshold playbook

Tailor thresholds to study cadence (e.g., weekly vs biweekly lab cuts) and risk profile.

What good looks like

A single dashboard that anyone can read:

• Top tiles: Median age, % >SLA, queries/subject, total backlog.
• Segmented tables: By site and owner showing who must act next.
• Domain strips: AE/CM/Labs/Vitals with mini trends and flags where rules are noisy or data is late.
• Burn‑down chart: Backlog week‑over‑week with a dashed line to the interim/lock date.
• Playbook overlay: Each red/amber tile links to the action (coach/escalate/fix).
• Notes panel: Log decisions (e.g., “Lab file mapping corrected on 12‑Aug; expect improvement by 26‑Aug”). This becomes your inspection‑ready narrative.

Worked examples

Self‑contained scenarios you can reuse for practice or discussion.

Example 1 — Site aging problem (Cardiovascular trial)

Context: Phase III CV study with monthly visits. SLA for query response is 14 calendar days.

Signal: Site B shows median age 28 days, 62% >14 days, and 1.8 queries/subject for AE and Labs domains. Backlog has risen for three weeks as DSMB approaches.

Assessment: Owner split shows 80% site‑owned, not vendor. Monitoring notes show CRA turnover.

Actions:

1. Escalate and coach: two of Site B’s metrics are red, so DM sends the aging metrics and AE query patterns to the CRA and clinical operations; the CRA raises them with the PI and runs a 30‑minute office hour for Site B, including how to use EDC “My Queries.”
2. Capacity support: CRO assigns experienced CRA for two weeks.
3. Follow‑up: Weekly checkpoint and burn‑down; if there is no improvement, clinical operations escalates further before the DSMB data cut‑off.

Outcome to look for: Median age at or under 14 days and %>SLA at or under 20% (both green) within 2–3 weeks; queries/subject trending toward study median.

Example 2 — Vendor transfer backlog (Central lab)

Context: Labs vendor sends files every Tuesday; SLA to post in EDC ≤ 48 hours.

Signal: Spike in “CRF present, transfer missing” flags across all sites; Labs domain backlog adds 600 items in 10 days. Owner split shows vendor‑owned.

Assessment: Recent change in test panel coding; mapping failed on new LOINC (standard lab test) codes.

Actions:

1. Escalate vendor line via CRO oversight; open a ticket; request a tested mapping fix (under change control) and extra ad‑hoc cut this week.
2. Communicate to sites: no action needed on their side; prevent noise.
3. Re‑baseline once the backload posts; verify record counts against the vendor file and spot‑check values, units and reference ranges.

Outcome to look for: Backlog drops after compensatory cut; Labs domain returns to green without penalizing sites.

Example 3 — Rule noise inflating queries (Internal)

Context: New derived rule on concomitant meds created 1,200 low‑value queries in 48 hours.

Signal: Queries/subject jumps at most sites, but median age remains low; %>SLA still green. The queries sit with sites (site‑owned next action), but the cause is internal: a DM‑owned rule.

Assessment: Over‑tight logic; missing allowable use cases.

Actions:

1. Pause the rule under change control (document decision).
2. Tune logic with examples from three data‑rich sites.
3. Bulk close clearly spurious queries with an audit‑trailed reason (closed, never deleted) and tell sites no response is needed.

Outcome to look for: Queries/subject normalizes; rule retested and re‑enabled with lower false‑positive rate.

Example 4 — Expected‑but‑missing (Visit schedule drift)

Context: Early‑phase oncology; weekly visits for first 4 weeks.

Signal: 8% of due forms missing at several sites, mainly Visit 3 vitals and labs. Owner shows site‑owned.

Assessment: Visit rescheduling due to public holidays; EDC did not auto‑shift expected forms.

Actions:

1. Run expectedness refresh so the report expects forms from actual visit dates. Protocol windows do not move: an out‑of‑window visit keeps its true date and the CRA assesses it as a possible deviation.
2. Site nudge (through the CRA) with a short checklist on how to enter out‑of‑window visits.
3. Monitor: expected‑but‑missing rate targeted under 3% in 2 weeks.

Outcome to look for: Backlog falls; no unnecessary queries created.

Pitfalls & misconceptions

• “Fewer queries = cleaner data.” Not always. Fewer queries may mean rules are disabled, under‑firing, or data never arrived. Check expected‑but‑missing and rule status.
• Counting closures as cleanliness. Resolved counts are history, not readiness. Use current backlog and aging.
• Mis‑routing: Sending vendor issues to sites wastes time and damages relationships. Always inspect the owner field first.
• Ignoring domain mix. A site with mostly AE queries needs different help than a site with lab timing issues.
• Thresholds without actions. A red tile with no playbook creates noise. Tie every threshold to a next step.
• Business vs calendar day confusion. Switching mid‑study breaks trend lines and undermines trust. Decide once.

Practice in the wild (checklist)

• Build a segmented dashboard (Site × Domain × Owner × Time).
• Include expected‑but‑missing and external transfer status in backlog.
• Set clear thresholds and link them to a written playbook.
• Review weekly in study ops; publish a burn‑down with narrative notes.
• After actions, re‑baseline and track improvement within 2–3 weeks.
• Document rule pauses/tuning and bulk closures with reasons (inspection‑ready).

Key points to remember

• Readiness is present‑tense: focus on what’s open now and what’s missing, not last month’s closures.

• Define backlog completely: open queries + expected‑but‑missing forms + missing external transfers (e.g., lab cuts). These are the blockers to cleaning.

• Use aging metrics that drive action:

  • Median age (preferred over mean; resists outliers) shows typical wait time.
  • % open > study SLA (e.g., 14 days) is your “stuck” indicator.
  • Queries per subject normalizes site comparisons.

• Segment every view so action lands correctly: by owner (site / vendor / internal), site, and domain (AE, CM, Labs, Vitals). The owner split prevents mis‑routing vendor issues to sites.

• Trend and forecast weekly: track aging + backlog burn‑down with a target line to interim/lock; estimate weeks‑to‑green = current backlog ÷ average net weekly burn (closed minus new items per week).

• Tie thresholds to a playbook: every red/amber state maps to a next step—Coach → Fix → Escalate → Re‑baseline—and you document the decision.

• Know who acts: DM supplies the metrics; the CRA coaches the site and takes red or persistent breaches to the PI; a sponsor DM overseeing a CRO escalates to the CRO’s lead data manager and project leader, not to sites.

• Be consistent on time basis: choose calendar vs business days once and keep it unchanged for the study.

• Treat vendor‑caused backlogs at the source: escalate via CRO/vendor leadership (not site chastising) and communicate clearly to avoid noise.

• Don’t equate fewer queries with cleaner data: low counts may mean disabled/under‑firing rules or missing data—always check expectedness and rule status.

• Keep an inspection‑ready trail: re‑baseline after interventions, retain history, and log rationale (rule pauses/tuning, bulk closures) in your notes.