Why §7.4.3 lives at the receipt step

ISO/IEC 17025:2017 §7.4.3 requires recorded customer consultation when a sample

arrives at the lab in a condition that deviates from what was agreed — broken,

improperly preserved, ambiguously labelled, outside transport temperature. The

way a LIMS implements this flow tells you a great deal about how it handles

the broader audit trail.

The problem with a separate workflow

Most LIMS (LabWare, STARLIMS, Labvantage in their default configurations) implement §7.4.3 as a standalone entity — a "Customer Consultation" with its own page, its own primary key, its own list view, and its own "New consultation" button. When the analyst marks conditionOnArrival ≠ OK, a banner sends them off to another form.

This architecture creates three problems:

1. Scattered evidence. Sample condition lives in the samples table, the consultation in customer_consultations. The auditor has to follow an FK lookup to confirm that every non-OK sample has a matching consultation record — and ask for an explanation of every orphan.
2. Drift between records. A user can change conditionOnArrival later without touching the linked consultation — two rows, two sources of truth, and no database constraint can enforce consistency between them.
3. UX cost. The analyst is looking at the sample, but has to navigate away to log the conversation they just finished on the phone. That friction favours omission.

The decision: inline on the receipt form

In Agrometrisis the consultation lives as columns on the Sample entity

itself: customerConsultedAt, customerConsultedById, consultationOutcome,

customerAuthorisedProceed, consultationNotes.

The receipt form reveals the §7.4.3 sub-block automatically via applyWhen()

keyed off conditionOnArrival ≠ OK — red left border, required fields, direct

link out to the clause. The fields are part of the same save; there is no

"don't forget to also fill in..." nag.

Why this satisfies the audit better

An ESYD assessor walking the audit trail sees the sample condition and the

consultation on the same row. No FK lookup, no "the related record is on

another screen". §7.4.3 asks for evidence about this specific sample — so

the evidence lives on the sample.

Closing the loop with status transitions

consultationOutcome has three values: PROCEED_AS_IS, REJECT, RESAMPLE. On save:

• REJECT → the sample auto-transitions to REJECTED with noteCode: SAMPLE_REJECTED_BY_CUSTOMER written to the status log.
• RESAMPLE → transitions to CANCELLED with SAMPLE_CANCELLED_FOR_RESAMPLING.
• PROCEED_AS_IS → additionally requires customerAuthorisedProceed=true, no status change.

The customer's decision becomes an action in the system, not a note that can be forgotten.

The trade-off

A separate workflow gives you a consultation list view "for free" as a distinct entity. In Agrometrisis the same list is one filter on the samples page: consultationOutcome IS NOT NULL. One query, zero extra entity, one source of truth — and as a bonus the list carries the full sample context (customer, method, analyst) without any extra joins.

When evaluating LIMS, it's worth asking the vendor: "show me how an auditor verifies in ten seconds that this specific non-OK sample has a recorded consultation." If the answer involves navigating to another screen, §7.4.3 is being treated as a side workflow — not as an inseparable part of the receipt step.