1Match each LabVantage value to its full data-item identity.
Seal’s LabVantage binding is read-only. It issues GET requests to approved REST web services and passes the JSON response to your Seal Scripts; it does not write to the LIMS. A sample and analyte name can still identify several datasets or replicates, so the Script should match each value on its complete identity. That keeps an original measurement, a replicate and a later remeasurement distinct in Seal.
2Choose the source route.
Read through an approved REST service
LabVantage documents REST and SOAP web services that apply its application business logic. Seal’s binding uses REST reads only; SOAP, cookies, multiple headers and request signing need an approved gateway or additional native support.¹
In Seal: Obtain the web-service contract for the installed release. In Settings → Integrations → LabVantage, enter the narrowest approved HTTPS prefix, a test resource path and the header for a read-only service account. Do not substitute a guessed /samples endpoint or a direct database query.
Carry the data-item identity through the read
LabVantage qualifies a data item by its record keys, parameter list with version and variant, dataset, parameter, parameter type and replicate. Which of these fields a web service returns depends on its contract.²
In Seal: Have the Script match each returned value on that full identity, not on the sample label and analyte name. If the service omits dataset or replicate, ask the LabVantage owner for a contract that returns them before mapping values into Seal.
Keep lifecycle status as source evidence
LabVantage treats sample entry, testing and review as separate stages of the sample lifecycle.³
In Seal: Confirm whether the service returns draft, authorised or corrected values, and store the returned status beside each value. Seal does not interpret laboratory approval; an unfamiliar status stays visible for the source owner to resolve.
3Read one sample’s data items and match them on full identity.
Seal’s LabVantage binding is read-only: it issues GET requests to approved REST web services and does not write to the LIMS. Use a test sample with one parameter list, two replicates and, if practical, a second dataset. The aim is a read whose values your Script places on the right data item every time.
Download the first-run procedure and receiving checks
Obtain the web-service contract
With the LabVantage owner, identify the installed release, the REST service that returns the intended data items and a read-only service account. Confirm the authentication header it needs: Authorization, X-API-Key or apikey. SOAP, cookies, multiple headers and request signing need an approved gateway or additional native support.
Check: The contract names the resource path and the fields it returns, including the identity fields in the map below. Do not substitute a guessed /samples endpoint or a direct database query.¹
Connect and test in Seal
Open Settings → Integrations → LabVantage. Enter the narrowest approved HTTPS API prefix and a relative test resource path, then choose Test and connect. Select the resources the Script needs and grant its Seal API key access.
Check: The test issues a GET and requires a bounded JSON object or array. Choose a test resource that reveals no unintended laboratory data. A successful test shows connectivity and readable JSON, not analytical correctness.
Compare the returned identities with LabVantage
Read the resource for LV-S910 in a Script with integrations.get and inspect fields.response. Compare each value with the LIMS view: record keys, parameter list, version, variant, dataset, parameter, type and replicate.
Check: Every value can be placed on exactly one data item. If the response lacks dataset or replicate, stop and ask for a contract that returns them rather than matching on sample and analyte.²
Record status and unit with each value
Confirm whether the service returns draft, authorised or corrected values, and which custom fields it exposes. Record the unit configured for the measurement with the LabVantage owner.
Check: The Script stores the returned status beside each value. Seal does not interpret laboratory approval, so an unfamiliar status stays visible instead of being mapped to Approved.³
Read every page before counting results
The complete response, including any pagination envelope, is in fields.response. The binding does not follow pagination or fetch linked records, so the Script must request each page the contract describes.
Check: The number of data items in Seal matches the LIMS for the test sample. A partial page is not treated as a missing result, and a JSON response carrying an application error is not treated as data.
Decide what each read outcome means
These are proposed decisions for the worked sample. Seal’s version for each read is a content hash and its time is the read time; neither is a LIMS revision or approval.¹
| Read evidence | Decision | Recorded outcome |
|---|---|---|
| Same value on the exact data item as the last read | Keep the existing Seal result | Unchanged; the read is another observation. |
| Different value on the exact data item | Record the change against the same identity | Changed, with both values and read times kept for review. |
| Value on a new dataset | Create a separate result | A remeasurement, not a correction to the earlier dataset. |
| Value with incomplete identity | Do not match on sample and analyte alone | Unresolved until the service returns the full identity. |
| Read fails or returns something other than JSON | Do not treat it as an empty result | Failed read. The binding never returns an older capture as current data. |
Three glucose data items for one sample
Fictional 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 not the output of a live LabVantage read.
sample,dataset,replicate,value,unit
LV-S910,1,1,1200,mg/L
LV-S910,1,2,1190,mg/L
LV-S910,2,1,1180,mg/LThree values, three data items. Two are replicates in dataset 1; the third is a remeasurement in dataset 2. A match on sample and parameter alone would find three candidates for each row.
4Three glucose values for one sample: two replicates and a remeasurement.
Fictional response fragment using LabVantage data-item property names. Your service’s field names and nesting depend on its contract; the unit was confirmed separately with the LIMS owner. The destination is a proposed Seal record design, not an API payload.
| 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 need their additional keys. |
| Test definition | paramlistid + paramlistversionid + variantid | GLUCOSE / 3 / Routine. Keep the version the result was recorded against rather than the current one. |
| Assigned execution | dataset | Dataset 1 is separate from a remeasurement assigned to dataset 2. |
| Individual measurement | paramid + paramtype + replicateid | Glucose / Standard / 2. Replicate 1 is a different data item under the same sample and dataset. |
All three values share a sample, parameter list and analyte. Matching on those alone would collapse them, or let one overwrite another. On the full identity, dataset 1 holds two replicates and dataset 2 is a separate remeasurement. A later read that returns 1185 for dataset 1, replicate 2 is a change to that data item, not a fourth result.
Inspect the source and proposed destination records
Source example
{
"sdcid": "Sample",
"keyid1": "LV-S910",
"paramlistid": "GLUCOSE",
"paramlistversionid": "3",
"variantid": "Routine",
"paramid": "Glucose",
"paramtype": "Standard",
"confirmedUnit": "mg/L",
"dataItems": [
{
"dataset": "1",
"replicateid": "1",
"enteredtext": "1200"
},
{
"dataset": "1",
"replicateid": "2",
"enteredtext": "1190"
},
{
"dataset": "2",
"replicateid": "1",
"enteredtext": "1180"
}
]
}Proposed Seal records
{
"sample": "LV-S910",
"parameterList": "GLUCOSE",
"parameterListVersion": "3",
"variant": "Routine",
"parameter": "Glucose",
"parameterType": "Standard",
"results": [
{
"dataset": "1",
"replicate": "1",
"value": "1200",
"unit": "mg/L"
},
{
"dataset": "1",
"replicate": "2",
"value": "1190",
"unit": "mg/L"
},
{
"dataset": "2",
"replicate": "1",
"value": "1180",
"unit": "mg/L"
}
],
"distinctDataItems": 3
}5Run these cases against the proposed Seal mapping.
These are worked test inputs and expected outcomes to verify in your configured connection.
Read the same resource twice
Input: Repeat the read with no change in LabVantage.
Expected: Seal still holds three results. The second read is recorded as another observation and creates nothing new.
Correct one value in the source
Input: In the test system, correct dataset 1, replicate 2 from 1190 to 1185 mg/L through the normal laboratory workflow, then read again.
Expected: The same Seal result records the change from 1190 to 1185 with both read times. There is no fourth result.
Remove the replicate field
Input: In a saved test response, remove replicateid from the dataset 1 values.
Expected: The Script leaves both values unresolved instead of matching them on sample and analyte, and names the missing field.
Return an unmapped status
Input: Use a status code in a test response that the mapping does not yet recognise.
Expected: The value keeps the source status and stays out of any approved count until the source owner defines it.
What to bring to the implementation review
Provide the web-service contract, the identity map, the configured unit and status codes, and the comparison between the LIMS view and the Script’s read. Seal can then keep each LabVantage value on its own data item, with a source link Neil can cite.
6Diagnose the failure from the source evidence.
Values from different replicates overwrite each other
The Script is matching on sample and analyte, which several data items share.
Add dataset and replicate to the match key. If the response does not return them, pause the Script and ask the LabVantage owner for a service that does.
The connection test fails or returns HTML
The binding needs a GET that returns a bounded JSON object or array, authenticated with one Authorization, X-API-Key or apikey header.¹
Use the REST resource path from the installed contract, not a login page or SOAP endpoint. For SOAP or cookie-based services, the site needs an approved gateway.
A corrected value appears without its earlier value
Each read returns the service’s current view. Seal records its own read time and a content hash, not a LIMS revision.
Confirm whether the service returns corrected values and their source timestamps. Keep each read’s value and status in Seal so a change on the same data item stays visible.
7Apply this to your records
Use this with the LabVantage data-item read first-run procedure. Retain the actual configuration and evidence, then record what happened in each receiving exercise. Expected behaviour 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 release, the REST service and resource path, the authentication header name (never the credential) and the read-only account. Note whether the service returns draft, authorised or corrected values.
For each value, retain the record keys, parameter list, version and variant, dataset, parameter, type and replicate. Show that the Script matches on this full identity and how it handles a response that omits part of it.
Compare each value read and its configured unit with the LIMS view. Record unchanged, changed, new-dataset and unresolved outcomes separately, with the source status beside each value.
Input: Repeat the read with no change in LabVantage. Expected: Seal still holds three results. The second read is recorded as another observation and creates nothing new. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Input: In the test system, correct dataset 1, replicate 2 from 1190 to 1185 mg/L through the normal laboratory workflow, then read again. Expected: The same Seal result records the change from 1190 to 1185 with both read times. There is no fourth result. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Input: In a saved test response, remove replicateid from the dataset 1 values. Expected: The Script leaves both values unresolved instead of matching them on sample and analyte, and names the missing field. Record the actual input/evidence references, observed result, whether it matches the expectation and any unresolved issue.
Input: Use a status code in a test response that the mapping does not yet recognise. Expected: The value keeps the source status and stays out of any approved count until the source owner defines it. 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 value read from LabVantage sits on exactly one data item, the population matches the LIMS for the test sample and a value with incomplete identity stays unresolved. The binding makes no changes in LabVantage.
8Use the connected evidence in a review.
Ask Neil to list the glucose results read for LV-S910 by dataset and replicate, and to flag any value whose source identity is incomplete. The summary should keep the dataset 2 remeasurement separate from the two dataset 1 replicates.