
TL;DR
Lab integration connects a laboratory information system (LIS) with analyzers, middleware, EHRs, billing platforms, patient channels, and external applications to automate the movement of orders, results, and billing data. Effective integration reduces manual data entry, minimizes errors, speeds up result delivery, and improves revenue tracking. Labs typically use ASTM or HL7 for instrument communication, HL7 v2 and FHIR for healthcare data exchange, and APIs or webhooks for custom integrations. Choosing the right integration approach requires evaluating instrument compatibility, middleware requirements, data mapping, billing workflows, security, and ongoing support. Ultimately, successful lab integration depends on connecting every system into a reliable workflow – not simply establishing individual interfaces.
FHIR is often described as the standard that will retire HL7 v2. The numbers disagree. In a 2023 national survey of health information exchanges, summarized by ASTP/ONC, most still exchanged HL7 v2 messages routinely, while FHIR API adoption was slower. Lab integration follows the same pattern: new connections get added beside old ones, and very little gets fully replaced. That is why integrated lab systems are better understood as a stack of separate connections, each with its own standard, owner, and way of failing.
Lab integration is the exchange of orders, results, and billing data between the LIS and six kinds of connected systems: instruments and analyzers, middleware, EHRs and hospital systems, billing and revenue cycle tools, patient channels such as apps and messaging, and APIs for analytics and partners.
This guide is the map. It covers each layer, gives you a decision table, and ends with the questions to ask before you sign. Linked guides go deep on individual layers, so this page stays at overview depth.
Lab integration means every order, result, and charge reaches the next system without a person retyping it. Three terms get used as if they were interchangeable, so here is how this guide, and the rest of the Lab Integration cluster, uses them.
| Term | What it means | Example |
|---|---|---|
| Integration | The outcome. Systems share data so a workflow runs from order to payment without manual handoffs. | A result moves from analyzer to LIS to EHR to invoice without being retyped. |
| Interfacing | The technical link between two specific systems. | One analyzer connected to the LIS. |
| Interoperability | The ability of different systems to exchange data and use it correctly, usually through shared standards such as HL7 and FHIR. | An EHR files a lab result as structured values because both sides follow the same standard. |
A lab can have dozens of working interfaces and still lack integration, if the data they carry does not line up across the workflow. When integration is missing, it shows up in three places:
The LIS sits at the center of all of this. It is your system of record, holding the order, the sample, the result, and the validation trail, and every layer connects around it. If that record is shaky, each integration copies the problem faster, so LIS integration starts with a clean record. If you run a LIMS rather than a clinical LIS, the same six layers apply, and CrelioHealth’s LIMS integration page covers the product side.
Six layers cover nearly everything a lab connects. Each asks one main question. Whether you call the result lab integration software or a lab interface system, it has to cover all six rows.
| Layer | What connects | Typical standard or method | Key decision | Go deeper |
|---|---|---|---|---|
| Instruments and analyzers | Analyzers, sample handlers | ASTM or HL7 messages over serial (RS232) or network (TCP, LAN) connections | One-way or two-way? | Why instrument interfacing matters |
| Middleware | Instrument-to-LIS rules layer | Middleware interface, or custom drivers and emulators for older analyzers | Needed or not? | See the instruments section below |
| EHR, EMR, and HIS | Client and hospital systems | HL7 v2, FHIR | Orders, results, or both? | LIS vs EHR vs HIS vs RIS |
| Billing and RCM | Payer, point-of-sale, and invoicing systems | Built-in billing, or an interface to separate RCM software | Native or third party? | Lab revenue cycle management guide |
| Patient and portal | Apps, messaging, portals | Messaging platforms such as WhatsApp and SMS, apps, portals | Which channels? | WhatsApp integration for labs |
| APIs and data | Analytics, ERP, partner systems | APIs, webhooks, FHIR | Build or buy? | CrelioHealth API documentation |
Read the table from the key decision column. If you can answer all six questions for your lab, you have already defined most of an integration project. If you cannot, you have just written your scoping list.
An instrument interface is a software link that carries data between an analyzer and the LIS. The analyzer sends results to the LIS. In a two-way interface, the LIS also sends the analyzer its test orders, usually keyed to the sample barcode. The link removes manual result entry and the transcription errors that come with it.
This is where most labs start, and where lab instrument interfacing earns its keep. Lab interface software and lab instrument integration software describe the same idea: a driver that speaks the analyzer’s language and a connection that delivers its output to the LIS.
| Aspect | One-way | Two-way |
|---|---|---|
| Direction | The analyzer sends results to the LIS. | The analyzer also receives orders from the LIS. |
| Who tells the analyzer what to run | Staff at the analyzer. | The LIS, after the analyzer scans the sample barcode. |
| Best fit | Analyzers that cannot support two-way communication. | Analyzers that support it, where manual ordering costs time. |
| Watch for | Mismatches between the order and the result. | Barcode quality and test code mapping. |
The instrument often makes this choice for you, because not every analyzer supports two-way communication.
Middleware is software between the instruments and the LIS. It applies rules, such as autoverification or rerun logic, before results reach the LIS. These three questions tell you whether you need it:
A lab interface system is only as useful as the instruments it supports, so check whether your analyzers are supported before any architecture debate.
For a real example, read the Arpan Diagnostic Centre story. The Rajkot lab interfaced a Sysmex XN-series analyzer so that analyzer flags appear on the LIMS reporting screen, and technologists no longer check the analyzer separately before reporting. For the basics, see why lab instrument interfacing is a must today.
A lab connects to an EHR by exchanging electronic orders and results in a standard message format. HL7 v2 remains widely used; FHIR, which exchanges data through web APIs, is growing. The EHR sends the order, the LIS processes it, and the result returns to the clinician’s chart.
That is EHR lab integration in one breath. HIS and LIS integration follows the same pattern, except that a hospital information system also owns registration, billing, and ward workflows around the lab. The post on LIS vs EHR vs HIS vs RIS explains who owns what, and the hospital management software post covers the hospital side. The goal throughout is laboratory interoperability: results that arrive in a form the receiving system can file, trend, and act on.
The instrument often makes this choice for you, because not every analyzer supports two-way communication.
Step five hides the hardest work. In a December 2023 ONC Annual Meeting session, the Association of Public Health Laboratories (APHL) named lack of standardization as the biggest challenge in lab data exchange. The ASTP/ONC deck points to three places it shows up:
So when a vendor says it supports HL7, ask who builds and maintains the code mapping, and which version your partner actually runs.
You will probably meet both in an HL7 FHIR lab project. This table shows where each tends to fit.
| Use case | Typical fit | What to ask |
|---|---|---|
| Orders and results with an established hospital or EHR interface | HL7 v2 messages | Which v2 version does the partner use, and who maintains the field mapping? |
| Live lookups, patient apps, partner access to individual results | FHIR APIs | Which FHIR release and which resources are supported? (US Core lab reporting uses DiagnosticReport and Observation with LOINC coding.) |
| Structured data for analytics and reporting | FHIR, or v2 converted to FHIR | Where does the conversion happen, and who validates it? |
| A mixed environment, which describes most labs | Both, with translation | Which side translates, and what happens when a message fails? |
For more depth on the standard, read CrelioHealth’s post on FHIR in healthcare and lab interoperability.
Outreach labs face a different problem. The EHR belongs to your client, not to you, so each new client can mean a new interface and a new IT team. A portal alone often leaves a gap between result and decision; see why standalone lab portals fall short.
Billing is where lab software integration pays or leaks money most visibly. Four things move out of the LIS, and each carries its own question for the vendor.
| What moves | Where it goes | What to ask |
|---|---|---|
| Orders | Billing system | Does the right price list apply at order entry? |
| Charges | Billing system | Does every resulting test create a charge automatically? |
| Claims or invoices | Payers, clients, patients | Is billing built in, or exported to separate RCM software? |
| Payments | Back to the LIS record | Do point-of-sale and gateway payments post to the same record? |
The key question is native versus bolted on. The lab revenue cycle management guide describes three common setups:
Picture an illustrative reference lab that bills walk-in patients, collection centers, hospital contracts, home collection, and insurance claims, all on different terms. Every export between order and invoice is a place where a test can be run and never charged. Native billing does not make errors impossible, but it gives you one record to check when the numbers disagree.
Go deeper: B2B lab billing automation and billing with an integrated POS machine.
Start with how your patients already reach you, then add channels one at a time.
| Channel | What it does | Turn it on first when | Go deeper |
|---|---|---|---|
| Messaging (WhatsApp, SMS) | Alerts the patient that a report is ready and can deliver the file. | Your patients already use the app daily, and you want no new login. | WhatsApp integration |
| Apps and portals | Give patients and clients access to result history. | Patients or clients keep asking for past results. | Standalone portals |
| Home collection and at-home testing | Adds scheduling, collector tracking, and sample handoff to the data flow. | Your volume depends on convenience. | At-home testing |
For many labs, messaging comes first because it needs no new app and no login. Add a portal or home collection once the demand is visible.
An API is the right tool when the system you need to reach is not a standard clinical one. HL7 and ASTM cover clinical messaging; APIs cover most of the rest. This table shows how to choose.
| Situation | Better fit |
|---|---|
| ERP, accounting, payment gateway, or messaging platform | A prebuilt connector. The integrations page lists these categories. |
| A workflow unique to your lab | APIs and webhooks. |
| A website, patient portal, or partner app that needs live data | APIs and webhooks. |
| An EMR or EHR that exchanges HL7 messages | An HL7 interface. |
For LIMS API integration, CrelioHealth’s developer documentation covers APIs you trigger, webhooks that push events to you, and an HL7 interface for EMR and EHR connections. Once orders, results, and billing share one record, reporting across them also gets simpler. Before you commit to any API, ask the vendor:
Brochures list integrations. Contracts should list deliverables. The gap between the two is where lab software integration projects go wrong.
Question six exists for a reason. CrelioHealth’s own integrations page notes that some integrations with other systems may incur additional charges. That is the kind of line to find before signing, not after.
Turn each brochure phrase into a deliverable you can test.
| Brochure phrase | Contract deliverable |
|---|---|
| "Integrates with all major analyzers" | A named two-way interface for each of your models, validated against a written test plan. |
| "Supports HL7" | HL7 v2 orders and results at a stated version, with a named owner for test code mapping. |
| "Fast go-live" | A written timeline for each interface, with its dependencies listed. |
| "Support included" | Response times and an escalation path in the agreement. |
Most projects pass through five stages. The labels differ by vendor, but the work does not.
| Stage | What happens | What to check |
|---|---|---|
| Scoping | List every instrument, system, and message type in scope, and name one owner on each side. | Does the list match your real environment? |
| Interface build | The vendor configures or builds each interface and maps your test codes. | Who owns the code mapping? |
| Testing | Run real samples and messages through each interface, including reruns, add-on tests, cancelled orders, and corrected results. | Did you test your hardest workflow, not your cleanest? |
| Go-live | Switch over, with a plan for samples that are in flight. | What happens to a result that arrives mid-switch? |
| Monitoring | Watch for failed messages and drifting results. | Are failed messages logged and flagged? CrelioHealth's integrations page says they are. |
What you will need to provide:
Ready to start? Check whether your analyzers are supported or request an integration.
The rule is short. Map your layers, choose per layer, then test with your hardest workflow. Start with the layer that hurts most: instruments, EHRs, billing, patient channels, or APIs. An integration is not finished when the demo works. It is finished when the Friday evening rerun does not need a human.
Check whether your analyzers are supported or request an integration.
Lab integration is the exchange of orders, results, and billing data between the LIS and the systems around it: instruments, middleware, EHRs, billing tools, patient channels, and APIs. The aim is simple. Data moves from one system to the next without anyone retyping it.
An LIS interface is one technical link between the LIS and one other system, such as an analyzer. LIS integration is the broader outcome of many interfaces working together so a workflow runs from order to payment. You can have many interfaces and still lack integration.
Not always. Some labs connect analyzers directly to the LIS. Others add middleware to apply rules such as autoverification before results reach the LIS, or because older analyzers need a translation layer. Ask your vendor which applies to your instruments and workflow.
HL7 v2 sends lab results as messages between systems and is still widely used. FHIR exposes results as individual resources, such as a DiagnosticReport, that other systems can request through web APIs. Many labs run both, with translation between them.
It depends on how many interfaces you need, whether your analyzers are already supported, how quickly your EHR partners respond, and how much validation you require. Treat any quoted timeline as an estimate until scoping is complete, and ask the vendor to list what each stage depends on.
Check the vendor’s interfacing list for your exact make and model, because support can differ between models of the same brand. CrelioHealth’s interfacing list shows which devices are integrated, and you can share details of any instrument that is missing.