Remote Patient Monitoring Systems: Architecture Decisions for Scalable IoT Health Data

TL;DR: Remote patient monitoring (RPM) looks simple on a slide: a device takes a reading, the reading reaches a clinician, the clinician acts. In production, it is a distributed system that has to handle unreliable home connectivity, dozens of device types, bursts of data, alert fatigue, strict privacy rules, EHR integration and increasingly detailed billing and audit requirements. This guide walks through the architecture decisions that determine whether an RPM programme scales from a pilot of a few hundred patients to tens of thousands: device connectivity, ingestion, data modelling with FHIR, alerting and triage, clinical workflow, EHR integration, security and compliance, and the data you need to prove the service was actually delivered.

Why RPM architecture matters more now

Remote monitoring has moved from a pandemic-era experiment to a routine part of chronic care management. In the United States, the HHS Office of Inspector General reported that Medicare payments for RPM, across Original Medicare and Medicare Advantage, rose to about $536 million in 2024, with close to a million enrollees receiving the service. Programmes are growing in other markets too, including home-care and post-discharge monitoring in India, the Middle East and Europe.

Growth has brought scrutiny. OIG reviews have raised concerns that many enrollees did not receive all components of RPM (setup and education, device supply and treatment management), and that oversight bodies often lacked basic information about which devices were used and what data was collected. At the same time, the 2026 US Physician Fee Schedule introduced new codes for shorter monitoring periods (CPT 99445 for 2–15 days of device supply in a 30-day period) and shorter management time (CPT 99470 for the first 10 minutes). Both changes increase the importance of precise, auditable data about readings, days of transmission and clinician time.

The upshot for healthcare providers and digital health companies is that RPM software is no longer just a data pipe. It is clinical infrastructure and a compliance record at the same time.

The reference architecture at a glance

A scalable RPM platform typically has seven layers:

1. Devices and connectivity — Blood pressure cuffs, glucometers, pulse oximeters, weight scales, ECG patches, continuous glucose monitors and wearables.
2. Gateways — Smartphone apps, dedicated hubs or cellular-enabled devices that relay readings to the cloud.
3. Ingestion — Authenticated endpoints and message brokers that receive readings reliably, including delayed and duplicated data.
4. Normalisation and storage — Transformation into a common clinical data model (increasingly FHIR) and storage in both operational and analytical stores.
5. Rules, alerting and triage — Threshold, trend and model-based logic that decides which readings need human attention.
6. Clinical workflow — Care-team dashboards, task queues, patient communication, documentation and time tracking.
7. Integration and reporting — EHR write-back, billing data, programme analytics and audit trails.

Each layer involves decisions that are hard to reverse later. The sections below take them in turn.

Decision 1: Device strategy and connectivity

Bluetooth vs cellular

Most consumer-grade medical devices use Bluetooth Low Energy and cannot reach the internet on their own. They need a gateway, usually the patient's smartphone or a dedicated hub. Cellular-enabled devices send data directly over mobile networks and need no pairing.

The right answer often differs by patient cohort, so design the platform to support more than one connectivity model.

Vendor clouds vs direct device integration

Many device manufacturers route readings through their own cloud and expose an API or webhook. This is quick to integrate but adds latency, a dependency on the vendor's uptime and a second copy of patient data outside your control. Direct integration gives more control but requires device-level SDK work and more certification effort. A pragmatic approach is an abstraction layer with a common internal interface, so you can swap or add device vendors without touching downstream systems.

Device lifecycle management

At scale, device logistics become a software problem: inventory, assignment to patients, shipping, activation, battery and firmware status, returns and refurbishment. These records also matter for billing and audit, because they prove which device was supplied to which patient and when.

Decision 2: Ingestion that tolerates the real world

Home monitoring data is messy. Patients take readings without connectivity and devices sync hours later. Gateways retry and send duplicates. Clocks drift. Some devices batch a week of readings at once.

A robust ingestion layer should:

