RPM Technology Stack: What Health IT Teams Need to Know

The RPM technology stack health IT teams choose now has a direct effect on whether remote monitoring becomes a scalable clinical service or just another disconnected data feed. That sounds obvious, but the architecture question keeps getting underestimated. Device selection gets attention. Reimbursement gets attention. The harder problem is everything in between: ingestion, normalization, patient identity, alert routing, EHR writeback, audit controls, and the reporting layer that operations teams actually need. As home-based care expands, the stack matters more than the device.

"Up to $265 billion worth of healthcare services for Medicare fee-for-service and Medicare Advantage beneficiaries could shift from traditional facilities to the home by 2025." - Pooja Kumar, Oleg Bestsennyy, and David Edelman, McKinsey

RPM technology stack architecture in practice

A usable RPM stack is usually not one product. It is a connected set of layers, each with its own owner, failure modes, and integration burden.

At the edge, the stack starts with data capture. That may be a connected blood pressure cuff, pulse oximeter, scale, thermometer, or a camera-based vitals workflow on a smartphone or tablet. The next layer is the collection interface: mobile app, patient portal, or embedded telehealth workflow. After that comes the ingestion and normalization layer, where raw readings are timestamped, linked to the right patient, checked for completeness, and mapped into a standard clinical structure.

For many health IT teams, this is where the real work begins. HL7's Personal Health Device implementation guidance treats the Observation resource as the core unit for device-generated readings, which makes sense. But getting from a reading on a phone to an Observation that is usable inside an EHR is rarely automatic. Identity matching, unit normalization, device provenance, encounter context, and threshold logic all have to be decided somewhere in the architecture.

Core layers in a modern RPM stack

Stack layer	What it does	Common health IT concern	Why it matters
Data capture layer	Collects vitals from devices, apps, or camera workflows	Device variability, patient usability	Bad capture quality creates bad downstream data
Ingestion layer	Receives readings and metadata	API reliability, queue handling, retries	Prevents data loss during peak volume
Normalization layer	Maps readings to standard units and codes	LOINC/UCUM mapping, patient matching	Makes data clinically interpretable
Rules and orchestration layer	Applies thresholds, escalation logic, and routing	Alert fatigue, workflow ownership	Determines whether staff can act on data
Interoperability layer	Writes or exposes data to EHRs and partner systems	FHIR support, HL7 v2 fallback, vendor API limits	Connects RPM to the real care workflow
Application layer	Dashboards, care management tools, billing support	UX, reporting, user roles	Drives daily operational use
Governance and security layer	Consent, audit trails, retention, access controls	HIPAA, BAAs, breach response	Keeps the program enterprise-ready

That table looks neat on paper. In production, the trouble usually comes from the handoffs between layers, not the layers themselves.

Where health IT teams usually get stuck

Most RPM projects run into one of four architecture problems.

• The monitoring data lands in a vendor dashboard but never becomes part of the EHR workflow.
• Alert logic is built before data quality rules are stable, so clinicians stop trusting what they see.
• The implementation assumes one vendor and breaks down when a second device source is added.
• Reporting is treated as an afterthought, which leaves operations without a clean way to track utilization, documentation, or staffing load.

Jennifer Claggett, Stacie Petter, Amol Joshi, Todd Ponzio, and Eric Kirkendall described this problem well in their 2024 paper on an infrastructure framework for remote patient monitoring interventions and research. Their point was simple: RPM is not just a device program. It is an infrastructure program with interacting technical, workflow, and organizational components. That framing is useful because it shifts the discussion away from isolated features and toward system design.

The interoperability question is still central

A lot of teams now treat FHIR support as a basic requirement, and they should. But "supports FHIR" can mean almost anything. S. M. R. Islam, M. M. Rahman, M. A. Hossain, and M. A. Khan noted in their JAMIA Open scoping review that real-world FHIR implementations vary widely in scope and maturity. In other words, the label alone tells you very little.

For RPM programs, the practical questions are narrower:

• Can the platform write standardized Observation resources?
• Can it preserve device provenance and collection timestamps?
• Can it support event-driven routing, not just scheduled exports?
• Can it coexist with HL7 v2 or flowsheet-based workflows where the EHR still depends on them?

Those questions matter more than glossy architecture diagrams.

Industry applications by workflow model

EHR-centered RPM programs

In an EHR-centered model, the stack is built to make the chart the source of truth. The RPM platform handles collection and orchestration, but the long-term record and clinician workflow sit inside the EHR. This model usually works best for large health systems that want RPM tightly connected to ambulatory care, case management, and documentation.

