For health tech products
We build eClinicalWorks integrations for health tech products: provider SMART apps, backend and bulk data feeds, patient and scheduling apps through healow, HL7 v2 interfaces and contracted write-back. We also run the access path with you, from app registration and agreements to activation in each practice. For API-level detail, read our eClinicalWorks API integration guide.
Plan my eClinicalWorks integrationFor digital health products, practice networks and healthcare software teams selling into eClinicalWorks practices. Updated September 2026.
What we build
eClinicalWorks splits developer access across two portals: provider and backend apps register on eClinicalWorks Connect, and patient, scheduling and remote monitoring apps on the healow developer portal. Most products need pieces from both.
Documentation, decision support and review tools that a clinician opens inside eClinicalWorks. The EHR launch loads your app in an iframe with patient and encounter context; a standalone launch signs the user in from your own app. We handle secret or private key JWT clients, PKCE with S256 and refresh tokens. For cards in the workflow, eClinicalWorks supports CDS Hooks for encounter-start and order-select.
Analytics, population health and data platform feeds that use client_credentials with a signed JWT and a JWKS URL registered on the portal. eClinicalWorks returns invalid_client when that URL is unreachable or not allowlisted, and expects system/Group.read in bulk token requests only. Bulk export follows Bulk Data STU 1.0.1 against patient groups the practice saves from its EMR Registry, with _since for incremental loads.
Patient access apps read US Core 6.1.0 data through healow, need no contract, and go live for every practice with Patient APIs enabled once registration succeeds. Online booking runs on the healow Scheduling API (FHIR DSTU2), which needs a pricing agreement with healow and each practice's consent. Remote monitoring devices post readings through the healow RPM Device API.
ADT, SIU, ORM, ORU, DFT and MDM messages over an interface the practice sets up with eClinicalWorks. eClinicalWorks says lab interfaces need a statement of work and may carry costs, and publishes no HL7 v2 specification, so we work from the practice's interface documents. We build and run the Mirth Connect channels, mapping, acknowledgements, alerting and replay.
eClinicalWorks lists 29 create, update and delete FHIR APIs, among them Patient, Coverage, Condition, Immunization, MedicationRequest, vital signs, referrals and clinical notes. They are contracted through interop@eclinicalworks.com, many need a specific 12.0.2 or 12.0.3 patch, and none appear in the public CapabilityStatement. We build against the resource specifications and error code guide.
Two kinds of access
Read and search APIs for USCDI v1 (US Core 3.1.1) and USCDI v3 (US Core 6.1.0) on a per-practice base URL. USCDI v3 reads need a recent 12.0.2 or 12.0.3 patch; otherwise eClinicalWorks answers that the scope is not supported.
Write-back, healow appointment booking and one Encounter read labelled as a paid API sit outside the certified set. Each needs its own agreement, and prices are not published.
From registration to production
Contracts and practice activation decide the calendar more than code does, so we start them on day one.
We set up your organization on eClinicalWorks Connect and, where needed, healow, then register each app with its scopes, URLs and JWKS URL. EHR-launch apps are tested in the eClinicalWorks sandbox.
Registered apps, a first launch and a scope list.If the product writes back or books appointments, we prepare the request to eClinicalWorks or healow with you, listing the exact APIs.
A written API list for each agreement.We build the integration and check each practice's eClinicalWorks version against the patch each API needs, including USCDI v3 reads and every write.
Tested workflows and a version matrix per practice.We publish the app, share its App Activation Code and walk each practice through activation. Bulk apps also need the practice's patient groups.
A repeatable activation runbook and support handover.Evidence
The engineering behind our eClinicalWorks delivery, with public code and test results you can inspect.
One app run against the Epic and Oracle Health developer sandboxes in a single session, with the launch, PKCE and token handling an eClinicalWorks SMART app needs.
Our team has built 350+ interfaces on Mirth Connect, the engine we use for the HL7 v2 side of an eClinicalWorks integration.
Passes 47 of 47 ONC (g)(10) SMART App Launch tests (11 Jun 2026), so we know the server side of the launch.
Headless EHR on GitHub ↗Before you commit
Your organization does. Apps are registered to your organization on eClinicalWorks Connect and healow, and any contract is between you and eClinicalWorks, so the integration and its access stay yours. We handle the registration work, build the integration and run activation with each practice.
Not for the certified FHIR APIs today: eClinicalWorks says they are available at no cost at this time, including bulk. Write APIs, healow scheduling and the Encounter read labelled as paid need an agreement, and those prices are not published.
Yes, for the resources eClinicalWorks lists, under a contract arranged through interop@eclinicalworks.com, and many writes need a recent 12.0.2 or 12.0.3 patch. We confirm each write, how clinicians see it and how duplicates are handled before it goes into scope.
Not through the eClinicalWorks FHIR server, which has no Appointment, Schedule or Slot resource. Booking runs on the healow Scheduling API, which needs a pricing agreement with healow and consent from each practice. HL7 SIU messages are the other route.
For provider and backend apps, you share the App Activation Code, the practice adds it under Product Activation, you approve the practice on the portal and the practice clicks Activate. Patient apps on healow skip this step.
Going over 250 calls a minute on any practice blocks your whole app for the rest of that minute. We cache tokens, queue requests per practice and use bulk export for large loads, so one busy practice cannot stop the others.
Partly. EHR-launch apps run in the eClinicalWorks sandbox and patient apps in the healow sandbox. Backend and bulk apps need a practice that has activated them, so we line up a first practice early.
Often, yes. eClinicalWorks was designated a QHIN in January 2025 and exchanges records through PRISMANet. That helps retrieve records for treatment, but it does not put your product in the clinician's workflow, book appointments or write back to the chart.
The number of workflows, read versus write scope, healow scheduling or HL7 v2, how quickly agreements are signed and how many practices you activate. Any eClinicalWorks or healow charges are separate from our engineering fees.
Define the next step
Tell us about your product and the practices you sell to. We will come back with the app types, agreements and activation steps your workflow needs.
Please don’t include patient data, credentials or sensitive records.
eClinicalWorks and healow are trademarks of eClinicalWorks, LLC. Other product names are trademarks of their respective owners.
