A practice buys remote patient monitoring devices, enrolls patients, and expects a steady stream of blood pressure, glucose, and pulse oximetry readings to land automatically in the chart. Then the reports come back with gaps. A patient’s cuff synced fine on their end, but nothing shows up in the EHR for days. For a practice trying to bill CMS’s remote patient monitoring devices codes correctly, that gap is not a minor annoyance — it is the difference between a clean claim and a denied one.
The connection layer is the first point of failure
Most RPM devices reach the outside world one of two ways: Bluetooth paired to a patient’s phone or a cellular hub, or a built-in cellular radio that skips the phone entirely. Bluetooth is cheap and convenient, but it depends on the patient’s hub or app staying paired and the phone staying charged and in range — any of which can quietly break without the practice knowing. Cellular-only devices remove that dependency on the patient’s home network, but they trade it for coverage gaps: a patient in a rural stretch of the state with weak signal can still miss transmission windows even though the device itself is working correctly.
Either way, the failure usually isn’t visible to the clinical staff reviewing the chart. The device reports success on its own dashboard. The EHR simply shows nothing for that day, and unless someone is actively reconciling the two, the gap goes unnoticed until it affects a billing cycle.
Proprietary formats meet a chart that expects structure
Even when a reading transmits successfully, it has to survive translation. Many device manufacturers use their own data formats internally, and that data has to be converted into something the EHR will accept before it can post to the chart. When that conversion step is incomplete or the format doesn’t map cleanly, the EHR can reject the payload outright. From the practice’s side, this doesn’t look like a data problem — it looks like the data was never sent, because there’s no error banner in the chart telling anyone otherwise.
This is exactly the kind of interoperability gap that industry standards like HL7 and its newer successor FHIR (Fast Healthcare Interoperability Resources) exist to close. FHIR’s REST-API, modular-resource approach is a real improvement over older HL7 v2 messaging for connecting modern devices to modern systems. The complication is that adoption is uneven: plenty of EHRs and RPM platforms still lean on legacy HL7 v2 pipes, or implement FHIR only partially, so a device and an EHR can both technically "support standards" and still fail to talk to each other cleanly.
What incomplete data does to CMS reimbursement
The technical gap has a direct financial consequence. CPT 99454, the RPM device-supply-and-data code, requires at least 16 days of transmitted readings within a 30-day period to bill. A connectivity dropout or a rejected data format doesn’t just leave a hole in the clinical record — it can push a patient below that 16-day threshold and turn a billable month into an unbillable one. Combined with 99453 (initial setup), and 99457/99458 (the clinician time spent reviewing data and interacting with the patient), a practice running RPM at any scale is depending on that data arriving intact, on time, and in a format the EHR will actually post.
Missing or corrupted transmission streams also raise audit exposure. If the chart shows fewer transmission days than what was billed, the documentation doesn’t support the claim — regardless of whether the shortfall was the patient’s fault, the device’s fault, or a silent format rejection somewhere in the middle.
Workflow gaps compound the technical ones
Even a well-integrated RPM platform can still lose data at the human layer. Front-desk or clinical staff need a defined process for checking transmission status, not just assuming that "no alert" means "all is well." Staff turnover, inconsistent training on the RPM dashboard, and unclear ownership of who reconciles device data against the chart each week are common, mundane reasons that otherwise-functional integrations still produce gaps at month-end.
| Failure point | What it looks like in the chart |
|---|---|
| Bluetooth pairing drop | Readings stop for days, then resume without explanation |
| Cellular dead zone | Intermittent gaps tied to a patient’s location, not the device |
| Proprietary format rejected by EHR | Reading appears sent on the device dashboard, never posts to the chart |
| HL7/FHIR version mismatch | Partial data fields post; others silently drop |
| No staff reconciliation process | Gaps aren’t caught until the billing cycle closes |
What this means for choosing a vendor
None of this means remote patient monitoring devices are unreliable as a category — the technology works for thousands of practices every month. It means the integration between the device, the RPM platform, and the specific EHR a practice runs needs to be verified before enrollment scales up, not discovered after a billing cycle comes up short. A practice evaluating vendors should ask directly: what standard does the platform use to post into our EHR, what happens when a reading fails to transmit, and who is notified when a patient falls below the transmission threshold for the month. A vendor that can’t answer those questions specifically for your EHR, rather than in general terms, is asking the practice to find out the hard way.
Getting device readings into the chart reliably is a narrower, more solvable problem than it sounds — but only when the connectivity method, the data format, and the practice’s own workflow are all accounted for together, not treated as someone else’s responsibility.