BLE-Integration für Diabetes-Management-Apps: CGM und Blutzuckermessgeräte

Der größte Vorteil von BLE besteht darin, dass es im Vergleich zu Classic Bluetooth den Energieverbrauch und die Kosten reduziert. Im medizinischen Bereich kann diese Technologie dabei helfen, Messwerte von einem System zur kontinuierlichen Glukosemessung (CGM) oder einem Blutzuckermessgerät an eine mobile App und anschließend an einen Backend-Service zu übertragen. Eine solche Übertragung klingt zunächst recht unkompliziert. Die eigentliche Herausforderung liegt jedoch in der Integration, da dabei verschiedene Schritte umgesetzt und unterschiedliche Einschränkungen berücksichtigt werden müssen.
Dieser Artikel zeigt, welche Faktoren eine solche Integration in Diabetes-Anwendungen in der Praxis erschweren.

Zwei sehr unterschiedliche Geräte, ein Standard

Zunächst ist es wichtig, klar zwischen den beiden Gerätetypen zu unterscheiden. Ein Blutzuckermessgerät liefert dem Nutzer ein einzelnes Messergebnis. Der Nutzer sticht sich in den Finger, der Teststreifen ermittelt einen Wert und das Messgerät speichert das Ergebnis. Später stellt die App eine Verbindung her, ruft den neuen Messwert ab und trennt die Verbindung wieder. Daher kommt die Integration eines Blutzuckermessgeräts in der Regel mit kurzen, gelegentlichen Verbindungen aus.

Ein CGM-System überwacht den Glukosespiegel kontinuierlich und erzeugt dadurch eine Zeitreihe von Messwerten. Dafür müssen regelmäßig neue Daten an die Software zur Glukoseüberwachung übertragen werden. Die App muss die Verbindung wiederherstellen, um jeweils den neuesten Messwert abzurufen. Ist das Smartphone oder die Verbindung über einen längeren Zeitraum nicht verfügbar, arbeitet das CGM-System weiter. Sobald die Verbindung wiederhergestellt ist, sollte die App alle zwischenzeitlich erfassten Messwerte abrufen. Dies ist zwar nur ein vereinfachtes Beispiel – die konkreten Abläufe können je nach Gerät variieren –, zeigt aber, dass eine CGM-Integration auf beiden Betriebssystemen (iOS und Android) über viele Stunden zuverlässig im Hintergrund funktionieren muss. Dafür müssen plattformspezifische Einschränkungen berücksichtigt werden, die iOS und Android für BLE-Verbindungen im Hintergrund vorgeben.

Auch beim Fehlermanagement unterscheiden sich die beiden Systeme. Tritt bei einem Blutzuckermessgerät ein Fehler auf, erhält der Nutzer in der Regel sofort eine Rückmeldung, da er aktiv auf das Messergebnis wartet. Ein CGM-System arbeitet dagegen kontinuierlich, auch wenn der Nutzer die Werte gerade nicht überwacht. Deshalb sollte die App einen Verbindungs- oder Übertragungsfehler selbstständig erkennen, damit keine Datenlücke entsteht, die über Stunden unbemerkt bleibt.

Standardprofile im Vergleich zu Hersteller-SDKs

Die Bluetooth SIG definiert sowohl den Continuous Glucose Monitoring Service als auch den älteren Glucose Service. Da beide auf GATT basieren, kann jedes Gerät, das diese Profile implementiert, seine Daten über dokumentierte GATT-Dienste bereitstellen. Die BLE-Unterstützung ist jedoch nur ein Teil der Integration. Für eine zuverlässige Interoperabilität in der Praxis muss weiterhin jedes unterstützte Gerätemodell getestet werden.

Bei Blutzuckermessgeräten, die den standardisierten Glucose Service korrekt implementieren, benötigt eine generische BLE-Implementierung nur wenig gerätespezifische Logik, um mit dem Gerät zu kommunizieren.

