Central Lab vs CRF: Source Alignment

Why this matters

Laboratory data drives safety review, dosing decisions, and endpoints. It is high‑volume and usually delivered on a fixed schedule by a central lab vendor. If you do not set clear rules for which data source is authoritative and which delivery window a result belongs to, you will open the wrong queries, chase “missing” data that is simply coming in the next cut, and slow database lock.

Core concepts & definitions

• Case Report Form (CRF): The study form completed in the electronic data capture (EDC) system by the site. For central labs, the CRF usually holds only the collection details (sample taken, date and time, accession number); the results arrive in the vendor transfer and are not re‑keyed. Where a study does have the site transcribe results (as in the examples below), the CRF value is only a copy. Local lab results are different: the site enters them with units and reference ranges, and the site’s lab report is the source.

• Source of truth (SoT): For central lab tests, the vendor transfer file (or portal export defined in the transfer spec) is authoritative. The CRF is secondary.

• Transfer cut timing (“the cut”): The date/time rule that decides which results are included in a given delivery (for example, “all results finalized up to 00:00 UTC daily”).

• Reconciliation keys (“match keys”): The smallest reliable set of columns used to line up rows across systems. Common keys: subject_id, visit (the protocol visit or timepoint, coded as in the EDC), specimen_id or accession_number, collection_datetime, and test_code (mapped to a standard value). Unscheduled and repeat samples have no unique visit: match them on accession and collection date/time.

• Tolerances: Small, pre‑agreed wiggle room for differences that do not change meaning. Examples:

  • Time tolerance: collection time matches if within ±30 minutes after time‑zone normalization.
  • Value tolerance: numeric rounding to the precision agreed in the transfer spec, after unit conversion.
  • Unit conversion: mg/dL ↔ mmol/L handled by documented, analyte‑specific factors (for glucose, mg/dL ÷ 18 ≈ mmol/L).

• Owner routing: Rules that decide who gets the query:

  • Lab vendor for problems inside the transfer (row missing after its cut, wrong test code, duplicate accession).
  • Site for CRF‑side problems when the lab row is present (value, subject, visit, or collection date/time does not match; CRF entry missing), and when an expected test is in neither source.

The process, step‑by‑step

1. Confirm authority & cut rules In the data transfer specification (the “transfer spec”; many companies put it in, or attach it to, a data transfer agreement, DTA), state plainly that the lab transfer is SoT for central tests, and document:

   • Cut frequency and timestamp (with time zone).
   • Whether files are full refresh (cumulative: everything to date) or delta (only new and changed rows).
   • How late corrections and cancellations are signaled (e.g., status flags).

2. Normalize before you compare

   • Check structural conformance first: the file matches the transfer spec (columns, data types, allowed values, statuses, no duplicate keys).
   • Map test codes (vendor → study standard, e.g., to LOINC (Logical Observation Identifiers Names and Codes) or a sponsor dictionary).
   • Standardize units (define canonical units per analyte).
   • Normalize time zones and formats (keep the local time as collected and derive an ISO 8601 datetime in UTC for cut comparisons).

3. Reconcile on four axes

   • Presence: Is the test present in CRF, in lab, in both, or in neither?
   • Identity: Do keys line up (same subject/specimen/test)? Any duplicates or wrong mappings?
   • Timing: Does the CRF collection date/time agree with the lab’s within tolerance, and does it fall within the visit window?
   • Value: After unit conversion and rounding, do the results match?

4. Route and act using a decision tree

   • CRF present, lab missing → check the cut first; if the result is overdue, query the lab vendor (not the site). Likely omission, a sample not received, or code mapping.
   • Lab present, CRF missing → query the site. Ask the site to complete the entry or explain (the lab holds a result, so “not done” cannot be right).
   • Both present, values differ → query the site. Ask the site to verify the entry against the lab report and correct the CRF; data management (DM) never edits it.
   • Identity conflicts inside the transfer (e.g., duplicate accession, wrong test_code) → query the lab vendor, who corrects and re‑sends the data.
   • Header mismatch between CRF and lab (subject, visit, collection date/time, accession) → query the site first to check its copy of the requisition. If the lab’s record is the wrong one, the vendor corrects it on the site’s confirmation and re‑sends.
   • Neither present for an expected test → query the site (was the sample collected and shipped?).

5. Document outcomes for audit

   • Keep a reconciliation log of each discrepancy: type, owner, action taken, date closed, and rationale.
   • Reference the transfer spec and tolerance rules in your query notes to show controlled process.