The upside is cleaner clinician adoption. The downside is integration complexity, especially when writeback patterns differ by department or site.

Telehealth-first programs

Some organizations start the other way around. They embed vitals capture in virtual visit workflows first, then decide which parts need to flow into the longitudinal record. This model is often faster to launch, particularly when the telehealth team owns the workflow and the use case is episodic triage rather than longitudinal monitoring.

That said, telehealth-first architectures can become messy if they are later stretched into enterprise RPM without a stronger normalization layer.

Multi-vendor enterprise environments

This is where stack design gets serious. Once a health system supports more than one device source, one care management team, or more than one intake path, point integrations start to pile up. A centralized ingestion and reconciliation layer becomes far more valuable than another dashboard.

This is also where standards work pays off. The HL7 Personal Health Device guidance, CMS billing rules, and internal reporting needs all push in the same direction: preserve structured data, timestamps, and provenance early so the rest of the stack does not have to reconstruct them later.

Current research and evidence

The best recent evidence does not argue for one universal RPM architecture. It argues for modularity.

Claggett and colleagues' 2024 infrastructure framework paper makes the case that RPM programs should be evaluated as a combination of technical infrastructure, operational workflow, and organizational support, not as a simple device deployment. That is a healthy correction. Plenty of remote monitoring programs fail because the stack was designed for data capture without enough attention to escalation ownership or integration maintenance.

The 2023 JAMIA Open scoping review by Islam, Rahman, Hossain, and Khan reached a related conclusion in the FHIR world. Real deployments use FHIR in uneven ways, which means health IT teams still need to examine what part of the stack is truly standards-based and what part remains custom. If a vendor says the system is interoperable, ask exactly which resources, triggers, profiles, and writeback patterns are working in production.

McKinsey's analysis by Kumar, Bestsennyy, and Edelman adds the market context. If care continues shifting into the home at the scale they project, the burden on RPM infrastructure will rise with it. A stack that works for a pilot of 300 patients may not survive when the program spans service lines, care managers, and multiple intake channels.

CMS policy also shapes the stack more than vendors like to admit. The continued use of RPM billing codes 99453, 99454, 99457, and 99458 means the architecture has to support traceable setup, transmission cadence, and documented management time. That turns reporting and auditability into stack requirements, not optional extras.

The future of RPM technology stack design

The next generation of RPM stacks will probably look less like monolithic monitoring platforms and more like composable health IT infrastructure.

A few shifts seem likely:

• More event-driven architectures, especially where alerting and triage need lower latency
• Broader use of FHIR-native or FHIR-friendly middleware rather than custom per-vendor mappings
• More convergence between telehealth intake, asynchronous monitoring, and population health analytics
• Stronger enterprise controls around provenance, access, and retention as home-based care scales

I also think health systems will get less patient with black-box workflow layers. Once RPM moves beyond a pilot, operations teams want to know where data is, who touched it, and why an alert fired. That is not a nice-to-have. It is basic program survivability.

If there is one design principle worth keeping, it is this: buy flexibility at the normalization and orchestration layers. Devices will change. Care pathways will change. EHR capabilities will change more slowly than everyone hopes. The middle of the stack has to absorb that instability.

Frequently asked questions

What belongs in an RPM technology stack?

A complete RPM stack usually includes data capture, ingestion, normalization, rules orchestration, interoperability services, dashboards or care management tools, and governance controls. Leaving out any of those layers usually pushes the work onto manual staff processes.

Is FHIR enough for RPM integration?

No. FHIR is important, especially for Observation-based data exchange, but it does not solve identity matching, workflow routing, alert design, or reporting by itself. Teams still need operational architecture around the standard.

Should health IT teams prefer one RPM vendor or a modular stack?

It depends on scale. A single-vendor platform may be fine for a narrow deployment. Enterprise programs usually benefit from a more modular approach because multi-vendor data, departmental variation, and reporting demands show up quickly.

Why does the rules engine matter so much in RPM?

Because the rules engine decides what becomes actionable. Poor threshold logic creates noise. Clean routing, escalation logic, and suppression rules make the difference between a trusted workflow and alert fatigue.

---

Health IT teams planning RPM architecture often start with standards and workflow integration questions, then work backward into platform selection. For organizations exploring how contactless vitals and telehealth workflows fit into that stack, Circadify's telehealth solution overview offers a useful starting point. Related reading on this site: What Is HL7 FHIR? RPM Implementation Guide for Health IT and Interoperability Standards for Remote Monitoring Data: Overview.