Viele CGM-Systeme für Endverbraucher stellen ihre Daten dagegen nicht über den standardisierten CGM Service bereit. Bei Dexcom-Integrationen besteht beispielsweise in der Regel kein uneingeschränkter Zugriff auf das GATT-Protokoll des Sensors. Stattdessen kommen vom Hersteller freigegebene APIs oder Partner-Integrationskanäle zum Einsatz. Bei verschiedenen Generationen von FreeStyle Libre sowie in unterschiedlichen Märkten werden verschiedene Kommunikationsmethoden verwendet: NFC, BLE oder eine Kombination aus beiden. Der Zugriff durch Drittanbieter wird in der Regel über herstellerspezifische Integrationskanäle gesteuert.

Geräteerkennung und Pairing

Die Geräteerkennung beginnt mit einem BLE-Scan. Da in Kliniken und Krankenhäusern häufig mehrere Geräte gleichzeitig in unmittelbarer Nähe Signale aussenden, ist eine zuverlässige Filterung besonders wichtig. Ein zu weit gefasster Filter könnte dazu führen, dass ein Gerät gekoppelt wird, das zu einem anderen Patienten gehört.

Stellt der Hersteller eine UUID bereit, kann diese für die Filterung verwendet werden. Andernfalls lässt sich beispielsweise nach dem übertragenen Gerätenamen beziehungsweise einem bestimmten Namensmuster filtern. Teams berücksichtigen häufig auch die Signalstärke als zusätzliches Indiz. Diese kann jedoch durch Reflexionen, Störungen und Unterschiede zwischen den Funkmodulen der Geräte beeinflusst werden und eignet sich daher nicht als eindeutiger Identitätsnachweis. Eine bessere Alternative ist ein zusätzlicher Bestätigungsschritt, beispielsweise durch den Abgleich der Seriennummer auf dem Gerät oder seiner Verpackung.

Verschlüsselungsschlüssel und die Wiederherstellung der Verbindung werden auf Betriebssystemebene verwaltet. Die Zuordnung auf Anwendungsebene sollte unabhängig vom aktuellen Bluetooth-Status erfassen, welches Gerät welchem Patientenkonto zugeordnet ist. Dadurch bleibt die korrekte Zuordnung auch dann erhalten, wenn ein Smartphone zurückgesetzt oder ausgetauscht wird.

Der Datenpfad für Glukosewerte

Die Struktur der vom Gerät bereitgestellten Daten kann je nach implementiertem Profil variieren. Entwickler müssen daher genau darauf achten, welche Daten übertragen werden und welche Bedeutung den einzelnen Feldern zugewiesen ist. Häufige Fehler entstehen beispielsweise durch ein falsch interpretiertes Flag oder eine fehlerhafte Umrechnung. Einige dieser Fehler sind schwer zu erkennen, weil die App weiterhin funktioniert, jedoch eine falsche Konzentration oder einen plausibel wirkenden, aber dennoch fehlerhaften Wert anzeigt. Parsing-Bibliotheken können dabei helfen, dennoch sind gründliche Tests mit realen Geräten erforderlich.

CGM-Daten enthalten häufig zusätzliche Informationen wie Trendrichtung und Änderungsrate. Diese Werte werden normalerweise von den SDKs der Hersteller bereitgestellt. Ist dies nicht der Fall, kann die App sie anhand der letzten Messwerte berechnen. Ohne eine entsprechende Validierung sollten sie jedoch nicht als vom Hersteller bereitgestellte Indikatoren dargestellt werden.

Nach einer erneuten Verbindung kann das Gerät Messwerte übertragen, die erfasst wurden, während das Smartphone nicht verfügbar war. Einige davon wurden möglicherweise bereits verarbeitet, bevor die Verbindung unterbrochen wurde. Um Duplikate zu vermeiden, sollten sowohl die lokale Datenaufnahme als auch die Datenaufnahme im Backend idempotent ausgelegt sein.

