Wearable Dashboard

My role

Garmin integration and integration dashboard

The problem

Digital health research increasingly relies on wearables for continuous monitoring, as in the EU LETHE project. That runs into a practical wall: participants own different devices, every vendor exposes a different API, and every vendor returns a different shape of data. The alternative is handing every participant the same watch, which is expensive and changes behaviour.

How it works

• I connected the Garmin Health API end to end: the OAuth 2.0 PKCE authorisation flow, and real-time webhook push ingestion rather than polling. Garmin sends data when it has data, which means the interface has to accept and validate a payload it did not ask for, at a moment it did not choose.
• I built the integration dashboard: connection state per vendor, session browsing and the configuration surface.
• The architecture separates API communication, data transformation and output generation, so adding a vendor does not mean rewriting the pipeline.
• Data harmonisation, the Catapult integration and the backend pipeline were built by other members of the team.

Stack

TypeScript, HTML and CSS on the frontend. PostgreSQL for raw data handling, Python for harmonisation and transformation, AWS S3 for data acquisition, Git, Docker and Azure for infrastructure.

What I take from it

Webhook ingestion changed how I think about interfaces. With polling you decide when data arrives and what you are ready for. With push you get handed something at a moment you did not pick, in a shape you have to verify before you trust it, and every assumption you made about ordering quietly becomes a bug.

Outcome

The interface enables device-independent data acquisition. Data from different vendors ends up in a consistent internal representation, which makes it comparable across devices, reduces manual preprocessing, and lets further vendors be added without touching what already works. Published by FH JOANNEUM.