Telemonitoring von Patienten & Analyse von Wearable-Daten

Patienten mit Herzinsuffizienz, Bluthochdruck, COPD, Diabetes oder einem kürzlichen Krankenhausaufenthalt erzeugen zu Hause Gesundheitssignale, die zwischen den Terminen niemand beobachtet. Das Telemonitoring (Remote Patient Monitoring, RPM) sammelt Messwerte aus vernetzten Geräten und Wearables, trennt mit Zeitreihenmodellen echte Verschlechterungen vom Rauschen und gibt einem kleinen Behandlungsteam eine Rangliste, wer heute einen Anruf braucht. Ziel sind frühere Eingriffe und weniger vermeidbare Aufnahmen, nicht der Ersatz von Behandelnden.

Problem & Nutzen

• Heute: Chronisch Kranke werden alle paar Monate gesehen; Messwerte von zu Hause werden auf Papier notiert oder ignoriert. Alarme nur nach Schwellenwerten (z. B. „Gewicht +2 kg") erzeugen viele Fehlalarme und Alarmmüdigkeit.
• KI-Nutzen: personalisierte Basiswerte, Trenderkennung über mehrere Signale, Ausschluss von Artefakten (lockere Elektrode, nicht getragene Zeit) und eine Triage-Rangfolge, sodass das Pflegepersonal seine Zeit den wenigen gefährdeten Patienten widmet. LLMs ergänzen patientenverständliche Zusammenfassungen, Fragebogendialoge und Berichte für Behandelnde.
• Belege: Die deutsche TIM-HF2-Studie berichtete bei Herzinsuffizienz weniger Tage, die durch ungeplante kardiovaskuläre Krankenhausaufnahmen oder Tod verloren gingen, mit strukturiertem Telemonitoring; die Ergebnisse für andere Erkrankungen und für rein Wearable-basierte Algorithmen sind gemischt, der Nutzen hängt also vom Versorgungs- prozess ab, der die Daten umgibt [1][2].
• Erstattung: Deutschland erstattet das Telemonitoring bei Herzinsuffizienz über das gesetzliche System und führt DiGA (verschreibbare digitale Gesundheitsanwendungen) im BfArM-Verzeichnis, was einigen Produkten einen kommerziellen Weg eröffnet [3].

Varianten

• Programme für chronische Erkrankungen: Herzinsuffizienz, Bluthochdruck, COPD, CKD (von Kliniken oder Versicherern betrieben).
• Nach der Entlassung / Hospital-at-Home: 30 Tage Überwachung nach Operationen oder akuten Episoden.
• Screening auf Herzrhythmusstörungen: Wearable- oder Patch-EKG bei Vorhofflimmern → siehe HLTH-013.
• Diabetes: kontinuierliche Glukosedaten und Insulindosierung → HLTH-034 (höhere Risikoklasse).
• Altenpflege / Ambient Assisted Living: → HLTH-015, CONV-016.
• Klinische Studien (dezentral): Wearable-Endpunkte, digitale Biomarker.
• Wohlbefinden für Verbraucher (private Nutzung): Trends der Smartwatch und Schlaferkenntnisse; in der Regel ein Wellness-Produkt, kein Medizinprodukt, es sei denn, es verspricht Diagnose oder Überwachung einer Krankheit.

So funktioniert es

1. Gerät/Wearable (BLE)
2. Smartphone-App oder Gateway (LTE-Hub)
3. Erfassung (HL7 FHIR Observation / IEEE 11073 / Open mHealth, Hersteller-APIs)
4. Qualitätsfilter (Tragezeit, Artefakte, Plausibilität)
5. persönlicher Basiswert + Trendmodelle (Zeitreihen, Anomalieerkennung)
6. Risikowert (Gradient Boosting / Sequenzmodell mit KIS-Kontext)
7. Alarm-Engine (Schweregrad, Regeln, Eskalationsregel)
8. Arbeitsliste für Behandelnde
9. Anruf / Besuch / Medikationsänderung (menschliche Entscheidung)
10. Dokumentation + Abrechnungsdatensatz, Feedback-Labels zur Modellverbesserung

• Edge/Smartphone: Filterung und einfache Erkennung auf dem Gerät (Core ML, TFLite, ONNX) spart Akku und Bandbreite und hält Rohdaten lokal.
• Modelle: Basiswerte je Patient mit Change-Point-Erkennung, Gradient-Boosting-Bäume auf konstruierten Merkmalen (bei kleinen Tabellendaten oft am stärksten) sowie Sequenzmodelle oder Zeitreihen- Basismodelle (z. B. Chronos, TimesFM, Moirai) für Prognose und Imputation.
• LLM-Schicht: fasst die Woche für Patient und Behandelnde zusammen und führt Symptom-Check-ins durch; sie entscheidet nie allein über Therapie oder legt Alarmschwellen fest.
• Mensch-in-der-Schleife (Human-in-the-Loop): Eine behandelnde Person verantwortet den Versorgungsplan, die Alarmschwellen je Patient und jede Eskalation; Pflegekräfte bestätigen und dokumentieren jeden Alarm. Patienten erhalten klare Anweisungen für Notfälle (das System ist kein Notdienst).

Datenaufbereitung

Die Daten stammen aus Wearables, Heimgeräten (Blutdruck, Glukose, EKG-Pflaster), Patienten-Apps und Fragebögen und müssen mit dem KIS und den Versorgungsplänen zusammengeführt werden. Quellen sind eher Hersteller-Clouds und Geräte-APIs als hauseigene Systeme.

Typische Lücken: verschiedene Hersteller mit unterschiedlichen Formaten und Abtastraten, Lücken durch nicht getragene oder nicht geladene Geräte, Bewegungsartefakte, fehlende Zuordnungen von Patient und Gerät, kein Basiswert je Patient, uneinheitliche Zeitstempel und unklare Einwilligung je Datenstrom.

Schritte der Aufbereitung: 1. Geräte und Datenströme erfassen und den Überwachungszielen zuordnen (PREP-002). 2. Über Hersteller-APIs oder Standards wie FHIR und Bluetooth-Gateways anbinden (PREP-005, DATA-007). 3. Einheiten, Zeitzonen und Abtastung normalisieren; fehlende Daten ausdrücklich markieren (PREP-011). 4. Alarmkategorien und Schwellenwerte vor der Modellierung mit Behandelnden festlegen (PREP-019). 5. Rückmeldungen von Behandelnden zu Alarmen als Labels sammeln (PREP-021). 6. Einwilligung und Zweck je Datenstrom dokumentieren (PREP-025).

Aufwandsanteil: etwa 30 Prozent, überwiegend Integration und Umgang mit der Datenqualität; ein Plattformkauf verbirgt davon vieles, eine selbst gebaute Pipeline nicht. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• enterprise (Kliniken, Versicherer, Leistungserbringer): Weg A, weil zertifizierte Telemonitoring-Plattformen mit Geräteanbindung und Alarm-Workflows existieren und der klinische Einsatz regulatorische Nachweise braucht.
• developer: Weg C, weil offene Zeitreihenmodelle und offene Plattformen auf kleiner Hardware laufen und die Patientendaten beim Bau der Integrationen unter eigener Kontrolle bleiben.
• public (Krankenhäuser, öffentliche Gesundheitsdienste): Weg A mit zertifizierten Plattformen in EU-Hosting, weil Vergaberegeln und Pflichten für Medizinprodukte gelten; verlangen Sie im Vertrag eine Ausstiegsstrategie.
• private (Patienten, gesundheitsbewusste Personen): Weg A, weil Verbraucher-Wearables und ihre Apps die praktische Option sind; die Nutzerin oder der Nutzer entscheidet, welche Daten geteilt werden.

Weg A — Kaufen (Standardsoftware) (empfohlen)

• Zertifizierte RPM-Plattformen (MDR-reguliert, wo die Aussagen es verlangen): Philips (Remote Patient Monitoring, BioTelemetry), Medtronic, Biotronik Home Monitoring (DE, Implantat-Telemetrie), Withings (FR, vernetzte Geräte und Withings Health Solutions), Doctolib und andere EU- Telemedizin-Stacks, Luscii (NL), Docobo/Doccla (UK/EU, virtuelle Stationen), Preventicus (DE, PPG- Herzrhythmus-Screening), Corify, Tyto Care. Für Krankenhäuser: RPM-Module mit Epic-/Cerner-Anbindung.
• Aggregation von Wearable-Daten: Apple HealthKit, Google Health Connect, Garmin Health API, Oura sowie Aggregatoren wie Terra oder Thryve (DE, EU-Hosting).
• A wählen, wenn: ein klinisches Programm besteht und Sie CE-gekennzeichnete Aussagen, Erstattung, 24/7- Support und Geräte-Logistik brauchen. Prüfen Sie: MDR-Klasse und Zweckbestimmung, EU-Hosting, FHIR-Export, Alarmanpassung je Patient, Geräte-Logistik und Einführung der Patienten.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Erfassung/Speicherung: Azure Health Data Services (FHIR, EU-Regionen), Google Cloud Healthcare API, AWS HealthLake, mit Regionen in Frankfurt/EU und unterzeichneten Auftragsverarbeitungsverträgen (AVV).
• Analytik: verwaltete Dienste für Zeitreihen und Anomalien (z. B. Amazon SageMaker, Azure ML, Vertex AI); EU-LLMs (Mistral) oder Spitzen-LLMs in EU-Regionen für Zusammenfassungen und Check-ins.
• Vorsicht: Jede Software, die klinische Entscheidungen steuert, kann ein Medizinprodukt sein; wer sie baut, wird zum Hersteller. Nutzen Sie B für nicht diagnostische Funktionen (Zusammenfassungen, Terminplanung, Berichte).

Weg C — Selbst betreiben (Open Source)

• Stack: HAPI FHIR oder Medplum für Akten, MQTT/Kafka für Datenströme, TimescaleDB oder InfluxDB für Zeitreihen, HeartPy / NeuroKit2 / wfdb für die PPG-/EKG-Verarbeitung, scikit-learn / XGBoost / LightGBM sowie PyOD oder Darts für Anomalieerkennung und Prognose.
• Zeitreihen-Basismodelle: Chronos, TimesFM, Moirai, MOMENT (offene Gewichte).
• LLM: Llama-, Mistral- oder Qwen-Modelle über vLLM/Ollama für Zusammenfassungen auf HW2–HW3.
• Hardware: Die Signalmodelle laufen auf CPU oder kleinen Edge-Geräten (HW1); eine GPU wird nur für die LLM-Schicht gebraucht. Der Betriebsaufwand ist hoch (24/7-Bereitschaft, Geräteverwaltung, Sicherheit).

Weg D — Eigenes Training

Lohnt sich für einen neuen Endpunkt (z. B. Vorhersage einer Dekompensation für eine bestimmte Population) mit tausenden Patientenmonaten an gelabelten Ergebnissen. Erfordert Ethikvotum/Einwilligung, Ergebnis- Labels aus dem KIS, externe Validierung an anderen Standorten, Prüfungen nach Untergruppen (Einfluss des Hautton auf PPG, Alter, Geschlecht) und, für ein Produkt, eine MDR-Konformitätsbewertung und klinische Bewertung.

Stand der Technik (2026)

• Wearable-Sensorik: Verbrauchergeräte (Apple Watch, Samsung, Garmin, Oura, Withings) haben behördlich freigegebene Funktionen wie Benachrichtigung bei unregelmäßigem Rhythmus und EKG; die Genauigkeit auf klinischem Niveau hängt vom Signal ab: Herzfrequenz und Rhythmus sind gut, manschettenlose Blutdruckmessung und nicht-invasive Glukosemessung sind weiterhin eingeschränkt und brauchen Kalibrierung.
• Basismodelle für physiologische Signale: große selbstüberwachte Modelle, trainiert auf Wearable- und EKG/PPG-Daten (z. B. von Google, Apple und akademischen Gruppen), verbessern Aufgaben mit wenig Daten; die meisten befinden sich noch im Forschungsstadium.
• Alarmierung: personalisierte Modelle über mehrere Signale senken Fehlalarme gegenüber festen Schwellenwerten, doch prospektive Belege für bessere Ergebnisse sind begrenzt; der Versorgungspfad zählt mehr als der Algorithmus.
• Interoperabilität: FHIR-R4-Observation-Profile, IEEE 11073 PHD und Open mHealth sind die gängigen Formate; die Verordnung zum Europäischen Gesundheitsdatenraum (EHDS) wird den standardisierten Austausch vorantreiben.
• Grenzen und Fehlerbilder: fehlende Daten und mangelnde Therapietreue, Bewegungsartefakte, Verzerrung bei Hautton und Körperzusammensetzung in optischen Sensoren, Verteilungsverschiebung zwischen Geräten, Alarmmüdigkeit, Automatisierungsverzerrung sowie Patienten ohne Smartphone oder Verbindung (digitale Kluft).

Gemeinsame Bausteine & Kombinationen

• Gleicher Zeitreihen-Stack: HLTH-012 (Frühwarnung bei Verschlechterung im Krankenhaus), HLTH-013 (EKG-Analyse), HLTH-035 (EEG/Schlaf), HLTH-019 (Stimm-Biomarker), HLTH-034 (Glukose).
• Bevölkerungsebene: Die Risikostratifizierung HLTH-020 wählt aus, wen man einschreibt; HLTH-028 bildet Daten auf FHIR/LOINC ab; HLTH-003/HLTH-011 senken den Dokumentationsaufwand.
• Edge: ROBO-011 TinyML auf Mikrocontrollern und Laufzeitumgebungen auf dem Gerät; HLTH-015 Umgebungssensoren.
• Ein FHIR-Speicher, eine Datenstrom-Pipeline und eine Alarm-Engine können alle Monitoring-Fälle bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis Monate bis zum Pilotstart; die Kosten fallen pro Patient und Monat an, plus Geräte und Pflegezeit. Der Hauptkostenblock ist das klinische Personal, nicht die Software.
• Weg B: 6–12 Monate mit klinischer Arbeit, Sicherheitsarbeit und (falls zutreffend) MDR-Aufwand.
• Weg C/D: 12+ Monate; die regulatorische Arbeit dominiert.
• Kennzahlen: ungeplante Aufnahmen und Bettentage, Zeit von der ersten Abweichung bis zum Kontakt, Alarm- Präzision (Anteil der Alarme, die zu einer Maßnahme führten), Alarme je Pflegekraft und Tag, Therapietreue der Patienten (Tage mit Daten), von Patienten berichtete Ergebnisse, Kosten je eingeschriebenem Patienten, Leistung je Untergruppe.

Menschen & Veränderung

Beziehen Sie die Geschäftsleitung und die ärztliche Leitung für Verantwortung und Alarmregeln, die Pflege- und Betreuungskräfte, die Alarme bearbeiten, die IT und Informationssicherheit für Geräteanbindung und Cloud-Übertragung sowie die Datenschutzbeauftragten und Legal/Compliance vor jedem Pilot ein: Dauerhaft erfasste Gesundheitsdaten sind Daten besonderer Kategorien, eine DSFA ist wahrscheinlich, und die Plattform ist vermutlich ein Medizinprodukt. Patientinnen und Patienten sind unmittelbar betroffen und brauchen klare Informationen und eine Einwilligung.

Betriebsrat: kommt darauf an. Die Überwachung von Patienten löst für sich genommen § 87 Abs. 1 Nr. 6 BetrVG nicht aus, aber Protokolle der Alarmbearbeitung zeigen Reaktionszeiten des Pflegepersonals, und das genügt nach der Rechtsprechung des BAG. Informieren Sie den Betriebsrat rechtzeitig nach § 90 Abs. 1 Nr. 3 und vereinbaren Sie eine Zweckbindung für die Protokolle. Öffentliche Träger beteiligen den Personalrat.

KI-Kompetenz (Art. 4 KI-Verordnung, unterstützende Maßnahmen): Schulen Sie das Personal in Alarmlogik, Fehlalarmen und Eskalation; schulen Sie Patienten in der Gerätenutzung. Beginnen Sie mit einer kleinen Pilotgruppe motivierter Patienten und einem Behandlungsteam, messen Sie die Alarmbelastung und passen Sie die Schwellenwerte an, bevor Sie ausweiten. Typische Sorgen sind Alarmmüdigkeit, Arbeitsbelastung und Überwachung von Patienten; begegnen Sie ihnen mit angepassten Schwellenwerten, freiwilliger Teilnahme und der klaren Regel, dass Menschen über jede Intervention entscheiden.

Siehe GUIDE-005, GUIDE-009 und GUIDE-013.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Hochrisiko, wenn die KI (ein Sicherheitsbauteil von) ein Medizinprodukt ist, das eine Konformitätsbewertung durch Dritte nach MDR/IVDR braucht (Art. 6 Abs. 1, Anhang I). Die meiste diagnostische oder überwachende Software mit klinischer Entscheidung ist nach MDR Klasse IIa oder höher (Regel 11), also Hochrisiko, wobei Pflichten (Risikomanagement, Daten-Governance, Protokollierung, menschliche Aufsicht, Genauigkeit und Robustheit) neben der MDR gelten; reine Wellness-Funktionen können beim minimalen Risiko bleiben. Das Ableiten von Emotionen aus Wearables am Arbeitsplatz oder in der Schule würde gegen die Verbote in Art. 5 verstoßen. Prüfen Sie vor der Planung die aktuellen Anwendungstermine und die jüngsten Änderungen durch das Digital-Omnibus-Paket [4][5].
• MDR: Die Zweckbestimmung bestimmt die Einstufung (Regel 11); EU-Hersteller brauchen eine CE-Kennzeichnung, klinische Bewertung und Überwachung nach dem Inverkehrbringen. Geräte und Gateways haben eigene CE-Kennzeichnungen.
• DSGVO: Gesundheitsdaten sind eine besondere Kategorie (Art. 9); nötig sind eine ausdrückliche Einwilligung oder eine versorgungsbezogene Rechtsgrundlage, eine DSFA (Art. 35), Datenminimierung, EU-Hosting und klare Auftragsverarbeitungsverträge. Der Zugriff von Arbeitgebern oder Versicherern auf Einzeldaten erfordert besondere Sorgfalt. Nationale Regeln gelten (z. B. DiGAV/§ 139e SGB V in Deutschland, Patientendatenschutz im Zusammenhang mit KHZG/GDNG).
• Cybersicherheit: NIS2, die Sicherheitsanforderungen in Anhang I der MDR und der Cyber Resilience Act für vernetzte Geräte; sichere Kopplung, Aktualisierung und Schlüsselverwaltung.
• Gegenmaßnahmen: von Behandelnden festgelegte Schwellenwerte je Patient, dokumentierte Eskalationswege, klinische Validierung an der lokalen Population, Drift-Überwachung, Fairness-Tests, Aufklärung der Patienten über die Grenzen („kein Notrufkanal") und ein Offline-Rückfall bei Ausfällen.

Erste Schritte

1. Eine Erkrankung und einen Versorgungspfad wählen (z. B. Herzinsuffizienz nach der Entlassung) mit einer benannten klinisch verantwortlichen Person, und festlegen, wer auf Alarme reagiert und innerhalb welcher Zeit.
2. Eine CE-gekennzeichnete Plattform oder Geräte wählen (Weg A) und einen Pilot mit 30–100 Patienten fahren.
3. Zuerst im stillen Modus laufen lassen: Alarme protokollieren, ohne zu handeln, und mit dem Urteil der Behandelnden vergleichen.
4. Die DSFA, die Auftragsverarbeitungsverträge und die MDR-Prüfung der Zweckbestimmung abschließen.
5. Alarm-Präzision, Arbeitsbelastung der Pflege und Aufnahmen messen; nur ausweiten, wenn die Arbeitsbelastung beherrschbar ist.

Quellen

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