Lab Integration: The Complete A to Z Guide (2026)

Updated October 2026

Lab integration connects a laboratory's software to the systems that order tests and use the results: EHRs, clinics, hospital systems, digital health apps, lab instruments and public health agencies. A working lab interface sends an electronic order to the laboratory information system (LIS), returns each result to the right patient and order, and handles corrections, rejections and critical values without anyone retyping data.

This guide covers lab integration from A to Z. It explains every way to connect a lab, from a fax and a portal to HL7 v2 interfaces, integration engines, FHIR APIs, lab networks, instrument middleware and public health reporting. It shows how an order travels to a result, which standards and codes each method uses, what Labcorp, Quest and Epic Beaker allow, where interfaces fail in production, the rules in the US, UK and EU, and how a project runs from discovery to go-live.

What is lab integration?

Lab integration is the electronic exchange of laboratory orders, specimens, results and reports between the systems involved in a test. People also call it laboratory integration, LIS integration, EHR lab integration or a lab interface. The words mean the same thing in practice: data moves between systems in a structured format, so no one has to print, fax or type it.

A complete lab integration has two directions:

• Orders in. A provider orders a test in the EHR. The order reaches the lab's LIS with the patient, the ordering provider, the test code, the diagnosis, the specimen details and the bill-to party.
• Results out. The lab runs the test and releases results. Each result returns to the EHR as discrete values with units, reference ranges, abnormal flags and status, often with a PDF copy of the formal report.

A results-only interface sends results back for orders placed on paper or in a lab portal. A bidirectional lab interface handles both directions and is the goal for most clinics and labs, because it removes requisition errors at the source.

Who needs lab integration, and why

Each buyer has a different reason to connect, and the reason decides which method fits.

If you already know you need an interface built or fixed, our lab integration services page covers scope, deliverables and how we work. The rest of this guide explains every option so you can choose well.

How a lab order becomes a result: the 8 steps

Every lab integration method carries the same journey. Knowing the steps tells you where data can go wrong.

1. Order. The provider picks a test in the EHR, such as a CBC with differential. The EHR records the patient, provider, test, diagnosis codes, priority and any ask-at-order-entry (AOE) questions the lab requires, such as fasting status.
2. Check and map. The interface checks required fields and converts the EHR's test code into the lab's orderable code from the lab's test directory (the compendium).
3. Accept. The LIS accepts or rejects the order. It assigns an accession number and sends an acknowledgement. A rejection must reach a person, never disappear.
4. Collect and label. The specimen is drawn and labelled. The label barcode must match the order the lab received electronically. Requisitions and labels are a common source of mismatches.
5. Test. The analyzer runs the test and sends values to the LIS through instrument middleware. The lab checks quality control and a technologist verifies the result.
6. Release. The LIS releases preliminary or final results with values, units, reference ranges, abnormal flags and comments.
7. Deliver. The interface matches the result to the right patient and order, then files it in the EHR for the ordering provider and any copy-to providers.
8. Correct and reconcile. If the lab amends a result, the corrected version replaces the old one with history kept. A reconciliation job checks that every order received a result and every result reached a chart.

The three layers of lab integration

People say "lab integration" for three different jobs. They use different standards and often different teams.

Every way to integrate a lab: the 11 methods

There is no single lab integration protocol. The right method depends on who you connect to, which direction data flows, how many labs you need and what each partner supports.

1. Lab portal, fax and PDF (the starting point)

How it works. Staff order in the lab's web portal, such as Labcorp Link or Quest Quanum, or fill a paper requisition. Results come back by fax, portal download or PDF, and someone attaches them to the chart.

Best for. Very low volume, or a new lab relationship while the interface is being built.

Plan for. Manual entry errors, no discrete values for trending or alerts, and results that sit unread in an inbox. Every other method on this list exists to remove these steps.

Setup steps.

1. Open a client account with the lab and get portal logins for each ordering provider.
2. Set up result delivery: fax number, portal inbox or secure email.
3. Decide who files each result in the chart and who follows up on abnormal ones.
4. Keep a log of orders sent, so missing results are noticed.

Effort. Low to set up. High in staff time every day, and it grows with volume.

2. Direct HL7 v2 interface (point to point)

