EHR & EMR Integration, Built for the Lab
Automated order entry and result delivery between your laboratory and the 100+ EHR and EMR platforms your referring providers already work in. One interface, reused across hundreds of them.
100+
EMR Platforms
400+
Organizations Connected
2M+
Tests Resulted/Year
What EHR and EMR integration actually means
EHR and EMR integration is the electronic connection between a laboratory, or a diagnostic-support partner acting for it, and the electronic record systems clinicians use to order tests and read results. Done right, an order placed in the provider's system reaches the lab without a fax or a re-key, and the result flows back into the same chart automatically.
EMR vs EHR.The terms get used interchangeably; they are not the same. Per HealthIT.gov, an EMR is the digital version of the paper chart within a single practice. An EHR is built to be shared across more than one organization, so it draws on data from every clinician involved in a patient's care and follows the patient from provider to provider. For a lab the practical point is simple: you connect to both, and the connection method matters more than the label.
Integration vs interoperability. Integration is the plumbing, a working interface between two named systems. Interoperability is whether the data means the same thing on both ends once it arrives. A message can integrate perfectly and still be clinically useless if the receiving system cannot map the test code to something it understands. That gap is why the coding standards exist.
Most integration advice is written for the wrong side of the interface
Search “EHR integration” and every result is written from the software buyer's side: a practice wiring its EHR to a handful of apps. A diagnostic lab has the opposite problem. It has to reach outward to the many different EHRs and EMRs its ordering providers use, each a different platform, version, and interface, and make orders and results flow cleanly across all of them.
That is a hub problem, not a point-to-point one. The value is in building an interface once and reusing it across hundreds of provider systems, then owning the messy middle: specimen collection, accessioning, and result mapping that no EHR-side vendor touches. This page is written from that side, the lab's.
How lab-to-EHR integration works
Most lab interfaces are bidirectional: electronic orders come out of the provider's system, and results go back in. Here is the full loop as it runs in production.
Order
A physician places a test order in their EHR or EMR. It carries the patient, the ordering provider, the test, and any ask-at-order-entry answers the test requires (fasting status, collection time, relevant medications).
Transmission
The order crosses the interface to the lab, or to DS2 acting for the lab, as a structured electronic message rather than a fax or a phone call.
Collection & accessioning
The order drives the physical work: the right collection kit is dispatched, the specimen is drawn and labeled with an accession ID, and it moves by courier under chain of custody. This is the step generic integration skips.
Result
The lab runs the test and generates a result, coded so the receiving system files it against the correct test rather than dropping it in as loose text.
Delivery & reconciliation
The result files back into the ordering provider's chart automatically. Results that cannot be matched to an order or a patient fall to a reconciliation queue rather than disappearing.
What carries the data
Three standards do the real work of a lab interface. Two move the message; one makes it mean the same thing on both ends.
The workhorse of lab interfaces
Specific message types carry the traffic: ORM (or the lab-specific OML) for orders, ORU for results in its OBX segments, and ADT to keep patient identity in sync. It is not elegant, and implementations vary, which is why "HL7 compliant" rarely means two systems connect without work.
The modern, required standard
Built on REST APIs and JSON. Under the ONC Cures Act Final Rule, certified health IT must support a standardized API at 45 CFR 170.315(g)(10), built on HL7 FHIR Release 4, the US Core Implementation Guide, and USCDI. New and patient-facing integrations lean here.
What makes a result mean the same thing
Maintained by the Regenstrief Institute, LOINC gives universal codes for lab tests and observations, used inside HL7 and FHIR messages so a result files in the right slot. Mapping a lab's local test compendium to LOINC is where interfaces succeed or fail.
For a fuller treatment of the messaging standards, see the guide on HL7, FHIR & healthcare interoperability or the HL7 & FHIR services page.
Connecting to the major EHR and EMR systems
DS2 runs production interfaces with 100+ platforms. The connection leads with standards, not any one vendor's marketplace, because program names change and the standards do not.
Epic
Industry-standard interfaces: HL7 v2 for order and result messaging and HL7 FHIR (supporting USCDI through US Core) via Epic's standards-based resources, Epic on FHIR.
Oracle Health (formerly Cerner)
The Cerner Millennium EHR, now the Oracle Health Millennium Platform, exposes HL7 FHIR R4 APIs for exchanging lab orders and results.
athenahealth, eClinicalWorks, NextGen & more
Dozens of additional platforms connected through HL7 v2, FHIR, and custom interfaces, whichever fits the provider's architecture.
The point is not the logo. The integration team has usually built to the platform your referring providers use before, so the connection is a known quantity rather than a research project. Epic is a trademark of Epic Systems Corporation; DS2 is an independent integrator.
Lab data exchange sits inside the rules
The ONC Cures Act Final Rule (the agency is now ASTP/ONC) implements the 21st Century Cures Act's information blocking provisions, which prohibit regulated actors from practices likely to interfere with the access, exchange, or use of electronic health information, subject to defined exceptions, and it requires certified health IT to support the standardized FHIR API above.
That matters for labs specifically because lab data is squarely in scope. USCDI, the core data set the standardized API must expose, includes a Laboratory data class covering the test performed, the value or result, and supporting context such as specimen type, result status, units, and reference range. Separately, CLIA requires every lab, at 42 CFR 493.1291, to have an adequate system so that results are accurately and reliably sent from the point of data entry to the final report, and released only to authorized persons. A lab's interface is part of how it meets that standard, not a convenience layered on top.
What actually makes lab integrations hard
The interface is the easy part. The work is in the details generic pages never reach.
Compendium mapping
A lab's orderable and resultable test codes have to map to each EHR's order catalog and to LOINC. Get it wrong and orders route to the wrong test or results file as unmatched text.
Ask-at-order-entry (AOE)
Compliant orders often require extra answers, such as fasting status, collection date and time, or clinical history. Interfaces that drop these generate rejected or incomplete orders.
Patient & provider matching
A result is only useful filed against the right patient and returned to the right ordering provider. ADT feeds and matching logic are what prevent mismatches.
Result structure
Discrete, coded results file cleanly; PDF-only or scanned results do not become actionable data. Units, reference ranges, and abnormal or critical flags all have to survive the trip.
Reconciliation
Orphan results with no matching order, and duplicate patients, need a queue and a human, not silent failure.
Connect Your EMR to the Full DS2 Platform
From order entry to result delivery, DS2's EMR integrations close the loop between your providers and your laboratory.
100+ EMR Platforms Supported
Epic, Oracle Health (Cerner), athenahealth, eClinicalWorks, NextGen, and dozens more. DS2 has production interfaces with the platforms your referring providers use.
Automated Order Management
Physicians place specimen collection orders directly from their EMR. DS2 receives them instantly: no faxes, no phone calls, no portal logins.
Real-Time Result Delivery
Lab results flow back into the ordering provider's EMR automatically, closing the loop and reducing time-to-treatment.
Interfaced With 400+ Organizations
Our integration team has connected DS2 to over 400 healthcare organizations, from single-physician offices to multi-hospital health systems.
API Development Service
For organizations with custom EMR builds or unique connectivity requirements, DS2 offers dedicated API development services.
Dynamic Mapping Capabilities
HL7, FHIR, API, and custom mapping: DS2's platform adapts to your EMR's data format, not the other way around.
DS2 builds and runs the interface as part of moving the specimen and returning the result, so the messy middle does not fall through the cracks between a lab and a separate IT vendor. New to the systems? Read our guide: what is an LIS? or see LIS / LIMS integration.
From Assessment to Go-Live
A structured process that connects your EMR without disrupting your providers' workflows.
Need a custom protocol or clinical trial workflow? Talk to Our IT Team.
EMR Assessment
We identify your EMR platform, version, and integration capabilities, plus any custom configurations or third-party modules that affect connectivity.
Interface Build
Our engineers build the integration using the approach that fits your EMR architecture: HL7 v2, FHIR R4, or a custom API.
Validation & Testing
Testing of order flow, result delivery, and error handling with your clinical team before go-live.
Deployment & Monitoring
Managed go-live with real-time monitoring and dedicated support for a smooth transition for your providers.
EMR and EHR integration questions
What is EHR integration?
EHR integration is the electronic connection between a system that generates or needs clinical data, such as a laboratory, and the electronic health record a clinician uses. For a lab it means orders arrive electronically and results file back into the ordering provider's chart automatically, without faxes or manual re-keying.
What is the difference between an EMR and an EHR?
Per HealthIT.gov, an EMR is the digital chart within a single practice, while an EHR is built to be shared across more than one organization and to follow the patient between them. A lab typically connects to both; the integration method matters more than which term a given system uses.
How do laboratories integrate with Epic?
Through industry-standard interfaces: HL7 v2 messaging for orders and results, and increasingly HL7 FHIR (supporting USCDI via US Core) using Epic's standards-based resources, Epic on FHIR. There is no single proprietary shortcut; a working Epic lab interface is a standards build plus testing against that site's configuration.
What is the difference between HL7 and FHIR?
Both are HL7 standards. HL7 v2 is the older pipe-delimited messaging standard that still carries most lab orders (ORM, or the newer OML) and results (ORU). FHIR is the modern REST and JSON standard now required by US rules for certified health IT. Most labs need both.
How long does an EMR integration take?
It depends on the platform, the interface type, and how much validation the clinical team requires before go-live. The steps are consistent: assessment, interface build, validation and testing, then a monitored go-live. DS2 scopes the timeline against your specific EMR and workflow.
Is lab-to-EHR integration required?
In practice, yes. The ONC Cures Act Final Rule prohibits information blocking and requires certified health IT to support a standardized FHIR API, and referring providers increasingly expect electronic orders and results. A lab that cannot exchange data cleanly falls out of step with its providers and the rules.
References
- 1.HealthIT.gov (ONC/ASTP), EMR vs EHR: an EMR is a digital version of the paper charts in one clinician's office; an EHR is built to share information across more than one healthcare organization and follows the patient.
- 2.HL7 International, HL7 v2.5.1: ORU^R01 transmits observations and results from the producing system (e.g. a laboratory) to the ordering system; ORM^O01 is the traditional general order message (HL7 recommends OML^O21 for lab orders); ADT carries patient administration events.
- 3.HealthIT.gov (ASTP/ONC), Standardized API criterion 45 CFR 170.315(g)(10): requires HL7 FHIR Release 4, the US Core Implementation Guide, and USCDI. The ONC Cures Act Final Rule also implements the 21st Century Cures Act information blocking provisions (45 CFR Part 171).
- 4.ASTP/ONC, United States Core Data for Interoperability (USCDI): includes a Laboratory data class with Tests, Values/Results, Specimen Type, Result Status, Result Unit of Measure, and Result Reference Range (USCDI v6, 2025).
- 5.CLIA, 42 CFR 493.1291 (Test report): an adequate manual or electronic system must ensure results are accurately and reliably sent from the point of data entry to the final report, and results must be released only to authorized persons.
- 6.NLM / Regenstrief Institute, LOINC: a universal code system for identifying laboratory and clinical observations, used as the coded value in HL7 and FHIR messages so results file automatically in the right place.
- 7.Epic on FHIR (Epic Systems Corporation): Epic supports HL7 v2 interfaces and HL7 FHIR (R4, including USCDI via US Core). The App Orchard marketplace was retired in December 2022; current programs are Epic on FHIR / open.epic and Epic Vendor Services.
- 8.Oracle Health Millennium Platform APIs (Oracle): the former Cerner Millennium EHR exposes HL7 FHIR R4 APIs for lab order and result exchange; Oracle completed the Cerner acquisition in 2022.
Ready to Simplify Your Diagnostic Workflow? Let's Talk.
No commitment required. Our team responds within 24 hours.