A certified algorithm stack that no one could touch.
PKG Health had built a suite of algorithms for monitoring bradykinesia, dyskinesia and tremor in Parkinson's disease patients, validated through clinical studies and cleared by the FDA under 510(k) certification. The algorithms were running in production. They were generating clinical data for real patients.
The problem was the code they ran on. The algorithm implementations were spread across legacy codebases in C/C++, Julia, TCL and Java. Different teams had written them at different times, with different conventions, minimal documentation and no unified architecture. Nobody on the current team fully understood all of it.
The FDA certification was tied to the existing implementation. Any change to the algorithm code, even a bug fix or a refactoring that produced identical outputs, had to be formally assessed against the regulatory documentation before it could be deployed. In practice, this meant the algorithms were frozen. PKG could not add new hardware support, extend the algorithms to new device platforms, or fix known issues without triggering a regulatory review process whose outcome was uncertain.
That was the situation when Devsort engaged.
Refactor one algorithm at a time. Match the output exactly. Document everything.
Our methodology was defined by a single constraint: the refactored code had to produce outputs numerically equivalent to the certified original on every clinical dataset. Not approximately equivalent. Not equivalent on average. Equivalent at each data point, within a documented tolerance, for every input the algorithm would encounter in clinical use.
We worked one algorithm at a time. For each one, we began by reverse-engineering the existing implementation: reading the code, understanding the computation it performed, documenting its behaviour in language plain enough for a clinical reviewer to follow. This documentation step was not optional. It was how we confirmed that we understood what we were about to reimplement.
We reimplemented each algorithm in Python, with full documentation and a test framework that ran both the original and the new implementation on the same clinical datasets and compared every output. Any deviation from the expected output was investigated at the code level. If the deviation was within the documented clinical tolerance, it was recorded and accepted with rationale. If it was not, the code was corrected before moving forward.
The algorithms we refactored include the bradykinesia score and its associated statistics, the dyskinesia score and statistics, the tremor score and statistics, the off-wrist detection model, sleep scores, and early morning bradykinesia severity.
The tremor algorithm required particular attention. The original implementation took approximately five minutes to process a single recording. We reduced this to thirty seconds, a tenfold improvement, while keeping full numerical equivalence with the validated output. We got there by restructuring the algorithm, not by approximating: the same computation, organised to cut redundant work.
The same engagement covered the layers around the algorithms: the preprocessing pipeline that fed them and the embedded C that ran them on Empatica's wrist device. That combination is what we now offer as wearable app development.
How did the algorithms get onto five device platforms?
Validating the refactored algorithms in Python was step one. Step two was making them hardware-agnostic, so they could run on data from wearables other than the platform the original validation studies used.
PKG Health wanted the algorithm suite to run on Apple Watch, Samsung Galaxy Watch, Sony SmartWatch, Empatica E4, and ActiGraph devices. That meant five very different accelerometers, each with its own axis orientation convention, sampling rate, filter characteristics baked into the hardware and raw data output format.
We built a preprocessing pipeline that normalises these differences. The pipeline detects the device type from the data file, applies the right transformation (axis remapping, unit conversion, resampling to the algorithm's expected input frequency) and outputs a standardised signal that the clinical algorithms treat the same way whatever device it came from. Every transformation was validated against clinical datasets to confirm that algorithm outputs were equivalent across platforms.
A subset of the validated Python algorithms was then reimplemented in embedded C for deployment on the Empatica wrist device itself. That allowed on-device processing with the same numerical behaviour as the cloud-based Python implementation, validated on hardware.
What did the work make possible?
Before the engagement: the algorithm stack was hardware-locked to its original platform, implemented in four legacy languages, undocumented, and effectively unmaintainable. Any change required a regulatory assessment whose outcome and timeline were uncertain.
After the engagement: the same clinical algorithms ran in production-quality Python, fully documented, with a test framework that could validate any future change against the certified reference. They ran on five device platforms. A subset ran on the Empatica device hardware. The validation documentation for each algorithm and each platform transition was complete and structured for regulatory submission.
PKG Health was acquired by Empatica during the engagement period. By then Devsort had extended the algorithm suite to new device partners and made the codebase maintainable and documented, so the portfolio that changed hands was technically more capable. We do not claim to have caused the acquisition. We do think the work made the platform a significantly more valuable technical asset.
The engagement ran for 2.5 years, covering six algorithms across five device platforms, under FDA 510(k), CE, and TGA regulatory frameworks throughout.