Athenahealth RPM Integration: A Setup Guide for IT

Routing remote patient monitoring data into athenahealth is less a single API call than a sequence of architectural decisions, and the order in which an IT team makes them determines whether vitals land in a clinically useful place or in a parking lot of unmapped observations. A successful athenahealth RPM integration depends on three things working together: an authentication model that matches the deployment, a data mapping strategy that aligns device readings with athenahealth's vitals hierarchy, and a chart placement plan that puts each measurement where a clinician already looks. This guide walks EHR integration teams through those layers, with attention to the platform-specific quirks that separate a clean rollout from a stalled one.

athenahealth exposes more than 800 API endpoints across clinical, scheduling, and billing domains, and as of the ONC HTI-1 Final Rule, integration partners were required to migrate to FHIR R4 resources by May 30, 2025. Source: athenahealth Developer Portal, 2025 Release Notes.

What athenahealth RPM integration actually requires

The phrase athenahealth RPM integration covers two distinct technical paths, and choosing the wrong one early creates rework later. The first path uses athenahealth's standards-based FHIR R4 APIs, which follow the US Core Implementation Guide and support SMART on FHIR. The second uses athenahealth's proprietary REST APIs, including the dedicated Vitals and Flowsheet endpoints, which expose platform-native behaviors the FHIR layer abstracts away. Most production RPM connectors end up using both: FHIR for read operations and standards-aligned interoperability, and the proprietary Vitals or Flowsheet endpoints for the write operations that place device-generated readings into the right chart context.

A critical 2025 change reshaped how teams resolve endpoints. athenahealth moved to site-specific base URLs for its FHIR APIs, meaning integration partners can no longer hardcode a single base path. Your connector has to dynamically resolve the correct FHIR base URL per practice, typically through the SMART configuration discovery document. Teams that built against a static URL before this shift had to refactor their endpoint resolution logic.

Authentication is the next gate. athenahealth supports both two-legged and three-legged OAuth 2.0. Two-legged (client credentials) suits backend, system-to-system RPM data feeds where no individual user is present, which describes most automated device ingestion. Three-legged OAuth applies when a clinician or patient is actively authorizing access in a user-facing app. For a continuous vitals feed, two-legged flows are the workhorse, and scoping those credentials tightly is the difference between a defensible security posture and an audit finding.

Authentication and data routing approaches compared

The table below contrasts the main routing strategies an integration team will weigh when connecting an RPM platform to athenahealth.

Approach	Primary use	Auth model	Chart placement control	Best fit
FHIR R4 Observation API	Standards-based read/write of vitals	2-legged or 3-legged OAuth	Moderate, governed by US Core profiles	Multi-EHR connectors needing portability
Proprietary Vitals API	Encounter or manual vitals entry	2-legged OAuth	High, native vitals hierarchy	Device feeds tied to encounters
Flowsheet API	Longitudinal device data outside encounters	2-legged OAuth	High, problem-level flowsheet rows	Chronic-care RPM trend tracking
Marketplace partner listing	Productized turnkey integration	athenahealth-managed	Defined by partner build	Vendors distributing to many practices

No single row wins outright. A connector built only on FHIR gains portability across EHRs but cedes some control over exactly where data renders. A connector built only on proprietary endpoints gains precise chart placement but locks logic to athenahealth. Teams supporting a single-EHR client often lean proprietary; teams shipping a product across health systems usually lead with FHIR and fall back to native endpoints for placement.

Mapping RPM Vitals to the athenahealth Data Model

athenahealth structures vitals hierarchically into three levels: Vitals, Vital Attributes, and Readings. A blood pressure measurement, for example, is a Vital that carries Vital Attributes (systolic and diastolic) each holding a Reading. RPM device output rarely arrives in this shape. A cellular blood pressure cuff might emit a flat JSON payload with systolic, diastolic, pulse, timestamp, and device serial. The mapping layer's job is to decompose that payload into athenahealth's nested structure without losing the temporal and provenance metadata that clinical and billing workflows depend on.

Key mapping considerations for an athena vital signs feed include:

• Unit normalization. Convert device units to the units athenahealth expects per vital type before posting, since silent unit mismatches produce clinically dangerous values.
• Timestamp fidelity. Preserve the measurement time, not the ingestion time, because CMS RPM billing and trend analysis both depend on when the reading was taken.
• Provenance. Tag readings as device-generated rather than clinician-entered so downstream users can distinguish home measurements from in-office vitals.
• LOINC alignment. When using the FHIR Observation resource, map each reading to the correct LOINC code under the US Core vital signs profile.
• Deduplication. RPM devices retry on poor connectivity, so the connector must reconcile duplicate transmissions before they create duplicate chart entries.

