A pathology lab that retypes patient details from paper orders, or prints reports for someone to scan into the medical record, carries risk and cost at both ends of every case. This article explains LIS integration with hospital systems for lab managers, hospital IT teams and project leads who need to plan interfaces that actually hold up in daily use.
We cover the main standards, HL7 version 2 and FHIR, but the harder parts of integration are rarely technical. They are agreements about identity, ownership, testing and what happens when something fails.
What LIS integration should achieve
Before choosing standards or tools, agree on the outcomes. For most anatomic pathology labs these are:
- Electronic orders from the hospital system, so requisition data arrives without retyping.
- Patient demographics kept in sync, including merges and corrections.
- Results delivery of preliminary, final and amended reports to the medical record.
- Status updates so clinicians can see that a specimen was received and is in progress.
- Billing data where the lab charges through the hospital.
Each of these is a separate interface with its own triggers, fields and error handling. Treating integration as a single deliverable is how projects slip.
HL7 version 2: still the workhorse
HL7 version 2 messaging remains widely used in hospitals. It is a pipe-delimited message format, usually sent over a simple network protocol called MLLP, and organized into message types for different events. Order messages carry requests into the lab, result messages carry reports back, and admission and demographic messages keep patient data current.
Version 2 is flexible, which is both its strength and its main problem. Two systems can both claim HL7 v2 support yet disagree on which fields are used, how a narrative report is split into segments, or how an amended report is marked. Every interface needs a written specification that both sides sign off.
Pathology-specific challenges in v2
- Long narrative reports must survive line breaks, special characters and formatting without becoming unreadable in the medical record.
- Amendments and addenda need a clear status so the clinician sees the latest version and knows it changed.
- Multiple parts in a single case may map to one order or several, depending on how the hospital orders specimens.
- Embedded PDFs are sometimes sent alongside text results; agree on whether the PDF or the text is authoritative.
FHIR: web-style APIs for health data
FHIR, short for Fast Healthcare Interoperability Resources, is a newer HL7 standard built on web technologies. Data is organized into resources such as Patient, ServiceRequest, Specimen and DiagnosticReport, exchanged through APIs that modern developers find familiar.
FHIR makes some things easier: querying a patient's prior reports, building apps that read from several systems, and integrating with newer platforms. It is also useful for mobile and portal access to reports.
In practice, many hospitals run both. Core order and result flows may stay on HL7 v2 because they already work, while new projects use FHIR. Ask what your hospital's integration engine and medical record actually support today, not what is on the roadmap.
Images: DICOM and beyond
If your lab scans slides, whole slide images raise their own integration questions: where images are stored, how they link to the case and report, and whether clinicians or other hospitals can view them. DICOM has extensions for whole slide imaging, which helps image management across vendors. For more detail, see WSI file formats and DICOM.
Patient identity: the hardest part
Most serious interface problems are identity problems. A report attached to the wrong patient in the medical record is a significant safety event.
- Agree on the identifiers each system uses and which one is authoritative.
- Handle merges and corrections. When the hospital merges duplicate records, the LIS must follow.
- Match orders to specimens reliably, so a specimen received without an electronic order is not attached to the wrong one.
- Define a manual reconciliation process for messages that cannot be matched automatically, with clear ownership.
Access to these queues matters too. People resolving mismatches see patient data across many cases, so their permissions should be deliberate; see role-based access control in laboratory software.
Testing, go-live and ongoing monitoring
Most interface problems surface either during testing or in the first months after go-live, so plan for both.
Testing before go-live
Interfaces fail in ways that are hard to predict from a specification. Plan for realistic testing.
- Build test cases from real scenarios: a resection with many parts, an amended report, a cancelled order, a patient merge, a specimen arriving before its order.
- Test with realistic report text, including long reports and special characters.
- Have clinicians check how results actually look in the medical record, not just whether they arrived.
- Run a parallel period where possible, comparing interface output with the existing process.
- Agree on a rollback plan before go-live.
Monitoring and ownership after go-live
An interface is never finished. Messages fail when either system is upgraded, when a field changes, or when a network path breaks. Someone must be responsible for watching the queues.
Set up alerts for failed or delayed messages, and define who responds during and outside working hours. Keep a log of interface changes and retest after every upgrade on either side. If you are still selecting a system, include these responsibilities in your evaluation; how to choose an anatomic pathology LIS covers the questions to ask vendors.
Common mistakes
- Assuming two systems that support HL7 will interoperate without a detailed specification.
- Testing only happy paths and skipping amendments, cancellations and merges.
- No owner for interface error queues.
- Forgetting to retest after upgrades.
- Treating PDF reports as a substitute for structured data when downstream systems need discrete fields.
Key takeaways
- LIS integration is several interfaces, each with its own triggers, fields and error handling.
- HL7 v2 remains common for orders and results; FHIR is growing for queries, apps and new projects.
- Patient identity and amended reports are where most serious problems arise.
- Test with realistic, awkward cases and check how reports look to clinicians.
- Assign clear ownership for monitoring interfaces after go-live.
If you are planning how PATHOLOGY+ would fit alongside your hospital systems, our team can talk through your current interfaces and constraints. Book a demo to start the conversation.