Ein Smart Wearable für das Patientenmonitoring zu entwickeln, ist kein Standardprojekt. Die Kombination aus kontinuierlicher Biosensor-Integration, strikten Zertifizierungsanforderungen und dem Zwang zur Energieeffizienz auf kleinstem PCB-Footprint erzeugt Konflikte, die früh im Design gelöst werden müssen. Wer diese Entscheidungen zu spät trifft, zahlt mit Verzögerungen, Nachzertifizierungen oder einem Produkt, das im klinischen Alltag versagt.

Was ist ein Smart Wearable für das Patientenmonitoring?

Ein Smart Wearable für das Patientenmonitoring ist ein am Körper getragenes elektronisches Gerät, das kontinuierlich physiologische Parameter wie Herzfrequenz, Blutsauerstoffsättigung (SpO2), Hauttemperatur oder EKG erfasst, lokal verarbeitet und die Daten drahtlos an ein Backend oder eine klinische Plattform überträgt. Der entscheidende Unterschied zu einem Consumer-Fitness-Tracker liegt in der Anforderung an Messgenauigkeit, Datenverfügbarkeit und regulatorischer Konformität.

In der Praxis bedeutet das: Der Sensor muss unter Bewegungsartefakten stabil messen, die Firmware muss Ausfälle erkennen und melden, und die gesamte Signalkette von der Elektrode bis zur Cloud muss validiert sein. Ein Gerät, das Vitalzeichen messen soll und dabei klinische Entscheidungen beeinflusst, fällt in Europa typischerweise unter die MDR (Medical Device Regulation) und in den USA unter FDA 21 CFR Part 820. Das definiert den gesamten Entwicklungsprozess, nicht nur das Endprodukt.

Anwendungsfelder reichen von der postoperativen Überwachung auf der Normalstation über die Langzeit-EKG-Aufzeichnung bis hin zum Remote-Patientenmonitoring bei chronisch kranken Patienten. Jedes dieser Szenarien stellt andere Anforderungen an Akkulaufzeit, Datenlatenz und Tragekomfort.

Welche Hardware-Komponenten braucht ein medizinisches Wearable?

Ein medizinisches Wearable besteht aus fünf funktionalen Blöcken: Biosensor-Frontend, Mikrocontroller mit Analog-Frontend (AFE), Energieversorgung, drahtlosem Kommunikationsmodul und Gehäuse mit Elektroden- oder Optik-Interface. Jeder Block erzeugt Kompromisse, die sich gegenseitig beeinflussen.

Biosensor-Frontend

Für die Herzfrequenz- und SpO2-Messung sind optische Sensoren wie der Maxim MAX86150 oder der Texas Instruments AFE4900 verbreitet. Der AFE4900 integriert PPG und EKG in einem Chip, was PCB-Fläche spart, aber eine sorgfältige Layout-Trennung zwischen analogem und digitalem Bereich erfordert. Wird das Layout nicht korrekt ausgeführt, koppeln digitale Schaltsignale ins analoge Frontend ein und erhöhen das Rauschen auf dem EKG-Signal um 10 bis 20 µV, was klinisch relevante Artefakte erzeugt.

Mikrocontroller und Energieversorgung

ARM-Cortex-M-basierte MCUs wie der STM32WB oder der Nordic nRF5340 kombinieren BLE-Konnektivität mit ausreichend Rechenleistung für lokale Signalverarbeitung. Der nRF5340 bietet einen dedizierten Netzwerkprozessor für BLE, was den Applikationsprozessor entlastet und den durchschnittlichen Stromverbrauch im Connected-Idle-Modus auf unter 100 µA senken kann. Bei einem 300-mAh-Akku ergibt das theoretisch über 100 Stunden Laufzeit, aber das setzt voraus, dass das Sensor-Frontend in den richtigen Schlafmodus versetzt wird. Wird das Power-Gating des AFE nicht in die Firmware-Architektur eingebaut, dominiert der Sensor-Standby-Strom die Energiebilanz.

