athenahealth FHIR Integration: Certified APIs, athenaOne APIs and Marketplace

Developers register on athenahealth’s developer portal and create applications. A preview environment with synthetic, non-production data is available for building and testing; preview and production credentials are separate, so keys issued for one environment do not work in the other.

• Certified FHIR APIs. FHIR R4 APIs certified under ONC’s program for standardized API access, returning US Core-aligned clinical data.
• athenaOne APIs. Proprietary REST APIs covering practice operations such as scheduling, documents and patient registration. These are typically governed by separate commercial terms.
• Marketplace. athenahealth operates a marketplace where practices can discover partner applications. Listing is a separate process from API access.
• Practice authorization. Regardless of lane, each practice must authorize your application before you can access its real data.

The certified APIs are FHIR R4. Under ONC’s standardized API certification criterion (§170.315(g)(10)), certified health IT must support US Core-based access for single patients via the SMART App Launch framework and population-level access via the FHIR Bulk Data Access specification. Use athenahealth’s documentation to confirm the exact US Core version, scopes and launch types it currently supports.

Authorization uses OAuth 2.0: authorization-code flows for SMART user and patient apps, and client credentials for system-to-system access. See our FHIR security guide for scope and token-handling practice.

athenahealth customers are largely independent practices and medical groups rather than a few large health systems, so the commercial success of an integration often depends on onboarding many practices efficiently.

• Make practice onboarding as self-service as possible, with clear instructions for authorizing your app and confirming the data it will access.
• Treat practice identifiers and settings as configuration, not code.
• Expect variation in how practices document the same data, such as problem lists and medication history.
• Monitor error rates per practice so one misconfigured practice does not hide among many healthy ones.

For the broader architecture of multi-source data, see FHIR and healthcare interoperability.

GET [base]/fhir/r4/Condition?patient=<patient-id>&category=problem-list-item
Accept: application/fhir+json
Authorization: Bearer <access_token>

If your product combines FHIR reads with athenaOne writes, design your data layer so both map to the same internal model. Our FHIR API integration guide discusses this hybrid pattern.

• The certified FHIR APIs focus on reading clinical data; most operational writes rely on athenaOne APIs.
• Each practice authorizes access separately, so scale depends on practice-level adoption.
• Preview data is synthetic and will not reflect every practice’s configuration.
• Proprietary API usage may carry fees and contract requirements that affect your business model.

• Whether you can stay within the certified FHIR APIs or need athenaOne APIs and their contracting.
• Any marketplace listing or partner review you choose to pursue.
• Practice authorization and onboarding at each customer.
• Mapping effort between FHIR resources and athenaOne API payloads.

See FHIR integration cost for planning ranges and cost drivers.

• Which of our workflows fit the certified FHIR APIs and which need athenaOne APIs?
• Have you taken an app from preview to production on athenahealth, and what did that require?
• How will you handle practice-by-practice authorization and onboarding?
• How do you reconcile data read via FHIR with data written via athenaOne APIs?

Browse EHR integration vendors filtered by athenahealth.