Epic Beaker Integration: Lab Orders, Results and Pathology via HL7 and FHIR

Epic Beaker is Epic's laboratory information system (LIS). It runs the hospital lab inside Epic in two parts, Clinical Pathology for blood, urine and other specimen testing and Anatomic Pathology for tissue cases, and it exchanges lab orders and results with instruments, reference labs and outside software through HL7 v2 interfaces built in Epic Bridges, plus read access over Epic's FHIR APIs.

All Epic modules in one place: see our Epic modules list for what each module does and where outside systems connect.

When a lab vendor, a reference lab or a health app is told "you need to connect to Beaker," the work is usually a set of interfaces: orders out to instruments, results back in, send-out tests to a reference lab, and a read path for apps. Each one has its own Epic specification, its own owner on the hospital side and its own failure cases. This guide explains what Beaker is, who uses it, which Epic interface carries each connection, what an outside app can and cannot do over FHIR, and the problems that most often hold up a Beaker integration. For the wider picture across every Epic module, our Epic integration services page is the hub this guide links back to.

What is Epic Beaker?

Epic Beaker is the laboratory information system inside the Epic suite. Epic's own interface catalog calls it "Beaker, Epic's LIS" and describes it as the system that receives instrument results, sends orders to analyzers and returns results to the chart (open.epic.com, HL7v2 interfaces).

Beaker is set up as two separate applications, Beaker Clinical Pathology (CP) and Beaker Anatomic Pathology (AP). A 2022 review in Risk Management and Healthcare Policy describes it as an LIS "offered in the United States and Canada by Epic Systems Corporation" that "can be set up in two independent modules" (Sergi, 2022). The University of Iowa's Epic training site describes Beaker as "Epic's clinical laboratory application" that "supports inpatient and ambulatory laboratory workflows" (UI Health Care Epic support).

Beaker Clinical Pathology

Beaker CP handles specimen-based testing: chemistry, hematology, urinalysis, microbiology and point-of-care tests. The workflow starts with an order in Epic, moves through specimen collection and labeling, runs the test on an analyzer, and ends with a verified result in the chart. Most interface work in CP is about instruments and reference labs.

Beaker Anatomic Pathology

Beaker AP handles tissue and cytology cases: accessioning, grossing, histology, slide preparation, pathologist sign-out and the final report. The 2017 University of Iowa paper on Beaker AP walks through case building, barcoded cassettes, slide label printing and sign-out in detail (Blau et al., 2017). Interface work in AP is more about stainers, digital slide scanners, synoptic cancer reports and outreach clients.

Who uses Epic Beaker

Epic Beaker is used by hospitals and health systems that already run Epic and operate their own laboratory. The 2022 review notes that Beaker is commonly included in enterprise licenses for Epic customers. Some health systems move the lab onto Beaker years after the rest of Epic, as the Iowa example below shows.

The published implementations show how long that move takes. The University of Iowa adopted Epic as its EHR in 2009, kept its previous LIS, and went live on Beaker CP in August 2014 (Krasowski et al., 2016) and on Beaker AP in October 2015 (Blau et al., 2017). The 2022 review cites a pre-implementation stage of about two years and reports Beaker going live at the University of Alberta Hospital in 2019.

Around Beaker there are several groups an outside team will deal with:

• Laboratory staff and pathologists, who decide how tests, specimens and reports are built.
• Beaker analysts on the hospital's Epic team, who configure tests, workflows and result routing in Beaker.
• The interface team, who build and support the Bridges interfaces that carry orders and results.
• Outside vendors: instrument and middleware makers, reference labs, digital pathology vendors and app developers who need lab data.

How labs and instruments connect to Epic Beaker

Labs and instruments connect to Epic Beaker through HL7 v2 interfaces, each with its own Epic specification. Orders leave Beaker as HL7 v2 order messages, results come back as ORU^R01 result messages, and the hospital's interface team builds each feed in Epic Bridges.

Epic publishes the list of these interfaces on open.epic.com. The ones that matter for lab work, in Epic's own names, are below.

The two diagrams below show the same thing from two angles: the life of a single test, and the full set of outside connections around Beaker.

Instrument middleware

Some Beaker labs put instrument middleware between the analyzers and Beaker, as the University of Iowa did. Middleware talks to each analyzer in that instrument's own protocol, holds rules such as autoverification, and sends one consistent HL7 v2 feed to Beaker.

The Iowa paper explains why. At the time of their 2014 go-live, "Beaker CP does not directly interface with laboratory instrumentation," so the lab connected its core instruments through Data Innovations Instrument Manager. Most of their autoverification logic stayed in the middleware: "There are autoverification rules built within Beaker, but they simply autoverify what Instrument Manager sends" (Krasowski et al., 2016). Epic's current catalog lists instrument interfaces directly on Beaker, so check with the hospital which pattern it uses before you design: a direct instrument feed, or middleware in front.

