Taction Software — FHIR Integration with Mirth Connect
EHR Integration

eClinicalWorks Integration Services: FHIR, Healow, and Beyond

eClinicalWorks integration services need to account for a specific structural reality: certified FHIR R4 APIs are documented on two separate developer portals, one provider-facing and one patient-facing through Healow, and both use SMART on FHIR OAuth, but production access still requires per-practice enablement even for a fully certified application. Anything beyond the USCDI-aligned certified subset, like charges, claims, full scheduling, and other practice management data, becomes a separately negotiated commercial interface rather than a free API call.

Below is what eClinicalWorks' FHIR layer actually covers, how we navigate the per-practice enablement process, and where negotiated interfaces become necessary for broader data needs. If you're scoping an eClinicalWorks integration, our free Mirth Health Check can review your requirements directly — part of the Mirth Connect support work we do for US healthcare teams.

What eClinicalWorks' Certified FHIR APIs Actually Cover

eClinicalWorks documents its FHIR APIs across two distinct portals, and understanding which one applies to your specific use case matters before scoping any integration work.

Two Separate Developer Portals for Different Audiences

Provider-facing FHIR documentation lives on eClinicalWorks' own developer portal, while patient-facing access runs through the Healow platform, and each has its own specific credentialing and documentation you'll need to navigate separately.

FHIR Coverage Stops at the USCDI-Aligned Subset

The free, certified FHIR API surface is limited to the USCDI-aligned data set required for certification, meaning financial data, full scheduling, and many operational endpoints simply aren't available through the standard FHIR pathway.

SMART on FHIR OAuth Across Both Portals

Both the provider-facing and patient-facing FHIR surfaces use OAuth 2.0 with SMART on FHIR authorization, giving a consistent authentication pattern even though the underlying data access and audience differ between the two portals.

Open Sandboxes With Synthetic Data for Testing

eClinicalWorks provides open sandbox environments using synthetic data for both portals, letting you build and test integration logic before needing actual practice enablement or real patient data access.

How We Navigate Per-Practice Enablement Requirements

Even a fully certified FHIR application still needs each specific practice to enable API access before real data actually flows, and planning around that requirement matters for realistic project timelines.

Confirming Certification Requirements Upfront

We confirm exactly what certification your specific application needs before development begins, since building against the wrong certification tier can mean rework later when a practice's enablement process reveals a mismatch.

Coordinating Practice-Level Enablement Directly

Per-practice enablement requires direct coordination with each specific eClinicalWorks customer, and we help manage that process so technical readiness and administrative enablement happen on a realistic, coordinated timeline together.

Building and Testing Against the Open Sandbox First

We build and validate integration logic against eClinicalWorks' open synthetic-data sandbox before any real practice enablement, catching issues in a safe testing environment rather than during limited production access windows.

Documenting the Enablement Process for Future Practices

For integrations meant to scale across multiple eClinicalWorks practices, we document the enablement process clearly, so replicating the connection for additional practices doesn't require reinventing the coordination process each time.

Where Negotiated Interfaces Become Necessary

For data and workflows outside the certified USCDI subset, eClinicalWorks requires a separately negotiated commercial interface rather than free API access, and planning for this distinction avoids scoping surprises later in a project.

Financial and Revenue Cycle Data Sits Outside FHIR

Charges, claims, remittances, and other financial or revenue cycle data fall outside the free, certified FHIR surface entirely, requiring a negotiated interface with associated fees rather than a standard API integration approach.

Full Scheduling Needs a Negotiated Path Too

Beyond basic patient-facing scheduling through Healow, full practice management scheduling functionality typically requires the same negotiated commercial interface path as financial data, rather than being available through certified FHIR.

Custom Extracts and HL7 v2 Remain Commercial Arrangements

Proprietary, non-FHIR integrations including custom data extracts and HL7 v2 interfaces are negotiated commercially per integration, so budget both time and cost for this path if your project needs data outside the certified subset.

We Scope Realistically Around What's Actually Free vs Negotiated

Rather than assuming FHIR alone covers your project, we clarify upfront which specific data your integration needs falls into the free certified tier versus the negotiated commercial tier, avoiding budget surprises partway through.

Scoping an eClinicalWorks integration project?

Start with a free Mirth Health Check to review your requirements, send us the exact error if you're troubleshooting an existing integration, or check pricing for our support plans.

FAQ

Frequently Asked Questions

Are eClinicalWorks' FHIR APIs actually free to use?
The certified, USCDI-aligned FHIR APIs are free, but production use still requires per-practice enablement by eClinicalWorks, and anything beyond that certified subset requires a separately negotiated commercial interface with associated fees.
What's the difference between the two eClinicalWorks developer portals?
The provider-facing portal at fhir.eclinicalworks.com covers clinical FHIR APIs for practice-side applications, while the patient-facing portal through Healow serves patient access use cases, and each requires separate documentation and credentialing.
Does eClinicalWorks support full practice management scheduling via API?
Not through the free, certified FHIR surface — full scheduling functionality beyond basic patient-facing capability typically requires a negotiated commercial interface, similar to how financial and billing data access works outside FHIR.
How long does per-practice enablement typically take?
This varies by practice and use case, so there's no fixed universal timeline, though starting the coordination process early and testing thoroughly against the sandbox first generally shortens the overall path to production.
Can I access eClinicalWorks financial data through their FHIR API?
No, charges, claims, remittances, and other revenue cycle data sit outside the certified FHIR subset entirely, requiring a separately negotiated commercial interface arrangement rather than standard API access.
Does Mirth Connect work well for eClinicalWorks integration projects?
Yes, Mirth Connect can consume eClinicalWorks' FHIR API responses and also handle any negotiated HL7 v2 interfaces your project requires, making it a practical single engine for projects spanning both integration types.

Need expert Mirth Connect support?

Whether you have a one-time integration project or need ongoing managed support, every engagement is named, scoped, and priced upfront — productized packages, no hourly billing.

Talk to a Mirth Solutions Architect

60-second form. Senior engineer responds within one business day.

What is 9 + 9 ?