Remote Patient Monitoring Software: A Development Guide

Remote patient monitoring (RPM) is one of the fastest-growing segments in digital health. The market hit $71B in 2025, driven by aging populations, chronic disease prevalence, and reimbursement expansion (CMS RPM codes 99453, 99454, 99457, 99458). If you're building RPM software - whether as a startup or as a health system extending your digital capabilities - this guide covers the architecture, features, and compliance requirements you need to get right.

Core Architecture

RPM software connects three actors: patients (who generate health data), clinicians (who monitor and respond), and administrators (who manage the program). The architecture must serve all three while maintaining HIPAA compliance at every layer.

System Components

Medical Devices → Gateway (BLE/Cellular) → Data Ingestion API
                                                    ↓
                                           Processing Pipeline
                                           (Validation, Normalization, Alert Rules)
                                                    ↓
                              ┌──────────────────────┼──────────────────────┐
                              ↓                      ↓                      ↓
                     Clinical Dashboard      Patient App              EHR Integration
                     (Alerts, Trends,        (Readings,               (FHIR R4,
                      Messaging)              Education)               HL7v2)
                              ↓
                     Billing Engine
                     (CPT Codes, Time Tracking, Claims)

Data Flow

1. Device reads vitals - Blood pressure cuff takes a reading, glucose meter records a value, pulse oximeter captures SpO2
2. Data transmits - Via Bluetooth to a patient's phone (most common), or via cellular gateway (for less tech-savvy patients)
3. API ingests - Your backend receives the reading with device ID, patient ID, timestamp, and value(s)
4. Pipeline processes - Validate data (is this a physiologically plausible reading?), normalize units, apply alert rules
5. Alerts fire - If a reading crosses a threshold, the clinical team gets notified via dashboard, push notification, or page
6. Clinician reviews - Dashboard shows the alert in context (trend data, patient history, current medications)
7. Response - Clinician acknowledges, contacts patient, adjusts care plan, or escalates

Must-Have Features

Patient-Facing App

Vital sign capture:

• Manual entry (for devices without automatic transmission)
• Bluetooth pairing and automatic sync
• Photo-based capture (for wound monitoring, medication adherence)
• Symptom journals (free text + structured questionnaires)

Patient engagement:

• Daily reminders to take readings (configurable timing)
• Educational content linked to their condition
• Medication reminders (especially for conditions where adherence correlates with readings)
• Secure messaging with care team
• Trend visualization ("your blood pressure this week" - simple, clear charts)

Accessibility requirements:

• Large text support (elderly patient population)
• High contrast mode
• Voice guidance for measurement process
• Multi-language support (critical for diverse patient populations)
• Works on older devices (Android 10+, iOS 14+)

Clinical Dashboard

Alert management:

• Priority-ranked alert queue (critical, urgent, routine)
• Alert grouping by patient (one patient with 5 out-of-range readings = one alert, not five)
• One-click patient context (recent readings, medications, conditions, last contact)
• Bulk acknowledgment for routine alerts
• Configurable alert thresholds per patient (a BP of 150/90 might be concerning for one patient but expected for another)

Population health view:

