Remote patient monitoring & wearable analytics

Patients with heart failure, hypertension, COPD, diabetes or a recent hospital stay generate health signals at home that nobody watches between visits. Remote patient monitoring (RPM) collects readings from connected devices and wearables, uses time-series models to separate real deterioration from noise, and gives a small care team a ranked list of who needs a call today. The aim is earlier intervention and fewer avoidable admissions, not replacing clinicians.

Problem & value

• Today: chronic patients are seen every few months; home readings are noted on paper or ignored. Threshold-only alerts (e.g. "weight +2 kg") produce many false alarms and alert fatigue.
• AI value: personalised baselines, multi-signal trend detection, artefact rejection (loose electrode, missed wear time), and triage ranking so nurses spend time on the few patients at risk. LLMs add patient-friendly summaries, questionnaire dialogue and clinician reports.
• Evidence: the German TIM-HF2 trial reported fewer days lost to unplanned cardiovascular hospitalisation or death with structured telemonitoring in heart failure; results for other conditions and for purely wearable-based algorithms are mixed, so value depends on the care process wrapped around the data [1][2].
• Reimbursement: Germany reimburses telemonitoring in heart failure via the statutory scheme and lists DiGA (prescribable digital health apps) in the BfArM directory, which gives a commercial path for some products [3].

Variants

• Chronic disease programmes: heart failure, hypertension, COPD, CKD (clinic- or insurer-run).
• Post-discharge / hospital-at-home: 30-day monitoring after surgery or acute episodes.
• Cardiac rhythm screening: wearable or patch ECG for atrial fibrillation → see HLTH-013.
• Diabetes: continuous glucose data and insulin dosing → HLTH-034 (higher risk class).
• Elderly care / ambient assisted living: → HLTH-015, CONV-016.
• Clinical trials (decentralised): wearable endpoints, digital biomarkers.
• Consumer wellbeing (private use): smartwatch trends and sleep insights; typically a wellness product, not a medical device, unless it claims diagnosis or monitoring of disease.

How it works

1. device/wearable (BLE)
2. phone app or gateway (LTE hub)
3. ingestion (HL7 FHIR Observation / IEEE 11073 / Open mHealth, vendor APIs)
4. quality filter (wear time, artefacts, plausibility)
5. personal baseline + trend models (time-series, anomaly detection)
6. risk score (gradient boosting / sequence model with EHR context)
7. alert engine (severity, rules, escalation policy)
8. clinician worklist
9. call / visit / medication change (human decision)
10. documentation + billing record, feedback labels for model improvement

• Edge/phone: on-device filtering and simple detection (Core ML, TFLite, ONNX) saves battery and bandwidth and keeps raw data local.
• Models: per-patient baselines with change-point detection, gradient-boosted trees on engineered features (often strongest on small tabular data), and sequence models or time-series foundation models (e.g. Chronos, TimesFM, Moirai) for forecasting and imputation.
• LLM layer: summarises the week for patient and clinician, runs symptom check-ins; it never decides on therapy or sets alert thresholds on its own.
• Human-in-the-loop: a clinician owns the care plan, alert thresholds per patient and every escalation; nurses acknowledge and document each alert. Patients get clear instructions for emergencies (the system is not an emergency service).

Data preparation

Data comes from wearables, home devices (blood pressure, glucose, ECG patches), patient apps and questionnaires, and must be combined with the EHR and care plans. Sources are vendor clouds and device APIs more than in-house systems.

Typical gaps: different vendors with different formats and sampling rates, gaps from devices not worn or not charged, motion artefacts, missing patient-device assignments, no baseline per patient, inconsistent time stamps, and unclear consent per data stream.

Preparation steps: 1. Inventory devices and data streams and map them to the monitoring goals (PREP-002). 2. Connect via vendor APIs or standards such as FHIR and Bluetooth gateways (PREP-005, DATA-007). 3. Normalise units, time zones and sampling; flag missing data explicitly (PREP-011). 4. Define alert categories and thresholds with clinicians before modelling (PREP-019). 5. Collect clinician feedback on alarms as labels (PREP-021). 6. Document consent and purpose per data stream (PREP-025).

Effort share: about 30 percent, mostly integration and quality handling; a platform purchase hides much of it, a self-built pipeline does not. See GUIDE-003.

Implementation paths

Which path for whom

