A physician reviewing a patient's chart before a telehealth follow-up visit pulls up the EHR. Blood pressure readings from the past 30 days aren't there. They're in the RPM platform dashboard — in a different browser tab, behind a separate login, in a visualization that doesn't connect to the patient's medication record or problem list. The physician opens both windows, manually crossreferences the data, and makes a note to relay the RPM readings during the appointment.
This is the interoperability gap in practice. It's not a theoretical problem. It's a daily workflow interruption that adds cognitive load to an already overloaded clinical environment and creates the conditions for data to be missed or misinterpreted.
The gap exists because EHRs and RPM platforms are developed independently, use different data models, operate on different regulatory frameworks, and have historically had little commercial incentive to integrate smoothly with each other. The technical standards to bridge them exist. The implementations often don't.
What FHIR Promised and What It Delivered
The HL7 FHIR (Fast Healthcare Interoperability Resources) standard was supposed to resolve the fragmentation problem. The 21st Century Cures Act required EHR vendors to support FHIR-based APIs, and most major EHRs now have them. In theory, any application that speaks FHIR should be able to exchange structured data with any FHIR-compliant EHR.
In practice, the theory breaks down in several places. FHIR defines the structure of data but not the meaning of specific fields in a way that guarantees interoperability. An RPM platform that sends blood pressure readings as an Observation resource will be technically FHIR-compliant, but whether those readings appear in the right section of the EHR in a way the physician recognizes and trusts depends on implementation-specific decisions by both vendors.
FHIR also doesn't fully address authentication and authorization complexity in multi-organization deployments. When a patient's RPM program is managed by a care management organization that's separate from the EHR-using primary care practice — a common configuration — getting authorized data access across organizational boundaries requires patient consent management and organizational agreements that go well beyond the technical standard.
The Data Volume Problem
Even when integration works technically, RPM data volume creates EHR usability issues. A blood pressure cuff transmitting one reading twice daily generates roughly 60 data points per month per patient. At 300 enrolled patients, that's 18,000 blood pressure readings per month flowing into the EHR. Standard EHR vital sign documentation isn't designed to handle that volume in a way that's clinically useful.
Most practices that have successfully integrated RPM data into their EHR workflows don't send all raw readings to the EHR. They send summaries — daily or weekly aggregates, threshold crossings, trend alerts — and keep the full raw data in the RPM platform. This approach preserves EHR usability while ensuring clinically relevant RPM signals are visible where clinical decisions are being made.
Determining what goes into the EHR versus what stays in the RPM platform requires a deliberate workflow design decision. Most RPM-EHR integration projects fail at this point because the technical team assumes "all data should sync" and the clinical team doesn't get involved in integration design until after go-live.
Documentation for Billing Compliance
There's a separate interoperability requirement for RPM billing under Medicare: the monitoring data and the clinical interventions that resulted from it need to be documented in the medical record in a way that auditors can follow. If your RPM data lives in a separate platform that doesn't write to the EHR, and your care coordinators are documenting their interventions in the RPM platform rather than the EHR, your billing documentation trail is broken.
OCR audits and Medicare RAC audits for RPM claims specifically look for this: they want to see that the data was reviewed, that it connected to a clinical response, and that both the data and the response are in the patient's medical record. If your integration strategy doesn't include a clear path for documenting RPM-driven interventions in the EHR, you have a compliance risk regardless of whether the clinical program is performing well.
What Good Integration Actually Looks Like
The integrations that work in clinical practice share a few structural features. The EHR receives curated, clinically relevant summaries rather than raw readings. Care coordinator actions taken in response to RPM alerts are documented in the EHR, not just in the RPM platform. Patient enrollment status in the RPM program is visible in the EHR context, so any clinician accessing the patient record can see they're being monitored. And the RPM platform receives relevant clinical context from the EHR — current medications, recent labs, diagnosis changes — so alert thresholds can be calibrated to the patient's actual clinical status.
Bidirectional data flow, selectively designed around clinical workflow needs, is the goal. It requires coordination between clinical informatics, clinical operations, and both vendor implementation teams. It's not plug-and-play, and anyone who tells you otherwise hasn't done it.
But when it's done right, the physician reviewing that telehealth follow-up doesn't need a second browser tab. The RPM summary is in the chart, where it belongs.