• Patient panel overview (who needs attention today?)
• Adherence tracking (which patients haven't taken readings?)
• Trending analysis (which patients are deteriorating over the past 2 weeks?)
• Filterable by condition, provider, risk level, last contact date

Communication tools:

• In-app secure messaging (HIPAA-compliant)
• Video visit launcher (integrate with Zoom for Healthcare, Doxy.me, or native)
• Pre-built message templates (common responses to common alerts)
• Automated check-in messages for patients with improving trends

Documentation:

• Clinical notes tied to alert responses
• Auto-generated encounter summaries for billing
• Time tracking for RPM billing codes (16 minutes of clinical time required for 99457)

Device Integration Layer

This is often the most technically challenging component.

Common RPM devices and protocols:

• Blood pressure monitors (Omron, Withings - typically BLE)
• Glucose meters (Dexcom CGM via API, traditional meters via BLE)
• Pulse oximeters (Masimo, Nonin - BLE or proprietary)
• Weight scales (Withings, BodyTrace - BLE or cellular)
• Thermometers (various - BLE)
• Activity trackers (Fitbit/Google, Apple Health - API)

Integration approaches:

1. Direct BLE - Your patient app pairs directly with the device. Most control, most development work, and you're responsible for device-specific quirks.
2. Device manufacturer API - Use Withings API, Dexcom API, etc. Easier integration but depends on manufacturer's API quality and reliability.
3. Health data aggregators - Services like Validic, Human API, or Google Health Connect aggregate data from multiple devices. Fastest path to multi-device support but adds a vendor dependency.
4. Cellular-connected devices - Devices with built-in cellular (like BodyTrace scales) transmit directly to your backend. Best for patients who struggle with Bluetooth pairing. Higher per-device cost.

Recommendation: Start with one device per condition using manufacturer APIs. Expand device support based on patient and clinician feedback. Cellular devices for your least tech-savvy patient segment.

Alert Engine

The alert engine is the clinical brain of your RPM system. Get it wrong and clinicians either drown in false alerts (alert fatigue) or miss genuine deterioration.

Alert logic layers:

1. Absolute thresholds - Reading crosses a fixed boundary (systolic BP > 180 mmHg = critical alert). Simple, necessary, not sufficient.
2. Personalized thresholds - Per-patient boundaries set by the clinician. A patient with well-controlled hypertension on medication might alert at 150/90. A patient with resistant hypertension might alert at 170/100.
3. Trend alerts - Readings are individually normal but trending in a concerning direction. Five consecutive systolic readings increasing by 5+ mmHg each day, even if all are under the threshold.
4. Adherence alerts - Patient hasn't taken a reading in X days. Configurable by condition (daily for heart failure, twice weekly for stable hypertension).
5. Composite alerts - Multiple vitals changing together. Weight increasing + BP increasing + SpO2 decreasing in a heart failure patient = early decompensation signal.

Alert delivery:

• In-dashboard queue (always)
• Push notification to clinician's phone (for critical alerts)
• SMS (as backup for critical alerts)
• Integration with on-call systems (PagerDuty, etc.) for after-hours critical alerts

HIPAA Compliance: Non-Negotiable Requirements

Technical Safeguards

• Encryption - AES-256 at rest, TLS 1.3 in transit. No exceptions.
• Access controls - Role-based access. Nurses see their panel. Doctors see their patients. Admins see de-identified analytics.
• Audit logging - Every access to patient data logged (who, when, what, from where). Retain for 6 years minimum.
• Automatic session timeout - 15 minutes of inactivity on clinical dashboard, 30 minutes on patient app.
• Device authentication - Verify data comes from registered devices only.

Administrative Safeguards

• BAA (Business Associate Agreement) with every vendor that touches PHI - your cloud provider, your analytics tool, your notification service, everything
• Documented security policies and procedures
• Regular risk assessments (annually minimum, after every significant system change)
• Workforce training on HIPAA obligations
• Incident response plan for breaches

Infrastructure Choices

• Cloud: AWS (GovCloud or standard with BAA), Azure (with BAA), Google Cloud (with BAA). All three offer HIPAA-eligible services, but not all services within each platform are covered - verify each service you use.
• Database: Any major database works if encrypted. PostgreSQL with pgcrypto, MongoDB with encryption at rest, or managed services (RDS, Cloud SQL) with encryption enabled.
• Hosting: Dedicated or isolated compute. Avoid shared tenancy if possible. Kubernetes with namespace isolation is acceptable with proper network policies.

EHR Integration

RPM data is most valuable when it flows into the patient's electronic health record. Without EHR integration, clinicians are switching between systems, duplicating documentation, and missing context.

Integration standards:

• FHIR R4 - The modern standard. Most EHR vendors (Epic, Cerner/Oracle Health, athenahealth) support FHIR APIs. Use FHIR Observation resources for vitals, FHIR Communication for messaging.
• HL7v2 - Legacy standard still widely used. You'll encounter ADT messages (patient demographics), ORU messages (results), and ORM messages (orders). Interface engines like Mirth Connect or Rhapsody handle HL7v2 translation.
• Direct integration - Epic App Orchard, Cerner App Gallery, and similar marketplaces provide pre-built integration pathways. Certification takes time (3-6 months) but dramatically simplifies sales into health systems.

What to integrate:

• Patient demographics (pull from EHR - single source of truth)
• Vital sign readings (push to EHR as observations)
• Clinical notes (push encounter summaries)
• Alerts and responses (push as communication records)
• Billing data (push encounter records for claims)

Billing Engine

RPM reimbursement is what makes the business model work. CMS RPM codes:

Your billing engine needs:

• Automatic tracking of transmission days (for 99454 - must verify 16+ days of device data)
• Time tracking for clinical staff interactions (for 99457/99458 - must document minutes)
• Eligibility verification per patient per period
• Claims generation in 837P format or integration with practice management/billing systems
• Audit trail for every billing event

Development Timeline

For a team of 4-5 engineers:

At 1Raft, we've built healthcare technology including patient monitoring platforms and clinical workflow tools. RPM is complex but well-understood - the architecture patterns are proven, and the reimbursement model makes the business case straightforward. For AI-powered alert engines, see our AI product engineering services. If you're planning an RPM build, our team can help you work through the clinical, technical, and compliance dimensions.