eClinicalWorks Integration Guide: V11, FHIR, Healow & HL7 v2

eClinicalWorks (eCW) is one of the most widely deployed ambulatory EHRs in the United States. You find it in independent primary-care offices, multi-specialty clinics, Federally Qualified Health Centers (FQHCs), urgent-care chains, and Accountable Care Organizations that span dozens of small practices. If your product, registry, or platform needs to work with ambulatory providers at scale, eCW will be on your list.

This guide is written for integration engineers, product managers, and health-IT leaders planning an eCW project. It covers the V11 platform, cloud vs on-prem deployment, FHIR R4 APIs, Healow patient-engagement integration, HL7 v2 message flows, 837/835 claim handling, and the role Mirth Connect plays as a neutral translation layer between eCW and everything else.

For broader context, see our EHR integration guide, HL7 integration guide, and FHIR integration guide.

1. eClinicalWorks in the EHR Landscape

Founded in 1999, eClinicalWorks is privately held and headquartered in Westborough, Massachusetts. It is one of the largest ambulatory EHR vendors in the US by number of providers served, with particular strength in:

Independent primary-care practices (1–10 providers).
Federally Qualified Health Centers (FQHCs) and community health centers.
Multi-specialty ambulatory groups.
Urgent care networks.
Independent physician associations (IPAs) and ACOs aggregating small practices.

That positioning matters for integration design. eCW customers range from two-provider practices with no IT staff to 300-provider groups with full integration teams. Your integration should work across that range, ideally without per-practice custom code.

Competitively, eCW runs adjacent to athenahealth, NextGen, Greenway, and Allscripts/Veradigm TouchWorks in the ambulatory segment. See our athenahealth integration guide, NextGen EHR integration guide, Greenway Health integration guide, and Allscripts / Veradigm integration guide for head-to-head comparisons.

2. V11 Platform — Cloud vs On-Premise

V11 is the current generation of eCW. Major subsystems:

Clinical EHR — charting, orders, results, prescriptions, documents.
Practice Management (PM) — scheduling, registration, claims, payments.
Healow — patient portal and mobile app, kiosk, televisit, messaging.
Interoperability layer — FHIR R4 APIs, HL7 v2 interfaces, CCDA generation.
Analytics & population health — reporting, quality measures, risk stratification.

2.1 Cloud (eCW SaaS)

eCW cloud is the default for most new customers. eCW hosts the application, manages infrastructure, performs upgrades, and exposes integration endpoints over HTTPS and (for HL7 v2) MLLPS. Network setup involves VPN or IPSec tunnels between the practice’s integration points and eCW’s hosting environment.

2.2 On-premise

Larger groups and some specialty practices still run eCW on-prem, typically on Windows Server and SQL Server. Integration surface is broadly similar but the firewall and security model is controlled by the practice’s IT team. On-prem deployments often have older HL7 v2 versions and long-established interface inventories.

2.3 Hybrid arrangements

Some multi-practice organizations run multiple eCW tenants (one per brand or region) that appear as a single operational entity. Integrations must handle per-tenant endpoints and credentials. Plan for multi-tenant configuration from the start.

3. Interface and API Surfaces — The Menu

The practical integration surfaces you’ll encounter:

FHIR R4 REST APIs — US Core profile reads, OAuth 2.0 with SMART on FHIR.
HL7 v2 MLLP — ADT, ORM, ORU, MDM, SIU, VXU, DFT.
CCDA generation and ingestion — for Direct messaging and document exchange.
Healow APIs — patient portal integration, televisit, messaging.
X12 837/835 — claim submission and remittance.
SFTP batch exports — for registry reporting and analytics.
Direct messaging (DirectTrust) — secure point-to-point clinical document exchange.

Surface          | Latency     | Authentication         | Typical use
-----------------|-------------|------------------------|---------------------
FHIR R4 REST     | Sync (ms)   | OAuth 2.0 / SMART      | App integration
HL7 v2 MLLP(S)   | Near-RT     | Network/TLS trust      | ADT, orders, results
X12 837/835      | Batch/RT    | Clearinghouse account  | Claims, remittance
CCDA via Direct  | Minutes     | DirectTrust cert       | Clinical summary
SFTP batch       | Daily/Hourly| SSH keys               | Registry, analytics
Healow APIs      | Sync        | Practice API key       | Patient engagement

