1. Map authority from worklist to filed result
Name the authoritative system for worklist and sample identity, plate and source file, approved method, analysis configuration, calculated result, review or release status, report, and final laboratory filing. Document every manual and automated handoff.
Assign stable request, run, plate, sample, method, analysis, result, and report identifiers. Carry the original identifiers through every transformation so the LIMS result can be traced back to the exact analysis and source.
2. Approve the versioned data contract
Define field names, types, lengths, required status, units, controlled vocabularies, time-zone reference, qualifiers, status transitions, report references, format version, and error schema. Separate the calculated scientific result from review, approval, and release decisions.
A minimal worked result might carry request RQ-1042, analysis AN-8821, result RS-8821-1, endpoint relative_potency, value 80.0, unit %, suitability PASS, method RP-4PL-v3, and report RP-8821.pdf. The receiver validates each field rather than accepting an opaque result string.
{"format_version":"1.0","request_id":"RQ-1042","analysis_id":"AN-8821","result_id":"RS-8821-1","endpoint":"relative_potency","value":80.0,"unit":"%","suitability":"PASS","method_id":"RP-4PL-v3","report_id":"RP-8821.pdf"}| Result field group | Example retained content |
|---|---|
| Identity | RQ-1042, AN-8821, RS-8821-1, and RP-8821.pdf |
| Scientific result | relative_potency = 80.0 % |
| Decision evidence | Suitability PASS under RP-4PL-v3 |
| Source traceability | Source and configuration fingerprints plus immutable report identity |
| Workflow state | Calculated result kept distinct from review or release status |
3. Validate the transaction before sending
Confirm that the source analysis is complete and in an allowed state, all required identities agree, values are finite and in the declared units, qualifiers and criteria are valid, the report exists, and the payload matches the approved schema version. Reject unsupported versions, unknown units, missing identifiers, invalid status transitions, and unexpected fields according to the approved contract.
Create one immutable payload and idempotency key. Record its content identity, producing release, creation time, and authorization so a retry sends the same transaction rather than rebuilding a subtly different one.
- Validate the payload against the exact schema version.
- Reconcile request, analysis, result, method, and report identities to the source analysis.
- Reject unknown units, qualifiers, states, or nonfinite values.
- Create an immutable payload identity and idempotency key.
- Authorize the transaction only from an allowed analysis state.
- Retain the validation outcome before the first send attempt.
4. Deliver securely and expose every attempt
Use authenticated service identities, least privilege, encrypted transport, protected credentials, controlled endpoints, bounded retries, and monitored queues or transfer locations. Record each attempt, response, error, and next eligible action.
A timeout is an unknown outcome, not proof of failure. Keep the transaction in a visible uncertain state until the receiver can confirm whether it committed the idempotency key.
5. Require a business acknowledgement
The receiver validates identity, format version, units, allowed state, duplicate key, and business rules, then returns an accepted or rejected status with a stable acknowledgement identity and error details. Network receipt alone is not acceptance.
Store the exact sent payload and received acknowledgement together. Rejected records remain visible with their error, owner, and approved retry or correction path.
6. Reconcile both systems and investigate exceptions
On a defined schedule and after outages, compare request and result identities, payload identity, value, unit, qualifier, status, report link, and acknowledgement. Detect missing, duplicate, mismatched, rejected, unacknowledged, corrected, and superseded records.
Assign every exception an owner, investigation, resolution, approval, and completion time. Reconciliation closes the evidence gap between sender logs and the receiver’s actual records.
7. Correct by linking a new transaction to the old one
A corrected result uses a new identity, references the superseded result and reason, follows the required review or release procedure, and preserves both versions. The LIMS should display which result is current without deleting the earlier transaction.
Retain requirements, risk assessment, configuration, test evidence, deviations, access, payloads, acknowledgements, errors, retries, reconciliation, corrections, monitoring, and change approvals. Revalidate affected paths when the contract, system, security, or workflow changes.
Limits and current Provenarium support
Start with a documented file exchange if it helps both teams prove the contract, but do not call a file drop an automated integration until delivery state, acknowledgement, retry, monitoring, reconciliation, and correction are controlled.
Provenarium does not currently ship a standard LIMS or ELN connector or public customer API. The transport and payload examples are implementation guidance; a customer-specific connector and its validation are separately scoped.
Frequently asked questions
Should the LIMS receive every fitted parameter?
Send the fields required for downstream use and retain a link to the complete analysis. Avoid placing an undocumented block of JSON inside a single result field.
Why use a job queue for analysis or delivery?
A reliable queue can preserve work through temporary failures and long-running analyses. It still needs unique request identifiers, visible status, monitoring, and checks for missing or duplicate results.
Can CSV be validated?
Yes, but define the encoding, delimiter, fields, identifiers, units, format version, error handling, and transfer controls. JSON or an API is not automatically safer without equally clear rules.