Your email address will not be published. Required fields are marked *
Our expert reaches out shortly after receiving your request and analyzing your requirements.
If needed, we sign an NDA to protect your privacy.
We request additional information to better understand and analyze your project.
We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.
If you're satisfied, we finalize the agreement and start your project.
Athenahealth occupies a unique position in the US EHR market. While Epic and Oracle Health dominate hospitals and large health systems, athenahealth is the platform of choice for ambulatory practices — the physician groups, specialty practices, urgent care centers, community health centers, and multi-location outpatient organizations that deliver the majority of US healthcare outside of hospital walls.
Market position: Over 160,000 providers across the United States use athenahealth. The platform processes claims for over $39 billion in annual medical charges. For any health tech company, patient engagement platform, telehealth service, or clinical tool targeting the ambulatory market, athenahealth integration is essential for market access.
Cloud-native advantage. Athenahealth was built cloud-native from the beginning — not migrated to cloud from on-premises like Epic and Oracle Health. Every athenahealth customer runs on the same single-instance platform. There is no per-site deployment, no customer-specific infrastructure, and no site-specific API variation. When you build an integration against the athenahealth API, it works for every athenahealth customer without per-site configuration.
Revenue cycle integration. Athenahealth is not just an EHR — it is a combined EHR and revenue cycle management (RCM) platform. This means the API exposes clinical data (patients, encounters, clinical documents, orders, results) and financial data (claims, payments, denials, eligibility, statements) through the same interface. For companies building billing, analytics, or financial workflow tools, this unified access is a significant advantage.
Network effects. Athenahealth’s cloud network aggregates de-identified data across its entire customer base to provide benchmarking, best practice insights, and claims intelligence. Integrations that leverage this network data (payer rules, denial patterns, scheduling optimization) can deliver value that is impossible with single-site EHR deployments.
Athenahealth’s platform is organized into three core modules, each with corresponding API domains:
athenaClinicals — the clinical EHR module. Handles patient charting, clinical documentation, orders, results, prescriptions, immunizations, allergies, problem lists, and clinical workflows. This is where clinical data lives.
athenaCollector — the practice management and revenue cycle module. Handles patient registration, scheduling, insurance verification, claims submission, payment posting, denial management, reporting, and financial workflows. This is where administrative and financial data lives.
athenaCommunicator — the patient engagement module. Handles patient portal (athenaPatient), appointment reminders, patient messaging, satisfaction surveys, reputation management, and patient outreach campaigns.
athenaNet — the underlying cloud platform that hosts all three modules. All customers share the same athenaNet instance. API calls go to centralized endpoints regardless of which customer’s data you are accessing.
athenaPatient — the patient-facing portal. Patients access their health records, schedule appointments, message providers, pay bills, and complete intake forms through athenaPatient. If you are building a custom patient portal that replaces or supplements athenaPatient, the API provides full access to the underlying data.
athenaOne — the unified product brand combining athenaClinicals, athenaCollector, and athenaCommunicator. In current marketing, athenahealth refers to the combined platform as athenaOne.
| Method | Best For | Availability | Complexity |
|---|---|---|---|
| Athenahealth REST APIs | Primary integration method for all use cases | All customers | Moderate |
| FHIR R4 API | Standards-based data access, patient-facing apps, regulatory compliance | All customers | Moderate |
| HL7 v2 Interfaces | Legacy system connectivity, lab interfaces, imaging | Configured per customer | Higher |
| Flat File Exchange (SFTP) | Batch data exchange, claims files, large data exports | Configured per customer | Lower |
| Marketplace Embedded Apps | In-workflow clinical applications | Marketplace approved apps | Higher |
Key difference from Epic and Oracle Health: The athenahealth REST API is the primary and recommended integration method for almost all use cases. Unlike hospital EHRs where HL7 v2 remains critical for real-time clinical events, athenahealth’s REST API with webhooks/subscriptions covers most real-time notification needs. HL7 v2 is used primarily for lab instrument interfaces and legacy system connections, not as a primary integration pathway.
Athenahealth’s proprietary REST APIs are the most mature and feature-rich integration pathway. They predate athenahealth’s FHIR implementation and provide deeper access to athenahealth-specific functionality than the FHIR API.
Base URL: https://api.athenahealth.com/v1/{practice-id}/
The {practice-id} parameter identifies which athenahealth customer’s data you are accessing. A single API integration can access data for multiple practices by changing the practice ID — no separate infrastructure or configuration per practice.
Patient Management:
GET /patients — search patientsGET /patients/{id} — get patient detailsPOST /patients — create new patientPUT /patients/{id} — update patientGET /patients/{id}/insurances — get patient insurance packagesGET /patients/{id}/documents — get patient documentsScheduling:
GET /appointments/open — find available appointment slotsPOST /appointments/{id}/book — book an appointmentGET /appointments/booked — get booked appointmentsPUT /appointments/{id}/cancel — cancel an appointmentPUT /appointments/{id}/reschedule — rescheduleGET /appointments/{id}/checkin — check in a patientClinical Data:
GET /chart/{id}/problems — active problem listGET /chart/{id}/medications — medication listGET /chart/{id}/allergies — allergiesGET /chart/{id}/vitals — vital signsGET /chart/{id}/labresults — lab resultsGET /chart/{id}/orders — ordersGET /chart/{id}/immunizations — immunizationsGET /chart/{id}/encounters — encounter historyGET /chart/{id}/documents — clinical documentsRevenue Cycle:
GET /claims — search claimsGET /claims/{id} — claim detailsGET /claimcharges — charge detailsPOST /claims/{id}/payments — post paymentGET /patients/{id}/collectionsbalance — patient balanceGET /eligibility — insurance eligibility checkProvider and Practice:
GET /providers — list providersGET /departments — list departments/locationsGET /customfields — practice-specific custom fieldsAll responses are JSON. Athenahealth APIs use a consistent response structure:
totalcount, next, and previous linkserror and detailedmessage fieldsMM/DD/YYYY (note: this is athenahealth-specific, not ISO 8601)HH:MM in practice-local timezoneList endpoints are paginated. Default page size is typically 10–25 records. Use limit and offset parameters to control pagination:
GET /patients?limit=100&offset=200
For large data exports, iterate through all pages using the next link until no more pages are returned. Implement rate-limit-aware pagination that backs off when approaching API throttle limits.
Athenahealth provides a FHIR R4 API alongside its proprietary REST APIs. The FHIR API is standards-based and increasingly important for regulatory compliance.
Clinical:
Administrative:
Financial:
Base URL: https://fhir.athenahealth.com/r4/
Authentication: OAuth 2.0 with SMART on FHIR scopes (same authorization server as proprietary API).
| Use Case | Recommended API | Why |
|---|---|---|
| Standards-based patient data access | FHIR R4 | Regulatory compliance, cross-EHR portability |
| Patient-facing third-party apps | FHIR R4 + SMART | Cures Act compliance, standard authorization |
| Revenue cycle and billing | Proprietary REST | FHIR financial resources are limited on athenahealth |
| Scheduling operations | Proprietary REST | More granular scheduling control |
| Custom field access | Proprietary REST | Custom fields not available in FHIR |
| Practice management workflows | Proprietary REST | Deeper athenahealth-specific functionality |
| Cross-EHR integration (supporting Epic + Oracle Health + athena) | FHIR R4 | Single codebase across EHR vendors |
| Bulk data export | FHIR Bulk Data | Standard-based large-scale export |
Practical guidance: If your application needs to integrate with athenahealth only, the proprietary REST API provides the richest functionality. If your application needs to support multiple EHR platforms (athenahealth + Epic + Oracle Health), build on FHIR R4 for the common data access layer and supplement with proprietary API calls for athenahealth-specific features.
While the REST API is the primary integration method, athenahealth supports HL7 v2 and flat file interfaces for specific use cases.
Lab interfaces (most common). Reference labs and in-house lab instruments send results to athenahealth via HL7 v2 ORU messages. Athenahealth sends lab orders via ORM messages. These interfaces are configured per practice and routed through athenahealth’s interface engine.
Imaging interfaces. Radiology and diagnostic imaging orders (ORM) and results (ORU) between athenahealth and PACS/RIS systems.
ADT feeds. For practices that need to notify external systems of patient registration, check-in, and checkout events. Less common than in hospital settings but used by practices with complex multi-system environments.
Pharmacy interfaces. While athenahealth handles e-prescribing through Surescripts natively, some specialty pharmacy workflows require custom HL7 v2 interfaces.
Unlike Epic and Oracle Health where you connect directly to the EHR’s interface engine, athenahealth’s HL7 v2 interfaces are managed centrally by athenahealth’s integration team. You do not configure COI or Bridges yourself — you work with athenahealth’s interface services team to set up and test interfaces.
This means less control over interface configuration but also less per-site infrastructure work. The interface is configured once against athenahealth’s platform and works for the target practice.
If your integration requires HL7 v2 interfaces with athenahealth, using Mirth Connect on your side for message parsing, transformation, and routing remains the standard approach.
Athenahealth supports SFTP-based flat file exchange for:
Flat file interfaces are configured through athenahealth’s implementation team and follow athenahealth-specified file formats.
The athenahealth Marketplace is the primary distribution channel for third-party applications integrating with athenahealth. Unlike Epic’s App Orchard which is primarily an integration approval mechanism, the athenahealth Marketplace is an active commercial distribution platform.
Discovery. Your application is listed in a searchable marketplace visible to all athenahealth customers. Practices browse the Marketplace to find solutions for clinical, financial, and operational needs.
Activation. Practices can activate your application directly from the Marketplace with minimal friction. No lengthy per-site IT projects — a practice administrator can enable your integration in minutes.
Embedded workflows. Marketplace apps can embed directly within the athenaOne clinical workflow. Your application can appear as a tab, sidebar, or iframe within the clinician’s athenaOne interface — no context switching required.
Billing integration. The Marketplace supports billing your application’s subscription fee through athenahealth’s existing billing relationship with the practice. This eliminates the need for separate billing agreements with each customer.
Marketplace Standard. Your application integrates via API and is listed in the Marketplace for discovery. Practices activate and configure the integration. Most common type.
Marketplace Embedded. Your application runs within the athenaOne interface. Clinicians interact with your app without leaving their EHR workflow. Requires additional UX review and approval from athenahealth.
Marketplace Data Exchange. Your application receives data feeds from athenahealth (via webhooks or batch export) for analytics, population health, quality reporting, or other data processing use cases.
Timeline: The full Marketplace approval process typically takes 6–12 weeks — significantly faster than Epic App Orchard (2–4 months) or Oracle Health review processes.
Athenahealth charges a revenue share on Marketplace transactions. The specific percentage varies by agreement but typically ranges from 15–30% of revenue generated through the Marketplace channel. Factor this into your pricing model.
For companies building healthcare technology products, the athenahealth Marketplace provides instant access to 160,000+ providers without a direct sales force. The revenue share is offset by the distribution reach and the elimination of per-practice sales cycles.
All athenahealth API access requires OAuth 2.0 authentication.
Authorization Code Grant (user-facing apps):
Client Credentials Grant (system-to-system):
Every API call requires:
A practice must explicitly authorize your application before you can access their data. For Marketplace apps, this authorization happens when the practice activates your app. For non-Marketplace integrations, authorization is configured through athenahealth’s implementation team.
For FHIR API access, athenahealth supports SMART on FHIR scopes:
patient/*.read — patient-context read accessuser/*.read — user-context read accesslaunch — EHR launch supportpatient/Observation.read)Athenahealth enforces rate limits on API calls:
X-RateLimit-Remaining and X-RateLimit-Reset headers. Monitor these and throttle proactively.When rate limits are exceeded, the API returns HTTP 429 (Too Many Requests). Implement exponential backoff with jitter for retry logic.
Athenahealth provides flexible patient search capabilities:
GET /patients?firstname=John&lastname=Smith&dob=01/15/1980
Additional search parameters: SSN (last 4), phone number, email, insurance member ID, department ID. Combine parameters for precise matching.
Best practice: Search by multiple criteria (name + DOB + department) rather than single fields. Athenahealth returns fuzzy matches ranked by confidence score. Always verify matches against multiple demographic fields before assuming a positive patient match.
Complete scheduling workflow through the API:
GET /appointments/open?departmentid={id}&providerid={id}&reasonid={id}&appointmentdate={date}POST /appointments/{id}/book with patient ID and booking detailsPUT /appointments/{id}/checkinPUT /appointments/{id}/checkoutAthenahealth-specific detail: Scheduling in athenahealth is department-specific. A provider may work at multiple departments (locations), and available slots are defined per provider-per-department combination. Always include departmentid in scheduling API calls.
Access chart data through structured API endpoints:
Problem list: GET /chart/{patientid}/problems — returns active, inactive, and resolved problems with ICD-10 and SNOMED codes.
Medications: GET /chart/{patientid}/medications — returns active medications with drug name, dose, route, frequency, prescribing provider, and pharmacy.
Allergies: GET /chart/{patientid}/allergies — returns allergies with reaction type, severity, and substance.
Lab results: GET /chart/{patientid}/labresults/{orderid} — returns individual lab result details including reference ranges, abnormal flags, and result values.
Vitals: GET /chart/{patientid}/vitals — returns vital signs with date, values, and units.
Encounter summary: GET /chart/encounter/{encounterid}/summary — returns complete encounter documentation including HPI, exam findings, assessment, plan, and orders.
Athenahealth’s API provides unusually deep access to revenue cycle data — a differentiator from Epic and Oracle Health where financial APIs are more limited:
Eligibility verification: GET /insurances/{insuranceid}/eligibility?patientid={id} — real-time insurance eligibility check returning coverage status, copay, deductible, and benefit details.
Claims: GET /claims?patientid={id} — returns claims with status, charges, payments, adjustments, and denial information.
Payment posting: POST /claims/{id}/payments — post payments against specific claims.
Collection balances: GET /patients/{id}/collectionsbalance — patient’s outstanding balance across all encounters.
Denial management: Claims API includes denial reason codes and remark codes, enabling denial analytics and automated denial workflow applications.
Athenahealth offers a subscription model for receiving real-time notifications when data changes — this is the alternative to polling the API continuously.
Subscribe to specific data change events:
GET /changed/{datatype}?departmentid={id} returns all changes since your last checkImportant distinction: Athenahealth subscriptions are pull-based (you poll for changes) rather than push-based (athenahealth calls your webhook endpoint). This is different from true webhook implementations where the server pushes events to your URL. Plan your polling frequency based on how real-time your data needs to be — every 1–5 minutes for clinical data, every 15–30 minutes for financial data is typical.
| Approach | Latency | API Calls | Complexity | Best For |
|---|---|---|---|---|
| Direct API polling | Variable (depends on poll frequency) | High (many wasted calls when nothing changed) | Low | Simple integrations, low-volume data |
| Changed data subscriptions | 1–5 minutes (depending on poll interval) | Low (only retrieve actual changes) | Moderate | Production integrations, high-volume data |
| FHIR Subscriptions | Near real-time | Low | Moderate-High | Standards-based real-time needs |
Date format: MM/DD/YYYY — athenahealth uses US date format, not ISO 8601. Your integration must handle this conversion when interfacing with systems that use ISO format.
Time format: HH:MM in the practice’s local timezone. Timezone is not included in the API response — determine the practice’s timezone from their department configuration and convert accordingly.
Identifiers:
patientid — athenahealth’s internal patient identifier (unique within a practice)enterpriseid — patient identifier across multi-practice enterprisespatientid serves as the primary identifierDepartment-centric model: Unlike hospital EHRs where the facility is the primary organizational unit, athenahealth organizes everything by department. A single practice can have multiple departments (locations). Most API calls require or benefit from departmentid as a parameter. Scheduling, provider availability, and many clinical workflows are department-specific.
Athenahealth uses standard terminologies with some platform-specific conventions:
| Data Type | Primary Terminology | Notes |
|---|---|---|
| Diagnoses | ICD-10-CM | Standard ICD-10 codes used throughout |
| Procedures | CPT | Standard CPT codes for billing and orders |
| Medications | RxNorm + NDC | Medication database mapped to standard drug databases |
| Lab tests | LOINC (partial) | Some tests use athenahealth-internal identifiers alongside LOINC |
| Allergies | Athenahealth internal + RxNorm | Allergy substance identification uses a combination |
| Problems | ICD-10 + SNOMED CT | Problem list entries typically include both |
Terminology mapping challenge: Athenahealth’s clinical terminology coverage is generally cleaner than hospital EHRs because the single-instance architecture enforces more consistency. However, lab result coding can be inconsistent — particularly for lab tests ordered through third-party reference labs where the lab’s coding may differ from athenahealth’s internal coding. Build validation logic that flags lab results with missing or unexpected codes.
Athenahealth allows practices to define custom fields for capturing data not covered by the standard data model. Custom fields are practice-specific — one practice’s custom fields will differ from another’s.
Access custom fields through: GET /customfields (to discover which custom fields exist) and GET /patients/{id}/customfields (to read values).
If your integration depends on custom field data, you need a configuration mechanism to map each practice’s custom fields to your application’s data model. This is the one area of athenahealth integration that requires per-practice configuration.
Athenahealth provides a preview (sandbox) environment for development and testing:
Advantage over Epic and Oracle Health: Athenahealth’s sandbox is immediately available upon developer registration with no approval gating. Epic and Oracle Health sandbox access may require application review before granting access. This accelerates the initial development phase significantly.
Date format testing. Verify your application correctly handles athenahealth’s MM/DD/YYYY date format throughout all API interactions. This is one of the most common bugs in athenahealth integrations.
Department-specific testing. Test with multiple department IDs to verify your application correctly handles the department-centric data model.
Pagination testing. Test with data sets large enough to trigger pagination. Verify your application follows pagination links correctly and handles edge cases (empty pages, last page).
Rate limit testing. Simulate production API call volumes to verify your rate limit handling and backoff logic work correctly before going live.
Changed data subscription testing. If using subscriptions, test the full lifecycle: subscribe, generate changes in the preview environment, poll for changes, process changes, and verify data accuracy.
Use case: Your application needs a synchronized copy of clinical data from athenahealth for analytics, population health, care coordination, or workflow automation.
Approach:
Considerations: Initial bulk sync for a large practice (50,000+ patients) can take hours and consume significant API quota. Schedule bulk syncs during off-peak hours. Use parallel API calls within rate limits to maximize throughput.
Use case: Your application (patient portal, telehealth platform, website) allows patients to book appointments directly into athenahealth’s schedule.
Approach:
Considerations: Available slots change in real-time as other channels (phone, in-office) book appointments. Cache slot availability for no more than 5–10 minutes. Implement graceful handling when a selected slot is no longer available at booking time.
Use case: Your application provides financial analytics, denial management, or revenue optimization for athenahealth practices.
Approach:
Considerations: Revenue cycle data is high-volume. A busy practice generates hundreds of claims per day. Design your data sync for throughput and build efficient storage for financial analytics.
Use case: Your application provides clinical decision support, prior authorization, or specialty-specific tools that need to appear within the clinician’s EHR workflow.
Approach:
Considerations: Embedded apps must meet athenahealth’s UX guidelines. Performance is critical — the app loads within the clinical workflow, and slow load times disrupt clinician productivity. Target sub-2-second load time for the initial view.
This comparison helps developers planning multi-EHR integration strategies:
| Factor | Athenahealth | Epic | Oracle Health |
|---|---|---|---|
| Primary market | Ambulatory practices | Hospitals, large health systems | Hospitals, health systems |
| Architecture | Cloud-native, single-instance SaaS | Per-site deployed | Centralized hosting (transitioning to OCI) |
| Primary API | Proprietary REST + FHIR R4 | FHIR R4 + HL7 v2 | FHIR R4 (Ignite) + HL7 v2 |
| HL7 v2 importance | Secondary (lab/imaging only) | Critical for real-time events | Critical for real-time events |
| Per-site configuration | Minimal (custom fields only) | Extensive (every site is different) | Moderate (code values, facility config) |
| Sandbox access | Immediate, self-service | Requires App Orchard approval | Self-service through Cerner Code |
| Marketplace | Active commercial distribution | App Orchard/Showroom (discovery + approval) | No formal marketplace |
| Approval timeline | 6–12 weeks | 2–4 months | 4–8 weeks |
| Typical integration time | 2–4 months | 4–8 months | 3–6 months |
| Typical integration cost | $30,000–$120,000 | $50,000–$300,000+ | $40,000–$250,000+ |
| Revenue cycle API depth | Deep (full RCM access) | Limited | Moderate |
| Real-time notifications | Pull-based subscriptions | HL7 v2 events | HL7 v2 events |
| Date format | MM/DD/YYYY | ISO 8601 | ISO 8601 / varies |
Key insight for multi-EHR developers: If you are building a product that needs to support all three platforms, design your architecture with an abstraction layer between your application logic and EHR-specific API calls. Use FHIR R4 as the common data access layer for clinical data that all three support. Build EHR-specific adapters for proprietary features (athenahealth’s revenue cycle API, Epic’s MyChart integration, Oracle Health’s MPages). This approach lets you maintain a single application codebase while supporting all three EHR platforms.
| Integration Type | Cost Range | Timeline | Key Cost Drivers |
|---|---|---|---|
| REST API read-only (patient data, clinical records) | $25,000 – $60,000 | 1.5–3 months | Number of data domains, subscription setup |
| REST API read/write (scheduling, clinical documentation) | $50,000 – $120,000 | 3–5 months | Write operation complexity, workflow design |
| FHIR R4 integration | $30,000 – $70,000 | 2–4 months | Number of FHIR resources, SMART implementation |
| Marketplace Standard app | $40,000 – $100,000 | 3–5 months (including approval) | App complexity, review timeline |
| Marketplace Embedded app | $60,000 – $150,000 | 4–7 months (including approval) | Embedded UX, clinical workflow design |
| Revenue cycle integration (claims, billing, analytics) | $40,000 – $100,000 | 2–4 months | Data volume, analytics complexity |
| Full-featured integration (clinical + scheduling + billing) | $80,000 – $200,000 | 4–8 months | Combined scope |
| HL7 v2 lab interface | $15,000 – $40,000 | 1–2 months | Message types, device connectivity |
Additional costs:
Why athenahealth integration costs less than hospital EHR integration:
Athenahealth integration opens access to the largest ambulatory EHR market in the United States. The cloud-native architecture, well-documented APIs, and Marketplace distribution program make athenahealth one of the most developer-friendly EHR platforms to integrate with.
If you are planning an athenahealth integration — whether building a Marketplace application, connecting clinical workflows, or syncing revenue cycle data — connect with our integration team to discuss your specific requirements and timeline.
Related Resources:
This guide was developed by the healthcare interoperability team at Taction Software, drawing on direct experience building athenahealth Marketplace applications and API integrations for US ambulatory practices, multi-location physician groups, and health tech companies targeting the ambulatory EHR market.
Athenahealth is significantly easier and faster to integrate with than Epic or Oracle Health (Cerner). The cloud-native, single-instance architecture eliminates per-site configuration and infrastructure variation. REST API documentation is straightforward, sandbox access is immediate, and the Marketplace approval process is faster. Taction Software’s benchmarks show 40–50% less integration time compared to equivalent hospital EHR integrations.
No, but it is strongly recommended for commercial products. Non-Marketplace integrations require direct arrangement with individual athenahealth practices and athenahealth’s integration team. The Marketplace provides distribution, easier practice activation, and embedded billing — advantages that are difficult to replicate through direct arrangements.
Yes. A single API integration can access data from any practice that has authorized your application. You simply change the practice-id parameter in your API calls. No separate infrastructure or configuration per practice. This is a major advantage over hospital EHR integrations that require per-site deployment.
API queries return current data — there is no synchronization delay between what clinicians see in athenaOne and what the API returns. For change notifications, the changed data subscription model introduces 1–5 minutes of latency depending on your polling frequency. For true real-time needs, frequent polling (every 60 seconds) is possible within rate limits.
Athenahealth supports FHIR Bulk Data Export for large-scale data extraction, conforming to Cures Act requirements. This is the recommended approach for initial data loads and periodic full syncs rather than paginating through individual FHIR resource queries.
Athenahealth maintains API versioning and provides deprecation notices before removing endpoints. Major API changes are communicated through the developer portal and typically include a migration period. The centralized architecture means API changes apply to all customers simultaneously — there is no risk of different customers running different API versions.
AthenaPatient offers limited customization. Organizations wanting differentiated patient experiences or advanced features beyond athenaPatient’s standard capabilities typically build custom patient portals that access data through athenahealth’s API. See our patient portal development guide for custom portal planning.
More feasible than hospital EHR integrations because the cloud-native architecture eliminates site-specific configuration complexity. However, understanding US healthcare workflows, HIPAA compliance requirements, and ambulatory practice operations is still essential. A hybrid model with US-based healthcare domain expertise and offshore development works well for athenahealth projects.
