AppMatic Tech engineers remote patient monitoring apps for iOS and Android that combine Twilio telehealth video, Bluetooth Low Energy medical device pairing, offline reading queues, and server-side threshold alerting on a Laravel backend, as shipped in Homecare2go and the Capmedic app deployed at Northwestern Medicine. AppMatic Tech is based in Ahmedabad, India.
What makes a remote patient monitoring app hard to build?
A remote patient monitoring (RPM) app is not a standard mobile application. It combines real-time audio/video communication, Bluetooth Low Energy device pairing with medical hardware, live clinical data transmission, and threshold-based alerting, each of which has its own reliability requirements that compound when combined in a single product.
A social video app can tolerate a dropped call frame. An RPM app managing a post-operative patient at home cannot tolerate unreliable video during a clinical consultation, missed BLE readings from a blood pressure cuff, or a data transmission failure that leaves an adverse reading unrecorded.
AppMatic Tech built Homecare2go, an iOS and Android remote patient monitoring platform connecting caregivers and patients through real-time telehealth consultations, vitals tracking, and care coordination, and the Capmedic asthma controller tablet app for a product deployed at Northwestern Medicine. This article documents the architecture decisions that make clinical reliability possible.
How should telehealth video work in an RPM app?
The video consultation layer of an RPM app is the most visible reliability requirement. Call quality, connection stability, and session management under clinical conditions drive the SDK selection.
Server-Side Token Model
The first architecture decision in telehealth video is not which SDK to use; it is how session tokens are generated.
A server-side token model generates short-lived session tokens on the backend and delivers them to the mobile client via an authenticated API call. The client presents the token to the video SDK to join a session. The mobile app never holds the credentials used to generate tokens. This model is required for HIPAA-compliant clinical applications; client-side token generation exposes SDK credentials in the app binary, creates an audit trail gap, and prevents server-side session revocation.
AppMatic Tech selected Twilio for the Homecare2go video layer because Twilio enforces server-side token generation by design. The alternative SDKs evaluated (Agora, Daily.co) offered configurable token models, which creates a deployment risk when the token server implementation is omitted during development.
Twilio's Access Tokens are scoped to a specific Room name, participant identity, and expiry window. The Homecare2go backend generates a token per consultation session, delivers it to the caregiver and patient mobile clients separately, and logs the token issuance in the consultation audit trail.
Network Quality Handling
Clinical consultations must remain functional on residential broadband and mobile data connections, not enterprise network conditions. AppMatic Tech implements adaptive bitrate management in the video layer; Twilio's network quality indicators (1–5 scale per participant) drive real-time UI feedback showing connection quality to both participants.
For connections that degrade below a reliable video threshold, the app's UI surfaces a connection warning before the call drops entirely, giving the clinician a window to switch to an audio-only mode or reschedule.
Call Recording and Audit Trails
Some clinical use cases require consultation recording (with patient consent) for care coordination or medico-legal documentation. Recording is handled server-side; Twilio's composited recording creates a single video file from the multi-participant room rather than requiring the mobile client to capture and upload video from the device. Server-side recording also works when a participant's connection is unstable.
How do RPM apps connect to BLE medical devices?
Remote patient monitoring apps that capture vital signs and clinical measurements from medical devices use BLE as the device-to-phone communication channel. The engineering complexity in this layer is consistently underestimated.
GATT Profile Implementation
BLE medical devices expose their data through GATT profiles, a hierarchy of Services and Characteristics. Each device type has a profile that defines what data is available, how to subscribe to updates, and what format the data arrives in.
Some medical device categories have standardised Bluetooth SIG-defined profiles (Blood Pressure Profile, Heart Rate Profile, Glucose Profile). Others use proprietary GATT profiles that require device-specific implementation against the manufacturer's documentation.
AppMatic Tech implemented the Capmedic BLE integration against the Capmedic device's proprietary GATT profile, subscribing to characteristics that report spirometry readings, inhaler event timestamps, and lung function measurements. Each reading is received as a raw byte array that must be parsed according to the device's protocol specification before the values can be displayed or stored.
Reconnection Handling
BLE connections are not persistent in the way TCP connections are. A user walking out of Bluetooth range, the phone screen turning off, or an iOS background app suspension can all interrupt a BLE connection. An RPM app must implement a reconnection strategy that handles these interruptions without losing readings.
AppMatic Tech's BLE reconnection pattern:
- The app maintains a list of previously paired devices by peripheral UUID.
- On connection loss, the BLE manager starts a scan for the known peripheral UUID.
- On peripheral discovery, the connection is re-established automatically.
- The characteristic subscription is re-registered after reconnection; subscriptions do not persist across connections.
- The app's UI reflects the connection state (connected, scanning, disconnected) with appropriate user messaging.
On iOS, background BLE operations require the bluetooth-central UIBackgroundMode in the app's Info.plist and use of the Core Bluetooth state restoration mechanism to re-establish the BLE manager after the app is suspended and relaunched by the OS.
Data Reliability: Offline Queuing
An RPM app cannot assume continuous network connectivity. A BLE device may be capturing readings while the patient is in a location with poor cellular signal. Readings captured during a connectivity gap must not be lost.
AppMatic Tech implements a local queue for clinical readings: all BLE readings are written to a local SQLite or Core Data store on the device before transmission. A background sync service uploads queued readings when connectivity is available. Readings are removed from the local queue only after a confirmed server-side write. The server-side write confirmation triggers a timestamp update on the reading record so the clinical record reflects the actual capture time, not the upload time.
How do RPM apps transmit readings and raise clinical alerts?
Clinical readings need to reach the backend in near real-time for threshold monitoring and provider alerts. AppMatic Tech uses WebSocket connections (via Socket.io on the Laravel backend) for real-time data delivery rather than polling; readings are pushed to the server immediately on capture rather than batched at intervals.
Threshold-Based Alerting
The clinical alerting layer monitors incoming readings against predefined thresholds per patient:
- Blood oxygen below threshold: escalation alert to care coordinator
- Respiratory rate outside normal range: flag on the patient's dashboard
- Missed reading window (patient has not captured a vitals reading within the expected timeframe): passive alert to the care team
Alert logic runs server-side, not on the device. This is critical: a device that is offline or whose app has been force-closed cannot fire client-side alerts. Server-side threshold monitoring against the stored readings provides consistent alert coverage regardless of device state.
Zone-Based Monitoring
The Capmedic app implements zone-based respiratory monitoring drawn from the asthma management framework:
- Green zone: Peak flow above 80% of personal best. Normal function.
- Yellow zone: Peak flow 50–80% of personal best. Caution, potential early symptoms.
- Red zone: Peak flow below 50% of personal best. Medical attention required.
Zone classification is computed on the device immediately on reading capture and displayed with appropriate colour-coded UI feedback. The raw reading and computed zone classification are both transmitted to the backend for longitudinal tracking.
Why do RPM codebases degrade, and how are they fixed?
One of the most common failure modes in RPM app development is a codebase where multiple teams have independently added features across the video, BLE, and data layers without a unified architecture. AppMatic Tech resolved exactly this pattern on the Homecare2go engagement, an existing codebase where network latency and call quality issues traced directly to conflicting socket connections and competing background tasks from independently developed feature modules.
The resolution involved a codebase audit to map all background processes, socket connections, and data flows; a unified connection manager that owns all network and BLE state; and sequential refactoring of each layer under that manager. The performance issues resolved without rebuilding the application from scratch.
How does AppMatic Tech build remote patient monitoring apps?
AppMatic Tech builds remote patient monitoring applications and clinical mobile tools for healthcare operators and medical device manufacturers. For healthcare delivery examples, see how AppMatic Tech rebuilt the Homecare2go iOS and Android platform, built the Anvahi platform with a practitioner-validated AI transcription pipeline, and delivered the Capmedic asthma controller app for Northwestern Medicine. For related engineering, read FHIR API integration for mobile health apps and BLE vs Wi-Fi vs MQTT for IoT integration. Contact the team at contact@appmatictech.com to discuss the technical requirements of a clinical app project.
Frequently Asked Questions
- How does a remote patient monitoring app avoid losing readings when offline?
- AppMatic Tech writes every BLE reading to a local SQLite or Core Data queue on the device before transmission, and a background sync service uploads queued readings when connectivity returns. A reading leaves the local queue only after a confirmed server-side write, and the clinical record keeps the actual capture time rather than the upload time.
- Should RPM clinical alerts run on the device or the server?
- On the server. A phone that is offline or whose app has been force-closed cannot fire a client-side alert, so AppMatic Tech runs threshold monitoring server-side against stored readings, such as escalating low blood oxygen to a care coordinator or flagging a missed reading window. Server-side alerting gives consistent coverage regardless of device state.
- What compliance documentation does an RPM app need for US deployment?
- It depends on whether the app is classified as a medical device under FDA guidance. Many RPM apps fall under FDA enforcement discretion for software that supports clinical care without being the primary decision-making tool, while clinical decision support tools may need a 510(k) or De Novo pathway. AppMatic Tech advises on the architecture implications of each pathway and recommends a healthcare regulatory consultant for the compliance determination.
- How does BLE integration work when a medical device uses a proprietary protocol?
- A proprietary GATT profile needs the manufacturer's full protocol specification. AppMatic Tech obtains that specification, builds a test harness that logs every characteristic notification in raw form before parsing, and validates parsed values against device-reported reference measurements before production deployment.
- Can one RPM app support multiple BLE medical device types?
- Yes. AppMatic Tech implements a device abstraction layer that maps each supported device's GATT profile to a standard internal reading format. A new device type is added by writing a new GATT profile handler, without changing the rest of the data pipeline.