Patient Vitals App — Bluetooth Sensor Monitoring
Physical hardware on one end, a phone in the middle, a clinician on the other.
Published anonymously at the client’s request
Overview
A Flutter application that pairs over Bluetooth Low Energy with an Arduino Nano 33 BLE carrying a temperature probe and a heart-rate and blood-oxygen sensor, charts the readings live, and syncs them to the cloud so a clinician can see them from a separate app.
What this proves
That we work past the browser. Device pairing, permission handling and a live sensor stream are a different discipline from web work, and this is that discipline.
Key features
Direct BLE pairing with the sensor board
The app scans for, connects to and subscribes to characteristics on an Arduino Nano 33 BLE running a DS18B20 temperature probe and a MAX30102 pulse-oximetry sensor. Runtime permissions and the location requirement that Android imposes on BLE scanning are both handled explicitly rather than assumed.
Live charting of the reading stream
Incoming values render as continuously updating charts rather than bare numbers, so a trend is visible as it forms — which is what a vital sign is actually read for.
Cloud sync to the clinician app
Readings are written to Cloud Firestore, which is the shared surface between this app and the separate clinician application — the patient device is the source, the clinician device is a reader.
An analytics view over history
A dedicated analytics page reads back the stored series rather than only showing the live window, so the record survives the session.
Firmware supplied with the app
The Arduino sketch and a full wiring guide — pin assignments, the pull-up resistor the temperature probe needs, the required libraries — ship in the repository. The deliverable is the whole system, not just the half that runs on a phone.
The system
Three pieces have to agree: a microcontroller reading two sensors over different protocols — one-wire for temperature, I²C for pulse oximetry — a phone that pairs with it over Bluetooth Low Energy, and a cloud store that a second, separate application reads. This app is the middle piece, and it is the one that has to be robust, because it is the only one a non-technical person touches.
Why it is harder than it looks
Bluetooth Low Energy on Android is a permissions problem before it is a data problem: scanning requires location access on most versions, permissions must be requested at the right moment in the lifecycle, and a refusal has to leave the app in a usable state rather than a dead screen. The app carries explicit permission and geolocation handling for exactly this reason.
It builds for Android, iOS, web, Windows, macOS and Linux from one Dart codebase — though only the mobile targets are meaningful for a Bluetooth application.
Not demonstrated by this project
Stated plainly, because a portfolio is more useful when it is precise about its limits.
- No clinical validation — this is a monitoring tool, not a certified medical device
- No automated tests
- The whole application lives in a single Dart file
- No authentication — device identity, not user identity, scopes the data
- English only, and no Arabic or RTL interface
- No offline queue — readings taken without connectivity are not backfilled
Portfolio assessment
- Visual design
- 5.0 / 10
- Technical complexity
- 8.0 / 10
- Interactivity
- 6.0 / 10
- Business value
- 7.0 / 10
- Portfolio appeal
- 7.0 / 10