Written and maintained by CASRAI Editorial Board
Last updated
eClinicalWorks (eCW) is a cloud-based ambulatory electronic health record (EHR), practice management, and patient engagement platform whose external interoperability architecture splits across two specialized HL7 FHIR Release 4 (R4) developer portals: eClinicalWorks Connect (fhir.eclinicalworks.com) for provider-facing SMART on FHIR and Bulk Data backend services, and the healow Developer Portal (connect4.healow.com) for patient-access apps, remote patient monitoring (RPM) devices, and online scheduling.
What eClinicalWorks and healow Are
eClinicalWorks develops ambulatory EHR and revenue cycle software used by outpatient medical practices, federally qualified health centers (FQHCs), urgent care clinics, and multi-specialty groups. Within the eClinicalWorks software ecosystem, three components govern clinical data capture, patient access, and reporting:
- eClinicalWorks EHR & Practice Management: The core clinician charting, order entry, e-prescribing, and billing environment, connected to national interoperability frameworks such as Carequality.
- healow (Health and Online Wellness): eClinicalWorks’ patient-facing portal, mobile app, telehealth, online appointment booking, and remote patient monitoring (RPM) platform.
- Enterprise Business Optimizer (eBO): The analytics and business intelligence reporting layer used by practices and clinical researchers to query structured clinical, operational, and financial tables from the eClinicalWorks backend database.
How Third-Party Systems Integrate With eClinicalWorks (eCW)
Unlike EHR vendors that host all API traffic on a single portal, eClinicalWorks separates third-party integration by whether the workflow is provider/system-driven or patient/scheduling-driven. Both portals operate on HL7 FHIR R4, align with United States Core Data for Interoperability (USCDI v3) and HL7 FHIR US Core profiles, and carry HIPAA and HITRUST security controls under ONC Health IT Certification criterion 45 CFR § 170.315(g)(10).
| Integration Dimension | eClinicalWorks Developer Portal (fhir.eclinicalworks.com/ecwopendev) |
healow Developer Portal (connect4.healow.com) |
|---|---|---|
| Portal Version & Scope | eClinicalWorks Connect (v4.0.7.6); over 3,710 registered applications |
healow Developer Portal (v8.19.9) |
| Target Application Types | Provider-facing EHR apps, SMART on FHIR clinician tools, and multi-patient Backend / Bulk Data services | Patient-facing SMART on FHIR apps, Remote Patient Monitoring (RPM) devices, and online appointment scheduling apps |
| Declared FHIR R4 Operations | Read, Create, Update, Delete, and Bulk operations ($export) |
Read, Create, Update, and Delete operations (single-patient & scheduling) |
| Standard vs. Contract Onboarding | Apps without contract-required scopes go from Sandbox Test to Publish and share an activation code with clients; contract-required scopes add Scope Review and a Pricing Agreement | Patient APIs go straight from Test to Connect; Scheduling APIs require the eCW practice to open a support case, sign a Pricing Agreement, and configure with an account manager |
How eClinicalWorks FHIR R4 and healow APIs Work
According to the official documentation on fhir.eclinicalworks.com/ecwopendev and connect4.healow.com/apps/jsp/dev/r4/fhirClinicalDoc.jsp, developers follow a structured five-to-six step lifecycle depending on which portal and scope class their application uses:
1. Provider and Backend Integration Steps (eClinicalWorks Connect)
- Join: Sign up for a developer account on the eClinicalWorks Developer Portal (
fhir.eclinicalworks.com/ecwopendev). - Register: Register the application metadata, OAuth 2.0 redirect URIs, and requested FHIR R4 scopes (Read, Create, Update, Delete, or Bulk).
- Scope Review and Pricing Agreement (only for contract-required scopes): If the app requests write/operational scopes beyond standard open scopes, complete Scope Review and execute a Pricing Agreement with eClinicalWorks.
- Test: Validate SMART on FHIR launch sequences, USCDI v3 resource parsing, and token handling in the eCW sandbox environment.
- Publish: Promote the validated application to production status in the portal.
- Connect: Share the generated application activation code with participating eClinicalWorks practices so practice administrators can enable the integration inside their EHR environment.
2. Patient-Access and Scheduling Integration Steps (healow API)
- Join and Register: Create an account on
connect4.healow.comand register the patient-facing, RPM, or scheduling app. - Test in Sandbox: Verify FHIR R4 Read/Create/Update/Delete calls and OAuth 2.0 authorization flows.
- Connect (Patient APIs) or Move to Production (Scheduling APIs): Standard 45 CFR § 170.315(g)(10) Patient APIs connect directly after testing so patients can authorize access using their healow credentials. For Scheduling APIs, the customer eCW practice opens a support case, signs a Pricing Agreement, and completes configuration with an eClinicalWorks account manager.
How the eClinicalWorks Backend Database Is Structured for Clinical Reporting
Clinical data managers and health services researchers working with eClinicalWorks encounter two distinct data access patterns:
- Relational backend database and Enterprise Business Optimizer (eBO): Internally, eClinicalWorks stores patient demographics, encounters (
enc), ICD-10 assessments, CPT/HCPCS billing lines, lab results,vital signs, and structured smart-form observations in a relational SQL database (commonly MySQL or Microsoft SQL Server depending on the deployment tier). Rather than running raw ad-hoc SQL queries against production transactional tables, health systems use Enterprise Business Optimizer (eBO)—an analytical reporting layer that exposes curated metadata packages for clinical quality measures, registry extraction, and financial reconciliation—or generate full Electronic Health Information (EHI) export files under 45 CFR § 170.315(b)(10). - FHIR Bulk Data Access (
$export) for multi-patient cohorts: For external research registries and population health pipelines, eClinicalWorks Connect supports the HL7 FHIR Bulk Data Access specification, exporting newline-delimited JSON (.ndjson) files mapped to US Core FHIR R4 resources without requiring direct SQL credentials.
Strengths and Limits for Clinical Informatics and Research
- Strength — Clear separation of patient vs. provider API governance: Routing patient-access and RPM apps through
connect4.healow.comwhile keeping provider SMART on FHIR and Bulk Data apps onfhir.eclinicalworks.comisolates patient portal traffic from clinical workstation integrations. - Strength — Broad CRUD and Bulk capabilities: Both portals document Read, Create, Update, and Delete operations alongside Bulk operations on the provider portal, supporting bidirectional clinical workflows.
- Limit — Practice-by-practice activation codes: Because eClinicalWorks serves thousands of independent medical groups, provider-facing apps require each participating practice to activate the developer’s activation code (or open a case for scheduling integrations) rather than flipping a single network-wide switch.
Alternatives to eClinicalWorks in Ambulatory and Health System Settings
| Platform | Primary Deployment Setting | Developer Portal Architecture | Reporting & Bulk Extraction Layer |
|---|---|---|---|
| eClinicalWorks (eCW & healow) | Ambulatory practices, FQHCs, urgent care, and multi-specialty groups | Dual portals: fhir.eclinicalworks.com (provider/Bulk) + connect4.healow.com (patient/RPM/scheduling) |
FHIR R4 Bulk Data ($export), EHI export, and Enterprise Business Optimizer (eBO) |
| athenahealth (athenaOne) | Ambulatory medical groups and outpatient networks | Unified developer portal (docs.athenahealth.com) + Marketplace |
Global FHIR R4 gateway (US Core 3.1.1 & 6.1.0, Bulk Data) + proprietary REST APIs |
| Epic | Academic medical centers and integrated inpatient/ambulatory health systems | open.epic.com + Showroom / App Orchard |
FHIR R4 Bulk Data, Clarity/Caboodle analytical data warehouses, and Epic Cosmos |
FAQ
How do third-party systems integrate with eClinicalWorks (eCW)?
Third-party systems integrate through one of two official FHIR R4 portals: provider-facing SMART on FHIR apps and backend Bulk Data services register on fhir.eclinicalworks.com/ecwopendev and activate at client practices via an activation code, while patient-facing apps, RPM devices, and online scheduling tools integrate through the healow Developer Portal at connect4.healow.com.
How do eClinicalWorks FHIR R4 and healow APIs work?
Both portals implement HL7 FHIR R4 and USCDI v3 profiles secured by OAuth 2.0 and SMART on FHIR launches, supporting Read, Create, Update, and Delete operations (plus Bulk operations on the eClinicalWorks provider portal). Patient APIs connect directly after sandbox testing, whereas Scheduling APIs and contract-required provider scopes require a scope/case review and Pricing Agreement.
How is the eClinicalWorks backend database structured for clinical reporting?
eClinicalWorks stores clinical encounters, diagnoses, labs, vitals, and billing records in a relational SQL backend queried internally through Enterprise Business Optimizer (eBO) reporting packages and 45 CFR § 170.315(b)(10) EHI exports, while external population and research pipelines extract standardized cohorts via FHIR R4 Bulk Data ($export) NDJSON files.
Sources
- eClinicalWorks, eClinicalWorks Connect FHIR Developer Portal (v4.0.7.6) (as of 2026-11-09): fhir.eclinicalworks.com/ecwopendev
- healow / eClinicalWorks, healow FHIR R4 Developer Portal (v8.19.9) (as of 2026-11-09): connect4.healow.com/apps/jsp/dev/r4/fhirClinicalDoc.jsp
- eClinicalWorks, Cloud EHR, Practice Management, and Interoperability Overview (as of 2026-11-09): eclinicalworks.com
- Electronic Code of Federal Regulations (via Cornell LII), 45 CFR § 170.315(g)(10) — Standardized API for patient and population services (as of 2026-11-09): law.cornell.edu/cfr/text/45/170.315