How it works. The EHR and the LIS exchange HL7 v2 messages directly, usually over MLLP (the standard way to frame HL7 messages on a TCP connection) inside a site-to-site VPN, or as files over SFTP. Orders go as ORM^O01 or OML^O21. Results come back as ORU^R01. Each side sends an ACK.

Best for. A lab and one high-volume client, or a practice with one main lab.

Plan for. Each lab has its own specification, compendium, onboarding queue and test cycle. Ten labs means ten interfaces to build and watch. If you only have two or three partners, this is the simplest route. Our guide to what an HL7 interface is covers the basics.

Setup steps.

1. Get the lab's interface specification and the EHR's HL7 specification, and compare them field by field.
2. Agree on transport: MLLP inside a site-to-site VPN is the most common; SFTP batches are the fallback.
3. Exchange VPN details, IP addresses and ports, and open the firewalls on both sides.
4. Load the lab's compendium into the EHR and map result codes to LOINC.
5. Build and unit-test the transforms on synthetic messages.
6. Run the lab's test scripts with test patients, then the go-live test pack.
7. Go live at one site, watch the first days of traffic, then expand.

Effort. Medium for results only, medium to high for orders and results. Most of the calendar time goes to the partner's queue and testing.

Sample. On the wire, MLLP wraps each HL7 message in a start byte (hex 0B) and two end bytes (hex 1C 0D), so the receiver knows where one message stops and the next begins. The receiver answers every message with an ACK before the sender moves on.

3. Integration engine (hub and spoke)

How it works. An integration engine sits between all systems. It receives each message, checks it, maps codes, transforms formats and routes it to one or more destinations. Common engines include Mirth Connect, Rhapsody, Corepoint, InterSystems HealthShare and Cloverleaf.

Best for. Hospitals, labs with many clients, and vendors connecting to many labs. One engine handles code mapping, retries, alerts and monitoring for every feed.

Plan for. Licensing and an engineer who owns the engine. Mirth Connect moved to a commercial license from version 4.6, so check the license before you plan around it. See how we route ORU lab results in Mirth Connect and our Rhapsody vs Corepoint comparison.

Setup steps.

1. Pick the engine and the hosting: in your cloud, on premises, or managed by a partner.
2. Build one inbound channel per source and one outbound channel per destination.
3. Put shared logic in one place: code mapping tables, patient and order matching, duplicate checks.
4. Add a queue with retries and a dead-letter area for messages that keep failing.
5. Set up alerts and dashboards before the first channel goes live.
6. Document each channel: source, destination, mapping version and owner.

Effort. Higher at the start (license, hosting, first channels). Lower for every lab you add after that, because mapping, monitoring and retries already exist.

4. The EHR's built-in lab interfaces

How it works. Many EHRs ship ready-made lab connections. Ambulatory EHRs such as athenaOne, eClinicalWorks and NextGen keep libraries of lab interfaces to national and regional labs. Hospital EHRs run their own lab systems: Epic Beaker and Oracle Health PathNet are full LIS products inside the EHR.

Best for. Practices whose EHR already has the lab connected. There may be nothing to build.

Plan for. Vendor fees, a queue for activation, and limits on what you can change. If the lab is not in the EHR's library, you are back to method 2 or 3, with the EHR vendor as one party.

Setup steps.

1. Ask the EHR vendor whether the lab is in its interface library and what activation costs.
2. Get your client account number from the lab and give it to the EHR vendor.
3. The vendor activates the interface and loads the lab's compendium.
4. Test orders, results, labels and requisitions with test patients.
5. Train staff on the new order screens, then go live.

Effort. Low for you when the lab is already in the library. You wait on the vendor's queue more than you build.

5. Reference lab connectivity programs (Labcorp, Quest)

How it works. National labs run their own connectivity teams. They supply interface specifications, compendium files, requisition and label formats, and onboarding tests, and they already connect to hundreds of EHR and practice systems.

Best for. Any product or practice that sends meaningful volume to Labcorp or Quest.

Plan for. The lab sets the specification. Expect AOE questions, ABN rules for Medicare patients, bill-to options, label printing and a formal certification test before go-live.

Setup steps.