Bei Zeitreihendaten spielt die Reihenfolge eine entscheidende Rolle. Das System sollte die Datensatz- oder Sequenzkennungen des Geräts beibehalten, sofern diese verfügbar sind, und verzögert eintreffende Datensätze akzeptieren, ohne die Zeitachse zu verfälschen. Andernfalls können gültige Messwerte in der falschen Reihenfolge erscheinen. Ein Messwert kann einen lokalen Zeitstempel des Geräts, einen Zeitzonen-Offset oder eine Zeitangabe relativ zur aktuellen Sensorsitzung enthalten. Was passiert jedoch, wenn eine Messung tatsächlich durchgeführt wurde, sich danach aber die Uhrzeit des Smartphones ändert, der Nutzer eine andere Zeitzone erreicht, die Geräteuhr abweicht oder der Sensor neu gestartet wird? Dies kann dazu führen, dass die App Zeitangaben überschreibt. Um solche Probleme zu vermeiden, können unter anderem das ursprüngliche Zeitfeld beibehalten, eine geeignete Referenz für die Normalisierung festgelegt und der Zeitpunkt des Empfangs auf dem Mobilgerät separat gespeichert werden.

Background Operation and ReconnectionThis topic is largely a platform constraint (not a BLE protocol problem) and is why most of the CGM integrations lose reliability at this stage.

Hierbei handelt es sich größtenteils um eine Einschränkung der jeweiligen Plattform und nicht um ein Problem des BLE-Protokolls. Genau an dieser Stelle verlieren viele CGM-Integrationen an Zuverlässigkeit.

Bei einer iOS-App muss der Hintergrundmodus Bluetooth-Central in der Info.plist deklariert werden. Das Scannen im Hintergrund verhält sich dennoch anders: Mehrfache Erkennungen desselben Geräts werden zusammengefasst, die Geräteerkennung kann länger dauern, wenn sich alle scannenden Apps im Hintergrund befinden, und das System kann eine App beenden, um Arbeitsspeicher freizugeben. Dadurch können aktive Verbindungen verloren gehen.

Der optionale Mechanismus von CoreBluetooth zur Zustandserhaltung und –wiederherstellung kann bestimmte Scans, ausstehende oder aktive Verbindungen sowie Subscriptions für Characteristics erhalten, bevor die App erneut gestartet wird, um ein Bluetooth-Ereignis zu verarbeiten. Dieser Ablauf muss jedoch von Anfang an berücksichtigt werden, da er beeinflusst, wie der Central Manager über den gesamten Lebenszyklus der App hinweg initialisiert wird – und nicht nur innerhalb eines einzelnen Screens.

CoreBluetooth bietet klare Modelle für die Central- und Peripheral-Rollen, die Einschränkungen für den Hintergrundbetrieb sind jedoch strenger. Im Apple App Store muss der Zweck der Nutzung des Hintergrundmodus angegeben werden. Apple überprüft zudem, ob dieser ausschließlich für den angegebenen Zweck verwendet wird. Auch die Notwendigkeit der Bluetooth-Nutzung muss während des Review-Prozesses eindeutig erläutert werden.

Unter Android erfordern unterschiedliche Verbindungsmodelle unterschiedliche Strategien. Für langfristige Verbindungen kann beispielsweise ein connectedDevice–Foreground-Service eingesetzt werden. Für die Geräteerkennung und regelmäßige Synchronisierung können dagegen ein PendingIntent–Scan, eine WorkManager–Task oder die Companion Device API verwendet werden. Neuere Android-Versionen beschränken das Starten von Prozessen im Hintergrund. Daher muss getestet werden, ob die Synchronisierung auch dann zuverlässig funktioniert, wenn die App nicht aktiv geöffnet ist.

