Die erste Gesundheitsintegration: FreeStyle Libre 3 Glukose

Ein kontinuierlicher Glukosesensor am Arm Foto: Bango Renders · StockSnap (CC0 1.0), via Openverse

Es gibt Momente in einem Produkt, in denen aus einer Idee ein Versprechen wird. Für Xircuit war das der Tag, an dem der erste echte Messwert aus einem echten Sensor in der Plattform ankam. Bis dahin waren Gesundheitsdaten für uns ein abstraktes Konzept — Tabellen, Diagramme, Platzhalter. Danach waren es die Blutzuckerwerte eines Menschen, alle paar Minuten, kontinuierlich, unaufhörlich.

Diese Woche geht es genau darum: um die erste Gesundheitsintegration, die wir gebaut haben, und um die Entscheidungen, die sie zu mehr gemacht haben als nur einer weiteren Datenquelle. Der Abbott FreeStyle Libre 3 war unser Anfang — und ganz bewusst auch die Blaupause für alles, was danach kommt.

Warum ausgerechnet Glukose zuerst

Man könnte meinen, Schritte oder Herzfrequenz wären der naheliegendere Einstieg gewesen. Diese Daten sind harmloser, sie fallen bei fast jedem an, und sie sind technisch einfacher zu handhaben. Wir haben uns bewusst gegen den einfachen Weg entschieden.

Kontinuierliche Glukosemessung ist der anspruchsvollste Fall, den wir uns vorstellen konnten. Die Werte sind hochsensibel, sie sind medizinisch relevant, und sie kommen in einer Dichte an, die keine Kompromisse bei Speicherung und Verschlüsselung erlaubt. Wenn eine Integration diesen Fall sauber löst, dann löst sie alle folgenden mit Leichtigkeit. Der Abbott FreeStyle Libre 3 wurde damit zu unserem Härtetest — und er läuft inzwischen live im Produktivbetrieb.

Fünf Ausbaustufen statt eines großen Wurfs

Ich habe früh gelernt, dass große Integrationen selten an der eigentlichen Aufgabe scheitern, sondern daran, dass man versucht, alles gleichzeitig zu bauen. Deshalb haben wir die Libre-3-Anbindung in fünf klar getrennte Ausbaustufen zerlegt und jede für sich fertiggestellt, bevor die nächste begann.

Anbindung: Zuerst der reine Zugang zur Datenquelle — Authentifizierung, Abruf, das Verstehen des fremden Datenformats.
Datenmodell: Dann die Frage, wie ein Glukosewert in Xircuit überhaupt aussieht. Zeitstempel, Einheit, Herkunft, Kontext.
Synchronisation: Als Drittes das verlässliche, wiederholbare Einlaufen der Werte in die Plattform.
Anzeige: Erst danach die Darstellung — Verläufe, Trends, das, was die Nutzerin am Ende tatsächlich sieht.
Absicherung: Und zuletzt die Verschlüsselung der sensiblen Messwerte, als eigene, abschließende Stufe.

Diese Reihenfolge klingt selbstverständlich, ist es aber nicht. Jede Stufe hatte einen definierten Zustand, in dem sie „fertig“ war, und keine baute auf halbfertigen Annahmen der vorherigen auf. Das hat uns davor bewahrt, am Ende ein Geflecht zu haben, das niemand mehr auseinandernehmen kann.

Ein eigener Schlüsselring für die Messwerte

Die vielleicht wichtigste Entscheidung betraf die Absicherung. Blutzuckerwerte sind keine gewöhnlichen Daten. Sie erlauben Rückschlüsse auf Krankheiten, auf Verhalten, auf den Zustand eines Menschen über Wochen hinweg. Eine einfache Verschlüsselung „irgendwo in der Datenbank“ kam für uns nicht in Frage.