1. Contact the lab's connectivity or client services team and open a client account.
2. Receive the specification, compendium, AOE list, requisition and label formats.
3. Decide bill-to rules (client, patient or insurance) and how you handle Medicare ABNs.
4. Build to the specification, directly or in your engine.
5. Pass the lab's certification tests: they send scripts, you return orders and accept results.
6. Go live and keep the compendium in sync as the lab updates tests.

Effort. Medium. The lab's process is well defined, but certification and label printing take care.

6. Lab network or aggregator API

How it works. You connect once to a network, such as Health Gorilla, that already connects to many labs. You send orders and receive results through the network's API, often FHIR-based, and the network handles each lab's format, compendium and routing.

Best for. Digital health companies that need many labs quickly, or nationwide patients.

Plan for. Per-transaction or subscription fees, the network's data model, coverage of the specific labs you need, and less control over edge cases such as corrections and AOE answers.

Setup steps.

1. Check that the network covers the labs and states you need, and how it handles corrections and AOE.
2. Sign the network agreement and a BAA, and get sandbox API keys.
3. Pull the compendium for each lab through the API and build your order screens from it.
4. Send test orders in the sandbox and receive test results through webhooks or polling.
5. Map the network's result format into your data model, keeping status and corrections.
6. Move to production one lab at a time.

Effort. Low to medium to build. The ongoing cost is per transaction or subscription fees.

Sample. Health Gorilla, for example, documents lab orders as a FHIR RequestGroup that holds one ServiceRequest per test, checked against the lab's compendium, with results returned as DiagnosticReport and Observation resources.

7. FHIR API

How it works. Systems exchange FHIR resources over a REST API. A lab order is a ServiceRequest. A result is a DiagnosticReport that points to Observation resources for each value, plus a Specimen. In the US, US Core defines lab profiles that certified EHRs support for reading results.

Best for. Reading lab results into apps, patient-facing products and data platforms. New products that start FHIR-first.

Plan for. Read access is common; order placement through a public FHIR API is not. An EHR that "supports FHIR" may let you read lab results but not create a ServiceRequest the lab will act on. Check the vendor's capability statement for write support before you design around it. See our US Core guide and HL7 v2 to FHIR migration guide.

Setup steps.

1. Read the EHR's or lab's FHIR capability statement to see which resources and operations you can use.
2. Register your app and pick the right access: patient-facing (SMART on FHIR) or system-to-system (SMART Backend Services).
3. Query results, for example GET /DiagnosticReport?patient=123&category=LAB and GET /Observation?patient=123&category=laboratory.
4. Handle paging, status changes and corrections: poll on a schedule or use subscriptions where offered.
5. If ordering is supported, POST a ServiceRequest and track it, usually with a Task.
6. Validate what you receive against US Core before you trust the fields.

Effort. Low to medium for reading results. Ordering depends entirely on what the other side supports.

Sample. The FHIR version of the hemoglobin result in this guide is shown in the FHIR section below.

8. File transfer: SFTP, CSV and PDF

How it works. The lab drops files on a schedule: batches of HL7 messages, CSV extracts or PDF reports. Your system picks them up from SFTP and loads them.

Best for. Small labs without an HL7 feed, research and wellness testing, or a legacy system that can only export files.

Plan for. Delays between batches, no acknowledgement per result, and weak matching. A PDF holds no structured values. Numbers extracted from one have not been validated the way a structured result is, so check them and keep the original.

Setup steps.

1. Agree on file format, naming, schedule and folder layout with the lab.
2. Set up SFTP with key-based logins and, if required, PGP encryption of each file.
3. For HL7 batches, check the batch header and trailer segments (FHS, BHS, BTS, FTS) and the message count.
4. Load each file, move it to a processed folder and report rejected records back to the lab.
5. Alert when an expected file does not arrive.

Effort. Low to build, but plan for manual follow-up on bad records.

9. HIE, TEFCA and Direct messaging

How it works. Results flow through a health information exchange (HIE), through TEFCA query networks, or as Direct secure messages. Many state and regional HIEs deliver lab results to their participants.

Best for. Seeing results ordered by other providers, care coordination, and payers or ACOs that need a wider view.

Plan for. Network onboarding, patient matching across organizations and data that arrives later than a direct feed. It complements a direct interface; it rarely replaces one for ordering. Read our TEFCA guide.

Setup steps.

