Wearables | Soroush Dianaty, M.D.

GaitScope: A Browser Lab for Movement-Sensor Signal Processing

Wed, 23 Sep 2026 00:00:00 +0000

GaitScope is an interactive lab, in the browser, for learning how movement-sensor signals are processed. You record or load a walk from a phone’s accelerometer, then filter it, look at its spectrum, and put several step detectors on the same plot to see where and why they disagree. There is nothing to install, and files never leave the browser.

At a glance


Status	Early development. Started 2026-09-23; version 0.1.0, no tagged release yet. Features still change from week to week.
Role	Maintainer: directs and reviews all work; code, tests and documentation largely written with Claude Code (Anthropic’s AI coding assistant) — see
Origin	A class project in BME 598/494 Wearable Devices for Sport, Health, and Wellness (ASU, Dr. Aurel Coza), Fall 2026
Domain	Wearable sensing, digital signal processing, education
License	MIT for now; a move to AGPL-3.0 is planned, pending the course instructor’s permission for the port of the course detector ( )
Repository
Live app

Why it exists

The course provides a MATLAB step-detection script, LabStepDet_2025.m, and a sample recording. Students may skip MATLAB and use an AI tool to run the code instead. GaitScope started there, with a Python port of the script and a browser dashboard to run it on other recordings.

Working through the script made a broader point visible. A step count depends on choices that are easy to miss: the sampling rate the code assumes, the threshold, which axis of the phone you analyse, where the phone sits on the body, and how ties and stray peaks are handled. GaitScope puts those choices on the screen, so a student can change one and see what happens to the steps.

What it does

Bring a walk.

Upload a MATLAB .mat file (v5 to v7.3), a Physics Toolbox Sensor Suite CSV export, a phyphox export zip, or any CSV with numbers in columns.
Or record a walk on a phone with the browser’s motion sensors, with no app to install. The page asks how many steps you counted and where the phone was, and compares your count with the detectors.
Reopen a previous analysis from a GaitScope JSON export.

Check the file. Every file is checked against a documented before analysis. The rule is to be strict where bad input would give wrong numbers with no visible sign, and lenient where a person looking at the plot can judge. Each problem comes with a concrete fix, such as the MATLAB line to re-save a file in a readable format.

Prepare the signal.

Pick x, y, z or the magnitude; when the recording includes gravity, also the vertical and horizontal acceleration.
Resample to a chosen rate (linear or monotone cubic, with optional anti-aliasing).
Filter: Butterworth, Bessel, Chebyshev I and II, elliptic, moving average, median, Savitzky–Golay, wavelet denoising and notch.

Detect steps. Detectors and envelopes work like indicators on a chart: any number on the plot at once, each with its own settings, colour and source signal (filtered or recorded), and its own metrics column.

Coza: the course’s detector, ported exactly as written.
Coza (modified): a variant of the same detector. It counts tied peaks once, drops start and stop artefacts, uses a window in seconds and real timestamps, and reports cadence.
Threshold peaks, Peak-to-valley and Zero-crossing: three textbook detectors, each credited to its source.
Envelopes and bands: sliding window, peak-trough, dynamic threshold, mean ± k·SD, Hilbert envelope and percentile band. They are a view only and never change the steps.

Read the results.

Metrics per detector: steps, step duration, cadence, step-time variability, gait asymmetry, walking span and harmonic ratio. All detectors’ metrics come from the same function, working only from step times, so the columns compare directly.
Frequency domain: a whole-recording view (Welch’s spectrum, Lomb–Scargle, autocorrelation) and an over-time view (spectrogram, Morlet wavelet scalogram, wavelet bands, Hilbert–Huang spectrum). Walking shows as a peak, which gives a cadence without detecting any steps. That is an independent cross-check on the detectors.
Step intervals, a steps table, and notes pinned to the plot or the spectrum (“turned around”, “counted twice”).

Export in the format each tool expects: CSV, a zip of CSVs, a MATLAB .mat struct, NumPy .npz (no pickle), or JSON, which reopens the whole analysis in GaitScope. Sample numbers are 1-based, as in MATLAB.

Python port. python/lab_step_det.py is a 1:1 translation of the course script. It reads the same file types and writes the same export layout.

How the methods are checked

The repository separates three kinds of evidence and states the limit of each.

1. The course detector matches the original script. On the course’s sample walk, the dashboard, the Python port and GNU Octave running LabStepDet_2025.m give identical steps and metrics on all three axes. Limit: the course files are not in the repository, so this check runs only on a machine that has them, not in continuous integration. CI checks the same code on a synthetic walk.

