Epic Beaker is Epic’s laboratory information system, and the single most useful thing to know about it is architectural: it is a module inside Epic, not a separate product you buy and connect. Almost everything that makes a Beaker project different from a conventional LIS project follows from that one fact.
This guide covers what Beaker is, how Beaker CP and Beaker AP differ, where Beaker sits relative to the rest of the Epic suite, and which lab interfaces you still have to build after a Beaker go-live. It skips the certification and careers material that dominates most Beaker explainers, and spends the space on the integration surface instead.
What Epic Beaker Is
Beaker is the LIS module within the Epic EHR. It covers what any laboratory information system covers: order entry and specimen collection, accessioning, worklists, instrument results, auto-verification rules, quality control, and result reporting back to the ordering clinician.
What it does differently is where it lives. A standalone LIS is a separate application with its own database, which means the EHR and the LIS have to agree on patients, orders, and results by exchanging messages. That agreement is the bidirectional HL7 v2 interface at the center of every traditional lab architecture: ORM^O01 orders out of the EHR, ORU^R01 results back, plus ADT to keep the patient index aligned.
Beaker removes that conversation. It runs on Chronicles, the same database as the rest of Epic, against the same patient record and the same security model. An order placed by a clinician in the chart is already in the lab’s work queue. A result verified in the lab is already in the chart. Nothing crosses a wire, so nothing can fail to cross a wire.
That is the whole value proposition, and it is a real one. It is also why Beaker projects surprise people: removing the biggest interface does not remove the integration work, it relocates it.
Beaker CP and Beaker AP
Beaker is not one module. It is two, licensed and implemented separately, and they are different enough that treating them as one project is a common scoping mistake.
| Module | Beaker CP | Beaker AP |
|---|---|---|
| Full name | Clinical Pathology | Anatomic Pathology |
| Disciplines | Chemistry, hematology, coagulation, urinalysis, microbiology | Surgical pathology, cytology, autopsy |
| Unit of work | The specimen and the test | The case, tracked through blocks and slides |
| Volume shape | High volume, short turnaround, heavily automated | Lower volume, multi-day turnaround, heavily manual |
| Result shape | Discrete numeric values with reference ranges and flags | A narrative report with a diagnosis line, signed out |
| Instrument picture | Analyzers on an instrument manager, auto-verification by rule | Grossing stations, cassette and slide labelling, scanners, dictation |
| Typical interfaces | Analyzers, reference labs, outreach, blood bank | Slide scanners, image systems, transcription, outside consults |
The practical consequence is that the two have almost nothing in common at the interface layer. A CP go-live is dominated by analyzer connectivity and auto-verification rule design. An AP go-live is dominated by specimen tracking through the grossing and embedding workflow, and by getting narrative reports to render correctly in the chart and in outbound documents.
Health systems frequently implement CP first and AP later, or run AP on a separate anatomic pathology system indefinitely. If someone says “we are going to Beaker,” the first useful question is which one.
Where Beaker Sits in the Epic Suite
Beaker is one of Epic’s clinical department modules, and it behaves like its neighbours. Willow covers pharmacy, Radiant covers radiology, OpTime covers surgery, and Beaker covers the lab. They share Chronicles, they share the patient record, and they share the same release train.
Two other pieces of the suite matter for lab integration specifically:
- Bridges is Epic’s interface engine. Every HL7 message entering or leaving Epic passes through it, including every lab interface that survives a Beaker implementation. Bridges is where your instrument feeds, reference lab connections, and outbound results actually live.
- Care Everywhere handles exchange with other organizations. It matters for lab because outside results arrive through it, and reconciling those against locally resolved codes is its own piece of work.
The thing to internalize is that Bridges, not Beaker, is the surface a third party integrates with. You do not build an interface “to Beaker.” You build a Bridges interface that Beaker consumes, against a specification Epic writes.
The Integration Surface That Survives
Here is the part that gets underestimated. Beaker deletes the EHR-to-LIS interface, which was the biggest one. It leaves five surfaces standing, and each of them is real work.
Analyzers and instruments. Clinical analyzers do not speak HL7. They emit ASTM E1394 frames, published by CLSI as LIS01-A2 for the low-level transport and LIS02-A2 for message content. Something has to translate those frames into HL7 v2 OBX segments before Beaker can accept them, and that something is typically instrument-manager middleware sitting between the bench and Bridges. Delta checks, range checks, and Levey-Jennings quality control usually live there too, gating what is allowed to reach auto-verification.
Reference labs. Send-out testing to national and specialty reference laboratories is an outbound order and an inbound result across an organizational boundary, over SFTP, MLLP, or HTTPS depending on the lab. Each reference lab has its own compendium, so the same test means a different code at each end, and results have to reconcile back to the ordering provider in the chart.
Outreach ordering. Health system labs that serve outside practices need those practices to be able to order and receive results without being Epic users. That is a separate ordering surface with its own identity, compendium, and result-delivery problem.
The compendium and its coding. The test catalog is the spine of a lab implementation. Every orderable test, every resulting component, every unit, every reference range, and the LOINC code that makes a result mean the same thing outside your walls. Local codes from analyzers and reference labs have to resolve to it, with UCUM units normalized so results trend correctly across sources.
Outbound results. Results going to other EHRs, to registries, to public health, and increasingly to FHIR R4 DiagnosticReport and Observation resources for patient apps and population analytics.
None of those five disappear because the LIS moved inside the EHR. They all move to Bridges, which is where the specification, build, and validation effort concentrates. This is the work we do on LIS and LIMS integration projects, and the Beaker variant of it is the most common shape we see.
How a Beaker Integration Differs From a Standalone LIS Integration
If you have integrated a standalone LIS before, the differences are worth naming explicitly, because they change estimates more than they change architecture.
The biggest interface is gone, and the rest got stricter. In a standalone world you controlled the interface engine, so a mapping change was a channel edit. In a Beaker world the surviving interfaces run through Bridges against an Epic-authored specification. Changing one is a specification change first and a build change second.
Effort moves from transformation to specification. Standalone LIS projects spend their hours in the engine, writing transforms and handling vendor quirks. Beaker projects spend them in the interface specification, the compendium build, and the validation package. The code volume goes down and the documentation volume goes up.
Auto-verification moves. In a standalone architecture, middleware often owns the rules that decide whether a result can be released without a human. In Beaker, much of that logic belongs in Beaker itself, and the middleware’s job narrows to protocol translation plus the checks that genuinely belong at the bench.
Validation has two shapes at once. The lab still owes CAP and CLIA a validation record, and 21 CFR Part 11 expectations apply where they applied before. On top of that, the work has to satisfy Epic’s own testing and go-live gates. Planning one validation effort that produces evidence for both is the difference between a calm go-live and a bad one.
The calendar is not entirely yours. Beaker work is sequenced against Epic’s project and upgrade calendar. Interface builds, testing windows, and cutover dates land where the broader Epic program puts them.
Getting the Scope Right
A useful first pass at scoping a Beaker lab integration is to answer four questions:
- CP, AP, or both? They are separate implementations with separate interface inventories.
- How many analyzers, and through what middleware? Count instruments, not vendors, and find out whether an instrument manager already exists.
- Which reference labs, and whose compendium wins? Every send-out relationship is a mapping exercise before it is an interface.
- Who outside the organization orders and receives? Outreach is frequently discovered late and is rarely small.
Those four answers drive most of the estimate. The EHR-to-LIS interface you would have built in a standalone project does not appear on the list at all, which is exactly the point.
If you are planning a Beaker implementation and want the interface inventory scoped properly, our LIS and LIMS integration practice covers analyzer connectivity, reference lab routing, compendium and LOINC work, and CAP-ready validation, and our Epic integration practice covers the Bridges and Open.Epic side. Our consultants hold individual Epic certifications.
Epic, Beaker, Bridges, Chronicles, Willow, Radiant, OpTime, and Care Everywhere are trademarks of Epic Systems Corporation. Saga IT is not affiliated with, endorsed by, or sponsored by Epic Systems Corporation.