4. eCW FHIR R4 APIs

eClinicalWorks’s FHIR R4 APIs are the modern path for application integration, especially for read-heavy use cases like quality reporting, care coordination, and patient-facing apps.

4.1 Resource coverage

Patient, Practitioner, Organization, Location
Encounter, Appointment, Schedule, Slot
Observation (labs, vitals), DiagnosticReport
Condition, AllergyIntolerance, Immunization, Procedure
MedicationRequest, MedicationStatement
DocumentReference (for CCDA and clinical documents)
CarePlan, Goal, CareTeam
Coverage (insurance information)

4.2 Authorization flow

# SMART on FHIR EHR launch flow (provider app)
GET /oauth/authorize?
  response_type=code&
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://yourapp.example.com/callback&
  launch=LAUNCH_ID&
  scope=launch openid fhirUser patient/*.read&
  state=RANDOM_STATE&
  aud=https://fhir.eclinicalworks.com/fhir/r4/PRACTICE_ID

# Token exchange
POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=RECEIVED_CODE&
redirect_uri=https://yourapp.example.com/callback&
client_id=YOUR_CLIENT_ID

4.3 Example patient query

GET /fhir/r4/PRACTICE_ID/Patient?identifier=MRN|12345
Authorization: Bearer eyJhbGciOi...
Accept: application/fhir+json

# Response: FHIR Bundle of matching Patient resources

4.4 Rate limits and quotas

eCW enforces per-application and per-practice rate limits. Plan for 429 responses with exponential backoff. For high-volume use cases like nightly population extraction, work with eCW to size quotas appropriately or use HL7 v2 batch patterns instead.

5. Healow Patient Portal Integration

Healow is eCW’s patient-engagement stack. Most patient-facing workflows go through Healow rather than the core EHR APIs:

Appointment booking and reminders.
Patient messaging and secure chat.
Records download (visit summaries, lab results).
Televisit and telemedicine.
Kiosk check-in.
Prescription refill requests.
Forms and intake questionnaires.

If your product is a digital front door, a patient app, or a self-service tool, you’ll integrate with Healow APIs for the patient-side flows and with the FHIR / HL7 v2 APIs for the clinical data. Healow API access is enabled per-practice and coordinates with the practice’s existing Healow configuration.

Patient-facing FHIR access (patient-scoped SMART on FHIR) is also available and is the recommended path for third-party patient apps that want raw FHIR resources rather than Healow’s pre-built flows.

6. HL7 v2 Interfaces on eClinicalWorks

HL7 v2 is still the dominant channel for near-real-time clinical data flow in and out of eCW. Typical message types:

ADT (A01, A03, A04, A08, A31) — patient demographics, encounters, updates.
SIU (S12, S14, S15) — appointment scheduling events.
ORM (O01) — orders for labs, imaging, and referrals.
ORU (R01) — lab and imaging results.
MDM (T02, T04) — clinical documents and addendums.
VXU (V04) — immunization updates (common for state registries).
DFT (P03) — charge capture events.

6.1 Sample ADT^A04 from eCW

MSH|^~\&|ECW|PRACTICE123|DOWNSTREAM|VENDOR|20260421101500||ADT^A04|MSG98765|P|2.5
EVN|A04|20260421101500
PID|1||MRN001234^^^PRACTICE^MR||SMITH^MARY^J||19850622|F||2106-3|456 OAK ST^^SPRINGFIELD^IL^62704||(217)555-0100|||M||ACCT554433
PV1|1|O|||||PRV001^JOHNSON^KEVIN^R^^DR||||MED||||ROU|||V2|||SC||||||||||||||||||PRAC|||||20260421101500
IN1|1|BCBSIL|BCBS001|BLUE CROSS BLUE SHIELD OF ILLINOIS||||||POLICY987654|EMP||||19850622|F|SMITH^MARY^J||SELF|||||||||||||||||||||POLICY987654

6.2 Transport

MLLP over TCP is the default, with TLS (MLLPS) strongly recommended and required for most payer and registry connections. For troubleshooting MLLP issues, see our MLLP connection refused guide.

7. 837 / 835 Claim and Remittance Flows

eCW has an integrated revenue cycle module that generates 837P (professional) and, where configured, 837I (institutional) claims. The 835 electronic remittance advice comes back and is posted to accounts automatically or semi-automatically.

7.1 Typical flow

Practice (eCW)
  → Claim generated from encounter
  → Scrubbed for payer-specific rules
  → Sent to clearinghouse (Trizetto, Change, Waystar, Availity)
  → Clearinghouse forwards to payer
  → Payer adjudicates
  → 835 ERA returns via clearinghouse
  → eCW posts payments, adjustments, denials

7.2 Where Mirth fits

When the practice has a non-standard clearinghouse setup, a specialty payer without a clearinghouse relationship, or a data warehouse that wants parsed 837 content, Mirth Connect acts as the broker. Mirth can read X12 files from SFTP, parse them into structured JSON, route to additional destinations, and archive for HIPAA audit.

8. Mirth Connect as the Integration Layer

eCW’s built-in integrations handle the common cases. But almost every practice we work with has at least one edge case that benefits from a neutral integration engine between eCW and the outside world. Common reasons:

Specialty registry feeds that don’t fit eCW’s stock interfaces.
Non-standard clearinghouse arrangements in 837/835 flows.
HL7 v2 ↔ FHIR translation for partners that expect a different format.
Multi-tenant aggregation when an ACO or IPA consolidates data across many eCW tenants.
Data warehouse hydration where messages land in structured stores for analytics.
HIPAA-grade audit logging beyond what eCW logs natively.

See our Mirth Connect guide for a deeper look at channel patterns, transformation, and operational setup.

9. FQHC and Ambulatory Deployment Patterns

Federally Qualified Health Centers have distinctive integration profiles:

UDS reporting — Uniform Data System annual submission to HRSA.
State immunization registries — VXU messages to the state IIS.
PCMH and HRSA quality reporting — multiple payer and program dashboards.
Dental and behavioral-health integration — FQHCs commonly have integrated dental (often Dentrix) and behavioral-health (often Credible or similar) systems alongside eCW.
Sliding-fee-scale financial workflows — unique to FQHCs and requiring careful interface design.
340B program reporting — pharmacy and payer interactions for discounted drugs.
HIE participation — most FQHCs connect to a state or regional HIE.

FQHC IT teams are typically lean (1–5 people for a mid-sized FQHC covering 10–50 providers), which makes reliability and self-monitoring essential. A typical FQHC integration footprint has 10–30 active interfaces, of which 3–5 are clearly critical (ADT, lab results, immunization registry) and the rest operate on slower or lower-risk cycles.

10. Sandbox and Developer Access

eClinicalWorks runs a developer program with a sandbox for FHIR R4 testing. To get started:

Apply via the eCW developer portal.
Receive sandbox credentials and FHIR endpoint URL.
Register your application with redirect URI(s) for OAuth.
Test against synthetic patient data in the sandbox.
Arrange per-practice production access with each customer practice.

Don’t assume sandbox parity with production on every edge case. Validate critical flows with at least one real practice in a low-volume pilot before rolling to more customers.

11. Common Pitfalls

11.1 Under-scoping multi-tenant handling

eCW organizations may span many tenants. If your product targets multi-site groups, plan for per-tenant credentials, endpoints, and identifiers from day one. Retrofitting multi-tenant support is painful.

11.2 Mixing up Healow and FHIR

Healow APIs and FHIR APIs address different audiences and have different scopes. If you try to build a patient app purely on core FHIR without Healow, you’ll miss the engagement workflows. If you try to build a clinical-data extraction purely on Healow, you’ll hit a ceiling.

11.3 Ignoring 837 scrubbing rules

Payer-specific scrubbing rules in eCW’s claim module determine whether claims will be accepted. Integrations that bypass the scrubber (by generating 837s externally) must reproduce those rules or face high rejection rates.

11.4 Weak monitoring

FQHCs and small practices rarely have 24/7 ops teams. Your integration must alert aggressively and fail gracefully. Build channel health monitoring, queue depth alerts, certificate expiry warnings (90/60/30/7/1 day), and an SLA that matches the practice’s actual operating hours.

11.5 Skipping the identifier conversation

eCW practices use local MRNs. ACO/IPA-level aggregation needs a cross-practice patient matching strategy. Decide early: enterprise MPI, probabilistic matching, or externally assigned global identifier.

12. Frequently Asked Questions

What is eClinicalWorks (eCW) and who uses it?

eClinicalWorks is a privately held ambulatory EHR vendor founded in 1999, headquartered in Westborough, Massachusetts. It is one of the most widely deployed ambulatory EHRs in the US, with particularly strong penetration in independent primary care practices, Federally Qualified Health Centers (FQHCs), community health centers, and multi-specialty ambulatory groups. The current platform is commonly called V11 or “eCW cloud” and runs both cloud-hosted and on-premise.

Does eClinicalWorks support FHIR?

Yes. eCW provides FHIR R4 APIs covering the US Core profile set required by ONC certification. Resources include Patient, Encounter, Observation, Condition, AllergyIntolerance, Immunization, MedicationRequest, Procedure, DocumentReference, and others. OAuth 2.0 with SMART on FHIR is supported for both patient-facing and provider-facing app launches.

What is Healow?

Healow is eClinicalWorks’s patient-engagement and portal product. It includes the patient mobile app, the Healow provider companion, kiosks, messaging, and televisits. Integrations that touch patient self-service (appointment booking, records download, messaging) typically flow through Healow rather than the core EHR APIs.

What HL7 v2 interfaces does eCW support?

All the standard ambulatory message types: ADT (demographics and encounter), ORM (orders for labs and imaging), ORU (results), MDM (documents), SIU (scheduling), VXU (immunizations), and DFT (charges). Transport is typically MLLP over TCP (or MLLP over TLS). eCW supports HL7 v2.3, 2.4, 2.5, and 2.5.1 depending on interface vintage.

How do 837 and 835 claim flows work in eCW?

eCW has an integrated revenue cycle module that generates 837 professional claims (837P) for outbound submission to payers and clearinghouses. The 835 electronic remittance advice comes back from the payer side for auto-posting. Many practices use a clearinghouse (Trizetto, Change Healthcare, Waystar, Availity) as an intermediary. Integration engines like Mirth Connect can broker these flows when eCW’s native connectors don’t fit the practice’s clearinghouse arrangement.

Is eCW cloud or on-premise?

Both. eCW cloud (often called eCW SaaS or hosted) runs on eClinicalWorks’s own infrastructure and is the default for most new customers. On-premise deployments still exist, especially in larger groups with custom integrations and data-residency requirements. The FHIR and HL7 v2 surfaces are broadly similar across hosting models, though network setup (VPN, firewall rules, endpoint addressing) differs.

How do I get a sandbox or developer access?

eClinicalWorks runs a developer program with a sandbox environment for FHIR R4 testing. Credentials are obtained via application to eCW’s developer portal, and the sandbox includes synthetic patient data. Production access for a specific practice requires that practice’s explicit authorization, and is enabled per-practice rather than globally.

Can I write data back to eClinicalWorks via FHIR?

Read access is broadly available across US Core resources. Write access is narrower: creating observations, documenting medications, or updating conditions via FHIR is possible for some resources and some practice configurations, but you should not assume full CRUD. For many real-world write-back needs, HL7 v2 ORM and MDM messages remain the practical channel.

Why add Mirth Connect if eClinicalWorks already has integrations?

eCW’s built-in integrations handle common ambulatory needs well, but practices almost always have edge cases: a specialty registry that needs a custom feed, a clearinghouse arrangement that doesn’t fit eCW’s defaults, a merger where two eCW tenants need data consolidation, or a population-health platform that expects FHIR but eCW is configured to send HL7 v2. Mirth Connect sits between eCW and the outside world to translate, route, and transform without modifying eCW.

What’s different about integrating with FQHCs on eCW?

FQHCs often have two characteristics that shape integration: (1) they participate in more registries and reporting programs than typical ambulatory practices (UDS, meaningful-use successors, state immunization registries, HRSA reporting), so outbound feed count is higher, and (2) their IT teams are typically lean, so reliability, monitoring, and alerting matter more than feature breadth. A thin, well-operated integration engine serves FQHCs better than a heavyweight, feature-rich one.

eClinicalWorks Integration Guide:V11, FHIR R4, Healow & HL7 v2

Table of Contents