• Separate measurement time from receipt time. Every reading needs both timestamps; clinical logic uses measurement time, while operational monitoring uses receipt time.
• Be idempotent. Use device identifiers and reading timestamps to deduplicate retries.
• Buffer bursts. A message broker or streaming platform between ingestion and processing absorbs spikes when many devices sync at once, for example after a network outage.
• Validate early. Reject or quarantine physiologically impossible values and malformed payloads before they reach clinicians.
• Record provenance. Store which device, firmware version, gateway and vendor API produced each reading.

Managed IoT services from cloud providers can handle device identity, secure connections and message routing. For programmes that mainly integrate vendor clouds, a set of webhook receivers feeding a message queue may be enough. The choice depends on how many devices you manage directly.

Decision 3: Data modelling with FHIR

Why FHIR is the default

HL7 FHIR has become the default data model for exchanging clinical data, and it maps naturally to RPM. The core resources are:

• Patient — Who is being monitored
• Device — What device produced the data, with identifiers and status
• Observation — Each measurement, coded with LOINC (for example, systolic and diastolic blood pressure, heart rate, body weight, SpO2)
• CarePlan and Goal — Target ranges and monitoring plans
• Task and Communication — Follow-up actions and patient contact
• Flag or DetectedIssue — Alert conditions

Modelling RPM data as FHIR R4 resources from the beginning makes EHR integration, analytics and future interoperability much easier than retrofitting later.

Operational store vs analytical store

Do not force every reading into a FHIR server and query it for everything. A common pattern is:

• A time-series or document store optimised for high-volume readings and fast trend queries
• A FHIR layer for clinically relevant, summarised or reviewed observations that need to be exchanged
• An analytical warehouse for programme reporting, outcomes analysis and model training

Don't flood the EHR

Writing every raw reading into the EHR overwhelms the chart and clinicians. Most programmes write summaries, reviewed abnormal readings and care-management notes, and keep full-resolution data in the RPM platform with a link or embedded view from the EHR.

Decision 4: Alerting and triage without alert fatigue

Alerting is where RPM programmes succeed or fail clinically. Too many alerts and nurses stop reading them; too few and deterioration is missed.

Layer the logic

1. Absolute thresholds — Readings outside safe ranges, such as a very high blood pressure, trigger immediate alerts.
2. Personalised thresholds — Ranges configured per patient in the care plan, reflecting baseline and conditions.
3. Trends — Sustained changes over days, such as weight gain in heart failure patients, which can be more meaningful than any single reading.
4. Adherence alerts — Missing readings, which can signal device problems, disengagement or deterioration.
5. Model-based risk scores — Predictive models that combine several signals. These should support, not replace, clinical judgement, and fall under the same governance as other clinical decision support tools.

Structure every alert

Each alert should carry a clear owner, priority, reason, patient context, recommended next action, due time, escalation rule and resolution state. Keep clinical alerts, operational alerts (a device offline, a battery low) and technical alerts (an ingestion failure) in separate streams so clinicians only see what needs clinical attention.

Measure alert quality

Track alert volume per patient per week, the proportion of alerts that lead to a clinical action, time to acknowledgement and resolution, and overrides. Review thresholds regularly with clinical leads. Alert logic should be versioned and changes documented, because it is effectively part of the clinical protocol.

Decision 5: Clinical workflow and time tracking

Care-team experience

Nurses and care coordinators spend their day in the RPM dashboard. It should show:

• A prioritised worklist of patients needing attention
• Trends and context for each patient on one screen
• One-click patient contact through phone, video or secure messaging
• Structured documentation of interventions
• Hand-offs between team members and shifts

Integration with telemedicine tools matters, because many interventions end in a video or audio consultation.

Time and interaction tracking

Reimbursement models in several markets depend on clinician time and interactive communication. In the US, treatment management codes are billed based on time spent in a calendar month, and CPT 99470 requires at least one real-time interactive communication with the patient or caregiver. Your platform should capture time and interaction data automatically as part of the workflow, not as a separate manual log, and should make it easy to show which activities that time covered.

Decision 6: EHR and ecosystem integration

RPM rarely lives alone. Common integrations include:

• EHR — Patient demographics, problem lists, medications, orders and write-back of summaries and notes, through FHIR APIs where available and HL7 v2 interfaces where not
• Practice management and billing — Structured data on device days, time and services delivered
• Patient communication platforms — SMS, voice and app notifications
• Pharmacy and lab systems — For medication adherence and results context
• Population health and analytics tools — For programme outcomes