2. Each method agrees with an established library. Test fixtures are generated by the reference implementation, and the tests compare against them on every pull request:

Method	Reference	Tolerance
IIR filters (Butterworth, Bessel, Chebyshev I/II, elliptic)	scipy	1e-9
Moving average, median, Savitzky–Golay, wavelet denoising, notch	scipy, PyWavelets	1e-9
Resampling	the Python port (numpy, scipy)	linear bit for bit; cubic and anti-aliased 1e-12
FFT, Welch, spectrogram	numpy, scipy	1e-12 (relative)
Lomb–Scargle, autocorrelation	scipy, numpy	1e-12, 1e-13
Morlet wavelet transform, Daubechies-4 bands	PyWavelets	1e-10 (relative), 1e-12
Empirical mode decomposition	PyEMD	1e-9

Every export format is read back with an independent reader (scipy, numpy, Python’s zipfile and csv, and Octave when installed). Limit: agreement is shown on test inputs. It is evidence that the code computes the intended method, not proof for every input.

3. A few real walks with hand-counted steps. On 2026-10-07 the maintainer recorded four walks with the dashboard and counted the steps: three on a Pixel 9a (10, 28 and 60 steps) and one on an iPad (24 steps). Inside the walk, Coza (modified), Threshold peaks, Peak-to-valley and Zero-crossing were within 2 of the count on the total acceleration and within 1 on the vertical. The unmodified Coza found 45 of 60 at the phone’s rate of about 60 Hz, because its window is counted in samples and assumes 100 Hz; resampled to 100 Hz, it found all 60. Limit: one person, two devices, a normal pace, two phone positions. That is too little to rank the detectors or to call any of them accurate.

Signal pipeline

