Skip to main content
[email protected]
Menu
Language
Appearance

FDA Clearance and Data Standards: What to Verify Before Choosing an RPM Device Vendor

ATAzHeC Technology Council
August 15, 2026
6min read
WhatsAppEmail

Search for "remote patient monitoring devices fda approved" and most results answer half the question: they confirm a cuff, scale, or pulse oximeter is legally marketed, then stop. For a practice building an RPM program, that is only the first filter. A device can be perfectly cleared by the FDA and still be a poor operational choice if its readings never land cleanly inside the practice’s EHR. Choosing an RPM device vendor is really two separate evaluations — a regulatory one and a data-interoperability one — and most buyers only run the first.

The Regulatory Filter: What FDA Clearance Actually Confirms

Most consumer-facing RPM devices — blood pressure monitors, glucose meters, pulse oximeters, and connected weight scales — are regulated by the FDA as Class II moderate-risk devices and reach the market through the 510(k) pathway. That process requires a manufacturer to show its device is substantially equivalent to an already-legally-marketed predicate device; it is a comparison to precedent, not a from-scratch safety review. That distinction matters for a buyer: 510(k) clearance tells you the device meets a baseline safety and performance bar, but it says nothing about whether the vendor’s platform can move that reading into your workflow. A practice that stops its diligence at "is it FDA cleared" has confirmed the hardware is legitimate and left the harder question — will the data actually reach the chart — completely unanswered.

The practical step here is simple but frequently skipped: ask every candidate vendor for the specific 510(k) number or clearance letter for the exact device model being proposed, not a generic claim that "our devices are FDA cleared." Vendors sometimes bundle a cleared sensor with an uncleared companion app or hub; the clearance covers the device, not necessarily every component of the kit a practice is being sold.

The Interoperability Filter: The Standards That Decide Whether Data Reaches the EHR

A cleared device generates a reading. Getting that reading into a clinician’s workflow depends on a completely separate set of technical standards, and this is where most RPM vendor evaluations go quiet because the buyer isn’t fluent in the vocabulary. Three layers are worth understanding, because a vendor should be able to speak fluently to all three:

  • The device-to-gateway layer. Most connected RPM hardware transmits locally via Bluetooth, using the GATT (Generic Attribute Profile) specification to hand a reading from the cuff or scale to a smartphone app or dedicated hub. This layer only gets the data off the device — it does not touch the EHR at all.
  • The device-interoperability layer. The Continua Design Guidelines, maintained by the Personal Connected Health Alliance (PCHAlliance), are the open industry specifications built specifically for end-to-end interoperability between personal medical devices and health information systems. A vendor whose hardware and platform are built to Continua guidelines has done real engineering work toward standards-based data exchange, rather than a proprietary pipe that only that vendor’s own dashboard can read.
  • The health-system layer. HL7 FHIR (Fast Healthcare Interoperability Resources), maintained by HL7 International, is the standard that governs how that monitoring data is structured and exchanged once it reaches the broader healthcare IT ecosystem — including the EHR itself. A platform described as "FHIR-native" is built to hand data to an EHR in a structured, standards-based format rather than requiring a manual export, a fax, or a proprietary portal a clinician has to check separately from the chart.

The table below is a simple way to keep the three layers straight when a vendor’s sales material starts blending them together:

LayerGoverning standardStandards bodyWhat it actually solves
Device → gatewayBluetooth GATTBluetooth SIGMoves a reading off the physical device to a phone or hub
Device → health systemContinua Design GuidelinesPCHAllianceStandardizes how a personal medical device talks to health information systems
Platform → EHRHL7 FHIRHL7 InternationalStructures monitoring data so it can be exchanged with and consumed by the EHR

A vendor that can only describe the first layer — "it pairs over Bluetooth" — and goes vague past that point is telling a practice, indirectly, that the data’s final leg into the EHR is unsolved or handled through a manual workaround.

A Short Vendor Vetting Checklist

Before signing an RPM device contract, a practice’s operations lead or office manager should be able to get clear, specific answers — not marketing language — to each of these:

  1. What is the exact FDA clearance status (510(k) number, if applicable) of the specific device model being proposed, not just the vendor’s product line in general?
  2. Does the platform describe itself as FHIR-native, or does it require a manual export, a separate portal login, or a fax to get readings into the chart?
  3. Is the hardware built to Continua Design Guidelines, or is the data pipeline proprietary to the vendor’s own app?
  4. Which specific EHR systems has this vendor already integrated with in production, versus "compatible in theory"?
  5. Who owns the escalation workflow when a reading crosses a clinical threshold — the vendor’s monitoring staff, or the practice’s own clinical team?

Why a Neutral Comparison Matters Here

RPM vendor marketing rarely volunteers the gap between "FDA cleared" and "actually interoperable," because the first claim is easy to make and the second requires real engineering the vendor may or may not have done. AzHeC’s role, going back to its history convening Arizona’s statewide health information exchange and its work on interoperability standards adoption, is to sit on the practice’s side of that conversation rather than the vendor’s — matching a practice with RPM vendors whose FDA clearance and data-standards story can actually be verified, instead of taken on faith from a sales deck. That is a narrower, more useful service than a generic "best RPM devices" list: it is a filter built around the two questions that determine whether an RPM program actually functions once the honeymoon period with a new vendor ends.

For a practice weighing RPM device vendors, the FDA clearance question is necessary but not sufficient. The standards conversation — Continua, FHIR, and how a vendor actually gets a reading from a patient’s living room into the chart — is where most of the real due diligence work, and most of the future headaches, actually live.

AT

Written by

AzHeC Technology Council

Join Our Community

Connect with like-minded readers, share your thoughts, and engage in meaningful discussions.

Explore More Articles

Discover our extensive library of health research and evidence-based insights.

Comments

0

Sign in to join the discussion

Share your thoughts and engage with the community

No comments yet

Sign in to be the first to comment!