Für die Energieversorgung gilt: LiPo-Zellen unter 100 mAh haben einen hohen Innenwiderstand, der bei Spitzenlast durch BLE-Transmission zu Spannungseinbrüchen führt. Ein Bulk-Kondensator von 100 µF direkt am Versorgungspin des Funk-Moduls ist kein optionales Detail, sondern eine Systemanforderung.

Wie entwickelt man die Firmware für ein Wearable Schritt für Schritt?

Die Firmware-Entwicklung für ein medizinisches Wearable folgt dieser Sequenz: Treiber-Layer für Sensoren und Peripherie, Echtzeit-Datenerfassung mit definiertem Sampling-Jitter, Signalverarbeitungs-Pipeline, BLE-Datenübertragung mit Datenpufferung und Fehlerbehandlung sowie ein Watchdog- und Logging-Framework für die klinische Validierung.

1. RTOS-Auswahl: Zephyr RTOS bietet native BLE-Integration über den Zephyr Bluetooth Stack und ist für medizinische Projekte geeignet, wenn ein auditfähiger Entwicklungsprozess gefordert wird. FreeRTOS ist leichtgewichtiger und einfacher nach IEC 62304 zu zertifizieren, erfordert aber mehr manuelle Integration für BLE. Die Wahl hängt davon ab, ob das Team bereits Erfahrung mit einem der beiden Systeme hat. Ein Wechsel des RTOS nach dem ersten Prototyp kostet typischerweise vier bis sechs Wochen Entwicklungszeit.
2. Sampling-Architektur: PPG-Daten werden typischerweise mit 100 bis 400 Hz abgetastet. Der DMA-Transfer vom AFE zur MCU muss interruptgesteuert sein. Polling-basierte Ansätze erzeugen Jitter von mehreren Millisekunden, was bei HRV-Analysen (Herzratenvariabilität) zu Messfehlern führt.
3. BLE-Profil: Für die kontinuierliche Vitalwerte-Überwachung wird das Health Thermometer Profile oder ein Custom GATT Service genutzt. Wer das Standard-Heart Rate Profile verwendet, stößt bei SpO2 und EKG an Kapazitätsgrenzen und muss nachträglich ein Custom Profile implementieren.
4. Fehlerbehandlung: Sensorausfall, BLE-Verbindungsverlust und Akku-Unterspannung müssen als definierte Systemzustände behandelt werden. Klinische Systeme erwarten eine Alarmmeldung, keine stille Unterbrechung der Datenübertragung.

Welche Zertifizierungen braucht ein Wearable für die Medizintechnik?

Ein Wearable für das Patientenmonitoring benötigt in Europa die CE-Kennzeichnung nach MDR 2017/745, klassifiziert je nach Anwendung als Klasse IIa oder IIb. In den USA ist eine FDA-510(k)-Zulassung oder De-Novo-Klassifizierung erforderlich. Hinzu kommen die Funkanlagen-Zertifizierung (RED-Direktive in der EU, FCC in den USA) sowie EMV- und Sicherheitsnachweise nach IEC 60601-1 für elektrische Medizingeräte.

Die IEC 62304 regelt den Software-Entwicklungsprozess und ist für MDR-konforme Geräte verpflichtend. Das bedeutet: Risikoanalyse nach ISO 14971, Softwarearchitektur-Dokumentation, Traceability-Matrix von Anforderungen bis Testfall und ein Change-Management-Prozess. Teams, die diese Dokumentation nachträglich erstellen, benötigen dafür acht bis zwölf Wochen zusätzlich.

Die CE-Zertifizierung nach MDR dauert für ein Klasse-IIa-Gerät mit einer benannten Stelle typischerweise zwölf bis achtzehn Monate, wenn alle Unterlagen vollständig sind. Unvollständige technische Dokumentation ist der häufigste Grund für Verzögerungen. Wer die BLE-Funk-Zertifizierung (RED, FCC ID) nicht parallel zur MDR-Einreichung vorbereitet, verliert weitere vier bis acht Wochen.

