athenahealth and athenaOne: Cloud EHR Architecture, FHIR R4 APIs, and Marketplace Integration

athenahealth is a healthcare technology company whose core platform, athenaOne, combines a cloud-based electronic health record (EHR), medical practice management and revenue cycle management, and patient engagement on a single-instance, multi-tenant software architecture. For clinical informaticists, health services researchers, and software engineers, athenaOne exposes both standardized HL7 Fast Healthcare Interoperability Resources (FHIR) Release 4 (R4) APIs and proprietary REST endpoints through a unified global gateway.

What athenahealth and athenaOne Are

athenahealth develops and operates cloud software for ambulatory medical practices, specialty clinics, and health systems. While searchers often use athenahealth EHR and athenaOne interchangeably, the terms distinguish the vendor from the integrated software suite:

• athenahealth: The platform operator, network coordinator, and developer of the underlying API gateway and national health information exchange connections.
• athenaOne: The unified Software-as-a-Service (SaaS) suite encompassing clinical documentation (athenaClinicals), revenue cycle and practice management (athenaCollector), and patient portal/communication workflows (athenaCommunicator).
• athenahealth Marketplace (formerly More Disruption Please / MDP): The partner ecosystem and application store through which third-party clinical decision support, ambient documentation, telehealth, and research data capture applications integrate with customer practices.

How athenaOne’s Single-Instance Multi-Tenant Cloud EHR Architecture Works

athenaOne operates on a single-instance, multi-tenant cloud architecture rather than isolated, hospital-hosted server deployments. Every participating medical group accesses the same underlying software release and API gateway infrastructure, with tenant data logically partitioned by practice identifier (practiceid), brand, and chart-sharing group.

This architectural choice has three concrete consequences for clinical informatics and multi-site research:

