The cover image is a representative scene generated with AI.
When a laboratory result appears on screen, “Did the file arrive?” is only the first question. Veterinary lab integration also needs to connect the result to the right patient, the right order and the right encounter context. Completed delivery does not mean a veterinarian has reviewed the result or that it is ready to share with the client.
This guide is for practice managers, laboratory coordinators and teams evaluating an integration. It is not a guide to interpreting tests or making diagnoses. Follow the data from the device or file into the record and establish who handles uncertain cases.
Make four stages visible#
- Order and identity: Which work was requested for which patient?
- Delivery: How did the device, laboratory or uploaded file provide the result?
- Matching: Which patient and order were associated with it?
- Review and sharing: Who reviews it, when and for which audience?
Finishing one stage does not automatically complete the others. A PDF can be in the patient file while its order is still uncertain. A result can be correctly matched without having been seen by a clinician. The statuses your team uses should make those distinctions understandable.
Our software integration guide covers the wider supplier evaluation. Here, the focus is the path of one result.
Do not match on the patient name alone#
Names can repeat, be shortened or be entered differently. Where an order or specimen reference is available, verify it against the intended patient context. If an identifier is missing or more than one candidate appears, assign the uncertainty for review rather than completing a match by guesswork.
Field | Purpose of the check |
|---|---|
Patient reference | Establish the intended patient record |
Order or specimen reference | Distinguish different studies for one patient |
Specimen and result times | Preserve the context of earlier and later results |
Device or laboratory source | Keep the origin traceable |
Test name and unit | Avoid changing the meaning of the source measurement |
Report status | Distinguish preliminary, completed and corrected output |
Systems may not provide every field in the same way. Ask which information actually arrives and how missing information is handled. The duplicate-record checklist can help structure a separate identity review.
Test manual uploads and device delivery separately#
For a manual upload, the team selects a file and associates it with a patient or visit. A device connection may automate delivery, but matching rules and exception handling still need verification. Support for one method does not establish support for the other.
Vetigen Cortex is our product for bringing results from supported devices into the patient record. Begin an evaluation with the device make, model, software version and current connection method. Do not assume compatibility for every device or laboratory; let us confirm the supported scope using a representative result.
For industry context, IDEXX VetConnect PLUS also describes connecting laboratory data with practice software. That source is not evidence of a Vetigen partnership or a particular supported integration with IDEXX.
Separate unmatched, repeated and corrected results#
An uncertain result needs a visible working state. Establish who reviews it and how it is held until the match is resolved. Quietly losing a result and placing it in the wrong record are both failures to address during evaluation.
A result may arrive again after a connection is restored. Distinguish a new test, a repeated delivery of the same message and a corrected report. Do not discard a result solely because its numeric values match another result. Review the source reference, timing and report status together.
Situation | Behaviour to request in the demonstration |
|---|---|
No patient found | Visible review state and an assigned owner |
More than one candidate | Verification rather than an assumed match |
Same message arrives again | Repeated delivery distinguished from a new test |
Corrected report arrives | Traceability of the earlier version and correction |
Connection is interrupted | Visibility of pending work and a recheck route |
These are proposed acceptance criteria for your installation, not a claim that every listed behaviour is a Vetigen feature. Mark anything not demonstrated as unverified.
Check units, time context and the source document#
Units and reference information should remain understandable in the context supplied by the source. Do not fill missing units or ranges by guessing. Putting measurements from different devices in the same column does not automatically make them comparable; clinical interpretation belongs with the veterinarian.
Specimen time, result time and entry time are different fields. Check that later imports preserve that distinction and that date and time display tells the team which event it is reading.
If a source report is retained, open it and confirm it is the expected document. A successful-upload notification alone is not enough. Ask how the original file and its relationships remain available during an export or system change.
Use six cases for an acceptance check#
Copy the matching worksheet and use test records agreed with the supplier instead of sharing real patient information.
- A routine result with the intended patient and order.
- Two distinct test patients with the same name.
- A missing or conflicting specimen reference.
- A repeat delivery of the same result.
- A new version correcting a previous report.
- An interrupted transfer followed by a recheck.
Record the expected behaviour, observed result, evidence and owner for each case. To mark a case complete, check both that the correct document opens in the intended record and that someone owns the review step. Leave unresolved cases with a named next action and decision date.
This small test set is a starting point. Add a case when your actual device or work pattern introduces a different failure, such as a result arriving before the expected order appears. Keep the test focused on what the practice needs to establish, rather than a long list of features that nobody verifies.
Frequently asked questions#
Does automatic delivery remove the need for human review?#
No. Delivery and matching move data. Clinical interpretation and appropriate sharing remain separate responsibilities. Define the owner of each stage.
Is the task complete when a result appears in the patient file?#
Check the order, time context, document content and review state too. Visibility alone does not show that those checks have happened.
Will our device work with Cortex?#
Check its make, model, version and connection method with the team. Support for a broad device category does not establish identical behaviour for every model.
Review the path from your device to the record#
Prepare a device list. If you are also changing systems, use the migration readiness guide to define the scope of historical results. We can discuss matching and review responsibilities alongside compatibility.
Worksheet#
Copy the CSV below and save it as a UTF-8 .csv file. Import it into Excel or Google Sheets using a comma delimiter. Fill the blank fields for your workflow; the examples contain no real patient data.
Test reference,Scenario,Expected check,Observed result,Evidence,Decision,Owner,Retest date
TEST-01,Routine result,Correct patient and order,,,,,
TEST-02,Two patients with one name,Correct identity-based match,,,,,
TEST-03,Missing specimen reference,Visible review state,,,,,
TEST-04,Repeated delivery,Repeat distinguished from a new test,,,,,
TEST-05,Corrected report,Traceable version relationship,,,,,
TEST-06,Connection interruption,Pending work and recheck route,,,,,Share your device model so we can check compatibility
Start with the make, model and connection method, and talk through your practice's result-delivery workflow.




