Remote patient monitoring hardware
Remote patient monitoring (RPM) extends the clinical record into the home. This page looks at RPM as a data source — the categories of hardware, how readings are transmitted, what makes that data reliable, and how a measurement taken on a kitchen table reaches a clinician — framed as infrastructure and standards, not a shopping list.
RPM is an interoperability problem first
The hard part is the journey, not the measurement
Taking a blood pressure or a weight at home is straightforward. The difficulty is everything that happens afterward: the reading has to leave the home reliably, identify the right patient, arrive in a structure the clinical system understands, and surface to a clinician at a moment when it can change a decision. RPM succeeds or fails on that journey, which is why AzHeC treats it as a standards-and-connectivity topic rather than a hardware one.
When systems cannot communicate, clinicians end up working across fragmented data and multiple logins — inefficient and error-prone. The goal of well-designed RPM is the opposite: readings that flow automatically and securely into the electronic health record using established data standards, so the home device behaves like any other source of truth in the chart.
Common categories of RPM hardware
RPM devices are best understood by the parameter they capture. The integration questions are similar across categories: how is the reading transmitted, and how does it reach the record?
Vital-sign devices
Blood-pressure cuffs, pulse oximeters, thermometers and connected weight scales — the most common chronic-care monitoring tools, each producing discrete, codeable observations.
How it's recordedContinuous monitors
Devices such as continuous glucose monitors and wearable cardiac patches that stream readings over time rather than capturing a single point — a higher data volume to integrate and interpret.
How devices connectConnected wearables
Consumer and clinical-grade wearables that contribute activity, heart-rate and sleep data, increasingly exchanged through FHIR-based APIs into patient and provider systems.
FHIR primerCellular versus Wi-Fi: the reliability trade-off
How an RPM device gets online materially affects how much data actually arrives. Cellular-enabled devices connect over the mobile network independently of any home internet, which matters in rural and underserved parts of Arizona where broadband is uneven; many can also store readings offline and transmit them once a signal returns, so data is not lost during a coverage gap. Wi-Fi and Bluetooth devices depend on a configured home network or a paired phone, which can lower adherence among older or less technical patients.
The practical consequence is data completeness. A device that quietly drops readings produces a misleadingly sparse picture of a patient's status. AzHeC's neutral framing is simply this: choose the connectivity model that maximises reliable, automatic transmission for the population being served — and validate, with real data, that readings are actually arriving.
From the home to the worklist
An RPM reading travels a defined path before it reaches the clinician who will act on it.
Measure at home
The patient takes a reading on a connected device, which captures the value, time and a device identifier.
Transmit
The reading leaves the home over cellular, Wi-Fi or a paired phone and reaches the RPM platform — buffered and resent if connectivity drops.
Integrate
The platform delivers the data into the EHR, commonly through a FHIR API or an interface engine, matched to the right patient and coded consistently.
Surface to the clinician
The reading appears in a flowsheet or monitoring worklist, where thresholds and trends turn a stream of values into an actionable signal.
Frequently asked questions
01Is cellular always better than Wi-Fi for RPM?
Not universally, but cellular devices tend to be more reliable for populations where home internet is unavailable or hard to configure, because they connect independently and can store-and-forward readings during outages. The right choice depends on the patient population and the level of data completeness the programme needs.
02How does RPM data get into the EHR?
Most RPM platforms integrate with the EHR through modern FHIR APIs or through an interface engine, so readings flow automatically into the record rather than being typed in. The device-to-EHR integration page covers the mechanics, including patient matching and unit validation.
03Does this page recommend RPM products?
No. It describes RPM as a data source and the infrastructure that makes it dependable. It is vendor-neutral and names no products or brands.
Keep going through Connected Devices
Once a reading has left the home, the integration layer decides whether it becomes useful clinical data or noise. See how that works next.