For an instrument or middleware vendor, the practical questions are where autoverification lives, how the specimen barcode reaches the instrument, and how reruns and add-on tests are signaled. Settle those three on paper before any message is sent. Our page on medical device integration covers the device side in more depth.

What the messages look like

A Beaker result feed is ordinary HL7 v2, constrained by the hospital's interface specification. Here is a synthetic result with a specimen segment and one numeric value. Every identifier in it is made up.

MSH|^~\&|IM|CORELAB|EPIC|HOSP|20261028101500||ORU^R01|MSG00042|P|2.5.1
PID|1||E1000234^^^HOSP^MR||TEST^PATIENT||19800101|F
ORC|RE|ORD5521^EPIC|LAB7781^LIS
OBR|1|ORD5521^EPIC|LAB7781^LIS|2345-7^Glucose^LN|||20261028091200
OBX|1|NM|2345-7^Glucose [Mass/volume] in Serum or Plasma^LN||98|mg/dL|70-99|N|||F
SPM|1|SP000123^LIS||119364003^Serum specimen^SCT|||||||||||||20261028091200

Our lab and LIS integration guide goes segment by segment through ORM and ORU messages and maps each field to FHIR ServiceRequest, DiagnosticReport and Observation. Read it alongside this page; we do not repeat that mapping here.

Epic Beaker FHIR API: what an outside app can read or write

An outside app can read Beaker lab data over Epic's FHIR R4 APIs, but Epic's public catalog does not list a FHIR write for lab results. Results go into Beaker through the HL7 v2 interfaces above; FHIR is the read path.

The lab-related FHIR R4 APIs Epic lists on open.epic.com and documents on fhir.epic.com are these (catalog read 28 Oct 2026):

On the write side, the same catalog lists Observation create only for categories such as vital signs, flowsheets and lines, drains and airways, not for labs, and lists no create for DiagnosticReport. For orders, the closest write is ServiceRequest.Create (Unsigned Order), listed under CDS Hooks, which works on orders that a clinician has not yet signed. If your product needs to put a result into Beaker, plan for an HL7 v2 results interface. If it only needs to show or analyze results, FHIR is usually the faster route.

A typical read looks like this. It follows the US Core lab search pattern; Epic's spec page for each API lists the search parameters and category values it accepts, and each health system decides which APIs to turn on for your app.

GET /api/FHIR/R4/DiagnosticReport?patient={patientId}&category=LAB
GET /api/FHIR/R4/Observation?patient={patientId}&category=laboratory&date=ge2026-10-01

The US Core lab profile asks for a LOINC code where one exists and a UCUM unit for numeric values (US Core Laboratory Result Observation). Whether a given Beaker result carries both depends on how the lab built its tests, which is one of the problems covered below. Our Epic FHIR integration guide covers app registration, OAuth and sandbox testing.

Digital pathology and Epic Beaker

Digital pathology connects to Beaker AP through the same instrument order and result interfaces used for analyzers. Epic's catalog says the integration between Beaker and an image management system "utilizes the Outgoing Lab Instrument Orders and the Incoming Lab Instrument Results interfaces. Beaker sends patient, case, and slide information and receives image availability notifications to enable whole slide imaging workflows" (open.epic.com).

In practice that means the slide barcode and case number in Beaker must match what the scanner and image management system store, and the "image available" message must reach the right slide. When a slide is rescanned or a case is relabeled, both sides have to agree on which record changed. Agree on the slide identifier format before scanning starts, and test a rescan and a relabel as part of validation.

Pathology reports that contain electronic cancer checklists can also go to cancer registries. Epic's Outgoing Results and Orders interface supports a NAACCR format that follows the North American Association of Central Cancer Registries rules for CAP electronic cancer checklist reporting.

Reference lab integration with Epic Beaker

Reference lab integration with Beaker runs in two directions, and Epic uses different interfaces for each. Know which side you are before you ask for a specification.

Beaker sends tests out. When the hospital lab does not perform a test, Beaker sends the order to the reference lab through the Outgoing Ancillary Orders interface, and the result comes back through Incoming Ancillary Results. The Iowa team "maintained two-way electronic interfaces to three commercial laboratories" through their Beaker go-live and reported "few problems associated with the interfaces" (Krasowski et al., 2016). The feeds are built in Bridges; our Epic Bridges integration guide explains how a Bridges interface project runs and the HL7 v2 quirks that get messages rejected.

