The First Health Integration: FreeStyle Libre 3 Glucose

A continuous glucose sensor on an arm Photo: Bango Renders · StockSnap (CC0 1.0), via Openverse

There are moments in a product when an idea turns into a promise. For Xircuit, that was the day the first real reading from a real sensor arrived in the platform. Until then, health data had been an abstract concept for us — tables, charts, placeholders. After that, it was one person's blood glucose readings, every few minutes, continuous, relentless.

This week is exactly about that: the first health integration we built, and the decisions that made it more than just another data source. The Abbott FreeStyle Libre 3 was our starting point — and quite deliberately the blueprint for everything that comes after.

Why Glucose, of All Things, Came First

You might think steps or heart rate would have been the more obvious starting point. That data is more harmless, it's generated by almost everyone, and it's technically easier to handle. We deliberately chose against the easy path.

Continuous glucose monitoring is the most demanding case we could imagine. The readings are highly sensitive, they're medically relevant, and they arrive at a density that allows no compromises on storage and encryption. If an integration solves this case cleanly, it solves every subsequent one with ease. The Abbott FreeStyle Libre 3 thus became our stress test — and it's now running live in production.

Five Stages Instead of One Big Leap

I learned early on that big integrations rarely fail because of the actual task, but because you try to build everything at once. That's why we broke the Libre 3 connection down into five clearly separated stages and finished each one on its own before the next began.

Connection: First, plain access to the data source — authentication, retrieval, understanding the foreign data format.
Data model: Then the question of what a glucose reading even looks like in Xircuit. Timestamp, unit, origin, context.
Synchronization: Third, the reliable, repeatable ingestion of readings into the platform.
Display: Only after that, the presentation — trends, charts, what the user actually ends up seeing.
Security: And last, the encryption of the sensitive readings, as its own, final stage.

This order sounds obvious, but it isn't. Every stage had a defined state at which it was "done," and none of them built on half-finished assumptions from the previous one. That saved us from ending up with a tangle nobody could take apart anymore.

A Dedicated Key Ring for the Readings

Perhaps the most important decision concerned security. Blood glucose readings aren't ordinary data. They allow inferences about illnesses, about behavior, about a person's condition over weeks at a time. Simple encryption "somewhere in the database" was out of the question for us.

Instead, we built our own key ring. The keys themselves live in Azure Key Vault, while the key material for the actual data encryption is managed in Azure Blob Storage. The idea behind it: the place where the values live and the place where the keys live are cleanly separated. Having one gets you nowhere close to having the other. The key ring also lets us rotate keys without having to re-encrypt existing data — every record knows which key secured it.

This effort might seem excessive for a first integration. But precisely because it was the first, we wanted to lay the foundation properly. Every piece of health data that gets added after this inherits that security, without us having to reinvent it a second time.

A key as a symbol for encryption Photo: Rawpixel (CC0 1.0), via Openverse

A Dedicated Worker and the Duplicate Problem

Glucose readings don't flow into the platform directly through the web application, but through a dedicated worker of their own. There's a simple reason for that: processing continuous measurement series is a background problem, not a request-response problem. A sensor delivers readings every minute, regardless of whether anyone happens to have the app open right now. A worker that operates decoupled from the user interaction path fits this reality much better.

The most interesting part of this processing is deduplication. Continuous measurement means sync runs overlap — the same hour often gets delivered again on the next fetch. Without a countermeasure, every run would insert the same reading again, and the charts would be full of ghosts. We solve this with hourly keys: every reading gets a deterministic key derived from its time window, and a duplicate key is simply discarded instead of being stored again. The result is idempotent — no matter how often a time window gets synced, it ends up in the platform exactly once.

Details like these determine the quality of a health integration. A chart that shows the same spike twice is worse than a gap, because it destroys trust. That's why this seemingly small rule holds a surprising amount of care.

The Pattern for Everything That Follows

What lifts this integration above itself is its structure. We built it to be a template: a dedicated provider library that encapsulates everything vendor-specific, a dedicated sync path, and a dedicated worker for background processing. Three clearly separated building blocks that together make up an integration.

The value of this pattern only shows up with the second and third source. Every new integration gets its own provider library, instead of being squeezed into one shared catch-all. Every one gets its own sync and its own worker, so that a failure in one source never drags the others down with it. Encryption, the data model, deduplication — all of that is already worked out and just needs to be applied. The FreeStyle Libre 3 didn't just give us one data source, it gave us a reusable architecture we can now follow going forward.

In hindsight, the deliberate decision to start with the hardest case was exactly right. It forced us to answer every question seriously right away — instead of postponing it until it hurt.