What does data science for healthcare organisations look like?
Data science for healthcare organisations is the application of algorithm development, signal processing, and data engineering to clinical problems, under the regulatory, ethical and quality constraints that healthcare imposes. Healthcare organisations working with patient data face requirements that do not exist in commercial data science: audit trails for every data access, validation evidence for every algorithm that informs a clinical decision, and documented change control for any modification to a validated system. The data itself is more demanding: wearable sensor streams require preprocessing before clinical algorithms can run on them; trial data from multiple sites requires harmonisation before statistical analysis is valid; and device data from different hardware platforms requires normalisation before cross-platform comparisons are meaningful. Devsort does this work for healthcare organisations that need engineers who understand clinical and regulatory requirements, from CROs designing wearable endpoints to digital health companies building monitoring platforms.
What kinds of healthcare data science problems do we solve?
The most common problem we are brought in to solve is the gap between a validated algorithm and a deployable one. A research team has a Python notebook that produces the right outputs on the original study dataset; the job is turning that into a validated, documented, cross-platform implementation that can run on the devices used in the next study or the commercial product. This requires signal processing expertise, cross-platform normalisation, and the formal validation process that produces the evidence base for regulatory or ethics review.
The second common problem is legacy algorithm debt. Many healthcare organisations are running clinical algorithms implemented years ago in R, MATLAB, or FORTRAN-era tools, with documentation that describes what the algorithm is supposed to do rather than what it actually does. Refactoring them means keeping the validated clinical behaviour and producing the documentation the organisation needs for regulatory maintenance. That takes algorithm skill and regulatory process discipline together.
We also work with CROs and clinical trial sponsors on wearable endpoint validation: confirming that the digital biomarker the study is designed around behaves correctly across the device platforms and patient populations the trial will recruit from, before the trial begins rather than after the data has been collected.
What did the PKG Health engagement involve?
PKG Health (now Empatica) engaged Devsort to refactor and validate their clinical algorithm suite for Parkinson's disease monitoring: six algorithms spanning bradykinesia, dyskinesia, tremor, off-wrist detection, sleep, and walking pattern analysis, originally implemented in multiple languages with minimal documentation.
The engagement produced a fully documented, cross-platform Python algorithm suite validated against the certified originals on clinical datasets, extended to run on five wearable device platforms, and partially reimplemented in embedded C for on-device deployment. All of it was done under FDA 510(k), CE and TGA regulatory requirements.
It set how we approach healthcare data science. The work is methodical and documented, and the regulatory constraints the client actually operates under shape it more than technical convenience does.
Who do we work with in healthcare?
Our typical healthcare client is a company or organisation that has a clinical algorithm or data system that needs to become more reliable, more portable or easier to defend to a regulator, and a technical problem their internal team cannot currently solve on its own.
This includes digital health companies building wearable monitoring platforms that need to extend their algorithm coverage to new devices or new clinical populations. It includes CROs that have adopted wearable endpoints for clinical trials and need validation evidence that the endpoint performs as specified across the study devices. And it includes established medical device companies that need to refactor or extend legacy algorithm implementations under change control.
We do not work with individual clinicians or research groups on exploratory data analysis. Our engagements are engineering projects with defined deliverables, not research collaborations. The minimum engagement is three months with a clear technical problem and a defined output.
Frequently asked questions
Do you work with NHS or other public health system clients?
We have not worked directly with NHS trusts or public health system procurement, but we have worked with companies whose products are used in NHS and public health contexts. Public sector procurement has different timelines and process requirements than commercial medtech engagement. We are open to discussions with NHS-adjacent organisations but are upfront that our usual engagement model (project-based, defined scope, three-month minimum) may need to be adapted for public sector procurement processes.
Can you help with wearable endpoint selection for a clinical trial?
We can advise on the technical characteristics of wearable platforms that should inform endpoint device selection: sensor specifications, data quality, cross-platform equivalence and the preprocessing requirements for specific algorithm types. We are not a clinical or regulatory affairs consultancy, so we do not advise on the clinical validity of an endpoint or its regulatory acceptability. We advise on whether the device can produce the data the endpoint requires, and whether the algorithm that computes the endpoint will perform correctly on that device.
Do you work on GDPR or HIPAA compliance for healthcare data systems?
We build healthcare data systems with data privacy requirements built into the architecture from the start: role-based access control, audit logging, encryption at rest and in transit, and minimal data retention. We are not a legal or compliance consultancy and we do not provide GDPR or HIPAA compliance certification. We produce the technical artefacts a compliance team needs from the engineering side (data flow documentation, access control specifications, encryption implementation) to complete a formal compliance assessment.
How do you handle patient data during algorithm validation?
We work with de-identified or pseudonymised clinical datasets provided by the client under a data processing agreement. We do not receive identifiable patient data unless it is a specific requirement of the engagement and a formal data processing agreement is in place. Validation runs are conducted on Devsort infrastructure, results are transferred to the client, and the dataset is deleted from our systems at engagement close. We maintain a data processing log throughout.