Remote hypertension monitoring, end to end.
Developed as a team project during the MSc program at FH Technikum Wien, this platform addresses the challenge of continuously collecting and acting on health data from wearable devices — specifically for remote hypertension monitoring. The goal is to provide patients and clinicians with timely, reliable health insights while keeping sensitive data secure and private.
The system architecture is structured around the IoT World Forum (IoTWF) 7-layer reference model, mapping each component of the platform to a specific layer — from physical sensors through connectivity, edge processing, cloud storage, and application logic up to the clinician-facing workflow.
Why IoTWF?
The IoT World Forum Reference Model was chosen as the structural backbone of the system design for three key reasons:
CLEAN SEPARATION
Each layer has a distinct responsibility — from physical device to clinician workflow — making the system easier to reason about, develop, and maintain.
EDGE TO CLOUD
The model naturally expresses the edge-cloud boundary, making it straightforward to show where data is processed locally versus in the cloud.
COMPLIANCE MAPPING
Security controls and privacy requirements can be attached to specific layers, making compliance reasoning structured and traceable.
Seven-layer architecture
The IoTWF reference model provided the structural backbone of the design. Each layer has a clear responsibility, and transitions between layers follow open, vendor-neutral protocols.
LAYER 1 — PHYSICAL
Blood pressure cuffs and wearable sensors capturing time-stamped health measurements at the patient's location.
LAYER 2 — CONNECTIVITY
Bluetooth Low Energy (BLE) link between the wearable and the smartphone gateway. Wi-Fi or cellular for the smartphone-to-cloud hop.
LAYER 3 — EDGE COMPUTING
The smartphone acts as the edge node — validating incoming readings, deduplicating data, and running immediate threshold checks to catch critical alerts before data leaves the device.
LAYER 4 — DATA ACCUMULATION
Validated telemetry is ingested into the cloud via a secure API. An MQTT broker distributes events across the backend — telemetry to storage, alerts to the notification service.
LAYER 5 — DATA ABSTRACTION
A time-series database (TSDB) stores health signals for trend analysis. A data lake provides scalable long-term storage for combining structured and unstructured health data across sources.
LAYER 6 — APPLICATION
Alert services trigger clinician workflows with acknowledgement logging. Dashboards provide real-time and historical views via WebSocket updates.
LAYER 7 — COLLABORATION
Role-based access separates patient and clinician views. Audit logs track alert creation and clinician acknowledgement to support accountability and compliance.
MVP technical data flow
Splitting responsibilities
A deliberate edge-cloud split was designed to keep latency and bandwidth low, and to avoid sending raw sensitive data to the cloud unnecessarily.
EDGE (SMARTPHONE)
Handles BLE connectivity, data filtering and deduplication, and immediate threshold-based alerts. Acts as a firm real-time layer — late alerts here are useless.
CLOUD (BACKEND)
Handles durable TSDB storage, long-term analytics, alert audit trail, and device fleet management. Operates on a soft real-time basis where short delays are acceptable.
Vendor-neutral design
All protocol choices follow open standards from bodies including IETF, IEEE, ETSI, CSA, and OMA SpecWorks — ensuring interoperability and avoiding vendor lock-in.
Team & institution
FH TECHNIKUM WIEN
Developed during the MSc program in IoT and Embedded Systems at FH Technikum Wien, Vienna — 2026.
TEAM PROJECT
Collaborative engineering project combining embedded systems, cloud architecture, and IoT system design expertise.