Resolve the LabVantage data item before entering or comparing its value
A sample and analyte name can still identify several datasets or replicates. Seal can retain the complete source relationship so a laboratory investigation distinguishes an original measurement, a repeat and a later result change.
Choose the source route
Use the enabled business operation
LabVantage documents REST and SOAP services that use its application business logic, including record relationships and audit behavior. Confirm the enabled operation and permissions in the installed system. LabVantage: LIMS web services and business logic.
In Seal: Record the service URL, operation, action/version where applicable, input contract and read-back route with the mapping. The action examples here describe documented business operations; they are not REST endpoint paths.
Enter an already assigned data item
EnterDataItem uses qualifying properties to match an existing item. The published reference requires parameter-list version, variant, dataset, parameter type and replicate as part of that match. LabVantage: EnterDataItem action reference.
In Seal: Carry the full identity through the exchange. Use it to find the intended source row and link the corresponding Seal result, rather than matching only the sample label and numeric value.
Create missing objects only when that is the intended operation
EnterResultDataGrid can create missing objects under its optional settings. Its reference recommends one data item per call. For released data, releasehandlingrule uses E to error, I to skip posting or O to override. The separate missingdataerrorhandling option uses E to error or I to log missing/invalid data while processing valid rows. LabVantage: EnterResultDataGrid action reference.
In Seal: For a fixed-target recovery test, resolve the target before delivery. Treat creation of another dataset or replicate as a separate outcome to verify, not an automatic way to make a repeated request succeed.
Test one exact data-item target and its recovery path
Use a test sample with an existing parameter list and two assigned replicates. Establish the installed service/action contract with the LabVantage owner before any writes. The public action references below are a starting point for that review, not proof that a particular action is exposed by your service or behaves identically in every release.
Download the first-run procedure and receiving checks
Identify the enabled operation and its read-back route
Record the LabVantage environment, permitted service operation, action name/version if the wrapper exposes actions, and the authorized service identity. Choose a supported query or source view that can retrieve the target and its current value/status before and after the test.
Check: The team can point to the actual configured operation and verify its inputs. A business-action name in documentation is not itself an HTTP endpoint. Keep result entry, review and release operations individually identified.
LabVantage: LIMS web services and business logic · LabVantage: sample lifecycle and review
Resolve the two targets before entering values
Use the identity map below to capture both glucose replicates for LV-S910. Check the parameter-list version and variant against the assigned test definition, then record the unit configured for that measurement. Keep an untouched third dataset or replicate available as a control if practical.
Check: The initial read shows two distinct intended targets with the agreed unit. The proposed values 1200 and 1190 belong to different replicates. Reject an unresolved identity instead of filling whichever row happens to be available.
Apply an explicit policy for existing and released targets
Inspect the selected action’s released-data and missing-object options with the source owner, using the distinctions described below. For this fixed-target exercise, choose a policy that prevents changing released data and does not create another sample, dataset or replicate to recover a missing response.
Check: Save the effective option values from the service wrapper, not just the caller’s intended values. Test the policy on a released disposable target and an absent target. Neither should silently acquire a new result under this evaluation policy.
Compare entered text with the source’s resulting display
After one permitted entry, retrieve the resulting value and associated state through the agreed source route. LabVantage’s EnterDataSet reference explains that result entry can also affect transformed, qualified and displayed values. Capture the applicable calculation/formatting context for the target.
Check: Do not compare only the number sent with a formatted report. In a separate fictional rounding test, entering 1.234 may display as 1.23 under the configured rule; retain what was entered and explain the display transformation rather than treating them as different measurements.
Interrupt the exchange and reconcile each intended row
Use a test harness or saved fixtures to represent a response lost after one result is written. Query both complete target identities before deciding what to resend. Record delivery attempt, expected value, observed value, unit and disposition for each row.
Check: A target with matching destination evidence is recovered as matched. A target with a different value is a conflict for investigation. A target whose read fails remains unresolved. Only a confirmed missing eligible target proceeds through the agreed recovery operation.
Use three recovery outcomes instead of a single retry flag
These are proposed reconciliation decisions for the worked sample. A transport response, scientific value and laboratory release state remain separate evidence.
Scroll across to see every column →
| Read-back evidence | Decision | Recorded outcome |
|---|---|---|
| Exact target and expected value/unit match | Retain the existing data item; do not create another replicate | Matched, with target identity and source observation. |
| Exact target exists with a different value | Investigate source version, mapping and prior entry before any overwrite | Conflict, preserving both the expected and observed values. |
| No eligible target is confirmed | Resolve missing assignment or release eligibility through the source workflow | Blocked for target resolution, rather than auto-creating a scientific repeat. |
| Read-back request fails or lacks identity | Do not infer that the earlier write failed | Unresolved; retain the failed lookup and original attempt. |
| Matching numeric value but wrong replicate | Reject it as recovery evidence for the intended row | The requested target remains unresolved despite the coincidental numeric match. |
Two replicates with an interrupted acknowledgment
Fictional reconciliation worksheet using the documented identity concepts. The shared test definition is GLUCOSE, version 3, variant Routine, parameter Glucose, type Standard; the confirmed unit is mg/L. These are fixture observations, not the output of a live LabVantage execution.
sample,dataset,replicate,expected_text,observed_text,observation
LV-S910,1,1,1200,1200,Matched
LV-S910,1,2,1190,,UnresolvedThe blank observation for replicate 2 means its value has not been established by read-back. It does not mean zero or prove absence. If a later query finds 1190 on that exact target, both rows can be matched without another write. If it finds 1180, retain the conflict rather than overwriting it during recovery.
Replicate 2 needs recovery; replicate 1 already contains its result
Fictional projection using documented EnterDataItem property names. Confirm the applicable action reference and service wrapper for the installed LabVantage release. The destination below is a proposed Seal reconciliation record, not an API payload.
Scroll across to see every column →
| Source information | Example identity or value | Why it stays distinct |
|---|---|---|
| Record identity | sdcid + keyid1 | Sample / LV-S910 in this example. Multi-key record types also require their additional keys. |
| Test definition | paramlistid + paramlistversionid + variantid | GLUCOSE / 3 / Routine. Preserve the selected definition rather than substituting the current version. |
| Assigned execution | dataset | Dataset 1 is separate from a remeasurement assigned to a later dataset. |
| Individual measurement | paramid + paramtype + replicateid | Glucose / Standard / 2. Replicate 1 is a different target even under the same sample and dataset. |
The two replicates intentionally have separate identities. A missing response for replicate 2 does not prove that its write failed; query that exact target before retrying. Matching the 1200 value on replicate 1 neither resolves replicate 2 nor authorizes creating replicate 3.
Inspect the source and proposed destination records
Source example
{
"action": "EnterDataItem",
"target": {
"sdcid": "Sample",
"keyid1": "LV-S910",
"paramlistid": "GLUCOSE",
"paramlistversionid": "3",
"variantid": "Routine",
"dataset": "1",
"paramid": "Glucose",
"paramtype": "Standard",
"replicateid": "2"
},
"enteredtext": "1190",
"overridereleased": "N",
"confirmedUnit": "mg/L"
}Proposed Seal records
{
"sample": "LV-S910",
"parameterList": "GLUCOSE",
"parameterListVersion": "3",
"variant": "Routine",
"dataset": "1",
"parameter": "Glucose",
"parameterType": "Standard",
"reconciliation": [
{
"replicate": "1",
"expectedValue": "1200",
"readBackValue": "1200",
"unit": "mg/L",
"state": "Matched"
},
{
"replicate": "2",
"expectedValue": "1190",
"readBackValue": null,
"unit": "mg/L",
"state": "Unresolved"
}
],
"remainingTarget": "replicate 2",
"expectedScientificResults": 2
}Run these cases against the proposed Seal mapping
These are worked test inputs and expected outcomes to verify in your configured connection.
Recover a lost response without sending the value again
Input: Start with the worksheet above, then provide read-back evidence of 1190 mg/L for dataset 1, replicate 2 under the same test definition.
Expected: Both intended results become matched. There are still two scientific replicates and no third replicate created by recovery.
Find a conflicting value on the correct target
Input: Return 1180 mg/L for the intended second replicate instead of 1190.
Expected: The recovery item records expected 1190 and observed 1180 with the same complete target identity. It remains a conflict for review and does not silently replace the observed result.
Return the expected number on a different dataset
Input: Return 1190 mg/L for dataset 2 while the pending target is dataset 1, replicate 2.
Expected: That observation does not resolve the pending row. The later dataset remains separate source evidence; the original target still needs a valid lookup.
Replay against released or missing targets
Input: Test the effective wrapper policy against a released data item and, separately, a target that has not been assigned.
Expected: Under this evaluation’s explicit policy, released content is unchanged and absent targets do not trigger additional sample/dataset/replicate creation. Each failure retains its target identity and actionable reason.
What to bring to the implementation review
Provide the deployed service/action contract, the full two-target identity map, source unit and calculation rules, effective option settings and the before/after read-back evidence. This lets Seal represent an interrupted exchange as specific matched, conflicting or unresolved rows that neil can explain from the source evidence.
Diagnose the failure from the source evidence
A retry creates another replicate
First-available selection and automatic object creation can change the target of a grid-based operation. LabVantage: EnterResultDataGrid action reference.
Inspect the deployed action’s default-dataset, default-replicate and auto-add settings. Recover against the recorded target. Test repeated submission with no free slot as well as with a free slot.
Released data changes unexpectedly
The published EnterDataItem reference gives overridereleased a default of Y. That default is significant when a service wrapper omits the property. LabVantage: EnterDataItem action reference.
For this fixed-target evaluation, pass N explicitly and test a released target. Confirm the actual wrapper preserves the setting and the existing value remains unchanged.
Some input rows appear to disappear
EnterResultDataGrid documents error and ignore modes for missing data; ignore can continue with valid rows while logging the problem. LabVantage: EnterResultDataGrid action reference.
Reconcile each submitted identity against its destination. A completed outer request is insufficient evidence that every intended data item was populated.
Apply this to your records
Use this with the LabVantage result-entry recovery first-run procedure. Retain the actual configuration and evidence, then record what happened in each receiving exercise. Expected behavior is printed as a prompt; your observed result starts blank.
Download the blank working review
Write your working notes here
Notes stay in this tab and are not submitted. Download them before leaving to keep a copy. Use record references to identify your evidence.
Record the installed version, enabled business operation and service wrapper, action/version reference and explicit released-data or missing-data options. Identify the supported lookup used to verify outcomes; record actual settings rather than relying on undocumented defaults.
For each target, retain SDC and record keys, parameter list/version/variant, dataset, parameter/type and replicate. Show how the source and destination identify the same existing item. List any auto-add/default-selection behavior that could change the target.
Compare intended entered text, configured unit and actual read-back value for every target. Classify matched, conflicting, absent and unresolved outcomes separately. Keep entered, transformed/display and reviewed values distinguishable when those differ.
Input: Start with the worksheet above, then provide read-back evidence of 1190 mg/L for dataset 1, replicate 2 under the same test definition. Expected: Both intended results become matched. There are still two scientific replicates and no third replicate created by recovery. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Input: Return 1180 mg/L for the intended second replicate instead of 1190. Expected: The recovery item records expected 1190 and observed 1180 with the same complete target identity. It remains a conflict for review and does not silently replace the observed result. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Input: Return 1190 mg/L for dataset 2 while the pending target is dataset 1, replicate 2. Expected: That observation does not resolve the pending row. The later dataset remains separate source evidence; the original target still needs a valid lookup. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Input: Test the effective wrapper policy against a released data item and, separately, a target that has not been assigned. Expected: Under this evaluation’s explicit policy, released content is unchanged and absent targets do not trigger additional sample/dataset/replicate creation. Each failure retains its target identity and actionable reason. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Identify the configuration/mapping revision tested, reviewer, open issues and owner for each next action. Cite the retained source and destination evidence. A filled note is not itself an accepted test; record the review decision through your actual process.
Unanswered sections remain marked ‘Not recorded’ in the download.
Evidence needed to finish
Each intended data item has a supported lookup outcome. Recovery targets the exact unresolved item; it neither creates another replicate to hide a failure nor overwrites released data contrary to the chosen policy. All submitted rows have an explicit reconciliation state.
Use the connected evidence in a review
Ask neil to list the two intended glucose replicates for LV-S910, identify which has matching read-back evidence, and prepare the remaining recovery item with its exact dataset and replicate. Keep entry, review and release evidence distinct in that summary.
Inspect repeated-delivery and revised-result cases →