1. Single global API base URL: Unlike client-server EHRs that require developers to discover and maintain hundreds of hospital-specific FHIR endpoint URLs, athenahealth routes production FHIR R4 traffic through one global base URL (https://api.platform.athenahealth.com/fhir/r4) and one sandbox base URL (https://api.preview.platform.athenahealth.com/fhir/r4), alongside site-specific base URLs that embed practice and chart-sharing group identifiers.
2. Synchronized regulatory and schema updates: When athenahealth updates its FHIR server to support a newer HL7 FHIR US Core Implementation Guide profile, every tenant practice receives the updated resource definitions simultaneously without local server patching.
3. Tenant routing via practice context: Because a single endpoint serves the entire network, API calls must specify the target tenant context—either embedded in the SMART launch token context or passed via practice-scoped parameters—so queries execute against the authorized organization’s clinical records.

What FHIR R4 and Proprietary Endpoints athenahealth Exposes

athenahealth exposes two complementary API layers: an ONC Health IT Certification standardized API layer complying with 45 CFR § 170.315(g)(10) (Standardized API for patient and population services), and a proprietary REST API layer for operational, scheduling, and billing workflows not covered by HL7 profiles.

Declared HL7 FHIR R4 CapabilityStatement and US Core Profiles

According to athenahealth’s live production FHIR R4 CapabilityStatement (https://api.platform.athenahealth.com/fhir/r4/metadata, FHIR version 4.0.1), the athenahealth FHIR Server accepts json, application/json, application/json+fhir, and application/fhir+json payloads and instantiates four formal HL7 capability specifications:

• HL7 FHIR US Core Server v3.1.1: http://hl7.org/fhir/us/core/CapabilityStatement/us-core-server|3.1.1
• HL7 FHIR US Core Server v6.1.0: http://hl7.org/fhir/us/core/CapabilityStatement/us-core-server|6.1.0
• HL7 FHIR Bulk Data Access v1.0.1: http://hl7.org/fhir/uv/bulkdata/CapabilityStatement/bulk-data|1.0.1
• HL7 FHIR Bulk Data Access v2.0.0: http://hl7.org/fhir/uv/bulkdata/CapabilityStatement/bulk-data|2.0.0

Across its R4 CapabilityStatement, athenahealth declares 32 FHIR resource types. The table below maps the supported resource types by their declared RESTful interactions:

Interaction Profile	Count	Declared FHIR R4 Resource Types (/fhir/r4/metadata)	Primary Clinical & Research Use
read, search-type	27	AllergyIntolerance, Appointment, CarePlan, CareTeam, Condition, Coverage, Device, DiagnosticReport, DocumentReference, Encounter, FamilyMemberHistory, Goal, Immunization, Location, Medication, MedicationDispense, MedicationRequest, Observation, Organization, Patient, Practitioner, Procedure, Provenance, Questionnaire, RelatedPerson, ServiceRequest, Specimen	USCDI clinical data extraction, cohort eligibility screening, longitudinal lab/vital sign retrieval, and provenance auditing
create, read, search-type	1	QuestionnaireResponse	Writing structured patient-reported outcomes (PROs) and intake assessment responses back into the chart alongside read/search queries
read only	2	Binary, Media	Retrieving raw clinical documents, PDF attachments, and diagnostic images referenced by DocumentReference or DiagnosticReport
Population / Bulk export profiles	2	Group, MeasureReport	Cohort-defined population exports under the FHIR Bulk Data Access ($export) specification and quality measure reporting

Proprietary athenaOne REST APIs

Because HL7 FHIR US Core focuses primarily on clinical summary retrieval, developers use athenaOne’s proprietary REST APIs when an integration must write administrative records, manage complex appointment slot rules, upload custom chart document categories, or automate claims and eligibility transactions. In hybrid architectures, applications commonly use SMART on FHIR for clinician sign-on and clinical read access while calling proprietary REST endpoints for write-back and practice-management automation.

How Developers Integrate With the athenahealth API and Marketplace

Integrating an application with athenaOne follows the OAuth 2.0 and HL7 SMART App Launch specifications declared in https://api.platform.athenahealth.com/fhir/r4/.well-known/smart-configuration and documented in the athenahealth Developer Portal (docs.athenahealth.com):

1. Register in the Developer Portal and select environment: Create a developer account and configure the application against the Preview sandbox (https://api.preview.platform.athenahealth.com/fhir/r4) before requesting production credentials.
2. Choose the OAuth 2.0 grant type: The authorization server supports two grant types in grant_types_supported: authorization_code (3-legged OAuth for clinician EHR launch or patient standalone launch) and client_credentials (2-legged OAuth for backend system-to-system services and Bulk Data exports).
3. Implement SMART App Launch and PKCE: Direct user-facing launches to https://api.platform.athenahealth.com/oauth2/v1/authorize using Proof Key for Code Exchange (PKCE) with S256 (the required challenge method in code_challenge_methods_supported). Declared SMART capabilities include launch-ehr, launch-standalone, context-ehr-patient, context-ehr-encounter, context-standalone-patient, sso-openid-connect, and both permission-v1 and permission-v2 scopes.
4. Exchange tokens and authenticate: Request access tokens from https://api.platform.athenahealth.com/oauth2/v1/token (with token introspection at /oauth2/v1/introspect, revocation at /oauth2/v1/revoke, and public signing keys at /oauth2/v1/keys). Supported token endpoint authentication methods are client_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt, and none (for public clients).
5. Scope to tenant practice and deploy via Marketplace: Patient-access apps certified to 45 CFR § 170.315(g)(10) connect through standard patient-authorized SMART flows. Commercial provider-facing apps and system-level integrations distribute through the athenahealth Marketplace, where participating medical practices authorize the application for their specific practice IDs.

Strengths and Limits for Clinical Informatics and Research

• Strength — Uniform network endpoint: Multi-site ambulatory studies and registry connectors do not need site-by-site firewall tunnels or local interface engines; a single FHIR R4 and Bulk Data client implementation addresses all participating athenaOne practices once tenant authorization is granted.
• Strength — Dual US Core v3.1.1 and v6.1.0 instantiation: Supporting both US Core 3.1.1 and 6.1.0 profiles alongside Bulk Data v1.0.1 and v2.0.0 allows research pipelines to ingest newer USCDI elements without breaking legacy parsers.
• Limit — Ambulatory vs. inpatient clinical scope: athenaOne is primarily deployed in ambulatory practices and outpatient clinics; studies requiring high-frequency inpatient ICU telemetry or operating-room anesthesia feeds typically encounter inpatient systems such as Epic or Oracle Health (Cerner).
• Limit — FHIR write constraints: In the production R4 CapabilityStatement, 27 clinical resources support read and search-type while only QuestionnaireResponse exposes create; broader operational writes require athenahealth’s proprietary REST APIs and Marketplace partner permissions.

Alternatives to athenaOne in Clinical and Research Environments

Platform	Primary Care Setting	Hosting & Tenancy Model	Standardized Interoperability Layer
athenahealth (athenaOne)	Ambulatory medical groups, specialty practices, and outpatient clinics	Single-instance, multi-tenant cloud SaaS	Global FHIR R4 gateway (US Core 3.1.1 & 6.1.0, Bulk Data 1.0.1 & 2.0.0) + proprietary REST APIs
Epic	Large academic medical centers, integrated health systems, inpatient & ambulatory	Health-system-hosted, Epic-hosted, or community-shared instances	Per-organization FHIR R4 endpoints published in the Epic endpoint directory + App Orchard / Showroom
Oracle Health (formerly Cerner)	Hospitals, federal health systems, and multi-facility acute care networks	Remote-hosted or client-hosted multi-domain instances	Per-tenant FHIR R4 and Millennium APIs via the Oracle Health codeprogram ecosystem

FAQ

How does athenaOne’s single-instance multi-tenant cloud EHR architecture work?

All participating practices run on a single shared cloud codebase and database framework logically partitioned by practice ID and chart-sharing group. Updates, US Core profile revisions, and API endpoints deploy simultaneously across the network through a single production base URL (https://api.platform.athenahealth.com/fhir/r4).

How do developers integrate with the athenahealth API and Marketplace?

Developers register in the athenahealth Developer Portal, build against the Preview sandbox using OAuth 2.0 (authorization_code with S256 PKCE for SMART on FHIR user/patient launches or client_credentials for backend services), and distribute commercial provider or backend integrations through the athenahealth Marketplace (formerly More Disruption Please / MDP).

What FHIR R4 and proprietary endpoints does athenahealth expose?

athenahealth’s FHIR R4 server (fhirVersion 4.0.1) exposes 32 resource types instantiating HL7 US Core v3.1.1 and v6.1.0 and Bulk Data v1.0.1 and v2.0.0—providing read and search-type across 27 clinical and administrative resources plus create on QuestionnaireResponse—alongside proprietary REST APIs for scheduling, billing, and document workflows.

Sources

• athenahealth, Production FHIR R4 CapabilityStatement (https://api.platform.athenahealth.com/fhir/r4/metadata, as of 2026-11-09): api.platform.athenahealth.com/fhir/r4/metadata
• athenahealth, SMART on FHIR Well-Known Configuration (https://api.platform.athenahealth.com/fhir/r4/.well-known/smart-configuration, as of 2026-11-09): api.platform.athenahealth.com/fhir/r4/.well-known/smart-configuration
• athenahealth, Developer Document Portal (as of 2026-11-09): docs.athenahealth.com/api
• 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
• HL7 International, US Core Implementation Guide and SMART App Launch v2.2.0 Specification (as of 2026-11-09): hl7.org/fhir/us/core and hl7.org/fhir/smart-app-launch