athenahealth FHIR Integration: API Access, Auth, and What to Expect
athenahealth's FHIR integration path runs through its developer marketplace program, which shapes both the technical access model and the review timeline differently from a typical hospital-EHR integration.
athenahealth's developer program and marketplace model
athenahealth exposes FHIR R4 APIs through its developer program, and - distinct from some other major EHRs - has historically emphasized a marketplace model where third-party apps are reviewed and listed for athenahealth's provider customer base to adopt, not just a bilateral technical integration. This marketplace review process is worth understanding early, since it can add its own timeline and requirements (security review, a working demo, marketplace listing content) beyond the pure technical integration work.
Authentication and access
Access follows the standard OAuth 2.0 / SMART on FHIR pattern - interactive SMART App Launch for provider- or patient-facing apps, with scopes declared during app registration. As with other EHR platforms, start in athenahealth's sandbox/preview environment to validate your integration before pursuing production access tied to specific practices using athenahealth.
Practical considerations
Since athenahealth serves a large number of independent practices on a shared platform (athenaOne), similar to the per-practice activation pattern seen with eClinicalWorks, technical approval at the platform level doesn't automatically mean every practice is reachable - plan for practice-level enablement as part of rollout, not just the initial technical integration.
Budget real time for the marketplace review process specifically if your app is intended for broader distribution to athenahealth's customer base, as opposed to a single custom integration for one organization - the two paths (marketplace app vs. single-customer integration) can have different review requirements.
FAQ