What is clinical algorithm development?
Clinical algorithm development is the process of designing, validating, and maintaining the software algorithms that medical devices use to derive clinically meaningful outputs from raw sensor data. Unlike general software development, every implementation decision is bounded by regulatory requirements: an FDA 510(k) clearance ties certification to the existing implementation, meaning any refactoring must preserve output equivalence against the certified original. Legacy clinical codebases are typically undocumented, written across multiple languages by researchers rather than engineers, and cannot be modified without a controlled validation process. The work produces validated implementations with documentation suitable for regulatory submission — evidence that the new system matches the certified original on every input in the clinical dataset. Engagements run months to years and often involve porting algorithms between languages or hardware platforms as device portfolios expand. Devsort has performed this work for PKG Health (now Empatica) on FDA 510(k) Class II cleared algorithms for movement disorder monitoring.
Why is clinical algorithm validation different from standard software development?
An FDA 510(k) clearance is tied to the specific implementation of the algorithm at the time of submission. The certified system cannot be refactored, ported, or extended without a controlled validation process — any output change, however small, constitutes a change to the cleared device software and requires evidence of equivalence before it can be deployed clinically.
Legacy clinical codebases compound this problem. Most clinical algorithm systems were built by research scientists, not software engineers. They are typically undocumented, written in combinations of C, Julia, MATLAB, or specialised scientific computing environments, and lack test coverage. The people who understood them have often left the organisation.
These constraints define the engagement model: Devsort does not rewrite clinical algorithms from a clean specification. We reverse-engineer the existing system, document its behaviour from the ground up, and produce a validated reimplementation that matches the original output on every input in the clinical dataset. That matching process is the certification evidence.
How does Devsort's algorithm refactoring process work?
- 1
Audit the legacy system
We begin by reverse-engineering the existing codebase: mapping data flows, identifying algorithm boundaries, documenting input and output specifications, and establishing the ground-truth output on a representative clinical dataset. This audit produces the baseline against which everything else is validated.
- 2
Build the refactored version in parallel
The refactored implementation is built alongside the original — not as a replacement. We work in Python for the validation layer, targeting whatever deployment language the client requires (Python for cloud pipelines, C for embedded devices). The original system stays running throughout.
- 3
Validate against the legacy system
Both versions run on the same clinical input data. Every output is compared, every deviation is investigated and resolved, and the full comparison is documented. The goal is numerical equivalence within the tolerance defined by the regulatory submission — not approximate similarity.
- 4
Regulatory review support
We produce a validation report in the format expected for regulatory submission: input specification, test datasets, comparison methodology, deviation log, and equivalence conclusions. We do not act as a regulatory consultant, but we produce the technical documentation that supports a regulatory submission.
- 5
Deploy
Once validated, the refactored algorithm is integrated into the client's pipeline or device stack. For cross-platform deployments, we build and validate the preprocessing pipeline — normalising heterogeneous device outputs to a common format — before the clinical algorithm runs.
The PKG Health engagement
PKG Health (now part of Empatica) engaged Devsort to refactor and extend their clinical algorithm suite for Parkinson's disease monitoring. The algorithms — covering bradykinesia, dyskinesia, tremor, off-wrist detection, sleep scores, and walking patterns — had been validated and certified but existed across a legacy codebase spanning C/C++, Julia, and TCL with minimal documentation.
Over 2.5 years, a two-person data science team plus one SQA engineer refactored each algorithm into Python, validated each against the original on clinical datasets, and built a cross-platform preprocessing pipeline enabling the algorithms to run on Apple Watch, Samsung, Sony, Empatica, and ActiGraph devices. A subset was re-implemented in C for embedded deployment on the Empatica wrist device.
The tremor processing algorithm was reduced from five minutes per session to thirty seconds. The off-wrist detection algorithm achieved greater than 90% accuracy in the refactored version. All work was conducted under FDA 510(k), CE, and TGA regulatory requirements.
Algorithms we have worked on
Frequently asked questions
How long does a clinical algorithm refactoring project typically take?
A clinical algorithm refactoring project typically takes 12 to 30 months, depending on the number of algorithms, the complexity of the legacy codebase, and the number of hardware platforms that require validation. Our engagement with PKG Health / Empatica ran 2.5 years and covered six algorithms across five device platforms under FDA, CE, and TGA requirements. Shorter engagements — a single algorithm, a single platform — can complete in three to six months.
What programming languages do you work with for clinical algorithms?
We work primarily in Python for algorithm refactoring and cross-platform validation, and in C for embedded deployment on resource-constrained wearable hardware. Our PKG Health engagement involved a codebase spanning C/C++, Julia, TCL, and Java — we normalised this to Python for the core validation layer and C for Empatica device deployment. The language choice is driven by the target deployment environment, not preference.
How do you ensure refactored algorithms preserve FDA certification?
We validate the refactored algorithm against the certified original by running both versions on the same clinical input datasets and documenting every output comparison. Any deviation — no matter how small — is investigated and resolved before the refactored version advances. This process produces a validation report that documents equivalence across the full input distribution, which is the evidence base for maintaining regulatory status through a change.
Can you support cross-platform algorithm porting (Apple Watch, Samsung, ActiGraph, etc.)?
Yes. Our cross-platform work for PKG Health extended their algorithm suite to Apple Watch, Samsung, Sony, Empatica, and ActiGraph devices. The technical challenge is building a preprocessing pipeline that normalises heterogeneous device outputs — different sensor sampling rates, axes, and units — to a common input format before the clinical algorithms run. We have implemented and validated this pipeline across five device types.
Do you provide documentation suitable for FDA submission?
Yes. We produce validation documentation as part of the engagement — the structured record of how the refactored algorithm was tested against the certified original, what inputs were used, and what the output equivalence evidence shows. The format follows standard regulatory expectations for software validation under FDA 21 CFR Part 11 and IEC 62304. We do not act as a regulatory consultant, but we produce the technical documentation that supports a regulatory submission.
What does a clinical algorithm validation engagement cost?
Engagements are scoped and priced based on the number of algorithms, the state of the legacy codebase, and the number of platforms requiring validation. We do not publish standard rates because the effort range is too wide — a single-algorithm engagement is structurally different from a multi-algorithm, multi-platform programme. The right approach is a scoping conversation: we assess the legacy system, define the validation scope, and provide a fixed-price proposal. Contact us to begin.