What does data science for medical device companies look like?
Data science for medical device companies is the engineering discipline of building the algorithm and data pipeline layer that turns raw sensor output from a medical device into a clinical measurement. This layer — often called the software component of the device — sits between the hardware and the clinical interface, and in most jurisdictions it is subject to the same regulatory requirements as the device itself. Under FDA 21 CFR Part 820 and IEC 62304, changes to the software component of a cleared device require documented verification and validation before deployment. The data science work — algorithm development, signal preprocessing, cross-platform normalisation, and output validation — must be conducted within this regulatory framework. Devsort has delivered this work for PKG Health (now Empatica) over a 2.5-year engagement: six clinical algorithms, five device platforms, and three regulatory jurisdictions — FDA 510(k), CE marking, and TGA — all managed under change control.
What data science challenges are specific to medical device companies?
The most common challenge for medical device companies is the algorithm portability problem. A clinical algorithm validated on a specific hardware platform — the device that was used during the original clinical study — must eventually run on successor hardware, additional platforms, or embedded on the device itself. Each of these transitions requires a formal validation showing that the algorithm produces equivalent outputs on the new platform. This is not a trivial engineering task: different devices have different sensor hardware, different sampling rates, different axis conventions, and different filter characteristics baked into the hardware. The preprocessing pipeline that normalises these differences must be built and validated from scratch for each new platform.
The second common challenge is legacy algorithm maintenance. Medical device companies that have been operating for several years often have clinical algorithms implemented in languages or frameworks that are no longer maintainable — C/C++ implementations with no documentation, MATLAB scripts that run only on specific toolbox versions, or Julia code written by a researcher who has since left the organisation. Maintaining regulatory compliance for a product whose algorithm is not understood by anyone currently at the company is a serious risk, and refactoring that algorithm safely — preserving the validated clinical behaviour while making it maintainable — requires both algorithmic expertise and regulatory process discipline.
What we have delivered for a regulated medical device company
PKG Health's movement disorder monitoring system is a cleared medical device — FDA 510(k), CE marked, and TGA registered — that uses wrist-worn accelerometry to measure bradykinesia, dyskinesia, and tremor in Parkinson's disease patients. The clinical algorithm suite underpinning the device was originally implemented across C/C++, Julia, and TCL, with documentation insufficient to support regulatory change submissions.
Devsort's 2.5-year engagement produced a fully validated Python reimplementation of the complete algorithm suite, a cross-platform preprocessing pipeline for five wearable devices, embedded C implementations for on-device deployment on the Empatica platform, and the complete validation documentation package for three regulatory jurisdictions. All changes were conducted under formal change control, with validation evidence produced for each algorithm and each platform transition.
This is the full scope of what medtech data science engineering looks like in practice: not a data analysis project, but a regulated software engineering programme with clinical and regulatory deliverables at every stage.
Which medtech companies are the right fit for Devsort?
We work best with medtech companies that have a specific, technically defined engineering problem and a runway of at least three months to solve it. The problem is typically one of: algorithm portability to a new device or platform; refactoring of a legacy algorithm implementation under regulatory change control; embedded deployment of a validated algorithm on device hardware; or validation testing for a new or modified software component.
We are not the right fit for companies that need a data analysis partner for exploratory research, or for companies in early-stage clinical development that do not yet have a defined algorithm or device platform. Our engagement model is engineering project delivery, not ongoing data science support or research collaboration.
We operate from Islamabad, Pakistan, with a UTC+5 timezone. This gives a four-to-five hour overlap with EU business hours and a one-to-two hour overlap with US Eastern morning. Asynchronous working with a defined check-in cadence is our default; real-time availability is not required.
Frequently asked questions
How do you work within a medical device company's existing regulatory processes?
We integrate into the client's existing change control and quality management system rather than running a parallel process. We produce the technical documentation — software requirements specification, verification test records, validation report, traceability matrix — in the format required by the client's QMS and regulatory affairs team. We attend change review meetings as the technical author of the change, and we support the regulatory affairs team during the submission process by answering technical questions about the engineering work.
Can you work under a medical device company's software development procedures?
Yes. We can operate under a client's documented software development procedures (SDP) rather than our own, where this is required for regulatory consistency. This includes adopting the client's code review process, version control conventions, defect tracking system, and documentation templates. Working under the client's SDP takes longer to set up initially but is often required for work that forms part of a regulatory submission the client owns.
What is the difference between algorithm validation and clinical validation?
Algorithm validation confirms that the software implementation produces outputs that are numerically equivalent to the validated reference, within defined tolerance, across the documented input space. Clinical validation confirms that the outputs of the algorithm have clinical meaning — that they correlate with the clinical condition they are intended to measure. Devsort performs algorithm validation; clinical validation is performed by clinicians and clinical study teams. We produce the algorithm validation evidence; the clinical validation evidence is produced by the clinical organisation.
Do you have experience with specific medical device regulatory frameworks?
We have direct experience with FDA 510(k) and the associated software documentation requirements (21 CFR Part 820, FDA guidance on software as a medical device), EU CE marking under MDR, and TGA registration in Australia. Our experience comes from the PKG Health engagement, where all three frameworks applied simultaneously. We are familiar with IEC 62304 (software lifecycle), IEC 62366 (usability), and ISO 14971 (risk management) as they relate to the software component of a medical device.
How do you handle IP and confidentiality for algorithm implementations?
We work under NDA before reviewing any proprietary algorithm implementation or clinical dataset. All code, documentation, and data produced during the engagement is owned by the client. We do not retain copies of algorithm implementations after engagement close. Our validation reports and case study references describe the scope and outcome of the work — what was validated and to what standard — without disclosing the internal logic of proprietary algorithms.