Stattdessen haben wir einen eigenen Schlüsselring gebaut. Die Schlüssel selbst liegen in Azure Key Vault, während das Schlüsselmaterial für die eigentliche Datenverschlüsselung in Azure Blob Storage verwaltet wird. Der Gedanke dahinter: Der Ort, an dem die Werte liegen, und der Ort, an dem die Schlüssel liegen, sind sauber getrennt. Wer das eine hat, hat noch lange nicht das andere. Der Schlüsselring erlaubt es uns außerdem, Schlüssel zu rotieren, ohne bestehende Daten neu verschlüsseln zu müssen — jeder Datensatz weiß, mit welchem Schlüssel er gesichert wurde.

Dieser Aufwand mag für eine erste Integration übertrieben wirken. Aber gerade weil es die erste war, wollten wir das Fundament richtig legen. Alles, was danach an Gesundheitsdaten dazukommt, erbt diese Absicherung, ohne dass wir sie ein zweites Mal erfinden müssen.

Ein Schlüssel als Sinnbild für Verschlüsselung Foto: Rawpixel (CC0 1.0), via Openverse

Ein dedizierter Worker und das Problem der Dubletten

Glukosewerte laufen nicht direkt über die Web-Anwendung in die Plattform, sondern über einen eigenen, dedizierten Worker. Das hat einen einfachen Grund: Die Verarbeitung von kontinuierlichen Messreihen ist ein Hintergrundproblem, kein Anfrage-Antwort-Problem. Ein Sensor liefert Werte im Minutentakt, unabhängig davon, ob gerade jemand die App geöffnet hat. Ein Worker, der entkoppelt vom Nutzerinteraktions-Pfad arbeitet, passt zu dieser Realität deutlich besser.

Der interessanteste Teil dieser Verarbeitung ist die Deduplizierung. Kontinuierliche Messung bedeutet, dass sich Synchronisationsläufe überlappen — dieselbe Stunde wird beim nächsten Abruf oft erneut mitgeliefert. Ohne Gegenmaßnahme würde jeder Lauf denselben Wert ein weiteres Mal einfügen, und die Verläufe wären voller Geister. Wir lösen das über Stundenschlüssel: Jeder Messwert bekommt einen deterministischen Schlüssel aus seinem Zeitraum, und ein doppelter Schlüssel wird schlicht verworfen statt erneut gespeichert. Das Ergebnis ist idempotent — egal, wie oft ein Zeitraum synchronisiert wird, in der Plattform landet er genau einmal.

Solche Details entscheiden über die Qualität einer Gesundheitsintegration. Ein Diagramm, das denselben Ausschlag zweimal zeigt, ist schlimmer als eine Lücke, weil es Vertrauen zerstört. Deshalb steckt in dieser scheinbar kleinen Regel überraschend viel Sorgfalt.

Das Muster für alles, was folgt

Was diese Integration über sich selbst hinaushebt, ist ihre Struktur. Wir haben sie so gebaut, dass sie eine Vorlage ist: eine eigene Provider-Bibliothek, die alles Anbieterspezifische kapselt, ein eigener Synchronisationspfad, und ein eigener Worker für die Hintergrundverarbeitung. Drei klar abgegrenzte Bausteine, die zusammen eine Integration ergeben.

Der Wert dieses Musters zeigt sich erst mit der zweiten und dritten Quelle. Jede neue Integration bekommt ihre eigene Provider-Bibliothek, statt sich in einen gemeinsamen Sammelbrocken zu drängen. Jede bekommt ihren eigenen Sync und ihren eigenen Worker, sodass ein Fehler in einer Quelle nie die anderen mitreißt. Die Verschlüsselung, das Datenmodell, die Deduplizierung — all das ist bereits durchdacht und muss nur noch angewendet werden. Der FreeStyle Libre 3 hat uns nicht nur eine Datenquelle gebracht, sondern eine wiederverwendbare Architektur, an der wir uns von nun an entlanghangeln.

Rückblickend war die bewusste Entscheidung, mit dem schwierigsten Fall zu beginnen, genau richtig. Sie hat uns gezwungen, jede Frage sofort ernst zu beantworten — statt sie zu vertagen, bis es weh tut.