1. Join the HIE or a TEFCA participant, or set up a Direct address through a HISP (the provider of Direct secure email).
2. Agree on how patients are matched across organizations.
3. Subscribe to result notifications or query for results when needed.
4. File outside results separately from your own lab orders, with the source shown.

Effort. Medium, mostly onboarding and agreements.

10. Instrument integration (analyzer to LIS)

How it works. Analyzers send results to the LIS, and the LIS sends worklists to the analyzers. Older and many current instruments use the ASTM protocols now published by CLSI as LIS01-A2 (the low-level transfer) and LIS02-A2 (the message content). Newer ones use HL7 v2 following the IHE Laboratory Analytical Workflow (LAW) profile. Point-of-care devices often use POCT1-A. Most labs place middleware, such as Data Innovations Instrument Manager, between the instruments and the LIS to run autoverification rules and manage many connections.

Best for. Labs, LIMS vendors and anyone building lab software. People search for this as "lab instrument integration" or "instrument integration with LIMS".

Plan for. Serial and TCP connections, each vendor's dialect of ASTM, QC handling, reruns and dilutions. Validate every assay after any change.

Setup steps.

1. List each analyzer, its protocol (ASTM or HL7), its connection (serial or TCP) and the tests it runs.
2. Connect analyzers to middleware, and middleware to the LIS.
3. Map instrument test codes to LIS test codes.
4. Set autoverification rules, QC rules and rerun handling in the middleware.
5. Validate every assay end to end, including flags and dilutions, before patient use.

Effort. Medium per analyzer type. Validation is the long part.

Sample. A simplified ASTM result from an analyzer looks like this. Each line is a record: H header, P patient, O order (here specimen SID12345 for glucose), R result, L end.

H|\^&|||ANALYZER^1.0|||||||P|1
P|1
O|1|SID12345||^^^GLU
R|1|^^^GLU|98|mg/dL|70-99|N||F
L|1|N

11. Electronic lab reporting (ELR) to public health

How it works. Labs and hospitals send reportable results, such as specific infections, to state and local public health agencies as HL7 2.5.1 ORU^R01 messages under the ELR implementation guide, often through the APHL AIMS platform.

Best for. Every lab that performs reportable tests, and hospitals that need to meet CMS Promoting Interoperability public health measures.

Plan for. Each jurisdiction's reportable condition list, onboarding tests, LOINC and SNOMED CT coding, and acknowledgement monitoring.

Setup steps.

1. Check each state's reportable conditions list and its ELR onboarding rules.
2. Register with the jurisdiction, often through the APHL AIMS platform.
3. Code tests in LOINC and results in SNOMED CT, and include the performing lab's CLIA number.
4. Send test messages, fix validation errors and run in parallel with the old method.
5. Move to production and monitor acknowledgements from public health.

Effort. Medium per jurisdiction. Onboarding queues set the timeline.

All lab integration methods compared

How to choose the right lab integration method

Most real setups combine methods. A common pattern: a direct HL7 interface to the one or two labs that carry most of your volume, a lab network for the long tail, FHIR to read results into your app, and ELR where you report to public health.

The standards behind lab integration

Lab integration needs message standards to move the data and code systems so both sides read it the same way.

HL7 v2 lab messages: ORM, OML and ORU

Three message types do most of the work. Our detailed post on mapping HL7 ORM and ORU to FHIR DiagnosticReport goes field by field; here is what you need to plan an interface.

The segments carry the data:

• MSH: sender, receiver, message type, version and a unique control ID.
• PID: patient identifiers and demographics.
• ORC: order control (NW new, CA cancel, RE results to follow), the placer order number from the EHR (ORC-2) and the filler number from the lab (ORC-3).
• OBR: the test or panel ordered (OBR-4), collection time and overall result status (OBR-25).
• OBX: one result each: code, value, units, reference range, abnormal flag (OBX-8) and result status (OBX-11).
• SPM: the specimen, in 2.5.1 messages.
• NTE: comments and interpretation text.

A simple result message for a hemoglobin test looks like this (synthetic data):

