Most practices evaluating remote patient monitoring devices start with the wrong question. They ask whether a blood pressure cuff or pulse oximeter is accurate and comfortable for patients, then discover months later that the data it collects never actually lands cleanly in the EHR — or worse, gets flagged during a payer audit because the device itself was never eligible for reimbursement in the first place. The devices that look identical on a spec sheet can behave very differently once they have to talk to your practice management system, your regional health information exchange, and your compliance program at the same time.
That gap is exactly what a neutral, standards-literate evaluation process is supposed to catch. Arizona has a long institutional memory here: the state built one of the country’s earlier statewide health information exchange efforts specifically because clinical data moving between disconnected systems was, and still is, the single biggest point of failure in digital health projects. The same lesson applies at the device level. Before comparing price sheets, a practice needs a short, specific checklist for interoperability, regulatory status, and data security — the three areas vendors are least likely to volunteer information about unprompted.
Why Interoperability Decides Whether the Device Is Worth Buying
A remote patient monitoring device that generates readings your staff has to transcribe by hand isn’t really "remote" monitoring — it’s a data-entry job with extra steps. The entire value of RPM depends on vitals, glucose readings, or ECG data flowing automatically into the patient’s chart where a clinician can act on it, and in many cases into a broader health information exchange so any other provider treating that patient has the same picture. When a device can’t do that reliably, practices end up paying for hardware, staff time, and a monitoring subscription while getting a fraction of the clinical or billing value they expected.
This is the point where "does it work" and "does it integrate" stop being separate questions. A device can measure blood pressure perfectly and still be a poor purchase if its data format, transmission method, or vendor API can’t be reconciled with what your EHR or HIE actually accepts.
HL7 FHIR: The Data Language Your EHR and HIE Actually Speak
HL7 FHIR (Fast Healthcare Interoperability Resources) is the standard that determines whether a device’s data can be understood by outside systems at all. FHIR defines structured "resources" for clinical and administrative concepts — an observation, a device reading, a patient record — so that an EHR, an HIE, and a monitoring platform can exchange information in a shared format instead of a proprietary one. When a vendor claims their platform is "interoperable," the specific, answerable question is whether their data is exposed through FHIR-based resources your systems can consume, or whether it only lives inside a closed vendor dashboard that has to be manually exported.
Ask vendors directly: does their platform expose an HL7 FHIR API, and has that connection actually been tested against your specific EHR, not just described as theoretically compatible? Generic interoperability claims and proven, tested connections are not the same thing, and the difference only becomes visible after the contract is signed.
FDA Clearance Class: A Regulatory Detail That Also Determines Reimbursement
Most remote patient monitoring devices — blood pressure monitors, glucose meters, pulse oximeters, digital scales, ECG monitors and patches, spirometers — fall under FDA Class II, the moderate-risk category, and typically reach the market through 510(k) clearance, meaning the device was found substantially equivalent to an already-marketed device. It’s worth being precise about the language here: these devices are "FDA-cleared," not "FDA-approved." Approval is reserved for higher-risk Class III devices, and vendors or marketing materials that blur that distinction should be treated as a red flag on accuracy, not just semantics.
This distinction has a direct financial consequence for RPM programs specifically: reimbursement generally requires the monitoring program to use FDA-cleared medical devices. A consumer wellness wearable, however accurate its sensor, does not qualify for billable remote monitoring services. Any RPM vendor evaluation should include a direct question — what is this device’s FDA clearance status, and is it accompanied by documentation, not just a claim on a product page?
Data Transmission and Security: What "HIPAA Compliant" Should Actually Mean
Every RPM device transmits protected health information, which means every RPM device and its supporting platform has to meet HIPAA’s security and privacy requirements for how that data is handled, transmitted, and stored. In practice, "HIPAA compliant" is a claim vendors make constantly and prove inconsistently, so it’s worth looking one layer deeper at the frameworks that back it up. Broader information-security frameworks — ISO/IEC 27001 for information security management, and the NIST Cybersecurity Framework for identifying and managing cyber risk — are the kind of independent structure that indicates a vendor has actually built a security program, rather than just checked a compliance box.
None of this is exotic or unreasonable to ask for. A vendor serious about the clinical market should be able to describe, specifically, how patient data is encrypted in transit, how it is stored, and what security framework their program is built on — not simply assert that they are "secure."
A Practical Evaluation Checklist
The table below condenses the questions above into a format a practice can actually use in a vendor call, without needing a compliance background to ask them.
| Evaluation Area | Question to Ask the Vendor | Why It Matters |
|---|---|---|
| Interoperability | Does the platform expose data through an HL7 FHIR API, tested against our EHR? | Determines whether readings flow automatically into the chart or require manual entry |
| Regulatory status | What is the device’s FDA clearance class, and can documentation be provided? | Affects both clinical credibility and RPM billing eligibility |
| Reimbursement eligibility | Is this device FDA-cleared for monitoring use, not a consumer wellness product? | Consumer wearables typically don’t qualify for billable RPM services |
| Data security | What security framework (e.g. ISO/IEC 27001, NIST) governs the platform? | Separates a real security program from a marketing claim |
| HIE connectivity | Has the vendor connected to a regional health information exchange before? | Prior HIE integration experience shortens implementation time significantly |
Why This Belongs in a Neutral Evaluation, Not a Vendor Pitch
Vendors are naturally going to describe their own devices in the best possible light, which is exactly why practices benefit from a neutral point of comparison built around standards rather than sales copy. This category exists to give Arizona medical practices a place to compare remote patient monitoring devices and vendors specifically on interoperability, regulatory status, and certification — the technical criteria that determine whether a device actually works inside a modern practice, rather than just on a spec sheet. Getting these questions answered before signing a contract is far cheaper than discovering the gaps after the hardware is already in patients’ homes.