What is data science for medtech?
Data science for medtech is the discipline of building, validating, and maintaining the algorithms and data pipelines that turn raw signals from medical devices into clinically meaningful information. Unlike standard data science, every output must be reproducible, regulatorily defensible, and tied to the device's intended use under FDA, CE, or TGA frameworks. The work spans signal processing, algorithm validation, cross-platform porting, and statistical analysis for clinical studies. It produces validated algorithm outputs and data pipelines with documentation suitable for regulatory submission — evidence that the system behaves correctly across all expected clinical inputs. Engagements range from short-duration pipeline builds to multi-year programmes covering multiple devices and regulatory jurisdictions. Devsort has delivered this work for PKG Health (now part of Empatica) over a 2.5-year engagement covering bradykinesia, dyskinesia, tremor, and off-wrist detection algorithms for Parkinson's disease monitoring.
How is clinical data science different from standard data science?
Standard data science optimises for aggregate performance: a model that is correct 95% of the time on a test set is a good model. Clinical data science operates differently. An algorithm that generates a clinically incorrect output for a specific patient at a specific point in time can cause harm. Performance must be documented, not just measured — every validation run is a record, not an experiment.
The second distinction is auditability. In a clinical context, the question is not only 'does this algorithm produce good outputs?' but 'can we prove that it produces correct outputs for every input it will encounter in deployment?' This requires a formal validation process, a documented input specification, and a record of how the system performs across the full range of that specification.
The third distinction is regulatory constraint. Algorithm changes — even bug fixes — must go through a controlled change process when the software is part of a cleared or certified medical device. Devsort's PKG Health engagement was shaped by this constraint at every stage: the refactored algorithms could not simply replace the originals until their output equivalence was documented and the change was formally closed.
What does working with Devsort look like?
- 1
Discovery and scoping
We begin by understanding your algorithm or data system: what it does, what it is built on, what the regulatory or clinical requirements are, and where the technical risk is. We review the legacy codebase, the existing validation evidence, and the deployment environment. This produces a clear scope: what will be built or refactored, how it will be validated, and what the deliverables are.
- 2
Build and validate
We implement the agreed scope — whether that is a new preprocessing pipeline, a refactored algorithm, a cross-platform port, or a statistical analysis framework. Validation runs in parallel: every component is tested against the specification as it is built, not at the end. For regulatory-tied work, we maintain the validation log throughout so it is always current.
- 3
Deploy and hand over
We support integration into your pipeline or device stack and produce the documentation package: validation report, input specification, change log, and any regulatory-facing artefacts required. We do not disappear at handover — we are available for questions during the integration period and for follow-on scoping if the work grows.
The PKG Health engagement
PKG Health (now Empatica) engaged Devsort to refactor and extend their clinical algorithm suite for Parkinson's disease monitoring — six algorithms spanning bradykinesia, dyskinesia, tremor, off-wrist detection, sleep, and walking patterns, originally written across C/C++, Julia, and TCL with minimal documentation.
The two-year engagement produced a Python-based, fully documented, cross-platform algorithm suite validated against the certified originals on clinical datasets and extended to run on Apple Watch, Samsung, Sony, Empatica, and ActiGraph devices. A subset was reimplemented in C for embedded Empatica device deployment.
This is the engagement that defines how Devsort approaches clinical data science work: methodical, documented, and bounded by the regulatory constraints that the client actually operates under.
Frequently asked questions
How do you handle proprietary algorithm IP during a refactoring engagement?
We work under a standard NDA before reviewing any code or data, and we do not retain copies of client algorithm implementations after the engagement ends. Our validation methodology documents inputs, outputs, and equivalence — not the internal logic of the algorithm. We describe what the algorithm does and how it was validated; we do not publish or share what it does internally. This is consistent with the level of specificity we use in our PKG Health case study.
What does the validation process look like when an FDA certification is at stake?
We run both the original and refactored algorithm on the same clinical input datasets, compare every output value, and document every comparison. Any deviation is investigated at the code level to determine whether it is within tolerance or a genuine difference requiring resolution. The process produces a validation report — input specification, comparison methodology, dataset description, deviation log, and equivalence conclusions — which is the evidence base for a regulatory change submission.
How do you work across time zones with US and EU clients?
We are based in Pakistan (UTC+5), which gives us a four-to-five hour overlap with EU business hours and a one-to-two hour overlap with US Eastern morning time. For most engagements, this means asynchronous work with a daily sync in the morning EU / afternoon Pakistan slot. For US West Coast clients, we use end-of-day EU / early morning Pakistan. We do not require real-time availability; we require clear written specifications and predictable check-in cadence.
What size of project do you typically engage on?
We have delivered projects ranging from three-month single-algorithm validation engagements to 2.5-year multi-algorithm, multi-platform programmes. The minimum engagement size is typically three months; anything shorter does not allow enough time for a proper discovery, build, and validation cycle. We do not take on small ad-hoc tasks. We work best with clients who have a clear technical problem and a six-month-plus runway to solve it.
Do you support regulatory submission documentation?
Yes. Our validation reports follow the format expected for FDA software validation submissions under 21 CFR Part 11 and IEC 62304. We produce the technical documentation — input specification, test datasets, methodology, deviation log, equivalence conclusions — that supports a regulatory change submission. We do not act as a regulatory affairs consultant, but we produce the artefacts that a regulatory affairs team needs from the engineering side.
Can you work as an extension of an existing data science team?
Yes, and this is often the most effective engagement model for clients with an internal team. We take on the algorithm refactoring, validation, or cross-platform work that requires deep wearable domain knowledge, while your team retains ownership of the broader system and the clinical interpretation. We integrate with your existing code review, ticketing, and documentation processes rather than running a parallel workflow.