Eine oft übersehene Anforderung: Wenn das Gerät patientenbezogene Gesundheitsdaten überträgt, greift in Europa zusätzlich die DSGVO mit spezifischen Anforderungen an die Datenspeicherung und Einwilligung.

Was sind häufige Fehler bei der Wearable-Entwicklung?

Die häufigsten Fehler bei der Entwicklung medizinischer Wearables sind: zu späte Einbindung der Zertifizierungsanforderungen in das Hardware-Design, unterschätzte EMV-Probleme durch schlechtes PCB-Layout, fehlende Power-Budget-Analyse vor dem ersten Prototyp und eine Firmware-Architektur, die nicht auf klinische Fehlerszenarien ausgelegt ist.

Zu frühes Einfrieren des PCB-Layouts

Teams frieren das PCB-Layout nach dem ersten Prototyp ein, bevor EMV-Tests durchgeführt wurden. Das Ergebnis: Das BLE-Modul stört das analoge Sensor-Frontend, und das Layout muss grundlegend überarbeitet werden. Eine PCB-Revision kostet je nach Komplexität zwischen 5.000 und 20.000 Euro und vier bis acht Wochen Verzögerung.

Unterschätzung des Akku-Designs

Ein häufiger Fehler ist die Annahme, dass der durchschnittliche Stromverbrauch aus dem Datenblatt des Mikrocontrollers direkt auf die Systemlaufzeit hochgerechnet werden kann. Spitzenströme durch BLE-Advertising (bis zu 15 mA für 1,5 ms alle 100 ms) und Sensor-Initialisierung werden nicht in die Berechnung einbezogen. Das führt zu unerwartetem Auslösen des Akku-Tiefentladeschutzes unter Last.

Fehlende Validierung unter Bewegungsartefakten

PPG-Signale sind stark bewegungsabhängig. Wer die Sensorik nur im Labor an der ruhenden Hand testet, wird in der klinischen Validierung scheitern. Accelerometer-basierte Bewegungskompensation (z. B. über den ADXL362) muss bereits im ersten Prototyp integriert sein, nicht als nachträgliches Feature.

Wann sollte man einen externen Entwicklungspartner beauftragen?

Ein externer Entwicklungspartner ist sinnvoll, wenn das interne Team keine Erfahrung mit medizinischen Zertifizierungsprozessen hat, wenn der Zeitplan eine parallele Entwicklung von Hardware, Firmware und Zertifizierungsdokumentation erfordert, oder wenn spezifisches Know-how in analogem Frontend-Design oder EMV-gerechtem PCB-Layout fehlt.

Die Entscheidung hat direkte Kostenwirkung: Ein erfahrenes externes Team, das MDR-konforme Dokumentation und Hardware-Design parallel liefert, kann die Time-to-Market um sechs bis zwölf Monate verkürzen, verglichen mit einem internen Team, das diese Prozesse erstmals aufbaut. Die Kosten für externe Entwicklung liegen je nach Projektumfang zwischen 80.000 und 300.000 Euro, müssen aber gegen die Opportunitätskosten von Verzögerungen und Nachzertifizierungen abgewogen werden.

Ein externer Partner ist weniger geeignet, wenn das Unternehmen langfristig eigene Entwicklungskapazitäten aufbauen will und bereit ist, die damit verbundene Anlaufzeit einzuplanen. In diesem Fall ist ein hybrider Ansatz sinnvoller: externer Partner für die erste Produktgeneration, interner Team-Aufbau parallel dazu.

Wir bei Oxeltech haben über 20 Hardwareprodukte vom ersten Konzept bis zur Serienreife begleitet, darunter mehrere Projekte im Bereich IoT-Gesundheit und Medizintechnik. Wer einen Partner sucht, der Hardware-Design, Firmware-Entwicklung und Zertifizierungsvorbereitung aus einer Hand liefert, findet auf unserer Unternehmensseite mehr zu unserem Ansatz und unserer Erfahrung. Für eine direkte Einschätzung des eigenen Projekts steht unser Team über die Kontaktseite zur Verfügung.