Part of our complete guide to HL7 data exchange standards.

You signed a customer who runs eClinicalWorks. They want your app to read their patients' problems, meds, and results — and maybe write an order back. You open the docs and immediately hit the real questions: Is the FHIR API enough, or do I need an HL7 interface? Do I register with eCW or with healow? And why does everyone say production access takes longer than the build?

Those are the right questions. eClinicalWorks is one of the largest ambulatory EHRs in the US, dominant in private practice, so the customer demand is real — but the path in has three lanes, and picking the wrong one costs you weeks. This guide walks the FHIR R4 APIs, the healow app platform, the HL7 v2 fallback, and the onboarding reality that actually drives your timeline.

Why eClinicalWorks is its own integration project

eCW sits in a different market than the big inpatient names. It is an ambulatory, private-practice EHR — independent clinics, specialty groups, and physician offices rather than large hospital systems. That shapes everything about integration: there are many small, independently configured practices, each of which authorizes your app separately, and the patient-engagement layer (scheduling, portal, app access) lives in a sibling platform called healow.

If you have integrated with other vendors, the standards will look familiar but the operational model will not. The general playbook still applies — we cover it in our EHR integration guide on methods, vendor APIs, security — but eCW's split between the provider-facing FHIR portal and the patient-facing healow portal is the first thing that trips teams up.

The FHIR R4 APIs: certified, but a subset

eClinicalWorks exposes ONC-certified FHIR R4 endpoints aligned to US Core and the USCDI data elements. For read access, the coverage is genuinely broad: Patient, Condition, Observation, MedicationRequest, MedicationStatement, AllergyIntolerance, Immunization, DiagnosticReport, DocumentReference, Encounter, CarePlan, CareTeam, Coverage, Goal, Organization, Practitioner, and more across the USCDI v1 and v3 data classes.

The important word is subset. The FHIR implementation does not cover every resource you might want, and the read surface is where it is strongest. If your customer is on an older build, some USCDI v3 / HTI-1 data classes require them to be on a recent cumulative patch — so a "supported" resource on paper can still be unavailable until the practice upgrades. Verify the live capability statement for the specific practice rather than trusting a generic feature list.

Standalone vs EHR launch (SMART on FHIR)

Authentication uses OAuth 2.0 with SMART on FHIR launch flows, in the two standard flavors:

• Standalone launch — your app starts on its own (a patient or clinician opens it directly) and initiates the OAuth handshake to obtain a token.
• EHR launch — your app is launched from inside eCW with a launch context, so it inherits the current patient and user.

The scopes your app receives at authorization can be a subset of what you registered for, and each practice consents to its own scope set. If your auth model isn't watertight, this is exactly where it breaks. The OAuth, SMART, and HIPAA mechanics are worth getting right once and reusing — our OAuth and SMART on FHIR security goes deep on the token and scope handling.

Write access is the real ceiling

Reading from eCW over FHIR is the well-paved road. Writing is not. FHIR Create operations are supported for a limited, specific set of resources — including AllergyIntolerance, Condition (problems and encounter diagnoses), Immunization, MedicationRequest (orders), MedicationStatement (reconciliation), ServiceRequest (lab, diagnostic imaging, and procedure orders), DocumentReference (C-CDAs and PDFs), Patient (create/update), and Task. That list is real, but it is narrow compared to read, and it is gated behind a separate contract: clients have to specifically request and contract for the FHIR Create APIs.

This matters for scoping. If your product's core value is writing structured data back into the chart, assume two things: the resource you want may not be writable over FHIR, and even when it is, you'll need a commercial conversation before you get production write access. Teams that discover this late end up redesigning mid-build. For why these mismatches sink projects, see why EHR integrations fail without intelligent systems.

healow: the app marketplace and patient-facing path

healow is eClinicalWorks' patient-engagement and app platform — the patient portal, scheduling, and the app ecosystem patients and practices actually touch. The split in the developer experience is clean once you know it:

