Remote patient monitoring analytics
We build the data layer behind remote patient monitoring programs: pipelines that take readings from cellular hubs, Bluetooth apps and device clouds, normalize them to FHIR Observation with LOINC codes and UCUM units, and land them in an analytics warehouse. On top we build adherence tracking against the 16-day and 2 to 15 day billing thresholds, alert burden reporting, care team worklists and population dashboards for blood pressure, glucose, weight and oxygen saturation.
Scope your RPM analytics platformFor RPM companies, provider groups and care management organizations with device data they cannot yet trust or act on. Updated September 26, 2026.
Hub, app and vendor cloud feeds with source and transmission time kept
FHIR Observation with LOINC codes, UCUM units and device links
Duplicates, gaps, late arrivals and out-of-range values flagged
Adherence, alerts, worklists and population dashboards
Illustrative workflow · scope tailored to your environment
The short answer
RPM data analytics is the pipeline and reporting layer that turns remote monitoring readings into decisions. It ingests readings from every device source, normalizes them to one model (FHIR Observation with LOINC codes such as 8480-6 and 8462-4 for blood pressure), checks data quality, and then answers four questions: which patients are transmitting enough to stay on track for 16 days, which readings need a clinician now, how much alert load each care team carries, and how the monitored population is doing over time. We build it on your existing warehouse or a new one, with every figure traceable to the readings behind it.
Read our RPM data pipeline guide: device to FHIR Observation to alertStart with the real problem
An empty chart can mean the patient stopped measuring, the hub lost signal, the device was never assigned or the vendor feed is late. A falling average can mean patients improved or the sickest ones stopped transmitting. Care teams drown in threshold alerts on readings that were taken wrong, while patients drifting below 16 days go unnoticed until the period closes. The fix is a data model that keeps source, device, transmission time and quality on every reading, and metrics whose denominators are written down.
What we build
Programs usually start with the pipeline and adherence, then add alerting and population reporting. Each item runs on the same normalized reading store.
Connectors for cellular hubs, Bluetooth apps and device vendor clouds, with deduplication, patient and device matching, and a dead-letter queue for readings that cannot be placed.
Medical device integrationEvery reading stored as a FHIR R4 Observation linked to Patient and Device, with the original vendor payload preserved for audit.
FHIR integration servicesA running count of reading days per patient per 30-day period, with outreach lists for patients at risk of falling short and a view of who will land in the 16-day or the 2 to 15 day code.
RPM billing softwareClinician-approved thresholds per patient or cohort, trend and rate-of-change rules, and reporting on alerts per patient, time to acknowledgment and alerts closed without action.
Why clinicians ignore RPM alerts, and how to fix itProgram views by condition, clinic, payer and enrollment cohort: blood pressure control, glucose ranges, weight change for heart failure, enrollment and disenrollment, with the denominator shown on every chart.
Healthcare data engineeringWarehouse models for readings, periods, minutes, alerts and claims, plus write-back of summaries and flagged readings to the EHR.
EHR and EMR integration servicesYour starting point
Your program uses two or three device vendors and each has its own portal. We build one pipeline and one reading model so care teams see every patient in one place, whatever device they use.
Care teams receive more alerts than they can review. We measure alert burden by rule and cohort, remove invalid and repeat alerts, and give clinicians per-patient thresholds they can tune with an audit trail.
You need to show enrollment, adherence and control rates by cohort. We define the metrics with your clinical and finance leads and build dashboards that trace every number back to readings.
The Engineering Engagement
Workstreams are selected around your priorities. Each comes with an output your team can inspect, test and own.
List every device, hub, app and vendor cloud, agree the payload and transmission time for each, and build connectors with retries, deduplication and a dead-letter queue.
Map readings to FHIR Observation with LOINC and UCUM, link each to the right patient and device assignment, and keep the original payload.
Flag physiologically implausible values, duplicate readings, clock drift and gaps, and keep technical rejection separate from a valid but clinically unusual reading.
Count reading days per 30-day period and minutes per calendar month, and publish outreach lists for patients at risk of missing a threshold.
Implement clinician-approved thresholds and trend rules, route alerts to the right care team, and record acknowledgment and disposition.
Model readings, periods, alerts, minutes and claims in the warehouse, build dashboards, and restrict patient-level drilldown by role.
Compare your options
The right choice depends on how many device sources you have and whether analytics is part of the product you sell.
| Device vendor dashboards | BI tool on exported files | Custom RPM analytics platform | |
|---|---|---|---|
| Best for | One vendor, one small program | Monthly leadership reporting | Multi-vendor programs and RPM products |
| Device sources | One vendor each | Whatever is exported | Every source in one reading model |
| Data quality | Vendor-defined | Manual cleanup | Rules per source with a review queue |
| Adherence and billing thresholds | Per vendor, calendar based | Rebuilt by hand each month | Live day counts per 30-day period |
| Clinical alerts | Vendor thresholds | Not real time | Clinician-approved rules with burden reporting |
| Data ownership | In the vendor portal | Copies in spreadsheets | In your warehouse, with lineage |
Most programs keep vendor portals for device support and move analytics into their own warehouse once a second vendor arrives.
Expertise is in the decisions
Billing day counts use the day data was transmitted; clinical trends use the time it was measured. Store both on every Observation and state which one each metric uses.
Rules can run in the device vendor platform, the RPM application or the analytics layer. Pick one owner per rule so a threshold change reaches every patient, and version it with the approving clinician.
Alerting needs readings within minutes; population dashboards can run daily. Streaming everything costs more than it returns, so we split the two paths and show last-update time on every view.
Enrolled, active, transmitting and billable are four different populations. Every program metric names its denominator so a change in who is counted is never read as a change in health.
Alert thresholds, review urgency and interventions are set by your clinical leads. We implement, version and test the approved rules and report how they perform.
When a risk model is in scope, we define its intended use, evaluation population and monitoring plan with your clinical owners before it drives a worklist.
Timeline
The number of device sources and the state of existing data set the schedule more than the number of dashboards.
Review de-identified sample readings, device assignments, feed timing and current reports.
Connectors, FHIR Observation mapping and quality rules for the priority sources.
Day counts, outreach lists, alert rules and burden reporting.
Warehouse models, metric catalog, dashboards and EHR write-back.
Delivered work
Client names are withheld; each is a real engagement. Our open-source FHIR work is public on GitHub.
Blood pressure, pulse and oxygen readings from connected instruments captured into a durable, linkable patient record across a large network of rural clinics, correct offline and reconciled on reconnect.
Patients report pain location, character and impact on sleep, mood and work; clinicians review weeks of outcomes in one trend view and adjust the plan.
Deployment, integration, access governance and observability for a clinical data repository used for cohort discovery and export to FHIR or openEHR.
A headless EHR with a FHIR R4 API and SMART App Launch that passed all 47 tests in the ONC (g)(10) SMART App Launch Standalone Patient App suite in Inferno on October 27, 2026.
From discussion to delivery
Sources, sample payloads, device assignments and current metrics reviewed and written down.
Payload contracts and test fixtures for complete, missing, duplicate, late and invalid readings.
Working pipelines and views every two weeks, tested against real device payloads.
Freshness monitoring, metric change review and a runbook for investigating bad signals.
We agree the scope, dependencies, acceptance criteria and commercial model before implementation. Your existing team can stay involved throughout.
Find the right starting point ↓It is the pipeline and reporting layer of a remote patient monitoring program. It collects readings from every device source, normalizes and quality-checks them, tracks adherence against billing thresholds, runs clinical alert rules and reports on the monitored population, with every figure traceable to the readings behind it.
We build a connector per source: vendor cloud APIs and webhooks, cellular hubs, and Bluetooth devices through a patient app using Apple HealthKit or Android Health Connect. Each connector deduplicates readings, matches them to the patient's device assignment and writes them to one reading store with the source and transmission time kept.
FHIR Observation is the standard the EHR already understands. With LOINC codes (8480-6 and 8462-4 for blood pressure, 29463-7 for weight, 59408-5 for oxygen saturation) and UCUM units, readings from any device mean the same thing in your platform, your warehouse and the patient's chart, and write-back to the EHR needs no extra translation.
We count unique days with transmitted data per patient per 30-day device period, because that is how 99454 (16 or more days) and 99445 (2 to 15 days) are billed. Care teams see a running count and an outreach list of patients who will fall short unless they measure in the next few days.
We measure alert burden first: alerts per patient per month, time to acknowledgment, and alerts closed without action, by rule and cohort. Then we remove invalid and repeat readings before they alert, move to per-patient thresholds approved by clinicians, add trend rules, and track the effect of each change.
Enrollment and active patients, adherence by period, readings in and out of range by condition (for example blood pressure control for hypertension or weight change for heart failure), alerts and response times, minutes of management and billed codes, filterable by clinic, payer, device and cohort, with denominators shown.
Yes. We work with Snowflake, BigQuery, Databricks, Redshift and Postgres, and model the data with dbt. We review your orchestration, access controls and data contracts first and add only what is missing.
Yes. We write readings or summaries back as FHIR Observation or as a DocumentReference note, or as HL7 v2 ORU messages where the EHR prefers them. Write-back is scoped per EHR because Epic, Oracle Health and athenahealth each expose different write APIs.
Yes, for a defined use such as flagging heart failure patients with rising weight. We check that the data supports the model, agree the intended use and evaluation with clinical owners, and monitor the model after launch.
A first trusted pipeline with adherence tracking for the priority device sources is planned in weeks after the signal audit. Alerting, population dashboards and EHR write-back follow in phases, and EHR vendor access is started at kickoff.
Cost depends on the number of device sources, the state of the existing data, alerting needs, warehouse choice and EHR write-back. We give a fixed-scope estimate after the signal audit, broken down by source and module.
Yes. We sign BAAs and we are ISO 27001:2022 certified. Development runs on de-identified fixtures, patient-level drilldown is restricted by role, and every access is logged.
A useful first conversation
Tell us what exists today, who uses it and where the workflow breaks. We’ll discuss the scope, access dependencies and the next practical step.
A product overview and a de-identified workflow are enough to start. No patient records or credentials are needed.
These are independent reference sources, not endorsements. Applicability, platform access and current requirements are confirmed for your project.
