Challenge
Designing from assumptions, not the server
Agnotic approach
We start from the server's CapabilityStatement and SMART configuration and design only around what they declare.
eClinicalWorks FHIR capabilities
eClinicalWorks FHIR Capabilities
Ambulatory practices on eClinicalWorks want your product connected, and what the FHIR API allows has to be confirmed for the server you will use. Agnotic Technologies starts from the HL7 and ONC baseline, checks every resource and scope in the eClinicalWorks sandbox, and builds the integration for you.
HL7 FHIR R4US CoreSMART App LaunchSandbox checklist
Trusted by global innovators
What are eClinicalWorks FHIR capabilities?
eClinicalWorks FHIR capabilities are the HL7 FHIR resources, SMART authorization and export functions an eClinicalWorks server exposes to outside apps. Agnotic Technologies treats the HL7 and ONC standards as the baseline, confirms each capability your product needs in the eClinicalWorks sandbox, and then builds and tests the integration for you.
We do not list eClinicalWorks resource counts or version numbers here. The record of what is available is eClinicalWorks's own developer documentation and the CapabilityStatement of the server you connect to.
This page is the developer checklist. Our eClinicalWorks integration services page covers the wider integration and the engagement.
Sandbox checklist
What should you check in the eClinicalWorks sandbox?
We run this list before writing integration code. Each item turns an assumption into a tested fact.
- Fetch the server's /metadata CapabilityStatement and record its fhirVersion and the US Core version it claims
- List the resources your product needs and confirm the read, search or write interaction for each
- Read .well-known/smart-configuration for grant types, PKCE methods and launch modes
- Test the launch you need: EHR launch for practice staff, standalone for patients, or backend services for system access
- Request the narrowest scopes and inspect what the issued token actually grants
- Run the search parameters you rely on, such as patient, date and category, and note any the server rejects
- If you need population data, test Group $export with status polling and file download
- Check paging, error responses and data absent reasons, using synthetic patients only
Decision table
What does the standard guarantee, and what must you confirm?
The left column is fixed by HL7 or ONC. The right column is what we verify on the eClinicalWorks server before a release depends on it.
| Area | What HL7 or ONC defines | What you confirm on the eClinicalWorks server |
|---|---|---|
| FHIR version | FHIR R4 is a published HL7 release with defined resources and RESTful interactions | fhirVersion in the server's CapabilityStatement |
| Data profiles | US Core profiles FHIR resources for the USCDI data classes | Which US Core version is claimed, and the profile for each resource |
| App launch and auth | SMART App Launch uses OAuth 2.0 and OpenID Connect with scoped access | Launch modes, client types and scope syntax in the SMART configuration |
| System access | SMART Backend Services uses the client credentials grant with a signed JWT | Whether backend access is offered for your use case and how keys are registered |
| Writes | FHIR defines create and update interactions for resources | Which resources accept create or update, if any |
| Population export | The Bulk Data Access guide defines export for a group of patients | Whether Group $export is declared and how groups are set up |
| Certified API | ONC criterion 170.315(g)(10) requires a standardized FHIR API in certified EHRs | The certified version the practice runs and what its API supports |
Failure points
Where do eClinicalWorks FHIR projects stall?
These are the points we design for on any ambulatory FHIR integration, eClinicalWorks included.
Challenge
Promising write-back too early
Agnotic approach
We confirm create and update per resource in the sandbox before a release plan depends on writing data back.
Challenge
Scopes broader than the use case
Agnotic approach
Narrow scopes make practice approval simpler and limit what a leaked token could reach.
Challenge
One practice tested, many practices deployed
Agnotic approach
Rollout includes per-practice checks of endpoints, enabled scopes and launch context.
Challenge
Searches that quietly return nothing
Agnotic approach
Contract tests run every search parameter the product relies on, so a rejected parameter fails loudly in testing.
Challenge
Real patient data in test environments
Agnotic approach
Sandbox work uses synthetic patients only, and production credentials never reach development.
Who needs it
Who needs eClinicalWorks FHIR access?
Most demand comes from products that serve ambulatory practices.
Practice-focused startups
Products that need chart data from eClinicalWorks practices in their first pilots.
Specialty workflow apps
SMART apps launched by clinicians and staff inside the practice workflow.
Patient apps
Apps that read a patient's own record through standalone launch.
Care management programs
Scheduled backend reads of problems, medications and results.
Analytics and quality platforms
Population data through Group export, where the server declares it.
Remote monitoring programs
Device readings matched to the right patient and shared back where writes are supported.
Scope drivers
What drives the cost of an eClinicalWorks FHIR integration?
We do not quote a price before scoping. These factors move the effort most.
What the server declares
If everything you need is declared and tested in the sandbox, scope is mostly mapping. Gaps add design work for another path.
Read only or write back
Reads are the smaller build. Write-back adds validation, conflict handling and more testing.
Launch types
Staff, patient and backend access each need their own registration, testing and review.
Number of practices
Every practice adds enablement, configuration checks and support.
Population data
Group exports add long-running jobs, file handling and reconciliation.
Startup or established product
Startups often need the data model built with the integration. Established products mostly need mapping.
How we work
How do we take an eClinicalWorks FHIR integration live?
Four steps, with a fixed first release agreed before build starts.
1.
Run the sandbox checklist
We work through the checklist above and write down what the server declares for your use case.
Tested facts
2.
Agree the first release
Scope is set from tested capabilities only, with any gaps given their own plan.
Fixed scope
3.
Build and pilot
We build mapping, auth, audit logging and error handling, then pilot with one practice.
Pilot practice
4.
Roll out and monitor
Practices are added one by one, with monitoring of auth errors, failed calls and data quality.
Monitored
Compliance as engineering
How do we keep PHI safe on an eClinicalWorks integration?
HIPAA applies to your product as well as the practice. These are the safeguards we build in.
Business associate agreements
Agnotic signs a BAA before any PHI is shared. Development uses the sandbox and synthetic patients.
Least-privilege scopes
Each app requests only the scopes its use case needs, per practice.
Encryption and keys
TLS on every call, encryption at rest for synced data, and keys in a secrets manager with rotation.
Audit logging
Every FHIR call is logged with user, patient, practice and time.
Standards in scope
Standards an eClinicalWorks FHIR integration relies on
FHIR R4US CoreSMARTBulk Data(g)(10)HIPAA
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Facts and sources
Which standards facts shape eClinicalWorks FHIR work?
Short facts we design around, each linked to its primary source.
HL7 FHIR is a standard published by HL7 International for exchanging health data through RESTful APIs built on defined resources such as Patient, Observation and MedicationRequest.
Source: HL7 International (hl7.org/fhir)US Core is the HL7 FHIR implementation guide that profiles FHIR resources for the USCDI data classes used in the United States.
Source: HL7 International (US Core)The SMART App Launch implementation guide uses OAuth 2.0 and OpenID Connect so that apps can launch from an EHR with the user's and patient's context and only the access scopes they were granted.
Source: HL7 International (SMART App Launch)ONC certification criterion 170.315(g)(10) requires certified EHRs to offer a standardized API for patient and population services based on HL7 FHIR.
Source: 45 CFR 170.315 (eCFR)The HL7 FHIR Bulk Data Access implementation guide defines a standardized, FHIR-based way to export data on a group of patients from a FHIR server to a pre-authorized client.
Source: HL7 International, FHIR Bulk Data Access (Flat FHIR)
Frequently Asked Questions
Certified EHRs must offer a standardized FHIR API under ONC criterion 170.315(g)(10). For eClinicalWorks, the version, resources and scopes available are what the server's CapabilityStatement declares, so we read it before scoping.
The CapabilityStatement and SMART configuration, then the exact reads, searches and launch your product needs, with synthetic patients. Our checklist above lists each step.
Only where the server declares create or update for that resource and it works in testing. We confirm it per resource before a release plan depends on it, and plan another path if it is missing.
It depends on scope; we agree a fixed first release on the scoping call, after the sandbox checklist has shown what the server supports.
Yes. Agnotic signs a business associate agreement before any PHI is shared, and sandbox work uses synthetic patients only.
Engineers use AI tools for drafts and test generation, then review every change. AI tools never see real patient data, and every mapping is tested against sandbox data before it reaches a customer.