• Provider-facing apps (SMART on FHIR, bulk/backend services) register through the eClinicalWorks FHIR developer portal.
• Patient-facing apps (patient data access, scheduling) register through the healow FHIR developer portal.

Choosing the wrong portal for your app type is a common early mistake. Decide who your end user is — clinician inside the chart, or patient in an app — before you create a single credential.

Onboarding: approval and production access drive the timeline

Here is the part teams underestimate. The integration code — OAuth, fetching a Patient, parsing a Bundle — is a few days of work for a competent team. The timeline driver is everything around it: registering on the correct portal, building against a sandbox, passing review, contracting (especially for write APIs), and then getting production access scoped per practice. Compared to the largest hospital EHRs, eCW's onboarding is often faster, but "faster" is relative — review and production access are still measured in weeks, not hours, and they have cost attached.

Two specific traps live in this phase:

Sandbox vs production data

The sandbox is synthetic and limited. It is fine for proving your OAuth flow and your parsing, but it will not surface the messy reality of a live practice — the missing fields, the local code sets, the build-version gaps in USCDI coverage. Plan a deliberate validation pass against real (consented) production data before you call the integration done.

Rate limits and per-practice scoping

Production APIs are rate-limited, and access is scoped per practice rather than granted once globally. An app that works for your first customer still has to be authorized, scope by scope, for the next. Build your onboarding and token management to handle many independently configured practices from day one.

HL7 v2: the fallback when FHIR doesn't reach

When the FHIR endpoints don't cover the data you need — or you need real-time, event-driven push rather than polling — HL7 v2 interfaces are the established alternative. eCW, like every mature ambulatory EHR, speaks the classic message types:

• ADT (Admit/Discharge/Transfer) for patient demographics and registration events.
• ORU for observation results — lab and diagnostic results flowing back.
• ORM / order messages for orders into and out of the system.

HL7 v2 trades the clean, certified, self-service feel of FHIR for breadth and event-driven delivery. The cost is that each interface is typically a per-practice build over a VPN/MLLP channel, with its own mapping and testing. The practical pattern most teams land on is a hybrid: a FHIR read path for the certified USCDI elements, plus an HL7 v2 feed for the data FHIR doesn't expose or for real-time results. When you are integrating across several vendors at once, a unifying layer keeps this from multiplying — see our take on a multi-EHR FHIR facade for Epic, Cerner, athena, and a.

Choosing your path

Work through it by data element, not by preference. If you only need certified reads of USCDI elements, the FHIR R4 API via standalone or EHR launch is the cleanest route. If you must write structured data back, accept that you are looking at the limited FHIR Create set under contract, or HL7 v2 for orders and results. If you need data the FHIR API simply doesn't expose, plan an HL7 v2 interface. And if your app is patient-facing, you are in healow's lane from the start.

Mapping each data requirement to a path up front is what sets a realistic timeline. We've done this work for a number of teams — healthcare is the only industry we serve, we're FHIR R4 native, and we've delivered EHR integrations for 30+ healthtech startups, including multi-EHR builds spanning Epic, Cerner, Allscripts, and athenahealth for Yown Health. If you want the honest version of what the first stretch looks like, our first 90 days of EHR integration timeline lays it out without the sales gloss.

Key takeaways

• eCW offers three paths: certified FHIR R4 APIs, the healow patient-facing platform, and HL7 v2 interfaces — choose by data needs, not by what's newest.
• FHIR read coverage across US Core / USCDI is broad; write access is a narrow, separately contracted set of resources.
• Provider/SMART apps register on the eCW FHIR portal; patient-facing apps register on the healow portal.
• Approval, contracting, and per-practice production access drive the timeline — the integration code is the small part.
• Sandbox data is synthetic; validate against real consented data, and design for rate limits and per-practice scoping.
• When FHIR doesn't cover the data or you need real-time push, fall back to HL7 v2 (ADT, ORU, orders) — most real builds are hybrid.

If you're scoping an eClinicalWorks integration and want a second opinion on which path fits your data and your timeline, grab a 15-minute call and we'll map it with you.