MSH|^~\&|LIS|ACMELAB|EHR|CLINIC|20261025103000||ORU^R01^ORU_R01|MSG000123|P|2.5.1
PID|1||100245^^^CLINIC^MR||DOE^JANE||19800214|F
ORC|RE|ORD5521|ACC90876
OBR|1|ORD5521|ACC90876|58410-2^CBC panel - Blood by Automated count^LN|||20261025081500|||||||||1234567890^SMITH^ANNA||||||20261025101500|||F
OBX|1|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||13.5|g/dL^g/dL^UCUM|12.0-16.0|N|||F
OBX|2|NM|6690-2^Leukocytes [#/volume] in Blood by Automated count^LN||11.8|10*3/uL^10*3/uL^UCUM|4.0-10.5|H|||F

The status codes in OBX-11 drive how the receiving system files the result. Getting them wrong is how charts end up with stale or doubled values.

The receiver answers each message with an ACK. MSA-1 says accepted (AA), error (AE) or rejected (AR), and MSA-2 repeats the control ID of the message being answered, so the sender knows exactly which message it refers to:

MSH|^~\&|EHR|CLINIC|LIS|ACMELAB|20261025103002||ACK^R01^ACK|ACK000123|P|2.5.1
MSA|AA|MSG000123

FHIR lab resources

In FHIR, lab data is a small set of linked resources:

• ServiceRequest: the order.
• Specimen: what was collected, when and how.
• DiagnosticReport: the report, linked to the order (basedOn), the patient, the specimen and the results. It can carry the PDF in presentedForm.
• Observation: one per result value, with LOINC code, value, UCUM unit, reference range, interpretation and status.
• Task or RequestGroup: used by some networks to track or group orders.

US Core defines the laboratory profiles for DiagnosticReport and Observation that US certified EHRs support. HL7 v2 and FHIR map closely, which is why many teams keep HL7 v2 with the lab and expose FHIR to their apps:

Here is the same hemoglobin result as FHIR R4 resources, trimmed to the main fields:

{
  "resourceType": "DiagnosticReport",
  "status": "final",
  "category": [{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "LAB" }] }],
  "code": { "coding": [{ "system": "http://loinc.org", "code": "58410-2", "display": "CBC panel - Blood by Automated count" }] },
  "subject": { "reference": "Patient/100245" },
  "basedOn": [{ "reference": "ServiceRequest/ORD5521" }],
  "effectiveDateTime": "2026-10-25T08:15:00-05:00",
  "result": [{ "reference": "Observation/hgb-1" }]
}

{
  "resourceType": "Observation",
  "id": "hgb-1",
  "status": "final",
  "category": [{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory" }] }],
  "code": { "coding": [{ "system": "http://loinc.org", "code": "718-7", "display": "Hemoglobin [Mass/volume] in Blood" }] },
  "subject": { "reference": "Patient/100245" },
  "valueQuantity": { "value": 13.5, "unit": "g/dL", "system": "http://unitsofmeasure.org", "code": "g/dL" },
  "referenceRange": [{ "low": { "value": 12.0, "unit": "g/dL" }, "high": { "value": 16.0, "unit": "g/dL" } }],
  "interpretation": [{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "N" }] }]
}

A corrected result keeps the same Observation and changes its status to "corrected", with the new value. Apps that cache results must re-read them, or they will show the old value.

LOINC, SNOMED CT and UCUM: the code mapping work

Most labs use their own local test codes. The receiving system needs to know that the lab's "HGB" is LOINC 718-7, or trends and alerts will break. Code mapping is often the longest task in a lab integration.

• LOINC names the test. Map every result code, and every orderable where the partner supports it. A panel and its components need separate codes.
• UCUM names the unit. "mg/dl", "mg/dL" and "MG/DL" must all become one unit, or numbers will not compare.
• SNOMED CT codes specimens, organisms in microbiology and coded findings such as "Detected" or "Not detected".

Keep mappings in a versioned table with a named clinical reviewer, and route any unmapped new code to a queue instead of letting it through. Our post on LOINC and SNOMED CT mapping in production shows how.

The test compendium

The compendium is the lab's test directory: every orderable test, its code, specimen rules, AOE questions and the result components it returns. The EHR's order list must match it. When a lab retires or changes a test and your system does not update, orders start failing. Sync the compendium on a schedule and run a regression test after each update. Some labs publish it in the HL7 eDOS (electronic directory of services) format; many still send spreadsheets.

Special result types: microbiology, pathology and genetics

Chemistry and hematology results are short numbers. Other result types need extra design.