Beaker is the reference lab. When a hospital lab runs tests for outreach clients such as clinics or other hospitals, orders can arrive through Incoming Orders from CPOE Systems, and Beaker returns order status and results through Outgoing Results and Orders in the LRI format, which follows the HL7 v2.5.1 Lab Results Interface implementation guide.

The same Outgoing Results and Orders interface can send results in the ELR format for reportable conditions to public health agencies.

Common problems in Epic Beaker integration

Most problems that stall Beaker integrations come from identity and meaning: which specimen a result belongs to, whether a correction replaces the right value, and whether the code and unit mean the same thing on both sides.

Result corrections

A corrected result must replace the earlier final value, not sit next to it. In HL7 v2 the result status in OBX-11 carries this: F for final, P for preliminary, C for "a correction and thus replaces a final result," and W for a result posted against the wrong patient (HL7 table 0085). The correction has to reuse the original order and result identifiers so Beaker can find what it replaces. FHIR R4 has matching Observation status values, amended and corrected. An app that cached the earlier value must update it instead of adding a second row.

Specimen IDs and labels

Every result has to land on the right specimen. Beaker prints specimen labels at collection, and the barcode becomes the key the instrument, middleware and reference lab all use. Iowa found that "improper label placement by nonlaboratory staff" caused scan errors after go-live and changed the label design to fix it. A separate trap in AP: the 2022 review notes that "all Epic applications use a single shared list" for specimen source, and microbiology and surgical pathology had different needs for that one list.

Unit mapping

Two systems can both be correct and still send different unit strings. An analyzer may send mg/dl, the reference lab MG/DL and the FHIR consumer expect the UCUM form mg/dL. A result with the right number and the wrong unit looks valid, which makes it more dangerous than a missing one. Keep one unit table per test, owned by the lab, and validate every inbound unit against it.

LOINC codes

Many labs build tests with local codes and add LOINC later, or only for some tests. Inside the hospital that works; outside it, an app or a public health agency cannot tell two local codes apart. Check LOINC coverage for every test your feed carries before go-live, and agree what happens when a test has none.

Microbiology and panels

Microbiology results are not simple numbers. Cultures, organisms and susceptibilities arrive as linked observations that change over days. Iowa reported that its most substantial workflow changes came with microbiology orders. Panels raise a similar question for autoverification: Iowa found the interface could not indicate whether a panel result should be autoverified.

Epic Beaker integration readiness checklist

A Beaker integration is ready to build when every item below has a written answer and a named owner on the hospital side. Use it as the agenda for the first call with the lab and interface teams.

1. Role. Is Beaker the ordering system, the performing lab or the result destination for this feed?
2. Interface. Which Epic interface carries it (from the table above), and which version of the hospital's specification applies?
3. Owners. Who on the lab side owns test build, and who on the interface team owns the feed?
4. Patient identity. Which identifier and assigning authority appear in PID-3?
5. Order and specimen identity. Which order numbers and specimen IDs travel in ORC, OBR and SPM, and who assigns them?
6. Codes and units. A test list with local code, LOINC code and unit for each test.
7. Result status. Which OBX-11 values are used, and how corrections and cancellations are sent.
8. Acknowledgements and resends. ACK mode, timeout, retry rule and duplicate handling.
9. Test data. Synthetic patients and sample messages for normal, abnormal, corrected and canceled results, with no real patient data.
10. FHIR access. If an app reads results, which FHIR APIs the health system will enable and for which users.
11. Go-live checks. Who signs off in the test environment, and what is monitored in the first week.

How we approach Epic Beaker work

We build and run the outside half of Beaker interfaces: the integration engine channels, the message mapping to the hospital's specification, the test harness and the monitoring. The Beaker build itself (tests, workflows and Bridges configuration) stays with the hospital's Epic team, and we plan our work around their change process.

We start every Beaker project with the readiness checklist above and a one-page inventory of feeds, then test corrections, cancels and duplicates before normal results, because those are the cases that cause chart errors. For the engine side, see our comparison of healthcare integration engines.

Planning a lab or pathology connection to Epic? See our healthcare interoperability services for how we scope HL7 v2 and FHIR work, or talk to our team and send the checklist answers you already have. We will tell you which Epic interfaces your use case needs and what to ask the hospital for first.

Related guides

• Epic Bridges integration: HL7 interfaces for labs, billing and radiology
• Lab and LIS integration: mapping HL7 ORM and ORU to FHIR DiagnosticReport
• Lab integration guide: connecting labs, LIS and EHRs
• Epic Radiant integration for radiology
• Epic Cupid integration for cardiology
• How to integrate with Epic