A technical guide to eClinicalWorks integration: FHIR R4 APIs, SMART on FHIR authorization, bulk export, write-back, and the HL7 v2 interfaces that carry real-time workflow, plus what each one costs.
The FHIR read path is standards-based and well documented. What teams underestimate is everything around the endpoints: developer programs, per-practice authorization, write access, and which capabilities carry their own contract and cost.
eClinicalWorks (eCW) is one of the largest ambulatory EHR vendors in the United States, with a footprint concentrated in independent practices, multi-site physician groups, community health centers, and specialty networks. If you build software that touches ambulatory care — care management, RCM, lab, imaging, digital front door, analytics, population health — you will eventually be asked to connect to an eCW instance.
The good news: eClinicalWorks (eCW) is ONC-certified and publishes FHIR R4 endpoints aligned to US Core and USCDI, so the read path is standards-based and well documented. The part teams underestimate is everything around the endpoints — which developer program you belong to, how each practice authorizes you, which resources are actually writable, and which capabilities carry a separate contract and cost.
This guide covers what's available, how authorization works, and the design decisions that determine whether your integration scales past the first customer.
What determines scope, cost, and timeline
$export), and HL7 v2 interfaces. Most production integrations use at least two.There are three distinct surfaces, and most real deployments use more than one:
Standards-based RESTful access to USCDI data classes — demographics, problems, medications, allergies, immunizations, labs, vitals, encounters, documents, care plans, coverage. This is the certified surface and the cheapest path to data.
Asynchronous, population-scale export for analytics, data warehousing, migration, and quality reporting. Server-to-server, no user in the loop.
The traditional interface engine path — ADT, ORU, SIU, MDM, DFT, ORM. This is where real-time, event-driven, and high-volume bidirectional workflow actually lives.
The practice initiates an HL7 interface request through its eClinicalWorks (eCW) account manager — a vendor partner cannot open it on the practice's behalf. Instances and channels are a chargeable line item, priced per instance and per channel. Get the request started early and budget for it at project kickoff rather than discovering it during scoping.
Alongside these sit C-CDA document exchange and the EHI export capability certified at 45 CFR §170.315(b)(10), which is designed for full-record export rather than for building a product on.
This is the first fork in the road, and getting it wrong costs weeks.
healow is eClinicalWorks' patient engagement platform. If your app is used by a patient, you are in the healow program regardless of what data you need. If it is used by staff or runs headless, you are in the eCW program. Registering in the wrong one means a second intake cycle and a second developer agreement.
The intake, review, and execution of the eClinicalWorks (eCW) FHIR API developer agreement is a real dependency on your project timeline — treat it as a critical-path item, not paperwork.
eClinicalWorks (eCW) uses OAuth 2.0 under the SMART on FHIR framework. There are three flows you'll encounter, and which one you use is determined by your app type — not by preference.
Your app is launched from inside the eCW chart. The EHR passes a launch token, you exchange it via the authorization endpoint, and you receive an access token scoped to the current user and patient context. Scopes take the patient/Resource.read form. This is the flow for clinical decision support, in-workflow tooling, and anything a provider opens during a visit.
Your app initiates authorization outside the EHR; a user authenticates and consents. Scopes take the user/Resource.read form. Refresh tokens are typically available so you can maintain a session beyond the short access-token lifetime.
The flow for bulk export and any unattended, server-to-server integration. You register a public key (via JWKS URL or direct upload), sign a JWT client assertion with your private key, and exchange it at the token endpoint for a short-lived access token. Scopes take the system/Resource.read form. There is no refresh token — you mint a fresh assertion each time, which is a feature, not a limitation.
/metadata on each practice's endpoint. Resource coverage, supported search parameters, and USCDI version vary with the customer's build and upgrade cadence. Do not assume the documentation matches the instance in front of you.Bulk export follows the HL7 FHIR Bulk Data Access (Flat FHIR) implementation guide. The pattern is asynchronous:
Group/[id]/$export) with Prefer: respond-async. Narrow the payload with _type to request only the resources you need, and _since for incremental pulls.Content-Location status URL. Poll it; it returns 202 Accepted while the job runs and 200 OK with a manifest when complete.application/fhir+ndjson. Download, then process line by line.Export duration scales with population size, number of resource types, and date range. A first full pull on a large practice is measured in hours, not minutes.
Use bulk export for: initial data loads, seeding a warehouse or lakehouse, migration off eCW or onto a new platform, population health and risk stratification, quality measure calculation, ML training sets, periodic full reconciliation.
Do not use bulk export for: real-time workflow, single-patient lookups, or same-day synchronization. Those belong on the single-resource FHIR reads or, more often, on HL7 v2.
The read surface is the strongest part of the eClinicalWorks (eCW) API. Coverage is aligned to US Core profiles across USCDI data classes, and typically includes:
| Data class | FHIR resources |
|---|---|
| Patient demographics | Patient |
| Problems | Condition |
| Medications | MedicationRequest, MedicationStatement, Medication |
| Allergies | AllergyIntolerance |
| Immunizations | Immunization |
| Labs and results | Observation, DiagnosticReport |
| Vitals and smoking status | Observation |
| Procedures | Procedure |
| Encounters | Encounter |
| Clinical notes and documents | DocumentReference |
| Care coordination | CarePlan, CareTeam, Goal |
| Coverage | Coverage |
| Provider directory | Practitioner, PractitionerRole, Organization, Location |
| Devices | Device |
| Provenance | Provenance |
Two caveats worth designing around. First, this is a subset — it is not every FHIR R4 resource, and gaps in scheduling, financial, and order data are common. Second, USCDI v1 versus USCDI v3 / HTI-1 coverage depends on the practice's build. If your product depends on newer data elements, confirm against the instance before you commit to a scope.
Yes, but selectively — and this is the single most important scoping question in any eClinicalWorks (eCW) project.
eClinicalWorks (eCW) supports POST create operations for a defined subset of FHIR resources — considerably narrower than the read surface. Which resources are writable changes over time and by build, so confirm the current list directly with eClinicalWorks (eCW) rather than relying on any published summary, including this one. Create access is not part of the default read entitlement: it is licensed separately, carries a cost, and requires a commercial conversation before production access is granted.
For most write-back at volume, HL7 v2 remains the more capable path. Inbound ADT for registration and demographic updates, ORU for results, SIU for scheduling, MDM for documents, and DFT for charges cover workflows that FHIR create does not reach. The practice opens this request with its eCW account manager, and each instance and channel is chargeable.
Writing a C-CDA or PDF into the chart via DocumentReference is frequently the pragmatic middle path when structured create isn't available for your data. It gets clinically relevant information in front of the provider without waiting on a resource-level write entitlement.
Decide your write path before you build your data model. If your product's core value is structured data landing in the chart, validate that the specific resource is writable, on that customer's build, under a contract that exists — before you architect around it. Teams that assume write parity with read end up redesigning mid-project.
Three cost centers to plan for:
Read-only FHIR and bulk export are the least expensive way in. Every write path has a price attached. Sequence your roadmap accordingly: prove value on reads, then fund the write path with revenue.
FHIR reads are pull-based. If you need to know within seconds that a patient checked in or a result posted, that is an HL7 feed, not a polling loop. Polling FHIR for near-real-time is the most common architectural mistake in eClinicalWorks (eCW) integrations and it does not survive scale.
Single-tenant integrations tolerate manual credential handling. Multi-tenant products need per-practice base URLs, credential vaulting, token lifecycle automation, capability-statement drift detection, and per-tenant observability. Build it once, early.
Decide your identifier strategy up front: eCW patient ID, MRN, and your own internal ID, with explicit precedence and a documented handling path for mismatches and duplicates. Every downstream data-quality problem traces back to this decision.
Deltas drift. Plan a periodic full reconciliation — bulk export is well suited to it — against your incremental feed, plus alerting when counts diverge.
Map to standard code sets (ICD-10, SNOMED, LOINC, RxNorm, CVX) at the boundary, not in your application logic. eCW instances carry local codes; normalize once.
Sandbox data does not reflect a live practice's volume, custom fields, or build version. Budget a real validation cycle with the customer's instance before go-live.
Intely is an integration platform built for exactly this problem: connecting to eClinicalWorks (eCW) instances without your team absorbing the full cost of the developer program, the per-practice authorization lifecycle, and the HL7 channel build.
Teams typically use Intely to go live on their first eClinicalWorks (eCW) customer in a fraction of the time a from-scratch build takes, and — more importantly — to onboard the next twenty without linear engineering cost.
Yes. eClinicalWorks (eCW) exposes ONC-certified FHIR R4 APIs for provider-facing and backend/bulk access, plus HL7 v2 interfaces and C-CDA document exchange.
FHIR read access under the certified endpoints is the least costly path. HL7 instances and channels are chargeable and are requested by the practice through its eCW account manager, and FHIR create/write endpoints are licensed separately at additional cost.
FHIR R4, with US Core profiles aligned to USCDI. Confirm the exact USCDI version supported on each practice's instance via its capability statement.
Yes, for a limited subset of FHIR resources under a separate commercial agreement, and more broadly through inbound HL7 v2 channels.
Plan for the developer agreement intake and review as a critical-path item, plus per-practice authorization for each customer instance. HL7 interface requests add their own lead time and must be initiated by the practice with its eCW account manager.
Bulk export for initial loads, migrations, and population-scale analytics. Single-resource reads for patient-in-context workflows. HL7 v2 for anything that must be real time.
FHIR, bulk export, and HL7 in one managed connector — so your first eCW customer goes live faster and the next twenty don't cost you linear engineering time.
Talk to our team Visit intely.io
.png)
