Choose a diagnostic LIS using sample and result handovers
For Diagnostic/specialty operations director · Compare approaches
TL;DR — what you’ll learn
- Evaluate a diagnostic laboratory information system using the journey from order to authorised report.
- Keep collection, receipt, acceptance, result review and report release distinct.
- Include rejected samples and corrected reports in the demonstration.
- Verify instrument interfaces and downtime recovery in the proposed configuration.
A laboratory demonstration follows a clean sample from barcode printing to report delivery. The first week of real work also contains a rejected sample, an instrument message sent twice and a report corrected after release. Those cases reveal whether the system preserves the laboratory's decisions.
Evaluate the LIS with scenarios approved by the laboratory’s responsible staff. This guide covers record identity and handovers; specimen suitability, test validation and report-release criteria remain outside its scope. A barcode demonstration cannot establish those clinical or quality decisions.
Keep the diagnostic scope clear
Laboratory information system searches also surface industrial and research LIMS products. Begin with the diagnostic service's record relationships: a person, encounter or order, sample, test request, result version and report. Determine which relationships the laboratory must preserve across its sites and instruments.
MocDoc's sample-management page describes collection, rejection and tracking features. Use such documentation to identify demonstration topics, not as evidence that a particular configuration meets your laboratory's acceptance or accreditation requirements.
Follow an exception through the same order
In an illustrative batch, order O-21 has sample S-21 received for review. Authorised laboratory staff reject it under the applicable local procedure. A replacement sample receives S-22 and remains linked to O-21. The original sample and rejection reason stay visible; staff do not overwrite S-21 with the replacement's details.
Scroll horizontally to see all columns.
| Event | Record that should remain inspectable |
|---|---|
| Initial receipt | Sample identity, time and receiving actor |
| Rejection decision | Authorised decision, reason and order link |
| Replacement collection | New sample identity linked to the request |
| Result review | Result version and authorised reviewer |
| Report correction | Original and corrected versions plus release history |
This is a record-design example. The laboratory's qualified owners determine specimen suitability, repeat testing and release criteria; the article does not prescribe those criteria.
Treat a corrected report as a new controlled event
For a synthetic corrected report, ask the laboratory to supply its required approval, notification and history rules, then test the software against them. Preserve an unresolved notification as an open task in the example. This is a record-evaluation scenario, not a universal corrected-report procedure.
Do not demonstrate correction by silently replacing a PDF. That obscures what was available when an earlier decision was made. Test whether external systems receive the appropriate correction reference and whether a failed delivery remains visible.
Compare barcode tracking with instrument integration
Ask separately for evidence of barcode handling and the proposed instrument connection. Record the instrument model, protocol, software versions, mapping and support owner. Treat undocumented or untested interoperability as unresolved rather than inferring it from a general LIS feature claim.
Worked workflow
Original illustrative workflow. Follow the labelled transitions, including the exception paths.
- A · StepSample arrives
- B · StepRecord receipt
- C · DecisionAuthorised acceptance decision
- D · StepTesting and result workflow
- E · StepLaboratory exception and follow-up
- F · DecisionAuthorised release
- G · StepRestricted review queue
- H · StepVersioned report delivery
- I · DecisionDelivery reconciled
- J · StepOwned delivery exception
Scroll horizontally to see all columns.
| From | Condition | Next |
|---|---|---|
| A: Sample arrives | Continue | B: Record receipt |
| B: Record receipt | Continue | C: Authorised acceptance decision |
| C: Authorised acceptance decision | Accepted | D: Testing and result workflow |
| C: Authorised acceptance decision | Rejected or uncertain | E: Laboratory exception and follow-up |
| D: Testing and result workflow | Continue | F: Authorised release |
| F: Authorised release | Pending | G: Restricted review queue |
| F: Authorised release | Approved | H: Versioned report delivery |
| H: Versioned report delivery | Continue | I: Delivery reconciled |
| I: Delivery reconciled | No | J: Owned delivery exception |
The diagram describes responsibility rather than a clinical protocol. A successful interface message must not impersonate the laboratory's acceptance or release decision.
Rehearse the interrupted operating day
Use two synthetic report versions to expose the delivery boundary. Report R-21 version 1 was released and delivered; version 2 is subsequently authorised as a correction. The receiving interface acknowledges the correction, but one intended recipient's delivery remains unresolved. The LIS should show the current authorised version and the outstanding delivery task without erasing version 1's history or treating technical acknowledgement as completed recipient follow-up. The laboratory must approve the actual notification and acknowledgement requirements.
This is a selection test for the complete diagnostic record lifecycle. The sample-custody pilot examines the narrower collection-to-receipt handover; it does not claim that a received sample or a working barcode proves the full LIS is acceptable.
Run a duplicate instrument message, an unknown order, a missing label reference, a corrected report and a period of offline recording. Agree temporary identifiers and reconciliation before testing downtime. A restored connection should not create extra samples or release results merely because queued messages arrived.
Compare a specialist LIS with a hospital-suite laboratory module using the same cases. Include collection-centre support, export of version history, staffing effort and vendor support ownership. Record each unproven interface as a condition in the procurement decision.
The preferred LIS is the one that lets laboratory staff trace each sample and report version while retaining their decision authority. Automation helps when it carries evidence between those decisions reliably.
Next actions
- Map one diagnostic order with a rejected sample and replacement.
- Add a corrected report and failed delivery to the evaluation script.
- Obtain laboratory approval of the expected states and vendor evidence for each interface.
Discuss this workflow
Request a diagnostic LIS evaluation covering one sample rejection, replacement, corrected report and supported instrument handover.
Describe the operation using business information only. Please leave out patient details.
Applying this guide
The scenarios and numbers are illustrative. Confirm these provider-specific inputs before implementation:
- Laboratory director and quality manager: Current applicable laboratory SOPs and accreditation material; validate the synthetic sample/order lifecycle.
- Authorised laboratory clinical lead and quality manager: Approved corrected-report procedure, notification evidence and retention requirements.
- LIS owner, instrument vendors and integration lead: Versioned interface specifications and demonstration of duplicate messages, unknown orders and report corrections.
References
- MocDoc sample management — Advertised collection/tracking topics; not clinical sample criteria, accreditation or outcome evidence.
Topics: laboratory information system · diagnostic laboratory software · LIS selection India · pathology lab information system