Der BLE-Stack von Android wurde in den vergangenen Jahren verbessert. Die Fragmentierung bei älteren, weiterhin aktiv genutzten Geräten bleibt jedoch eine reale Einschränkung. Android 12 führte BLUETOOTH_SCAN und BLUETOOTH_CONNECT als Laufzeitberechtigungen ein, während das BLE-Scanning auf älteren Android-Versionen Standortberechtigungen erfordert. Teams, die ältere Versionen weiterhin unterstützen müssen, benötigen daher beide Berechtigungsmodelle parallel. Das erhöht die Komplexität und erschwert die Tests, da jede Änderung auf beiden Varianten überprüft werden muss.

Ein Gerät kann außer Reichweite geraten, der Akku kann leer sein oder das Betriebssystem kann den Hintergrundprozess beenden. Auch die bestehende Kopplung kann nach einem Betriebssystem-Update ungültig werden. Solche Situationen treten häufiger auf, als man vermuten könnte, und jede davon erfordert einen eigenen Wiederherstellungsmechanismus. Bei CGM-Systemen benötigen Fehler besondere Aufmerksamkeit, da wiederholte Ausfälle zu unbemerkten Lücken im Datenverlauf führen können.

Das folgende Diagramm zeigt eine vereinfachte Darstellung eines vollständigen BLE-Integrationsablaufs:

Fehlerbehandlung

Bei einem CGM-System führt eine unterbrochene Verbindung zu einer unbemerkten Datenlücke, sodass dem Nutzer veraltete Glukosewerte angezeigt werden. Dadurch wird auch die Zuverlässigkeit nachfolgender oder zusätzlicher Benachrichtigungen und darauf basierender Aktionen beeinträchtigt. Um dies zu vermeiden, sollten Teams die Fehlerbehandlung als zentralen Bestandteil der Integration betrachten und sicherstellen, dass Fehler in jedem Schritt korrekt verarbeitet werden.

Die Integrationsschicht sollte sich vor allem darauf konzentrieren, fehlende Daten zu erkennen, Messwerte als veraltet zu kennzeichnen und Nutzer vor Synchronisierungsfehlern zu warnen. Primäre Warnungen bei zu hohen oder zu niedrigen Glukosewerten sollten weiterhin über das vom Hersteller freigegebene Gerät, Empfangsgerät oder die entsprechende App erfolgen – es sei denn, die eigene Anwendung wurde speziell für klinische Warnmeldungen validiert.

Entwickler sollten außerdem die Datenkontinuität anhand eines definierten Schwellenwerts und eines eigenen Fehlerstatus überwachen. Eine klare Unterscheidung zwischen „keine neuen Daten“ und „Verbindung unterbrochen“ ermöglicht es, Probleme frühzeitig zu erkennen und die Zuverlässigkeit zu verbessern. Dies ist jedoch nicht immer einfach, da ein verbundenes CGM-System zwischen zwei Messintervallen auf Transportebene genauso aussehen kann wie ein System, bei dem unbemerkt ein Fehler aufgetreten ist. Ein gängiger Ansatz besteht darin, den erwarteten Zeitpunkt jedes neuen Messwerts zu überwachen.

Das Logging sollte Änderungen des Verbindungsstatus zusammen mit dem jeweiligen Zeitstempel erfassen. Dies vereinfacht das Debugging bei sporadisch auftretenden BLE-Problemen, da Entwickler auf den vollständigen Verlauf zugreifen können. Auch das Backend sollte unabhängig von den Meldungen des Geräts wissen, in welchen Abständen neue Daten erwartet werden. Wird innerhalb des erwarteten Zeitfensters kein neuer Messwert empfangen, sollte eine entsprechende Aktion ausgelöst werden, ohne darauf warten zu müssen, dass die mobile App das Problem erkennt.

Auch beim Parsen der Daten können Fehler auftreten. Diese sollten explizit behandelt werden, anstatt sie zu verwerfen oder zu ignorieren.

Ein Hinweis zur Sensibilität von Daten

