Tremor processing per session, down from 5 minutes
Off-wrist detection accuracy in the refactored algorithm
Wearable platforms running the same validated algorithms
On one FDA, CE and TGA regulated algorithm stack
Definition
What is wearable app development?
Wearable app development is building the software that runs on, or alongside, a body-worn device. For a wrist-worn sensor that usually means four layers. Firmware on the device collects accelerometer and other sensor data inside tight limits on memory and battery. A companion app on iOS or Android pairs with the device, syncs the data and shows results. Then there's the data pipeline, which cleans the raw signal, handles gaps and removes periods when the device wasn't being worn. Algorithms then turn the cleaned signal into something a person can use, such as a tremor score or a sleep estimate. Consumer products can live with rough edges in the last two layers. Medical and research products can't, because a clinician or a trial sponsor will act on the output. That is the part we're built for. We spent 2.5 years making clinical algorithms give the same answer on every device they run on.
What we build
What do we build for wearable devices?
On-device firmware
Algorithms ported to C for the microcontroller, with every output checked against the reference implementation. We did this for PKG's bradykinesia, dyskinesia and tremor algorithms on Empatica's wrist device, a 6-month job under FDA, CE and TGA constraints.
Embedded firmware developmentCompanion apps
iOS and Android apps that pair with the device and sync its data in the background. Our mobile team built Guidana's iOS and Android apps in React Native, and it's live and in use today.
Cross-platform preprocessing
The layer that lets one validated algorithm read data from Apple Watch, Samsung, Sony, Empatica and ActiGraph devices without being rewritten for each one.
How the pipeline worksClinical algorithms
Bradykinesia, dyskinesia and tremor scores, sleep scores, off-wrist detection, walking detection and fall prediction. We rewrote and documented each one, then checked it against the legacy output until the numbers matched exactly.
Clinical algorithm developmentPlatforms
Which wearable platforms have we worked with?
- Apple Watch
- Samsung
- Sony
- Empatica
- ActiGraph
Data from all five ran through the same preprocessing pipeline and the same PKG algorithms, and we compared the results platform by platform. Each session was about a week of continuous wrist data. There were thousands of them, from hospitals, clinics and research groups in Asia, Europe, the US and Australia. We also wrote the embedded C that runs PKG's movement algorithms on Empatica's own wrist device.
The differentiator
Why is cross-platform preprocessing the hard part?
An algorithm validated on one wrist device is only validated on that device. Move it to another watch and the inputs change: a different sampling rate, a different axis orientation, different units, a different way of reporting gaps and charging. The algorithm still runs. It just gives different answers, and nothing warns you.
Most teams find this out late, after the second device is already in a study.
Our pipeline sits between the device and the algorithm. It reads each platform's raw format and converts it into the one input the validated algorithm expects, and before anything is scored, a quality check catches off-wrist periods with better than 90% accuracy. Only then does the algorithm run. Its code never changes. The outputs are compared with the reference device before release.
This is what let PKG Health offer its algorithms to other device makers, including Empatica and ActiGraph. There's more detail on the pipeline in our wearable data science work.
- Apple Watch
- Samsung
- Sony
- Empatica
- ActiGraph
- 01IngestA reader for each device's raw format
- 02NormaliseSampling rate, axes and units converted to one input format
- 03Quality gateGaps and charging flagged. Off-wrist detection above 90%
- 04Validated algorithmThe cleared code runs exactly as validatedCode unchanged
- 05CompareOutputs checked against the reference device before release
Process
How does a wearable project with Devsort run?
- 1
Technical call
You tell us about the device and what the output has to do. We tell you what we'd need to see before we can quote.
- 2
Real data before a plan
We ask for a sample dataset and the SDK or data spec. Most scoping problems show up in the first look at real data.
- 3
One component at a time
Each piece gets built and tested against a reference, and you sign it off before the next one starts. We ran the PKG refactor this way, one algorithm at a time, with 2 data scientists and a QA engineer from our Islamabad team.
- 4
Documentation and handover
You get the source, the build configuration, the validation records and documentation your regulatory team can use.
Fit
Who is this for?
A good fit
Medtech and research teams that want to outsource the software around a wearable they already have, or that work with data from devices they don't make. The output has to be right because someone will act on it.
What we don't do
We don't design wearable hardware. We start once there is a device, an SDK or a dataset.
Can an algorithm validated on one wearable run on another?
Yes, if the input is converted properly and the outputs are checked. The algorithm itself shouldn't change. Changing it can undo its validation. What changes is the layer in front of it: resampling, axis alignment, unit conversion, gap handling and off-wrist detection. We then compare the outputs against the reference device before anything goes live. We did this for PKG Health across Apple Watch, Samsung, Sony, Empatica and ActiGraph data.
Do you work on FDA-regulated wearables?
Yes. The PKG system we worked on is FDA 510(k) cleared, CE marked and TGA approved. Our refactored outputs had to match the legacy validated version exactly, because a single deviation would have put the clearance at risk. The clearances belong to our clients, and we don't hold any ourselves. What we bring is the habit. Changes go through formal change control and every output is compared numerically against a reference. We write the documentation so your regulatory affairs team can use it as it is.
Which wearable platforms have you worked with?
Apple Watch, Samsung, Sony, Empatica and ActiGraph, through the PKG preprocessing pipeline. We've also written embedded C for Empatica's wrist device. For a platform we haven't used, we need the hardware spec, the SDK and a development unit before we can give you a real estimate.
Can you take over an undocumented codebase?
That's how the PKG engagement started. The algorithms were spread across C/C++, Julia, TCL and Java with little documentation, and the FDA clearance was tied to that implementation. We reverse-engineered them one at a time and rewrote each in documented Python. None moved forward until we had shown it matched the original output.
How long does a wearable project take?
It depends on how many layers you need and whether the output is regulated. For scale, the PKG refactor took about two years to reach production, plus six months for the embedded C work on Empatica's device. A companion app or a pipeline for one new device is a much smaller job. We'll give you a timeline once we've had the technical call and looked at sample data.
Do you only work on clinical products?
No. Clinical work sets how we test, but the same skills carry over to research, sports and consumer wearables. If your product doesn't need regulatory documentation, we leave it out and you don't pay for it.