• Microbiology. A culture produces a preliminary report, then organisms, then sensitivities to each antibiotic, sometimes over several days. HL7 links these as parent and child results (OBR-26 and OBR-29 point back to the parent). Organisms are coded in SNOMED CT. The receiving EHR must show the organism and its sensitivities together, and update them as each message arrives.
• Anatomic pathology and cytology. Reports are mostly narrative text with a diagnosis, often with structured cancer checklists and a signed PDF. Many interfaces send the text in OBX segments plus the PDF. Addenda work like corrections and must reach the provider.
• Genetic and molecular tests. Reports are long, include variants and interpretation, and often arrive as a PDF with a few structured findings. Agree with the lab which findings come as discrete data and which stay in the document.
• Point-of-care tests. Glucose meters, blood gas devices and rapid tests at the bedside report through POCT1-A device managers to the LIS, so the result still lands in the chart with the operator and device recorded.
• Send-out tests. When a lab sends a specimen on to a reference lab, the result must come back through the first lab's LIS with the performing lab's name and CLIA number shown, as CLIA requires.

Lab integration for digital health and RPM apps

Digital health companies usually need lab data for one of three jobs, and each has a different route.

The common mistake is to treat a lab result like any other data point. A lab result has a status, can be corrected, and can be critical. Your app needs the same rules for corrections and critical values as an EHR.

Example: how a specialty lab connects to a clinic's EHR

This is the typical shape of the project. A specialty lab wants a multi-site clinic group to order its tests from inside the clinic's EHR and see results there.

1. Week one questions. Does the EHR vendor have a standard lab interface the lab can join? Assume it does not, so the lab builds to the EHR's HL7 specification. Orders and results both flow, over a site-to-site VPN with MLLP.
2. Compendium. The lab exports its orderable tests with codes, specimen rules and AOE questions. The clinic's EHR team loads them as orderables. Each test's result components are mapped to LOINC.
3. Identifiers. The EHR sends its medical record number in PID-3 and its order number in ORC-2. The lab stores both and returns them in every result, so the EHR matches results to orders exactly. The lab's accession number travels in ORC-3.
4. Labels and requisitions. Specimens are drawn at the clinic. The EHR prints a barcode label with the order number the lab reads at intake, so the specimen and the electronic order meet.
5. Results. The LIS sends ORU^R01 messages with the PDF report embedded, and the interface files discrete values and the PDF together.
6. Testing. The two teams run the go-live test pack below with test patients, including a corrected result and a duplicate message. The clinic's medical director signs off on how results display.
7. Go-live and after. One site goes first. A daily reconciliation report compares orders sent with results received, and any order without a result after the expected turnaround goes to the lab's client services team.

Most of the effort sits in steps 2, 3 and 6. The connection itself is the smallest part.

LIS vs LIMS: what each one connects to

A laboratory information system (LIS) runs a clinical lab that tests patient specimens for diagnosis. A laboratory information management system (LIMS) runs research, pharmaceutical, environmental, food or manufacturing labs that test samples, batches and studies. The words overlap, but the integrations differ.

LIMS integration is mostly method 10 (instruments) plus enterprise APIs. Clinical labs that also run research work often need both.

Working with Labcorp, Quest, Epic Beaker and lab networks

Labcorp. Labcorp runs its own connectivity program and connects to hundreds of EHR, practice management and LIS systems. Providers order and view results through Labcorp Link, its portal. For an electronic interface, Labcorp provides the specification, compendium, label and requisition formats and runs certification tests. In May 2026 Labcorp and Epic announced an expanded integration for diagnostic ordering and results through Epic Aura. Our Labcorp API and integration guide covers every Labcorp route, including employer drug testing.

Quest Diagnostics. Quest says it interfaces with more than 900 EHR systems, and offers its Quanum tools for ordering and results, with its own specifications and onboarding. Plan for AOE questions, Medicare ABN rules and label formats specific to Quest.

Epic Beaker. Beaker is Epic's laboratory information system, with clinical pathology and anatomic pathology applications. In a Beaker site the lab and the EHR share one database, so in-house orders and results need no interface. Interfaces are still needed for reference lab send-outs, outreach clients on other EHRs, instruments and public health reporting. Access depends on the health system's Epic setup and agreements. Our Epic Beaker integration guide covers instruments, reference lab send-outs and the Beaker FHIR API in detail.

