eClinicalWorks is one of the largest ambulatory EMRs in the United States, which means a huge number of clinics, labs, billing services, and digital health products eventually need to exchange data with it. The reality of that integration is rarely pure FHIR or pure HL7. Ambulatory practices run on a hybrid: modern FHIR APIs for apps and patient access, and tried-and-true HL7 v2 interfaces for the lab and billing traffic that keeps the lights on. This guide is about using Mirth Connect to run both cleanly so an eClinicalWorks practice gets the connectivity it needs without a pile of brittle point-to-point links.
We have built EHR integrations for 30+ healthtech startups, several of them in ambulatory settings, so the hybrid pattern below is what we actually deploy, not an idealized diagram.
What eClinicalWorks exposes
eClinicalWorks gives you two broad surfaces. The first is an FHIR R4 API that follows US Core, available to provider-facing applications through the eCW FHIR developer portal and to patient-facing applications through the healow developer portal. This is the modern path; it uses OAuth 2.0 and SMART on FHIR, and it is what you build against for apps and patient data access.
The second surface is HL7 v2 messaging. Like most established EMRs, eCW emits and accepts HL7 v2 for the operational and financial workflows that FHIR does not fully cover, lab orders and results, charge and billing details, and similar feeds. These run through an interface engine, which is where Mirth Connect comes in. If the underlying formats are new to you, our guide to HL7 is a useful primer, and eClinicalWorks documents its broader approach on its interoperability page.
The honest summary: FHIR handles apps and access, HL7 v2 handles the clinical and financial plumbing, and most real clinics need both.
Why ambulatory practices reach for Mirth Connect
Small and mid-size clinics do not have a large integration team, so the last thing they need is a separate one-off connection for every lab, billing service, and app. An interface engine consolidates all of it into one manageable place.
Mirth Connect earns its keep in an eCW practice for a few specific reasons:
- It runs the hybrid. One engine can receive HL7 v2 lab results, call the eCW or Healow FHIR APIs, and present consistent output, so you are not maintaining two unrelated integration styles.
- It consolidates lab and billing feeds. Orders out, results in, and charges flowing to your billing service all live as channels in one place, with logging and retries built in.
- It absorbs the messy parts. Code normalization, reshaping, and routing happen in the transformer, not scattered across a clinic's various vendor connections.
- It scales down. Mirth is as comfortable running a handful of channels for a single clinic as it is running hundreds for a hospital, which suits the ambulatory world.
If Mirth is new to you, our complete guide to Mirth Connect and the architecture and deployment guide cover the basics, and the same pattern applies across vendors, as our Cerner integration guide shows.
FHIR and HL7 v2, side by side
The two paths suit different jobs. The FHIR R4 API, through the eCW and healow portals, is best for apps and patient access, exposing US Core resources over REST with SMART on FHIR authorization. HL7 v2 interfaces, over MLLP, are best for the lab and billing traffic that needs operational stability. There is one important caveat on the FHIR side: supporting US Core is not the same as delivering every USCDI element you expect, with complete search behavior and consistent coding. We dig into that gap in why FHIR-compliant does not mean interoperable, and it is worth verifying coverage for your exact use case before you design around it.
The architecture for a clinic
The shape is a small set of Mirth channels between eClinicalWorks and everything a clinic connects to. A source connector receives an HL7 v2 message or the result of an FHIR call. A filter keeps only what is relevant. A transformer normalizes eCW's codes to LOINC, SNOMED, and ICD and reshapes the data. A destination connector sends it onward, to a lab system, a billing service, a patient app, or an analytics store.
That normalization step is where quality is won or lost, because a result coded in eCW's local terms means nothing to an outside lab or registry. Our HL7 v2 to FHIR R4 mapping guide covers building those tables, and even a small clinic benefits from consistent channel design patterns, so the integration stays understandable as it grows.
Lab integration: the ambulatory bread and butter
For most ambulatory practices, the first and most valuable integration is labs. The flow is symmetric: an order goes out from eCW as an HL7 v2 ORM or OML message to a reference lab, and the result comes back as an ORU message that needs to land in the right patient's chart. Mirth sits in the middle of both directions, validating the order, routing it to the correct lab, and then taking the inbound result, mapping its codes, and posting it back so the clinician sees it without manual entry.
A nice optimization here is the hybrid pattern: as ORU results arrive over HL7 v2, a channel can precompute a clean results summary and store it for fast display, while FHIR is reserved for deeper drill-down when a clinician needs the full record. That gives the practice speed and operational stability at once. The broader lab pattern, including mapping HL7 ORM and ORU to FHIR DiagnosticReport, is covered in our lab integration guide.
Patient access through Healow
The patient-facing side of eClinicalWorks runs through healow, and its FHIR developer portal is how patient apps get authorized access to data. If your product lets patients view results, book appointments, or pull their records into a personal health app, this is the path you build against, using SMART on FHIR scopes so patients grant only the access they intend. Mirth can sit behind your app to cache and reshape what Healow returns, so your patient experience is fast and not bottlenecked by live API calls on every screen. Treating patient access as a first-class path, rather than an afterthought bolted onto a provider integration, is what makes these features feel polished.
Where the eClinicalWorks integrations get tricky
A few realities deserve attention upfront. FHIR coverage gaps are real: a resource may be supported in name but missing a field you need or behaving inconsistently in search, so always confirm against the actual API rather than the marketing claim. Code normalization is more variable in ambulatory settings because practices customize their setups, so your mapping tables carry real weight. And every channel needs a recovery path for the messages that fail, especially lab results, where a dropped ORU is a clinical safety issue, not just a technical one; our guide to message replay and dead letter queues covers handling those safely. Plan for these, and the integration stays stable.
Billing and revenue feeds
After labs, billing is the integration most ambulatory practices care about, because cash flow depends on it. eClinicalWorks generates charge and financial detail that needs to reach a billing service or clearinghouse, often as HL7 v2 DFT messages, and eligibility and claim status need to flow back so the front desk and billing team are not working blind. Mirth Connect handles this as a set of channels: it picks up charge messages as encounters close, reshapes them to whatever the billing partner expects, and routes them reliably, with a record of every message in case something needs to be resent.
The reason to run billing through the same engine as clinical and lab data is correlation and reliability. When a charge can be tied back to the encounter and the result that justified it, denials are easier to work with, and audits are less painful. And because the engine logs and can replay messages, a transient outage at the billing partner does not silently drop revenue, the messages queue and are resent. For a clinic, that reliability is the difference between an integration that quietly works and one that generates a stream of billing exceptions someone has to chase by hand.
A realistic rollout for a clinic
Ambulatory practices do not have the luxury of a long integration project, so the sequence matters. Start with a single high-value interface, usually a lab connection, and prove it end to end: orders out, results back, codes mapped, results landing in the right chart. Run it in parallel with whatever manual process it replaces until the staff trusts it. Then add billing feeds, then patient access through Healow, one capability at a time, so the practice always has a working system and never a big-bang switchover.
Keep the footprint small and well monitored. A clinic rarely needs hundreds of channels, but the handful it has should be named consistently, logged, and alerted so that a failed lab result or a stalled billing feed surfaces immediately rather than days later. This phased, monitored approach is what lets a small practice get hospital-grade integration without a hospital-sized team, and it keeps each new connection low-risk because the ones before it are already stable. Done this way, an eClinicalWorks integration grows with the practice instead of becoming a fragile dependency nobody wants to touch.
Security and compliance
Both paths handle Protected Health Information, so a Business Associate Agreement is required. The FHIR path uses OAuth 2.0 and SMART on FHIR scopes; HL7 v2 interfaces rely on network-level trust arranged with the practice or its hosting. We sign BAAs with US health systems and digital health customers, and we build on HIPAA-compliant, SOC 2 Type II, and ISO 27001 certified infrastructure with FHIR R4 native architecture. The FHIR resource reference is at hl7.org/fhir/R4.
This content describes engineering patterns. It does not include actual Protected Health Information. All data examples are synthetic.
How Nirmitee approaches the eClinicalWorks work
Healthcare is the only industry we serve, and ambulatory integration is a regular part of it. Our architecture is FHIR R4 native, so the eCW and Healow FHIR paths are familiar, and we treat HL7 v2 lab and billing feeds with equal care because that is where a clinic's daily reliability lives. The pattern we see work is consistent: one engine, the hybrid done deliberately, and lab integration treated as the safety-critical flow it is.
If you are connecting an eClinicalWorks practice to labs, billing, or a patient app and want a second set of eyes on the design, or want it built, share your use case at nirmitee.io, and we will tell you what we have shipped for similar ambulatory work.
