Why this matters
If you overload your Electronic Data Capture (EDC) system with heavy, cross‑visit logic, sites feel lag and frustration at the point of entry. If you delay basic validation, you create downstream query debt that is slow and expensive to clear. Splitting rules between real‑time (during entry) and batch (asynchronous) keeps usability and quality in balance.
Core concepts & definitions
Where the checks run
- Real‑time checks (a.k.a. at‑entry): Very fast validations that can run as the user types or on page save. Scope is usually the field or the same page/form.
- Batch checks (a.k.a. asynchronous): Deeper rules that need data from other forms, visits, or external sources (e.g., central labs, devices). Run on a schedule (hourly, nightly) or triggered by data changes, inside the EDC or as programs and listings outside it; the output is a query or a review listing.
What the checks look for
- Type & format: Is it an integer, date, or a value that matches a pattern?
- Range/allowed values: Is it plausible and within clinically acceptable bounds?
- Consistency: Does it agree with values on the page, across visits, or in external feeds?
- Completeness/expectedness: Is everything the schedule expects by now actually there?
Quality & performance terms
Signal‑to‑noise: How many flags are true issues versus noise. A false positive is a flag on correct data (usually the query closes with no data change); the share of flags that are true issues is the check’s precision. High noise erodes trust.
Latency budget: Maximum acceptable delay from data entry to a useful flag.
Severity:
- Hard stop — blocks save/submit. Use it only where no true value can fail (wrong data type, impossible date).
- Warning — prompts review but allows save; in EDC it usually opens a query that the site corrects or confirms.
- Informational — no action required; supports review.
Scope: Field → Page/Form → Cross‑page → Cross‑visit → Cross‑domain (e.g., adverse events vs concomitant medications) → External (vendor feeds).
People & artifacts
- CRF: Case Report Form (the screens/pages in EDC).
- CDM: Clinical Data Manager. The CDM specifies and tunes the checks, leads their testing, and raises and closes queries; the site corrects or confirms its own data (the CDM never edits it); vendors correct and re‑send theirs.
- Rule specification (edit check specification): Document that states what, where, when, and why for each check. “Check”, “rule” and “validation” all mean an edit check here.
The process, step‑by‑step
Inventory rules by scope Gather candidate checks and tag each by scope (field, page, cross‑page, cross‑visit, cross‑domain, external). Note the data they require and any edge cases (e.g., unscheduled visits).
Classify into real‑time vs batch
Real‑time candidates
- Data type and format (integer, date pattern).
- Required fields and controlled codelists.
- Plausibility ranges, as warnings (e.g., adult systolic blood pressure).
- Simple within‑page consistencies (e.g., “If ‘Pregnant’ = No, ‘Trimester’ must be blank”).
Batch candidates
- Time relationships across visits (e.g., adverse event date relative to randomization).
- Longitudinal patterns (e.g., repeated orthostatic drops).
- Cross‑domain and external joins (adverse events ↔ concomitant medications; EDC ↔ lab/device/electronic patient‑reported outcome (ePRO) data).
- Complex derived logic (multiple inputs, exception lists).
Decide by cost, not by label. Many EDC systems run a simple cross‑form comparison (e.g., visit date before consent date) at save without lag. Use batch when the rule needs many records, data not yet arrived, or an external source.
Set thresholds and service‑level agreements (SLAs)
Performance targets (typical starting points)
- At‑field validation: target under 300 ms.
- Page save with all at‑entry rules: target under 2 seconds.
- Batch cycles: nightly for standard checks; hourly/near‑real‑time for critical safety endpoints.
Quality targets
- Aim for more than 70% of warnings being true issues (a starting point, not a standard); revisit anything noisier.
- Define a latency budget (e.g., “first flag within 24 hours of data arrival”).
Implement and observe
- Log: run times, firing counts per check over time, user actions (accept/override), and closure reasons. A check that never fires may be broken; one that fires far more than the rest is probably mis‑tuned.
- Test every check before release with data that should and should not fire it. Mid‑study changes go through change control: retest, and run the changed check over data already entered.
- Version rules with clear release notes; keep a change log.
Tune continuously
- Widen ranges that fire mostly on valid values, add clinically sensible exceptions, or move a rule from real‑time → batch if it hurts usability.
- If a batch rule consistently finds issues that could be prevented at entry with low cost, consider moving it to real‑time.
What good looks like
- A concise check taxonomy that states where each rule runs and why (see table below).
- EDC remains responsive; sites don’t notice lag from validations.
- Batch jobs run on a predictable cadence, with alerting on failures.
- Flags are actionable; closure reasons are reviewed and used to refine rules.
- You track signal‑to‑noise and latency as first‑class metrics.
Check taxonomy (starter template)
| Tier | Where it runs | Typical checks | Place it… | Why |
|---|---|---|---|---|
| 1 | Field | type, required, format, plausibility ranges, codelists | Real‑time | Fast, prevents obvious errors |
| 2 | Page/Form | simple cross‑field logic on same page | Real‑time | Minimal data needed; immediate feedback |
| 3 | Cross‑page/visit | date relationships, longitudinal patterns | Batch | Needs broader context; costly at entry (simple comparisons can run at save) |
| 4 | Cross‑domain/external | a treated adverse event has a medication record; EDC vs lab/device/ePRO reconciliation | Batch | External timing; joins and tolerances |
| 5 | Programmatic review | trend/anomaly detection, complex derivations | Batch | Analytical workloads unsuitable for EDC UI |
Worked examples
Example 1 — Vital signs field validation (Real‑time)
Context: Adult cardiovascular (CV) trial.
Rule (business): Systolic blood pressure (SBP) is entered as an integer in mmHg; a value outside 60 to 260 is queried at the time of entry.
Where & severity: Real‑time: hard stop for a non‑integer entry, warning (query) for a value outside the range.
Why here: Single field; catches obvious typos (e.g., 600) at once, while a real extreme reading can still be saved and confirmed.
Implementation notes:
- Field type integer (hard stop); add range 60–260 as a warning that opens a query.
- If Position is required (Sitting/Standing/Supine), enforce requiredness on the same page.
Example message: “SBP is outside the expected range (60 to 260 mmHg). Please check against source and correct or confirm.”
Edge cases: Pediatric studies would need different ranges; handle via study‑level configuration.
Example 2 — Date relationship across visits (Batch)
Context: Event‑driven efficacy endpoint in CV trial.
Rule (business): The first adjudicated MACE (Major Adverse Cardiovascular Event) must occur after the Randomization date/time.
Where & severity: Batch, warning: the data manager reviews the flag and queries the owner of the date in doubt (the site for a site‑entered date, the randomization or adjudication data provider for theirs).
Why here: Requires data from the Randomization form and Adjudication dataset; both may arrive at different times.
Implementation notes:
- Join Subject → Randomization (date/time) → Adjudication (first MACE date/time).
- Flag if a first MACE date/time exists and is earlier than Randomization by any amount. No MACE means no flag; an event with a missing date goes to a completeness listing.
Query text: “The reported event date/time is earlier than the randomization date/time. Please check the event date/time against source and correct or confirm it.”
Edge cases: Screen failures converted to randomized subjects; time zone normalization required if systems store local time.
Example 3 — Orthostatic drop at one visit (Batch, cross‑record)
Context: Baseline vitals taken in three positions: Supine → Sitting → Standing.
Rule (business): A drop in SBP of 20 mmHg or more from Supine to Standing at Baseline should be reviewed.
Where & severity: Batch, informational/warning, routed to central monitoring.
Why here: Needs the Supine and Standing readings, separate records that may be entered or edited at different times; the result is a medical review item, not an entry error.
Implementation notes:
- Pivot Baseline vitals by Position; compute differences without blocking entry.
- Create a review listing for central medical monitor.
Suggested note: “Orthostatic SBP drop of 20 mmHg or more at Baseline: for medical review.” Any site query asks only to confirm the readings against source, never to repeat a measurement.
Edge cases: Supine or Standing missing → do not flag here (the completeness check catches it); handle measurement repeats by taking the finalized record.
Example 4 — Expectedness/missingness (Batch schedule)
Context: Week‑12 visit expected for all randomized subjects unless early termination.
Rule (business): If Week‑12 vitals are expected but still absent once the visit window has closed and the study’s data‑entry timeline has passed, flag for follow‑up.
Where & severity: Batch, warning to site and study team.
Why here: Depends on visit schedule and subject status; not a single field issue.
Implementation notes:
- Use schedule table to determine expected visits.
- Apply visit windows (e.g., Week‑12 ± 7 days).
- Suppress for screen failures, withdrawals, or early termination prior to the window.
Query text: “Week‑12 vitals were expected by [window end date] and have not been received. Please enter the data or confirm that the assessment was not done.”
Edge cases: Unscheduled visits covering missed procedures—allow rule to accept equivalents if defined in protocol.
Example 5 — External lab reconciliation (Batch cross‑domain)
Context: Central lab provides hemoglobin results (HGB) with units and collection timestamps.
Rule (business): For each EDC lab collection at Week‑4, there should be a matching central lab result within the protocol window and in the correct units, and no lab result without an EDC collection record.
Where & severity: Batch, warning or listing for the reconciliation team: EDC‑side discrepancies go to the site as queries, lab‑side ones to the lab, which corrects and re‑sends.
Why here: Requires joining EDC collection records with external lab feed; timings and units vary.
Implementation notes:
- Match on Subject, nominal visit, collection date/time within an agreed tolerance (e.g., ± 1 day) and, where used, the sample accession number.
- Verify units; if units differ, confirm that unit conversion was applied before deriving any endpoints.
Query text: “No central lab HGB result has been received for the Week‑4 sample recorded in EDC. Please confirm the collection date and time against source.”
Edge cases: Merged/duplicate lab transmissions; daylight saving time—normalize times.
Pitfalls & misconceptions
- Anti‑pattern: Heavy cross‑visit checks at entry. Forcing heavy cross‑visit logic (many records, late or external data) into the EDC UI slows the page and encourages workarounds. Move these to batch; a simple cross‑form comparison can stay at save.
- “More real‑time is always better.” Not true. Too many at‑entry warnings increase fatigue and reduce trust; noisy rules get ignored.
- Slow batch cycles. Week‑long latency turns insights stale. Most operational checks should raise their flags within 24 hours of data arrival; safety‑critical items should be faster. No check replaces safety reporting: the site reports each serious adverse event (SAE) to pharmacovigilance directly, without waiting for a batch run.
- Unclear severity. If users can’t tell what to fix now vs later, they’ll delay everything.
- Ignoring closure reasons. If sites constantly respond “per protocol” or “known exception,” your rule needs refinement.
- One‑size‑fits‑all ranges. Adult vs pediatric, device vs manual measurement—calibrate ranges to context.
Practice in the wild (checklist)
- For every rule, record Scope, Where it runs (real‑time/batch), Severity, Rationale, and Owner.
- Define SLAs: at‑field and page‑save targets; batch completion window; failure alerts.
- Track signal‑to‑noise monthly; retire or redesign noisy rules.
- Review closure reasons to add exceptions or tighten logic.
- Ensure time zone and unit normalization in batch logic.
- Version and release‑note all rule changes; keep an audit trail.
- Re‑assess placement: promote/demote rules between real‑time and batch based on impact.
Key points to remember
- Place checks where they fit the data context. Keep simple, local rules in real‑time (type/format, requiredness, plausibility ranges as warnings, same‑page consistency). Put complex or cross‑context logic in batch (cross‑visit date relationships, longitudinal patterns, external reconciliations, complex derivations); a simple cross‑form comparison can still run at save.
- Why placement matters: Real‑time protects EDC usability and trust at the point of entry; batch provides the broader context needed for deeper logic without slowing the UI.
- Protect performance with explicit budgets. Aim for fast at‑entry feedback (starting points: at‑field under 300 ms, page save under 2 seconds). Run batch on a predictable cadence—nightly for most checks; hourly/near‑real‑time for safety‑critical items—with alerting on failures.
- Use severities consistently. Reserve hard stops for unambiguous, high‑confidence errors; rely on warnings and informational messages to guide review without blocking.
- Manage noise and timeliness as first‑class metrics. Target more than 70% true issues among warnings and define a latency budget (e.g., first flag within 24 hours of data arrival).
- Close the loop and iterate. Review closure reasons and monitoring insights to widen or tighten ranges, add sensible exceptions, or move rules between real‑time and batch as evidence warrants.
- Treat rules as living assets. Track changes with clear release notes and monitor impact so your validation set stays effective and usable over the life of the study.