Lab networks such as Health Gorilla. A network gives one API and one contract for many labs. Health Gorilla documents FHIR R4 lab ordering, compendium checks and results returned as DiagnosticReport and Observation. Check that the labs you need are covered and how corrections and AOE answers work.

Where lab interfaces fail, and how to prevent it

Moving the message is the easy part. Most production problems start when the data is wrong, late, duplicated or changed after the fact.

An ACK proves the message arrived at the other system. It does not prove the result was filed on the right chart or seen by a clinician. Reconciliation closes that gap: compare the orders sent with the results received, every day, and chase the gaps.

How to secure a lab connection

Every lab connection carries patient data, so security is part of the design from day one.

Use synthetic data in development and test environments. Keep production patient data in production, and give people access only when they need it, with every access logged.

What to monitor once an interface is live

An interface that worked on go-live day can fail quietly a month later when a lab changes a code or a VPN drops. Watch these signals and give each alert a named owner.

US rules that shape lab integration

• HIPAA. Anyone who builds or runs the interface with access to patient data is a business associate and needs a business associate agreement (BAA). Encrypt data in transit and at rest, give each person a unique login and keep audit logs.
• CLIA. 42 CFR 493.1291 sets what a lab test report must contain and says it goes to the authorized person who ordered it. Since 2014, labs may also give completed reports to patients on request. The electronic result must keep the content the regulation requires.
• Information blocking. Under the 21st Century Cures Act rules, holding lab results back from patients, for example until a clinician reviews them, is likely to count as information blocking. Delays are allowed when an exception applies, such as preventing harm, or when the patient asks for one. Plan release rules with your compliance team. See our information blocking guide.
• Public health reporting. State laws require reportable results to go to public health. For hospitals and critical access hospitals, electronic reportable lab result reporting is a required CMS Promoting Interoperability measure.
• Certification. ONC certified EHRs must support US Core lab data, which is why FHIR read access to results is widely available.

Lab integration in the UK and Europe

Europe is not one market. Each country has its own patient identifiers, national exchange, codes and procurement, and the UK sits outside the EU.

Data protection. GDPR and UK GDPR apply. Remote access to patient data from outside the EU or UK can count as a restricted transfer even when the servers stay in Europe, so you need a transfer mechanism and an assessment. For NHS-facing software, the DCB0129 (manufacturer) and DCB0160 (deploying organization) clinical risk management standards apply.

How a lab integration project runs

The go-live test pack

Before any interface goes live, prove each of these with test patients:

• A new order, a changed order and a cancelled order reach the lab and are acknowledged.
• A rejected order reaches a person with the reason.
• Normal, abnormal and critical results file on the right patient and order, with correct units and flags.
• A preliminary result is replaced by the final, and a corrected result replaces the final with history kept.
• A duplicate message does not create a second result.
• A message for an unknown patient or order goes to the exception queue.
• Microbiology results with organisms and sensitivities display correctly, if in scope.
• The PDF report attaches to the same result.
• After a simulated outage, queued messages replay in order and reconciliation shows no gaps.

What drives lab integration cost and timeline

The partner and the scope drive the price of a lab interface more than the code does. Size these factors before you ask for a quote.

Calendar time is usually set by the partner: the lab's onboarding queue and certification testing often take longer than the build. Start that conversation first.

Build it yourself, buy a network or hire a team?

• Build in-house when lab data is core to your product and you will keep an interface engineer on staff.
• Use a lab network when you need many labs fast and can accept the fees and the network's data model.
• Use the EHR's built-in interface when the lab is already in its library.
• Hire a specialist team when you need the first interfaces live quickly, have a backlog, or have interfaces that lose or mismatch results today.

How Nirmitee helps with lab integration

Nirmitee builds and runs lab interfaces for health tech companies, laboratories and health systems: HL7 v2 orders and results, Labcorp and Quest connections, LIS to EHR interfaces, compendium and LOINC mapping, FHIR DiagnosticReport and Observation feeds, instrument middleware links and ELR to public health. Every interface ships with a specification, the go-live test pack above, monitoring and daily reconciliation. See our lab integration services or our HL7 integration services, and tell us which lab and which system you need to connect.