eClinicalWorks FHIR Integration: healow and eClinicalWorks Developer Portals

Both portals handle developer sign-up and documentation. Choose based on who uses your app, not on which data you need; the same clinical data can be reachable through different authorization paths.

eClinicalWorks states that its certified FHIR APIs, including those certified to the ONC standardized API criterion §170.315(g)(10), are available to third-party developers and customers at no cost at this time, with at least 30 days’ notice of any future fees. It also notes it may offer chargeable value-added services.

• Customer activation. eClinicalWorks customers enable FHIR APIs through an On-Demand Activation feature in the application.
• healow production path. The healow portal describes joining, registering, testing and connecting; patient APIs connect directly, while scheduling APIs involve a contract and pricing review.
• Practice consent. As with other EHRs, access to a practice’s data depends on that practice enabling your app.

The healow portal describes its APIs as FHIR R4-based and lists USCDI v3. Because the APIs are certified to §170.315(g)(10), they are expected to support US Core-based single-patient access through SMART App Launch and multi-patient access through FHIR Bulk Data. Confirm the exact US Core version, scopes and launch modes in the portal documentation before you build. Our SMART on FHIR guide covers the flows.

GET [base]/Group/<group-id>/$export?_type=Patient,Condition,Observation
Accept: application/fhir+json
Prefer: respond-async
Authorization: Bearer <access_token>

eClinicalWorks customers range from small practices to large ambulatory groups, and each controls API activation for its own environment. Products that integrate with many practices need a repeatable onboarding process rather than a bespoke project per site.

• Document the activation steps a practice must complete and the scopes your app requests.
• Store per-practice endpoints and configuration outside your code.
• Monitor bulk export jobs per practice; large exports take time and can fail partway.
• Decide how you will refresh data: full re-export, incremental export using the _since parameter, or patient-level queries.

If you land exported data in your own repository, see FHIR server architecture.

• Patient-facing apps via healow: patient authorizes access to their record.
• Provider-facing apps via the eClinicalWorks portal, launched in clinician workflows where supported.
• Backend services for single-patient system access, authenticated with a signed JWT client assertion.
• Bulk data exports for population analytics and value-based care programs. See our FHIR API integration guide.
• Scheduling through healow scheduling APIs under commercial terms.

• Certified FHIR APIs focus on standardized data access; operational workflows may require value-added APIs with separate terms.
• Each practice must activate APIs and your application.
• Using the wrong portal for your app type causes rework in registration and authorization.
• Practice-level configuration varies, so map data defensively.

Timelines are driven by app type and portal, whether you need value-added APIs and their contracting, and practice-by-practice activation. See FHIR integration cost for planning.

• Have you shipped apps through healow, the eClinicalWorks portal, or both?
• Which of our workflows are covered by certified APIs and which need value-added APIs?
• How do you handle On-Demand Activation and practice onboarding at scale?
• Have you implemented bulk export against eClinicalWorks, and how did you handle large groups?

Browse EHR integration vendors filtered by eClinicalWorks.