The decision that trips up most teams is encounter versus flowsheet placement. The Vitals API can attach readings to an encounter, but RPM measurements taken at a patient's kitchen table do not belong to an office encounter. For longitudinal home monitoring, the Flowsheet API is usually the better destination because it supports patient-level, problem-linked data captured outside any visit, giving clinicians a time-series view of trends rather than orphaned encounter vitals.

Industry Applications

Chronic care management programs

Hypertension and heart failure programs generate the highest RPM volume, and they benefit most from flowsheet-based placement. Routing daily blood pressure and weight readings into a problem-linked flowsheet lets care teams see a 30-day trend at a glance, which supports both clinical decisions and the documentation needed for CMS RPM reimbursement.

Multi-site health systems

For organizations running athenahealth across many practices, the 2025 site-specific FHIR base URL change matters operationally. A connector has to resolve and cache the correct base URL per practice context and handle credential scoping per site. Teams that build this resolution layer once, cleanly, avoid a maintenance burden that compounds with every new location.

Marketplace-distributed RPM vendors

Vendors that want to reach many athenahealth practices without bespoke builds per client often pursue an athenahealth Marketplace listing. Partners including Smart Meter and Esvyda have used this path to flow cellular RPM data directly into athenahealth charts. The trade-off is conforming to athenahealth's partner review and certification expectations in exchange for distribution.

Current research and evidence

athenahealth's own developer documentation, updated through 2025, confirms that the platform standardized on FHIR R4 in response to the ONC HTI-1 Final Rule, with the May 30, 2025 migration deadline acting as a forcing function for partners still on DSTU2. The documentation also formalizes the distinction between the encounter-based Vitals API and the longitudinal Flowsheet API, which is the single most consequential design choice for RPM data placement.

Broader interoperability research supports the standards-first direction. The US Core Implementation Guide, maintained by HL7 under the work of contributors such as Brett Marquard and Eric Haas, defines the vital signs profiles that constrain how Observation resources should be structured, giving RPM connectors a shared target instead of EHR-specific guesswork. Industry analyses of athenahealth integrations, including 2025 and 2026 developer guides from firms like Topflight and Taction Software, consistently flag OAuth scoping and dynamic endpoint resolution as the most common implementation failure points, which aligns with what integration teams report in practice.

The Future of athenahealth RPM Integration

Three directions are taking shape. First, the regulatory push behind HTI-1 makes FHIR R4 the durable foundation, so investment in standards-based connectors will age better than investment in proprietary-only paths. Second, the shift to site-specific endpoints signals a broader move toward per-practice configurability, which rewards connectors that treat endpoint and credential resolution as dynamic rather than static. Third, as CMS reimbursement rules for RPM continue to evolve, the metadata quality of each reading, especially accurate measurement timestamps and device provenance, will carry more weight, because billing automation depends on that data being trustworthy at the point it enters the chart.

The practical implication for IT teams is to build the mapping and placement layer to be auditable and configurable from the start. The connectors that survive the next round of rule changes are the ones where unit conversion, LOINC mapping, deduplication, and chart-target logic are explicit and testable rather than buried in transformation code.

Frequently asked questions

Should RPM vitals go to the Vitals API or the Flowsheet API in athenahealth?

For home measurements collected outside an office visit, the Flowsheet API is usually the better target because it supports longitudinal, problem-linked data and gives clinicians a trend view. The encounter-based Vitals API fits readings tied to a specific visit. Many connectors use both depending on the workflow.

Which OAuth model should an automated RPM feed use?

A continuous, system-to-system RPM data feed with no user present should use two-legged OAuth (client credentials). Three-legged OAuth applies when a clinician or patient is actively authorizing access through a user-facing application. Scope the credentials narrowly to the resources the feed actually writes.

What changed with athenahealth FHIR endpoints in 2025?

athenahealth moved to site-specific base URLs for its FHIR APIs, so connectors can no longer hardcode a single base path. Integration partners must dynamically resolve the correct FHIR base URL per practice, typically through the SMART configuration discovery document, and migrate to FHIR R4 per the HTI-1 Final Rule.

How do we prevent duplicate readings from RPM devices?

Cellular RPM devices retry transmissions on poor connectivity, which can create duplicate payloads. Build a deduplication step in the connector that reconciles readings by device identifier, measurement type, and original measurement timestamp before posting to athenahealth, so the chart never shows the same reading twice.

Circadify is building tooling for exactly this layer of the problem, with HL7 FHIR compatible RPM data designed to plug into existing EHR and telehealth workflows rather than force a parallel system. For integration teams who want a platform-specific athenahealth walkthrough covering data mapping, chart placement, and endpoint resolution, see the integration docs and EHR guides at circadify.com/solutions/telehealth.