• enterprise (clinics, insurers, care providers): Path A, because certified remote-monitoring platforms with device integration and alarm workflows exist and clinical use needs regulatory evidence.
• developer: Path C, because open time-series models and open platforms run on small hardware and keep patient data under own control while building integrations.
• public (hospitals, public health services): Path A with EU-hosted certified platforms, because procurement rules and medical-device duties apply; demand an exit strategy in the contract.
• private (patients, health-conscious individuals): Path A, because consumer wearables and their apps are the practical option; the user decides what data to share.

Path A — Buy (recommended)

• Certified RPM platforms (MDR-regulated where claims require): Philips (Remote Patient Monitoring, BioTelemetry), Medtronic, Biotronik Home Monitoring (DE, implant telemetry), Withings (FR, connected devices and Withings Health Solutions), Doctolib and other EU telehealth stacks, Luscii (NL), Docobo/Doccla (UK/EU virtual wards), Preventicus (DE, PPG heart-rhythm screening), Corify, Tyto Care. For hospitals: Epic/Cerner-integrated RPM modules.
• Wearable data aggregation: Apple HealthKit, Google Health Connect, Garmin Health API, Oura, and aggregators such as Terra or Thryve (DE, EU-hosted).
• Choose A when: a clinical programme exists, you need CE-marked claims, reimbursement, 24/7 support and device logistics. Check: MDR class and intended use, EU hosting, FHIR export, alert tuning per patient, device logistics and patient onboarding.

Path B — Build on cloud APIs

• Ingestion/storage: Azure Health Data Services (FHIR, EU regions), Google Cloud Healthcare API, AWS HealthLake, with Frankfurt/EU regions and signed data processing agreements.
• Analytics: managed time-series and anomaly services (e.g. Amazon SageMaker, Azure ML, Vertex AI); EU LLMs (Mistral) or frontier LLMs in EU regions for summaries and check-ins.
• Caution: any software that drives clinical decisions may be a medical device; the builder becomes the manufacturer. Use B for non-diagnostic features (summaries, scheduling, reports).

Path C — Self-host (open source)

• Stack: HAPI FHIR or Medplum for records, MQTT/Kafka for streams, TimescaleDB or InfluxDB for series, HeartPy / NeuroKit2 / wfdb for PPG-ECG processing, scikit-learn / XGBoost / LightGBM, and PyOD or Darts for anomaly detection and forecasting.
• Time-series foundation models: Chronos, TimesFM, Moirai, MOMENT (open weights).
• LLM: Llama, Mistral or Qwen models via vLLM/Ollama for summaries on HW2–HW3.
• Hardware: the signal models run on CPU or small edge devices (HW1); a GPU is needed only for the LLM layer. Operations effort is high (24/7 on-call, device management, security).

Path D — Custom training

Worth it for a novel endpoint (e.g. decompensation prediction for a specific population) with thousands of patient-months of labelled outcomes. Requires ethics approval/consent, outcome labels from the EHR, external validation at other sites, subgroup checks (skin tone effects on PPG, age, sex) and, for a product, an MDR conformity assessment and clinical evaluation.

State of the art (2026)

• Wearable sensing: consumer devices (Apple Watch, Samsung, Garmin, Oura, Withings) have regulatory-cleared features such as irregular-rhythm notification and ECG; clinical-grade accuracy is signal-dependent: heart rate and rhythm are good, cuffless blood pressure and non-invasive glucose are still limited and need calibration.
• Foundation models for physiological signals: large self-supervised models trained on wearable and ECG/PPG data (e.g. from Google, Apple and academic groups) improve small-data tasks; most remain research-stage.
• Alerting: multi-signal personalised models reduce false alarms against fixed thresholds, yet prospective evidence of better outcomes is limited; the care pathway matters more than the algorithm.
• Interoperability: FHIR R4 Observation profiles, IEEE 11073 PHD and Open mHealth are the common formats; the European Health Data Space (EHDS) regulation will push standard exchange.
• Limits and failure modes: missing data and poor adherence, motion artefacts, skin-tone and body-composition bias in optical sensors, distribution shift between devices, alert fatigue, automation bias, and patients without smartphones or connectivity (digital divide).

Shared resources & combinations

• Same time-series stack: HLTH-012 (deterioration early warning in hospital), HLTH-013 (ECG analysis), HLTH-035 (EEG/sleep), HLTH-019 (vocal biomarkers), HLTH-034 (glucose).
• Population layer: HLTH-020 risk stratification chooses whom to enrol; HLTH-028 maps data to FHIR/LOINC; HLTH-003/HLTH-011 reduce documentation load.
• Edge: ROBO-011 TinyML on microcontrollers and on-device runtimes; HLTH-015 ambient sensors.
• One FHIR store, stream pipeline and alert engine can serve all monitoring cases.