What good looks like

• A reproducible reconciliation job (SQL or tool‑based) with explicit keys, windows, and tolerances.
• A routing matrix tied to service‑level agreements (SLAs) so the right team responds quickly.
• Trend charts and summaries by site, analyte, and reason code (e.g., “cut timing,” “unit mismatch,” “duplicate specimen”) that drive prevention (training, mapping fixes, or vendor change control).
• Clear versioning: when a vendor re-delivers data, the old row is superseded, and the history is traceable.

Example routing matrix (simplified)

Discrepancy type	Typical cause	Owner to query
CRF has sample or result; lab transfer missing	Not yet due (wait for its cut); file omission; sample not received	Lab vendor, once its cut has passed
Lab has result; CRF missing	Site delayed entry	Site
Values differ after unit normalization	CRF transcription error	Site
Wrong or unmapped test code in transfer	Vendor mapping issue	Lab vendor
Subject, visit, collection date or accession differs	Requisition or CRF entry error at site	Site first; vendor re‑sends if its record is wrong
Expected test in neither source	Sample not collected or not shipped	Site
Duplicate specimen/accession in transfer	Vendor process error	Lab vendor
Off‑window collection (visit mismatch)	Scheduling/CRF labeling at site	Site (confirm the date; a real off‑window draw is a protocol deviation, not a data error)

Worked examples

Below, each example is self‑contained with context, inputs, steps, and the expected action.

Example 1 — Presence gap caused by cut timing

Context: Cardiovascular (CV) study, central lab sends daily delta files cut at 00:00 UTC.

Inputs:

• CRF shows a Week‑12 Sodium sample for Subject 101‑003 collected 2025‑05‑02 23:55 (local, UTC‑05:00).
• Latest lab transfer (dated 2025‑05‑04 00:10 UTC) does not contain this result.

Steps:

1. Convert collection time to UTC → 2025‑05‑03 04:55 UTC.
2. The cut includes results finalized up to 00:00 UTC on 2025‑05‑04. The sample’s result was finalized at 14:30 UTC on 2025‑05‑04 (per vendor portal).
3. Therefore the result belongs to the next cut (00:00 UTC on 2025‑05‑05); it is not missing.

Action: No query yet. Log the row as “pending cut” and re‑check after the 2025‑05‑05 delivery. If the result is still missing then, query the lab vendor (not the site) to confirm that the sample was received and when the result will be delivered. Do not open a site query.

Example 2 — Value mismatch where lab is authoritative

Context: Same CV study.

Inputs:

• Lab transfer: Sodium 123 mmol/L for 101‑003, Week‑12.
• CRF: Sodium 132 mmol/L for the same visit and time.
• Units already aligned; no conversions needed.

Steps:

1. Confirm keys match (subject, visit, specimen/accession, test code).
2. Verify the lab file passes structural checks (status = “final,” no correction pending).
3. Compare numeric values (no rounding effect).

Action: Query the site to verify the entry against the lab report and correct the CRF. Cite the lab as source of truth and include the lab’s accession and finalization date in the query note. If the site’s report really shows 132, the lab’s data are in question: ask the vendor.

Example 3 — Lab present, CRF missing (operational follow‑up)

Context: Oncology study with weekly hematology panel.

Inputs:

• Lab transfer shows Hemoglobin 11.2 g/dL for Subject 204‑111 at Visit Wk 6.
• No corresponding CRF entry exists for this visit.

Steps:

1. Confirm visit window rules permit this collection time.
2. Ensure the analyte maps to a CRF field (panel → individual test).
3. Check the site’s data entry lag: it typically enters within 3 business days, and this visit was 8 business days ago, so the entry is overdue.

Action: Query the site to complete the Wk 6 lab entry, or to explain if the sample belongs to another visit or subject. Provide accession number and collection datetime to help them locate the report.

Example 4 — Identity conflict due to test code mapping

Context: Multi‑country metabolic study.

Inputs:

• Vendor sends GLUC_FAST and GLUC_RAND; sponsor dictionary expects GLUC_F and GLUC_R.
• CRF shows “Fasting Glucose” but the transfer has GLUC_RAND for the same accession.

Steps:

1. Check the code mapping table: GLUC_FAST ↔ GLUC_F; GLUC_RAND ↔ GLUC_R.
2. Ask the vendor what the requisition says: the sample was recorded as fasting.
3. So this is a mapping error in the vendor export, not a site error.

