Read only or write back
Most declared resources are read and search. Write needs beyond QuestionnaireResponse add a confirmation step and possibly another path.
athenahealth FHIR capabilities
athenahealth FHIR Capabilities
Your product needs to know what athenahealth exposes over FHIR before you design the data flow. Agnotic Technologies reads athenahealth's published CapabilityStatement and SMART configuration, maps what your use case can read, search and write, and builds and tests the integration for you.
FHIR R4 (4.0.1)US Core 3.1.1 and 6.1.0SMART v1 and v2Bulk Data $export
Trusted by global innovators
What are athenahealth FHIR capabilities?
athenahealth FHIR capabilities are the HL7 FHIR R4 resources, SMART authorization flows and Bulk Data export that athenahealth's platform FHIR server declares for apps that work with athenaOne practices. Agnotic Technologies checks those declarations, maps your use case to them, and builds the integration that reads, searches and writes the data for you.
athenaOne is athenahealth's platform for practices. This page covers its FHIR surface only; our athenahealth integration services page covers the wider integration and the engagement.
Every capability here comes from the server's own published CapabilityStatement and SMART configuration. What a practice has enabled for your app is confirmed in testing.
Server declarations
What does athenahealth's FHIR server declare?
The production CapabilityStatement declares FHIR 4.0.1, and conformance to US Core 3.1.1 and 6.1.0 and to the Bulk Data Access guide 1.0.1 and 2.0.0.
Its SMART configuration supports the authorization code and client credentials grants, EHR and standalone launch, public and confidential clients, and SMART v1 and v2 permissions.
Capability table
Which athenahealth FHIR resources can your app use?
Built only from athenahealth's production CapabilityStatement and SMART configuration. Interactions not listed are not declared.
| Resource or area | Interactions declared | Auth model | Notes |
|---|---|---|---|
| Patient | Read, search; $health-cards-issue | SMART patient or user scopes; client credentials for system access | Operation for issuing SMART Health Cards is declared |
| AllergyIntolerance, Condition, Immunization, MedicationRequest, Procedure | Read, search | SMART patient or user scopes; client credentials | US Core profiles declared |
| Observation | Read, search | SMART patient or user scopes; client credentials | US Core lab, vital signs and other observation profiles declared |
| DiagnosticReport, DocumentReference, Binary | Read and search; Binary read | SMART patient or user scopes; client credentials | Document content retrieved through Binary |
| Appointment | Read, search; $self-checkin-entry-url, $telehealth-zoom-credentials | SMART scopes | athenahealth-specific operations declared on the resource |
| QuestionnaireResponse | Create, read, search; $latest-response-by-questionnaire | SMART scopes | The one resource with create declared |
| Group | $export | client_credentials (system) | Bulk Data export, per guide versions 1.0.1 and 2.0.0 |
| MeasureReport | $submit-care-gaps | client_credentials (system) | Care gap submission operation declared |
FamilyMemberHistory also declares a $batch-write operation. We confirm any write path with athenahealth during scoping before a release depends on it.
Sandbox checklist
What should you check in athenahealth's preview environment?
athenahealth publishes the same discovery documents on its preview API host. We run this list before writing integration code.
- Pull the CapabilityStatement from the preview and production hosts and compare them
- Confirm every resource your app needs declares the interaction you need: read, search or create
- Read the SMART configuration and match your client type: public with PKCE, or confidential
- Request only the scopes your use case needs, in SMART v1 or v2 syntax, and inspect what the token grants
- Test Group $export end to end, including status polling and file download, with synthetic patients
- Check how your app handles missing US Core elements and data absent reasons
- Confirm the launch context your app receives: patient, encounter or both
What we build on athenahealth FHIR APIs
Each module is scoped on its own, so a first release can be one of them.
SMART apps for practice staff
EHR launch with patient and encounter context, single sign-on through OpenID Connect and only the scopes your workflow needs.
Patient-facing access
Standalone launch with PKCE for patient apps, with US Core data shown in a form patients can read.
Backend data sync
System access through the client credentials grant for scheduled reads into your product or warehouse.
Bulk Data pipelines
Group $export jobs with polling, NDJSON processing and reconciliation for population and analytics use cases.
Intake and questionnaire write-back
QuestionnaireResponse create for intake and screening forms that belong in the patient record.
Quality and care gap feeds
MeasureReport care gap submission for quality programs, where your contract with the practice covers it.
Scope drivers
What drives the cost of an athenahealth FHIR integration?
We do not quote a price before scoping. These are the factors that move the effort.
User, patient or system access
Each auth model needs its own registration, testing and review. Many products need two of them.
Bulk Data
Group exports add long-running jobs, file handling and reconciliation to the scope.
Number of practices
Each practice that adopts your app adds enablement, configuration checks and support.
Data model work
Mapping US Core resources into your product's model is quick for some products and a project for others.
Startup or established product
Startups often need the data model designed with the integration. Established products mostly need mapping.
Who builds on athenahealth
Who builds on athenahealth FHIR APIs?
The products we see most often on athenaOne practices.
Health tech startups
Products for independent and group practices that need chart data in the first pilot.
Practice workflow apps
SMART apps launched by staff with patient and encounter context.
Patient engagement apps
Patient apps that read records through standalone launch.
Intake and screening tools
Forms that write QuestionnaireResponse back to the record.
Analytics and quality platforms
Bulk Data exports and care gap feeds for value-based programs.
Care management products
Scheduled backend reads of problems, medications and results.
How we work
How do you build on athenahealth FHIR APIs?
Four steps, with a fixed first release agreed before build starts.
1.
Read the declarations
We map your use case against the CapabilityStatement and SMART configuration and flag anything that is not declared.
Declared only
2.
Build against the preview host
We register the app, request narrow scopes and test every call against the preview environment with synthetic patients.
Synthetic data
3.
Pilot with one practice
The first release runs with a pilot practice so launch context, data and performance are checked in real use.
Pilot practice
4.
Roll out and monitor
We add practices one by one and watch auth errors, failed calls and export jobs.
Monitored
Compliance as engineering
How do we keep PHI safe on an athenahealth 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 preview environment and synthetic patients.
Least-privilege scopes
Scopes match the use case, and system access through client credentials is kept for backend jobs only.
Secrets and keys
Client secrets and private keys live in a secrets manager with rotation, never in configuration files.
Audit logging
Every FHIR call is logged with user, patient, practice and time.
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.
Standards in scope
Standards athenahealth's FHIR server declares
FHIR R4US CoreSMARTBulk DataOpenID ConnectHIPAA
Facts and sources
Which facts shape athenahealth FHIR work?
Short facts we design around, each linked to its primary source.
athenahealth's production FHIR R4 CapabilityStatement declares FHIR 4.0.1 and conformance to US Core 3.1.1 and 6.1.0 and to the Bulk Data Access guide 1.0.1 and 2.0.0.
Source: athenahealth FHIR R4 CapabilityStatement (api.platform.athenahealth.com)In athenahealth's CapabilityStatement, clinical resources such as Patient, Condition, Observation and MedicationRequest declare read and search; QuestionnaireResponse declares create, and Group declares the $export operation.
Source: athenahealth FHIR R4 CapabilityStatement (api.platform.athenahealth.com)athenahealth's SMART configuration lists the authorization_code and client_credentials grants, EHR and standalone launch, SMART v1 and v2 permissions, and PKCE with the S256 method.
Source: athenahealth SMART configuration (api.platform.athenahealth.com)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)
Frequently Asked Questions
Yes. athenahealth's production CapabilityStatement declares FHIR 4.0.1, with conformance to US Core 3.1.1 and 6.1.0 and to the Bulk Data Access guide 1.0.1 and 2.0.0.
The CapabilityStatement declares create for QuestionnaireResponse and a batch-write operation on FamilyMemberHistory, while most clinical resources are read and search. Where your product needs other writes, we confirm the supported path with athenahealth during scoping.
Its SMART configuration lists the client_credentials grant and asymmetric confidential clients, which is how SMART Backend Services works. We use it for scheduled backend reads and Bulk Data exports.
athenahealth is the company and athenaOne is its platform for practices. This page covers the FHIR capabilities athenahealth's platform FHIR server declares for apps working with athenaOne practices.
It depends on scope; we agree a fixed first release on the scoping call. A read-only SMART app for one pilot practice is a smaller release than backend sync with Bulk Data across many practices.
Yes. Agnotic signs a business associate agreement before any PHI is shared, and we build and test against the preview environment with synthetic patients.
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.