LIS Integration Services
Bidirectional LIS and LIMS interfaces for orders, results and specimen tracking, built on HL7 and FHIR. Manual data entry goes away, and your lab connects to the full DS2 platform.
1,000+
Integrations Performed
Faster
Integration development than competitors
50%
Lower Cost
What LIS integration involves
A laboratory information system is the system of record for everything a clinical lab does with a specimen: the order, the accession, the result and the report. LIS integration is the work of connecting that system to everything around it, so orders arrive without being re-keyed, results leave without being transcribed, and the specimen's movement between the two is recorded rather than assumed.
Most of that work is not the interface itself. It is the mapping of one system's test list to another's, the handling of results that change after they are first reported, and the acknowledgments that prove a message was delivered. Those are the details this page covers, because they are where integrations succeed or fail. New to the systems? Start with the guide on what a laboratory information system is.
LIS integration vs LIMS integration
The two systems share a vocabulary and differ in what they are built around. An LIS is patient-centered: it exists to turn a clinician's order into a reported result, so its integrations are dominated by orders, results and demographics exchanged with EHRs and physician portals. A LIMS is sample-centered: it manages specimens, workflows and instruments in research, clinical trial and industrial laboratories, so its integrations lean toward instruments, sample tracking, sponsor systems and data pipelines. DS2 builds interfaces for both. The message standards overlap; the data model does not.
The four interfaces around an LIS
Every connection a lab needs falls into one of these families. Most labs have all four, built at different times by different vendors.
Instruments and analyzers
Analyzers send results to the LIS and, on bidirectional links, receive orders from it. Older instruments speak the ASTM-derived protocols now maintained by CLSI as LIS01-A2 and LIS02-A2; newer ones use HL7 v2.5.1 under the IHE Laboratory Analytical Workflow (LAW) profile.
EHRs, EMRs and physician portals
Orders leave the provider's system and results return to it. This is the interface most labs mean by LIS integration, and the one DS2 builds most often: HL7 v2 for the bulk of production traffic, FHIR R4 where the EHR exposes it.
Reference labs and send-outs
Tests the lab does not perform go out as electronic orders and come back as results that have to file against the original accession. The same order and result messages, pointed the other way.
Billing, public health and the DS2 platform
Charges post to revenue cycle systems, reportable results go to public health as electronic laboratory reporting, and operational data (kit orders, pickups, specimen tracking events) flows between the LIS and the systems that move the specimen.
What carries the data
HL7 v2 moves most of the world's lab orders and results. FHIR is how certified EHRs expose the same data as an API. LOINC is what makes a result mean the same thing on both ends.
| Message or resource | Role | What it carries |
|---|---|---|
| OML^O21 / ORM^O01 | Orders | The laboratory order message, introduced in v2.4, and the older general order message HL7 kept for backward compatibility, which many production interfaces still send. Carries the test codes, the ordering provider, ask-at-order-entry answers and specimen details. |
| ORU^R01 | Results | The unsolicited observation result. One OBR per ordered test or panel, one OBX per reported value, with units, reference range, abnormal flags and a result status. |
| ACK | Acknowledgment | Confirms receipt, or reports an application error, for every message sent. Without acknowledgments an interface cannot prove a result was delivered. |
| ADT | Demographics | Registrations and updates from the EHR keep patient identity consistent across systems, which is what the lab's positive identification rules depend on. |
| SPM segment | Specimen | Added in HL7 v2.5, it carries specimen type, collection date and time, source site and condition, the fields a receiving lab needs to judge acceptability. |
| FHIR R4 | APIs | ServiceRequest for the order, Specimen, DiagnosticReport and Observation for the result. US Core profiles define how laboratory results are represented for certified EHR APIs. |
Test codes are mapped to LOINC and units to UCUM so a result files correctly in every downstream system. In the US, the HL7 laboratory implementation guides constrain the base standard for ambulatory lab interfaces: LOI for orders, LRI for results and eDOS for the test directory. For the standards in depth, see the HL7, FHIR & healthcare interoperability guide or the HL7 & FHIR services page.
Where LIS integrations go wrong, and what fixes them
The interface is the easy part. These six are the reasons an integration that passed testing produces a rejected specimen or a misfiled result in production.
Test compendium mapping
The EHR's orderable and the LIS's performable are rarely the same list. Every orderable maps to one or more LIS test codes, with LOINC on the result side so a value means the same thing in every downstream system.
The fix: A maintained compendium with versioning and a change process, agreed before build, not discovered in testing.
Ask-at-order-entry questions
Fasting status, last menstrual period, specimen source, collection time: CLIA requires some of these on the requisition, and an order message that omits them produces a specimen the lab cannot accept.
The fix: Required fields enforced in the ordering system and validated at the interface, with rejections reported back rather than silently queued.
Result status and corrections
A preliminary that is later finalized, a final that is later corrected, a cancelled test: each carries a different status value, and a receiving system that does not honor them shows the wrong result as current.
The fix: Status handling tested for every path, including the corrected report CLIA requires when an error is found.
Partial and unsolicited results
Microbiology reports in stages, panels report piecemeal, and reflex tests produce results nobody ordered. Interfaces built for the simple case break on these.
The fix: Explicit handling for multi-stage reporting, reflex results and add-on tests, with the parent order preserved.
Patient matching
Two systems with two identifiers and no shared registration feed will eventually file a result to the wrong chart. The failure is quiet and the consequence is not.
The fix: Demographic feeds where available, deterministic matching rules, and a queue for exceptions a person reviews.
Acknowledgments, queuing and downtime
Interfaces fail at 2 a.m. and on the day the EHR upgrades. Messages that were sent but never acknowledged are the ones that go missing.
The fix: Application-level acknowledgments, monitored queues with replay, and a documented downtime procedure agreed with the lab.
What CLIA requires the messages to carry
An interface does not change a laboratory's obligations under CLIA; it has to preserve the data those obligations depend on. The order message has to carry what 42 CFR 493.1241(c) requires on a test request: patient identification, the ordering provider, the tests requested, the date and, where appropriate, time of collection, and the specimen source when relevant. The result message has to carry what 493.1291(c) requires on a test report: the patient identification, the laboratory that performed the test, the report date, the test performed, the result with its units or interpretation, and the condition and disposition of any specimen that did not meet acceptability criteria.
When a reported result turns out to be wrong, 493.1291 requires the laboratory to notify the ordering provider promptly, issue a corrected report and keep both the original and the correction. That is why result status handling is tested as hard as the happy path: a receiving system that cannot tell a corrected result from a final one defeats the rule. Protected health information moves on every one of these messages, so each interface runs under a business associate agreement with encryption, access control and audit logging.
What DS2 connects to your LIS
Our integration team has connected more than 1,000 laboratory systems. The interface carries more than orders and results: it carries the specimen's movement.
Bidirectional orders and results
Orders route from the DS2 platform, client portals and provider systems into the LIS; results return to the ordering system without re-keying. Transcription errors go with the manual step.
Specimen tracking events
Collected, picked up, in transit, received and accessioned: the transport record from DS2's courier network is pushed into the LIS, so the window before accessioning is no longer blank.
Kit and requisition data
Kit identifiers, requisition content and collection data captured at the draw arrive with the specimen rather than after it, matched to the accession by the same barcode.
Support for the major platforms
DS2 runs production interfaces with most major LIS and LIMS platforms and more than 100 EHR and EMR systems. If yours is not on the list yet, the integration team builds it.
Custom portals and cost estimators
Client portals and cost estimation tools that read from and write to the LIS, so ordering, pricing and status live in one place for the client.
HIPAA-conscious architecture
Encrypted transport, access controls and audit logging on every interface, with a business associate agreement in place, because a lab's data partner handles protected health information.
Connecting provider systems rather than the lab's own? See EHR & EMR integration for labs and the article on EMR lab integration for CLIA labs. The transport record the interface carries comes from specimen transport & logistics.
From Discovery to Go-Live
A structured, predictable integration process that gets your LIS connected without disrupting operations.
Need a custom protocol or clinical trial workflow? Talk to a kitting specialist.
Discovery & Assessment
We document your LIS platform, the systems on the other end, the order and result formats, the compendium and any custom fields, then agree the scope of the interface.
Interface Development
Integration engineers build the bidirectional interface using HL7 v2, FHIR or the platform's own API, whichever the systems on each side support in production.
Testing & Validation
End-to-end testing with your team against real orderables and result scenarios: normal, abnormal, corrected, cancelled, partial and reflex, plus acknowledgment and downtime behavior.
Go-Live & Support
Monitored cutover with dedicated support through the transition, then ongoing monitoring and technical support for the life of the interface.
LIS integration questions
What is LIS integration?
LIS integration is the connection of a laboratory information system to the other systems a lab depends on: analyzers, electronic health records and physician portals, reference labs, billing and public health reporting, and the platforms that move specimens. In practice it means bidirectional interfaces that carry orders in and results out without manual re-entry, built on HL7 v2 messaging, FHIR APIs or the ASTM-derived instrument protocols maintained by CLSI.
What does LIS integration involve in a modern clinical lab?
Four families of interface: instruments to the LIS, the LIS to EHRs and ordering portals, the LIS to reference labs for send-outs, and the LIS to billing, public health and operational systems such as courier tracking and kit fulfillment. Each one needs a mapped test compendium, agreed message formats, handling for result status changes and partial results, acknowledgments, and a monitoring and downtime plan.
What is the difference between LIS and LIMS integration?
An LIS manages patient-centered clinical testing and reports results to clinicians, so its integrations are dominated by orders, results and demographics exchanged with EHRs. A LIMS manages samples, workflows and instruments in research, clinical trial and industrial labs, so its integrations lean toward instruments, sample tracking, sponsor systems and data pipelines. DS2 integrates with both; the message standards overlap and the data model differs.
Which standards are used for LIS integration?
HL7 v2 carries most production traffic: OML^O21 for orders (or the older ORM^O01 many interfaces still send), ORU^R01 for results, ACK for acknowledgments and ADT for demographics, with the SPM segment for specimen data. FHIR R4 exposes the same content as ServiceRequest, Specimen, DiagnosticReport and Observation resources. LOINC identifies the tests and observations, and instruments commonly use CLSI LIS01-A2 and LIS02-A2, the standards that began life as ASTM E1381 and E1394.
How does EMR and LIS integration work for hospitals?
Hospital orders originate in the EHR, pass to the LIS as HL7 order messages, and results return as HL7 result messages that file to the chart. A demographic feed keeps identity consistent, and an interface engine typically sits between the systems to route, transform and queue messages. DS2 adds the operational layer: courier pickups, specimen tracking events and send-out logistics connected to the same LIS.
Can a reference lab automate result delivery to its clients?
Yes. A reference lab receives orders electronically from client labs and providers, files them against its own accessions, and returns results by HL7 or FHIR to each client's system as tests finalize, including partial, corrected and reflex results. Clients without an interface can receive results through a portal connected to the same LIS.
What does CLIA require of the data an interface carries?
The order has to carry the test request elements in 42 CFR 493.1241(c), including patient identification, the ordering provider, the tests requested, collection date and time and specimen source where appropriate. The result has to carry the test report elements in 493.1291(c), including the laboratory that performed the test, the report date, the result with units or interpretation and the condition of any unacceptable specimen, and corrected reports must be issued when errors are found. The interface does not change the obligation; it has to preserve the data.
References
- 1.HL7 Version 2.5.1, Chapter 4 (Order Entry) and Chapter 7 (Observation Reporting): ORM/OML order messages, ORU^R01 results, the OBR and OBX segments and result status tables.
- 2.CLSI LIS02-A2, Specification for Transferring Information Between Clinical Laboratory Instruments and Information Systems (formerly ASTM E1394); LIS01-A2 covers the low-level protocol (formerly ASTM E1381).
- 3.IHE Pathology and Laboratory Medicine (PaLM) Technical Framework, Volume 2b, Laboratory Analytical Workflow (LAW) profile: HL7 v2.5.1 based communication between analyzers and the analyzer manager, typically the LIS or LAS.
- 4.HL7 FHIR R4: ServiceRequest, Specimen, DiagnosticReport and Observation resources; US Core laboratory result profiles.
- 5.LOINC, the universal code system for laboratory tests and observations, maintained by the Regenstrief Institute.
- 6.42 CFR 493.1241 (CLIA, Standard: Test request) and 42 CFR 493.1291 (CLIA, Standard: Test report): the elements a requisition and a test report must contain, and the requirement to issue corrected reports.
- 7.CDC, Electronic Laboratory Reporting (ELR): transmission of laboratory reports to public health departments. Messaging follows the HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm), adopted at 45 CFR 170.205(g).
Ready to Simplify Your Diagnostic Workflow? Let's Talk.
No commitment required. Our team responds within 24 hours.