Da Glukosedaten sensible Gesundheitsdaten sind, müssen sie während des gesamten Integrationsprozesses angemessen geschützt werden. Für Entwicklungsteams bedeutet dies konkrete Maßnahmen. Dazu gehören die Überprüfung der Identität des Geräts und der durch dessen BLE-Verbindung bereitgestellten Sicherheit, die Verschlüsselung lokal zwischengespeicherter Messwerte sowie die Sicherstellung der Datenübertragung über TLS. Das System sollte außerdem angemessene Zugriffskontrollen für die Daten anwenden, die nach der Erfassung im Backend gespeichert werden.

Datenschutz gilt auch für Logs. Obwohl sie für das Debugging nützlich sind, können sie sensible Daten offenlegen. Dies sollte standardmäßig vermieden werden, und jede Ausnahme erfordert eine vorherige Genehmigung durch die für Sicherheit und Datenschutz zuständigen Abteilungen.

Abwägungen und Einschränkungen

Die Unterstützung mehrerer Anbieter-SDKs erhöht die Größe der App und den Wartungsaufwand, vor allem weil jeder Anbieter seinen eigenen Release-Zeitplan verwaltet. Darüber hinaus bringt jedes eingebundene SDK seine eigenen potenziellen Fehler mit sich. Teams, die sich dieser Herausforderung stellen, implementieren in der Regel eine interne Abstraktionsschicht, um die Komplexität des App-Codes zu reduzieren. Dennoch kann ein SDK neue Verhaltensweisen einführen, die von dieser Schicht nicht berücksichtigt wurden. Die indirekten Kosten lassen sich daher nicht vollständig vermeiden.

Eine Diabetes-App kann die Ausführung im Hintergrund erfordern, insbesondere bei Geräten zur kontinuierlichen Glukosemessung. Weder iOS noch Android garantieren dies. Diese Einschränkung muss bereits in der Designphase ausdrücklich berücksichtigt werden, indem das System so konzipiert wird, dass es auch unter eingeschränkten Bedingungen zuverlässig funktioniert. Zu den üblichen Ansätzen gehören ein eindeutiger Zeitstempel für die letzte Synchronisierung, eine klare Anzeige von Datenlücken sowie Warnmeldungen, die nicht von einer dauerhaft einwandfreien Verbindung als Ausgangsbedingung ausgehen.

Die Lizenzbedingungen von Anbieter-SDKs können Einschränkungen dazu enthalten, wie das SDK gespeichert, dargestellt oder an Dritte weitergegeben werden darf. Dies kann sich auf die Architektur des Systems auswirken. Daher sollten Entwickler die Lizenzvereinbarungen prüfen, bevor die erste Zeile des Integrationscodes geschrieben wird.

Aufbau einer zuverlässigen Integrationsschicht

Eine zuverlässige Geräteintegration für Diabetes-Anwendungen erfordert mehr als nur den Aufbau einer BLE-Verbindung. Auch die Bedeutung und Kontinuität jedes Messwerts müssen erhalten, Hintergrundprozesse verwaltet und Aktualisierungen verschiedener Anbieter-SDKs berücksichtigt werden.

Eine gemeinsame Integrationsschicht erweist sich in der Regel als sinnvolle Architekturentscheidung. Lokale Pufferung, das nachträgliche Laden historischer Daten und Kontinuitätsprüfungen sind sinnvolle Ergänzungen, um Fehler sichtbar zu machen und eine Wiederherstellung zu ermöglichen. Einschränkungen der Plattformen und gerätespezifisches Verhalten bleiben dennoch bestehen und sollten daher von Anfang an im Integrationsplan berücksichtigt werden. Genau darin liegt der Unterschied zwischen Teams, die lediglich einen einfachen Proof of Concept (POC) entwickeln, und Teams, die eine robuste Software für die kontinuierliche Glukoseüberwachung bereitstellen, die auch außerhalb kontrollierter Testbedingungen zuverlässig funktioniert.