flowchart TD A["Load or record
.mat, Physics Toolbox CSV, phyphox zip,
any CSV, phone recording, JSON export"] --> B["Input-schema checks
error / warn / info, each with a fix"] B --> C["Signal to analyse
x, y, z, magnitude, vertical, horizontal"] C --> D["Resample (optional)
linear or pchip, anti-aliasing"] D --> E["Filter (optional)"] E --> F["Step detectors
Coza, Coza (modified), Threshold peaks,
Peak-to-valley, Zero-crossing"] D -. "recorded signal" .-> F E --> G["Envelopes and bands
view only"] F --> H["Metrics
one function for every detector"] E --> I["Frequency domain
spectral cadence, steps from the rhythm"] I -. "cross-check" .-> H H --> J["Export
CSV, zip, .mat, .npz, JSON"] G --> J

The browser app is a static page with no build step: plain JavaScript, with Plotly for the charts. The computational core (src/core.js) has no DOM access, so the same code runs under Node in the tests.

Status and roadmap

Development started on 2026-09-23. The app is live and usable, but there is no tagged release yet and behaviour still changes. The plan lives in the . The main open threads:

Licence and purpose: move to AGPL-3.0 and settle the educational aim, after the instructor’s permission ( , ).
More counted walks: a back pocket, slow and fast walks, other people, and an iPhone, which has not been tested yet ( , ).
A citable release: tag v0.1.0 and archive it on Zenodo for a DOI ( ). Until then, cite the software through its CITATION.cff, with the version used.
An optional tutor: research into what a language-model tutor running in the browser would cost, and whether small models are good enough ( , ).
Plugins for user-supplied detectors, envelopes and filters ( ).

What it is, and what it isn’t

It is a teaching and exploration tool. It is for students and instructors who want to see what a filter, a spectrum or a step detector does to a real signal, and why two detectors disagree.
It is not a validated gait-measurement instrument. Step counts, cadence and the other metrics have been compared with hand-counted steps on a few walks by one person, nothing more. They have not been validated across people, devices or walking conditions, or against a reference system such as an instrumented walkway.
It is not for clinical use. Do not use it to diagnose, monitor or make decisions about anyone’s health.

Other known limits:

Phone recording needs https and the screen on. Browsers stop sending motion data when the screen locks, so a recording ends there ( ).
Whether each peak is a step or a stride depends on the axis and where the phone is carried; how the page should decide is still under investigation ( ).
The Python port covers only the course detector; the other detectors and the harmonic ratio are not ported yet ( ).
The page loads its charting libraries from a CDN, so it needs an internet connection.

Use in teaching

GaitScope is built for the questions a signal-processing or wearables lab tends to raise: what does this filter remove, why does the spectrum show a peak at half the step rate, why does the same detector find different steps at 60 Hz and 100 Hz. Each method shows its settings and credits its authors, with a DOI where one exists, on the page and in exports.

Its use in a course has not been settled. How the educational side will work is still to be decided ( ), and questions to the course instructor, including whether a Python version is acceptable for submissions, are open ( ). Students taking BME 598/494 are asked to check the course’s rules before contributing, since a contribution may count as shared work on an assignment.

Credits

Coza and the course’s sample walk come from BME 598/494 Wearable Devices for Sport, Health, and Wellness (ASU, Dr. Aurel Coza). The course files are not in the repository; the detector is ported and credited to Dr. Coza.
Coza (modified): Soroush Dianaty.
Every other method credits its authors on the page and in exports; the full list is under Credits in .
Who did what, including the use of AI, is recorded in .

: the research pillar on wearable sensor data. GaitScope is a teaching tool rather than part of that research, but it works with the same kind of signal.

vitals-on-fhir: Consumer Wearables and Home Health Devices to HL7 FHIR R4

Mon, 21 Sep 2026 00:00:00 +0000

Many consumer wearables and home health devices keep their data inside vendor apps, yet many of them also speak open Bluetooth health standards. vitals-on-fhir reads vital signs from those open channels and exposes them as HL7 FHIR R4 Observations that follow the US Core vital-signs profiles, so any FHIR-capable system can use them without a device-specific integration. It currently covers heart rate, blood pressure, oxygen saturation, body temperature, and body weight.

Not a medical device. vitals-on-fhir is a research and educational proof-of-concept for healthcare interoperability. It is not for diagnosis, treatment, or any clinical decision-making. It is not HIPAA-compliant, keeps data in memory only, and is not designed for untrusted networks.

At a glance


Status	Early development, version 0.1.0 (no tagged release yet). Heart rate is tested on one real device; the other four vital signs are tested without hardware.
Role	Maintainer and developer. Started as a BMI 540 team project at Arizona State University (team: Soroush Dianaty, MD; Nusrat Ashrafi, MS; Isha Uttham, BS; instructor: Sheetal Shetty, PhD). Developed spec-first, with Claude (via Claude Code) as author or co-author of most commits.
Domain	Health interoperability, patient-generated health data, Bluetooth health devices
License	GNU AGPL-3.0-or-later
Repository

Problem

Wearables and home devices such as blood-pressure cuffs, pulse oximeters, thermometers, and scales produce data that patients and caregivers might want in a health record or a research pipeline. Usually that data reaches other systems only through each vendor’s app and cloud. Building one integration per device does not scale.

Many of these devices also support standard Bluetooth Low Energy health services defined by the Bluetooth SIG, such as the Heart Rate Service and the Blood Pressure Service. FHIR, US Core, LOINC, and UCUM already define how vital signs should look in a health record. What is missing is a small, inspectable piece that connects the two: it reads the open Bluetooth channel and produces FHIR that validates.

The repository’s standards review also raises a second problem. Data that a patient collects at home should not look the same as vital signs recorded by a clinician, and simulated data should never be mistaken for real measurements.

Approach

Open channels only. The project reads only standard Bluetooth health services and documented formats. Proprietary or reverse-engineered protocols are permanently out of scope. Every payload parser cites the Bluetooth SIG specification it implements.
The bridge, not the app. The core takes in readings and produces FHIR. The dashboard is a demonstration consumer of the FHIR API. Analytics and clinical decision support are out of scope.
Metadata-driven mapping. Each vital-sign class declares its LOINC codes, UCUM unit, and US Core profile. Generic mappers build the Observation from that metadata, so adding a vital sign needs no new mapper code.
Careful with device-reported context. Measurement time, the thermometer’s body site, readings the device flags as unreliable, and which user of a shared cuff or scale took the reading are each either kept or acted on. Each choice is recorded in a decision record.
Checked against the standard. An Observation from each simulated adapter was last checked by hand with the HL7 FHIR validator (6.10.4) against US Core 9.0.0, with no errors. Adding this check to CI is an open issue.

Architecture

flowchart LR D["BLE device
(standard health service)"] --> A["Adapter + payload parser
yields VitalSign objects"] M["Mock adapter
(simulated, labelled HTEST)"] --> A A --> V["Validator chain
range, sensor contact,
device status, device user,
duplicates"] V --> F["FHIR mapper
VitalSign to US Core Observation"] F --> S{"Output sinks"} S --> ST[("In-memory
Observation store")] S --> WS["Dashboard broadcaster
(WebSocket)"] ST --> API["Read-only FHIR R4 API
(bearer token)"]

An adapter connects to one device and yields immutable vital-sign objects. Adapters do not import FHIR code. One shared Bluetooth connection helper handles scanning, subscribing, and reconnecting for every standard service.
A validator chain accepts or rejects each reading. Rejections are logged without the measurement value.
A FHIR mapper turns each accepted reading into an R4 Observation from the class metadata. A registry chooses the mapper by type, with one mapper for single-value vital signs and one for multi-component vital signs such as blood pressure.
Sinks receive each Observation: an in-memory store behind the read-only API, and a broadcaster that pushes it to the dashboard.

Every extension point is an abstract base class: vital-sign types, adapters, parsers, validators, mappers, stores, sinks, and authenticators. A third-party adapter can be selected by its import path without changing the repository. Tests that parse every module enforce the package boundaries, so adapters cannot import FHIR code, for example.

FHIR API (read-only). GET /fhir/metadata, /fhir/Observation (search by code, date, _sort=-date, _count), /fhir/Observation/{id}, /fhir/Patient/{id}, and /fhir/Device/{id}. Responses use application/fhir+json, and searches return searchset Bundles. Token and date search follow FHIR semantics, including date precision and the eq/ge/gt/le/lt prefixes.

Dashboard. A local web page shows safety notes and asks for the token on its start page. It then shows the live heart rate, the source device, the connection status with the reason when no device is connected, a scrolling heart-rate chart, and each reading as the FHIR Observation the server produced. With the mock adapter, it can also simulate heart-rate patterns such as sinus rhythm, atrial fibrillation, SVT, an exercise ramp, an off-wrist sensor, or a disconnect. These imitate heart rate only, with no ECG.

Supported vital signs

Vital sign	Bluetooth service	Adapters (real / simulated)	LOINC	UCUM	US Core 9 profile
Heart rate	Heart Rate `0x180D`	`miband10` / `mock`	`8867-4`	`/min`	Heart Rate
Blood pressure	Blood Pressure `0x1810`	`bp` / `mock-bp`	`85354-9` panel; `8480-6` systolic, `8462-4` diastolic	`mm[Hg]`	Blood Pressure
Oxygen saturation	Pulse Oximeter `0x1822`	`spo2` / `mock-spo2`	`59408-5` and `2708-6`	`%`	Pulse Oximetry
Body temperature	Health Thermometer `0x1809`	`temp` / `mock-temp`	`8310-5`	`Cel`	Body Temperature
Body weight	Weight Scale `0x181D`	`weight` / `mock-weight`	`29463-7`	`kg`	Body Weight

Hardware status. Heart rate is tested on a Xiaomi Smart Band 10. The cuff, oximeter, thermometer, and scale adapters follow the Bluetooth specifications and pass hardware-free tests, but none has been tried with a specific device yet.
Units are normalized: kPa to mmHg, °F to °C, and pounds to kilograms. Mean arterial pressure is not modelled because the device calculates it rather than measuring it directly.
For oxygen saturation, only the continuous-measurement stream is read. Spot-check measurements are deferred.
The default range limits only reject values a living body cannot produce, such as 20–250 bpm or 10–47 °C. They are not clinical thresholds.

Design decisions

The project records its decisions as ADRs (architecture decision records) and records findings in briefs before deciding.

ADR-0001: Open phase 2 (home health devices). The four new vital signs were delivered one spec at a time, with blood pressure first because it was the first multi-component vital sign. Components are typed class metadata, so the domain model stays FHIR-free. The Bluetooth lifecycle is shared through composition, not another level of inheritance. SMART on FHIR and durable storage were deliberately deferred because the project has no remote or multi-user deployment to protect yet.
ADR-0002: Mark patient-generated and simulated data. Every Observation sets performer to the Patient and adds the HL7 Personal Health Device IG’s phd category next to vital-signs. Simulated readings and their Device carry the HTEST security label. Each candidate marker was run through the HL7 validator first. The proposed US Core patient-supplied tag was not used because it produced validation errors against the published code system.
ADR-0004: Shared cuffs and scales. Multi-user devices tag each reading with a user ID. The service records only the configured user’s readings, and by default it rejects every reading from a multi-user device until that user is set. The ID is compared and then discarded. It is never logged, stored, or put into FHIR.
ADR-0005: Honour device-reported status. Blood-pressure and oximeter readings that the device marks as invalid, questionable, or not final are rejected rather than published as final. A cuff’s “irregular pulse” flag is accepted because it is a clinical finding, not a faulty reading. Rejecting it would drop every reading from a person with atrial fibrillation.
ADR-0006: Temperature measurement site. The thermometer’s reported site goes into Observation.bodySite as a SNOMED CT concept. The site is never guessed: “Body (general)” or a missing field gives no bodySite.
Brief: validation modes. If personal or clinical thresholds are added later, they should flag readings, for example through interpretation, and never drop them. An abnormal but real reading is the one a caregiver most needs to see.

ADR-0003 is reserved for a planned session capture and review feature, which is currently a brief. A standards-alignment brief compares the project with published guidance on bringing patient-generated data into EHRs (Dinh-Le et al., 2019; the IFCC C-MHBLM recommendations, 2024), the HL7 Personal Health Records IG, and SMART App Launch. The gaps it found became tracked issues, and most of them led to the ADRs above.

Getting started

Requirements: Python 3.12+, , and a Bluetooth LE adapter only if you use a real device.

git clone https://github.com/soroushdty/vitals-on-fhir.git
cd vitals-on-fhir
uv sync
uv run vitals-on-fhir # demo mode: simulated heart rate, no token needed

Then open http://127.0.0.1:8000/. Other simulated vital signs use --adapter mock-bp, mock-spo2, mock-temp, or mock-weight.

A real device always requires a token. Set VOF_API_TOKEN in .env (copy it from .env.example), enable heart-rate broadcast on the band, and run:

uv run vitals-on-fhir --adapter miband10

To query the API:

curl -H "Authorization: Bearer $VOF_API_TOKEN" \
 "http://localhost:8000/fhir/Observation?code=http://loinc.org|8867-4&_sort=-date&_count=10"

Development checks: uv run pytest (hardware-free suite), uv run pytest -m hardware (needs a real band), uv run ruff check ., and uv run mypy src. CI runs lint, a format check, strict type checks, and the hardware-free tests on every pull request.

Status and roadmap

The project is young. The first commit is from 21 September 2026, and the most recent changes are from 8 October 2026.

Heart rate from wearables: delivered.
Home health devices over standard Bluetooth profiles: in progress. All four vital signs (blood pressure, SpO2, temperature, weight) have shipped.
Phone health aggregators (Android Health Connect, Apple HealthKit): planned. This would be the route for devices with proprietary Bluetooth.
Persistence and outbound integration (durable storage, pushing to external FHIR servers, SMART on FHIR): planned. TLS, audit logging, and encryption at rest are listed as prerequisites.
Additional adapters as separately licensed packages: planned.

Each later phase is opened by its own decision record.

The project plans a preprint. The open work toward it includes running the HL7 validator in CI, measuring from git history what each new vital sign took to add, measuring device-to-Observation latency, documenting the development method (including AI assistance), and tagging a citable v0.1.0 release. None of these measurements exist yet.

Limitations and safety

Not a medical device. Research and education only. Not for diagnosis, treatment, or clinical decisions. The simulated heart-rate scenarios are not a diagnosis.
Not for real patient data in production. It is not HIPAA-compliant and has no TLS, audit log, or encryption at rest. It binds to 127.0.0.1 by default.
Bluetooth is unauthenticated. While heart-rate broadcast is on, any nearby device can read the stream. Turn broadcast off when you are not using it.
Limited hardware testing. Only heart rate has been tested on a real device, the Xiaomi Smart Band 10. The other four adapters have not yet been tried with real devices.
Standard-channel limits. The service receives live data only, with no stored history. Wearables send device-computed beats per minute, not raw PPG. Some devices need a workout mode for broadcast. Apple Watch, Oura, and most Wear OS watches have no open real-time channel.
Scope. The service reads one device at a time, for one local patient, and keeps data in memory only, so data is lost on restart.

: this project handles the interoperability side of consumer wearable data, getting device readings into a standard record format. It does not process signals and works with device-computed values, not waveforms.
: the same FHIR, LOINC, and SNOMED CT foundations, applied here to patient-generated vital signs.
and : both rely on FHIR meta.security labels. vitals-on-fhir uses the same mechanism to label simulated data as test data (HTEST).
: a related educational tool for consumer sensor data. It covers movement-sensor signal processing in the browser.

Wearables | Soroush Dianaty, M.D.

GaitScope: A Browser Lab for Movement-Sensor Signal Processing

At a glance

Why it exists

What it does

How the methods are checked

Signal pipeline

Status and roadmap

What it is, and what it isn’t

Use in teaching

Credits

Related work on this site

vitals-on-fhir: Consumer Wearables and Home Health Devices to HL7 FHIR R4

At a glance

Problem

Approach

Architecture

Supported vital signs

Design decisions

Getting started

Status and roadmap

Limitations and safety

Related work on this site