Action: Query the lab vendor to correct the test code and issue a re-delivery. Once corrected, no site action is needed.

Example 5 — Units and rounding

Context: The CRF potassium field holds one decimal; the lab reports two.

Inputs:

• Lab transfer: Potassium 4.15 mmol/L (canonical unit = mmol/L).
• CRF: Potassium 4.2 (entered with one decimal).

Steps:

1. Apply study rule: round to one decimal (half up) before comparing with the CRF, but store lab precision in the backend.
2. 4.15 → rounds to 4.2 (matches CRF once rounding rule is applied).

Action: No query needed. Record that rounding aligned with the agreed rule.

Example 6 — Canceled/hemolyzed specimen

Context: Sample was drawn, but the lab marked it “canceled—hemolyzed.”

Inputs:

• Lab transfer row exists with a status column indicating “canceled.”
• CRF shows a numeric result.

Steps:

1. Structural conformance: canceled tests should not have numeric results.
2. This is a value/meaning mismatch—CRF cannot override a canceled status.

Action: Query the site to verify where the CRF value came from (for example, a repeat sample or a local lab) and to correct or explain the entry. If a repeat sample was sent, expect a new accession in a later transfer.

Pitfalls & misconceptions

• Misconception: “If it’s in the CRF, that’s the data of record.” Reality: For central labs, the lab transfer is the source of truth.
• Anti‑pattern: Querying the site first for any lab–CRF mismatch. A row missing from the transfer, a wrong test code or a duplicate belongs to the lab vendor.
• Anti‑pattern: Comparing values before unit conversion, time‑zone normalization, or rounding.
• Overlooking re-deliveries: Failing to apply supersession rules when a vendor corrects a prior file.
• Not checking structure first: Skipping structural conformance (headers, types, statuses) leads to noise in reconciliation.

Practice in the wild (checklist)

• Write source‑of‑truth and cut timing plainly in the transfer spec (frequency, time zone, delta vs full, correction flags).
• Define match keys (subject, visit, specimen/accession, collection time, test code) and keep them stable.
• Establish unit and rounding rules per analyte; implement conversions centrally.
• Build a routing matrix (discrepancy type → owner) with SLAs.
• Run structural conformance checks before reconciliation (status fields, required columns, allowed values).
• Track reason codes for each discrepancy and trend by site/test to drive fixes.
• Keep a reconciliation log with decision notes that stand up to audit.
• Rehearse cut timing edge cases (near midnight local vs UTC, daylight‑saving changes).

Key points to remember

• Authority & cut timing

  • For central labs, the vendor transfer is the source of truth; the CRF holds the collection details or, at most, a transcribed copy.
  • Always assess the cut rules (frequency, timestamp, time zone). A result belongs to the cut after it is finalized, so a recent collection is often simply due in the next cut: check the cut rule first, query the lab vendor only if the result is overdue, and do not query the site.

• Normalize before comparing

  • Map test codes to the study’s standard dictionary.
  • Convert to canonical units and apply agreed rounding; preserve raw precision in the backend.
  • Normalize timestamps (keep local as collected; derive UTC).

• Reconcile on four axes

  • Presence: in lab, in CRF, in both, or neither.
  • Identity: keys align (subject, visit, specimen/accession, test code); no duplicates or mapping errors.
  • Timing: CRF and lab collection date/time agree within tolerance and fall within visit windows.
  • Value: compare only after unit conversion and rounding; honor cancellation/status fields.

• Owner routing (decision tree)

  • Transfer‑side issues (row missing after its cut, wrong test code, duplicates) → Lab vendor, who corrects and re‑sends.
  • CRF‑side issues when a lab row exists (value, subject, visit, or collection date/time differs; CRF missing), an expected test in neither source, and off‑window collections → Site. DM raises the query and never edits either side.

• Tolerances & structure first

  • Apply unit conversion and the time and rounding tolerances before declaring mismatches.
  • Run structural conformance checks (required columns, allowed values, status = final/corrected rules) before content reconciliation.

• Versioning & supersession

  • Treat vendor re‑deliveries as superseding prior rows with traceable history and clear versioning.

• Audit trail & prevention

  • Maintain a reconciliation log (discrepancy type, owner, action, date, rationale) suitable for inspection.
  • Trend reasons by site/analyte (e.g., cut timing, unit mismatch, duplicate accession) to drive training, mapping fixes, or vendor change control.