The CRO delivered your assay data. Your scientists still cannot use it.

The correction that arrives after the decision

On Tuesday the CRO delivers DR-014: plasma concentrations for forty samples. By Thursday a scientist has matched sample IDs by hand, fixed two unit labels and loaded the results. On Friday revision 2 arrives. SMP-201 is now 11.8 ng/mL, not 12.4, and Thursday’s project review already used the old value.

Nobody made a mistake. The workflow simply had no place for a correction. The file arrived on time; a result the team could rely on did not.

A received file and an accepted result are different stages of the same work.

DR-014 and the other identifiers in this guide are illustrative, not client data.

Start with one partner, one assay and one destination

Pick the delivery that hurts most and follow one result from the CRO’s file to the record your scientists trust. Note who resolves each question and what the destination needs. Then ask the reviewer to show an accepted record beside its original row. That comparison exposes what column headings hide: repeat measurements, result qualifiers and the difference between a missing result and a sample that was never tested.

Keep scientific meaning beside every value

In DR-014, SMP-202 is reported as BLQ: below the quantification limit. Converting BLQ to zero would introduce a measurement the CRO never reported. The record keeps the qualifier, the limit and the method context.

Agree a result key that separates sample, analyte, assay, timepoint and repeat. Keep the partner’s identifiers beside the approved internal match. File names and row order stop identifying anything once a partner re-sorts a spreadsheet.

Distinguish numeric values, qualified results, missing data and rejected measurements. Keep original units beside any approved conversion. A scientist decides when units and methods are comparable; the importer applies that rule and stops for review when context is missing.

Agree a delivery manifest with the partner as well. It tells a missing sample apart from an omitted repeat, which a row count never will.

Let a reviewer reconstruct any accepted value

Keep the original file, a content fingerprint, the receipt time and the delivery version. Record the parser and mapping versions and the reviewer’s decision. Show the source cell beside the proposed destination value, so tracing a result never means searching an inbox.

These are the properties regulators expect of trustworthy records. FDA’s data integrity guidance describes data that is attributable, legible, contemporaneously recorded, original or a true copy, and accurate: ALCOA. That guidance covers drug manufacturing, and discovery data may sit outside it, but the same properties make a CRO result reviewable. If results feed regulated studies, your quality team sets the requirements.

W3C PROV-O supplies useful vocabulary: the file is an entity, the transformation an activity, the person or service an agent. Ordinary database records can capture that distinction without an ontology project.

Decide whether one blocked row holds the whole delivery or whether reviewed records can proceed. If partial acceptance is allowed, show accepted and unresolved records separately, with a reconciliation view of expected samples, received results and destination records.

Treat a correction as a new review decision

When revision 2 arrives, keep both deliveries and the partner’s stated reason. Match the revised result to the accepted record and show exactly which value or context changed. Never overwrite source history.

Approval belongs to a result version. Agree which changes need fresh review: identifiers, units, qualifiers and method references. If revision 1 turns up late, it must not replace revision 2. Anyone whose analysis used 12.4 ng/mL gets a visible correction notice, and Friday’s problem becomes a routine notification.

Test the deliveries that break importers

Use historical deliveries plus a few unseen ones in a test environment. A pilot should pass checks like these before anyone measures time saved:

• Replay DR-014 under a new filename. The duplicate is recognized and creates no second result.
• Remove a unit, add an unknown sample and an ambiguous ID match. Each affected record waits for resolution.
• Send BLQ without its method context. The qualifier survives and interpretation is blocked.
• Interrupt publication after the destination may have received a write. The workflow reconciles actual state before retrying.
• Deliver revision 1 after revision 2. Arrival order cannot restore the superseded value.
• Sign in as a reviewer from another project. Source files, exceptions and results stay hidden.

Then change the template without changing the filename: reorder columns, drop the qualifier field, use an unfamiliar unit label. A parser can finish without errors and still put a plausible value in the wrong field, so inspect the accepted records, not the job status.

For the destination, Benchling documents its supported APIs and access controls. Confirm the objects, permissions and update behavior in your own tenant; safe retries and revision handling differ between systems.

Check what you own, then build only the gap

Platform vendors already cover parts of this. TetraScience describes CRO data onboarding with mapping and quality checks. If your licenses cover your partners and assay formats, configure them first. That is the cheapest fix.

The gap, when there is one, is the workflow around the tools: your identifier rules, a review queue scientists will actually use, correction handling, reconciliation and an operator who can recover a failed import. That is the part we build and hand over.

Scope one handoff you can accept and operate

Request a call from this article and describe your last difficult delivery in a few lines. The first conversation needs no data; confidential files can wait for an NDA or your approved access process. See how we work with biotech teams. If the recurring problem is a request between internal systems, read the ELN and LIMS integration guide.