Plan for identity matching across systems. Mismatched patient identifiers between the RPM platform and the EHR are a common and dangerous source of errors.

Decision 7: Security, privacy and compliance

RPM platforms handle continuous streams of health data from devices in patients' homes, which widens the attack surface.

Core controls

• Device identity and authentication. Each device or gateway should authenticate with unique credentials or certificates; shared keys across devices are a serious risk.
• Encryption. In transit between device, gateway and cloud, and at rest in every store.
• Least-privilege access. Care-team members see only their assigned patients; support staff see device status without clinical data where possible.
• Audit logging. Every access to patient data and every change to thresholds, alerts and documentation.
• Data residency. Store data in the jurisdictions required by local law and customer contracts.

Regulatory frameworks

Depending on your market, you may need to address HIPAA in the US, GDPR in Europe, India's Digital Personal Data Protection Act, and medical device regulations if your software makes diagnostic or treatment recommendations. Software that goes beyond displaying readings, such as algorithms that recommend interventions, may fall under software as a medical device (SaMD) rules. Determine this early with regulatory advisors, because it affects design, documentation and testing.

Scaling: from pilot to programme

Pilots often run on architectures that do not survive growth. The main scaling pressures are:

Build vs buy vs platform-plus-custom

Several commercial RPM platforms exist, and for straightforward programmes they may be the fastest route. Custom development tends to make sense when:

• You serve populations or markets that commercial platforms do not support well
• You need to integrate unusual devices, EHRs or regional systems
• RPM is central to your product or care model, not an add-on
• You want to own the data model and analytics for research or value-based contracts
• You need workflows specific to your clinical protocols

A common middle path is to use a commercial device-integration layer or cloud IoT service, and build the clinical workflow, alerting and integration layers that differentiate your programme.

Implementation checklist

• [ ] Device strategy defined per patient cohort (smartphone, hub or cellular)
• [ ] Device abstraction layer to support multiple vendors
• [ ] Idempotent ingestion with measurement and receipt timestamps
• [ ] FHIR-based data model with LOINC coding
• [ ] Separate operational, FHIR and analytical stores
• [ ] Layered alert logic with versioning and clinical sign-off
• [ ] Separate clinical, operational and technical alert streams
• [ ] Prioritised care-team worklist and integrated patient communication
• [ ] Automatic capture of time, interactions and device days
• [ ] EHR integration strategy with identity matching
• [ ] Device authentication, encryption, audit logs and data residency
• [ ] Regulatory assessment for SaMD and local privacy law

How Syslabs helps

Syslabs designs and builds custom healthcare software for providers, home-care operators and digital health companies, including RPM platforms, device integrations, care-team applications and EHR connectivity. Our IoT solutions practice handles device connectivity and ingestion, while our healthcare teams build the clinical workflow, FHIR-based data models, alerting and reporting layers on top. We also help teams extend RPM with clinical decision support and integrate it with existing patient engagement and telehealth systems.

Conclusion

RPM programmes scale when their software treats every reading as both clinical data and evidence: data that must reach the right clinician at the right time, and evidence that the service was delivered as documented. The architecture decisions that matter most (device strategy, resilient ingestion, a FHIR-based data model, disciplined alerting, workflow-embedded time tracking, EHR integration and strong security) are much cheaper to get right at the design stage than to fix after the programme has grown.

If you are planning a new RPM programme or struggling to scale an existing one, Syslabs can review your architecture and help you design a platform that grows with your patient population. Book a consultation with our healthcare team.

Sources

• HHS Office of Inspector General, Additional Oversight of Remote Patient Monitoring in Medicare Is Needed (OEI-02-23-00260) and subsequent 2025 data brief on RPM use and payments
• Centers for Medicare & Medicaid Services, CY 2026 Physician Fee Schedule Final Rule (new RPM codes 99445 and 99470), as summarised by industry billing guides
• HL7 International, FHIR R4 specification (Observation, Device, CarePlan resources)
• Regenstrief Institute, LOINC coding system
• Microsoft Learn, Azure IoT and MedTech service documentation (device-to-FHIR patterns)