Effort, cost & KPIs

• Path A: weeks to months to launch a pilot; costs are per patient per month plus devices and nurse time. The main cost is clinical staffing, not software.
• Path B: 6–12 months with clinical, security and (if applicable) MDR work.
• Path C/D: 12+ months; regulatory work dominates.
• KPIs: unplanned admissions and bed-days, time from first deviation to contact, alert precision (share of alerts that led to action), alerts per nurse per day, patient adherence (days with data), patient-reported outcomes, cost per enrolled patient, subgroup performance.

People & change

Involve management and the medical lead for responsibility and alarm policy, nursing and care staff who will handle alerts, IT and information security for device connections and cloud transfer, and the data protection officer and legal/compliance before any pilot: continuous health data is special-category data, a DPIA is likely, and the platform is probably a medical device. Patients are directly affected and need clear information and consent.

Works council: depends. Monitoring of patients does not by itself trigger §87(1) no. 6 BetrVG, but alert-handling logs show response times of nursing staff and that is enough under BAG case law. Inform the council in good time under §90(1) no. 3 and agree on a purpose limitation for logs. Public providers involve the staff council.

AI literacy (Art. 4 AI Act, supporting measures): train staff on alarm logic, false alarms and escalation; train patients on device use. Start with a small pilot cohort of motivated patients and one care team, measure alarm burden, and adjust thresholds before scaling. Typical concerns are alarm fatigue, workload and surveillance of patients; address them with tuned thresholds, opt-in participation and a clear rule that humans decide on any intervention.

See GUIDE-005, GUIDE-009 and GUIDE-013.

Risks, regulation & compliance

• EU AI Act: high risk when the AI is (a safety component of) a medical device requiring third-party conformity assessment under MDR/IVDR (Art. 6(1), Annex I). Most diagnostic or monitoring-with-clinical-decision software is MDR class IIa or higher (Rule 11), so it is high-risk with obligations (risk management, data governance, logging, human oversight, accuracy and robustness) applying alongside MDR; wellness-only features may stay minimal. Emotion inference from wearables at work or school would breach Art. 5 prohibitions. Verify current application dates and the latest digital-omnibus changes before planning [4][5].
• MDR: intended use drives qualification (Rule 11); EU manufacturers need a CE mark, clinical evaluation and post-market surveillance. Devices and gateways have their own CE marks.
• GDPR: health data is a special category (Art. 9); needs explicit consent or a care-based legal basis, a DPIA (Art. 35), minimisation, EU hosting, and clear processor contracts. Employer or insurer access to individual data needs special care. National rules apply (e.g. German DiGAV/§ 139e SGB V, patient data protection in the KHZG/GDNG context).
• Cybersecurity: NIS2, MDR Annex I security requirements and the Cyber Resilience Act for connected devices; secure pairing, update and key management.
• Mitigations: per-patient thresholds set by clinicians, documented escalation paths, clinical validation on local population, drift monitoring, equity testing, patient education on limits ("not an emergency channel"), and offline fallback for outages.

Getting started

1. Pick one condition and care pathway (e.g. heart failure post-discharge) with a named clinical owner, and define who responds to alerts and within what time.
2. Choose a CE-marked platform or devices (Path A) and run a pilot with 30–100 patients.
3. Run silent mode first: log alerts without acting, compare with clinician judgement.
4. Complete the DPIA, processor contracts and MDR check of the intended use.
5. Measure alert precision, nurse workload and admissions; expand only if workload is manageable.

Sources

1. Koehler F. et al., TIM-HF2 telemedical interventional management in heart failure, The Lancet 2018 — https://doi.org/10.1016/S0140-6736(18)31880-4
2. European Society of Cardiology — Guidelines for heart failure (telemonitoring recommendations) — https://www.escardio.org/Guidelines/Clinical-Practice-Guidelines
3. BfArM — DiGA directory (digital health applications) — https://www.bfarm.de/EN/Medical-devices/Tasks/Digital-health-applications/_node.html
4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
6. European Commission — European Health Data Space — https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en
7. HL7 FHIR R4 Observation resource — https://hl7.org/fhir/R4/observation.html
8. Chronos time-series foundation models — https://github.com/amazon-science/chronos-forecasting