Remote Patient Monitoring Platform Architecture: Devices to Dashboards

Remote patient monitoring is a data pipeline with clinical stakes. Blood pressure cuffs, glucometers, weight scales, and pulse oximeters emit readings; somewhere downstream a nurse decides whether to call a patient. Everything between the device and that decision is the platform, and the quality bar is set by two facts: missed deterioration harms patients, and RPM billing codes require provable data. This post covers the architecture that satisfies both.

Ingestion: three device realities

Device data arrives three ways, and a production platform usually handles all of them:

• Cellular-connected devices (the dominant model for elderly populations) push readings to the manufacturer's cloud, which forwards them via webhook or API. Integration is per-manufacturer: different payloads, different retry behavior, different clock discipline.
• Bluetooth devices pair with a patient app or hub; your mobile app becomes part of the pipeline, with the offline sync and PHI handling from our HIPAA mobile guide.
• Aggregators (Validic, Terra, and manufacturer-neutral platforms) normalize many device brands behind one API for a per-member fee, the same coverage-vs-cost trade as EMR integration platforms in our EMR integration guide.

Whatever the path, normalize at the boundary into a standard observation record. FHIR's Observation resource with LOINC codes is the sensible target: it keeps EHR export straightforward and forces unit discipline (mmHg, mg/dL, kg) at ingestion, where mistakes are cheap to catch.

The observation store

Time-series clinical data has specific requirements that a generic table eventually fails:

• Two timestamps per reading: when measured (device clock) and when received. Cellular devices buffer for hours; a Tuesday reading arriving Thursday must chart on Tuesday and bill on Thursday.
• Provenance per reading: device ID, firmware, transmission path, and whether the value was device-captured or manually entered. Manual entries are clinically useful and billing-suspect; auditors ask.
• Idempotent writes: manufacturer clouds redeliver webhooks. Dedup on (device, measured-at, type, value) or you will chart the same spike twice and alert on it twice.
• Retention that matches the program: years, not months, and exportable per patient for record requests and audits.

Alerting without alert fatigue

The naive design (threshold breach sends notification) collapses in weeks: a nurse monitoring 200 patients cannot process 300 daily pings, and real deterioration drowns. The design that survives:

• Per-patient thresholds set by the care team, not global defaults. A dialysis patient's "normal" weight change is another patient's emergency.
• Trend rules alongside point rules: three-day weight gain matters for heart failure where any single reading is unremarkable.
• A triage queue, not notifications. Alerts land in a worklist ranked by severity and staleness, with acknowledgment, disposition codes, and escalation timers if untouched. Notifications interrupt; queues get worked.
• Missed-transmission alerts. Silence is a signal: the patient who stopped weighing in is often the one deteriorating. Adherence monitoring is also a billing requirement (16 days of readings per 30 for the device-supply codes).

Billing-grade data

RPM programs bill CPT codes with hard evidence requirements: device supply with daily recording capability, 16+ days of readings per 30-day period, and clinician time (20+ minutes monthly) reviewing and managing. The platform must compute these per patient per period from raw data: day counts from measured-at timestamps, time tracking from actual clinician activity in the triage queue with an auditable log. Programs that reconstruct this in spreadsheets at month-end leak revenue and fail audits; programs that compute it continuously surface the patient at 13 days with a week left, while outreach can still fix the month.

Closing the loop with the EHR

Readings, alerts, and monthly summaries belong in the chart. The export surface is typically FHIR Observations plus a monthly summary document, and the escalation workflow should create real work items in the care team's system rather than emails. This is where RPM meets the coordination problem we covered in care coordination platform engineering: the reading is only useful if the right clinician acts on it.

RPM platforms reward unglamorous engineering: idempotent pipelines, honest timestamps, queues that respect human attention, and billing math that survives an audit. If you are building or rescuing one, our healthcare engineering team has shipped the full path from device webhook to reimbursed claim.