Healthcare ML & Data Infrastructure Evaluation & Benchmarking

Building the ML Training Pipeline for a Medtech Device

Standing up the end-to-end data and machine learning pipeline for a non-invasive biosensing startup, taking a hardware founder from raw sensor output to a reproducible training and evaluation system.

Client

Non-Invasive Biosensing Startup

Published

8/1/2025

Challenge

A medtech founder had working sensor hardware, accumulating time-series data, and no machine learning infrastructure: no reproducible path from raw sensor output to a trained model, and no way to tell whether a promising result was real signal or an artifact of fitting too many features to too little data.

Solution

Built an end-to-end training and evaluation pipeline spanning ingestion, feature engineering, time aggregation, and cross-validation, then used it to run a structured experimental program across target formulations, feature methods, and model architectures.

Key Results

  • Delivered a reusable training pipeline from database and file ingestion through cross-validated model comparison
  • Built a two-phase time aggregation framework handling high-frequency sensor data and lower-frequency reference labels
  • Established a feature engineering library spanning derivatives, spectral decomposition, wavelets, and dimensionality reduction
  • Characterized the spectral structure of the sensor waveform and identified the most informative features
  • Surfaced a predictive signal leading the reference measurement by roughly 35-40 minutes
  • Gave the founder a measured basis for prioritizing data collection over further modeling

Key Metrics

ML Lead

Our Role

2

Team

Training Pipeline

Deliverable

Leave-One-Out CV

Validation

Summary

A medtech founder had built working sensor hardware and was accumulating time-series biosignal data, aiming to predict blood glucose without drawing blood. What did not exist was anything between the raw sensor output and a trained model: no ingestion path, no feature pipeline, no way to compare one modeling approach against another and trust the comparison.

We built that pipeline, then used it to run the experiments that told the founder where the technology actually stood.



Case Study: From Raw Sensor Output to a Reproducible Training System

Client: An early-stage medtech company developing non-invasive biosensing hardware.

Engagement: A two-person team building the training and evaluation pipeline and running a structured experimental program across data formulation, feature engineering, and model architecture.



The Starting Point

Hardware founders and ML infrastructure are a common mismatch. The device worked and the data was accumulating, but every analysis was bespoke: pull some data, engineer some features in a notebook, fit a model, get a number. Nothing was reproducible, nothing was comparable across attempts, and there was no principled way to tell a real result from a lucky one.

That last point mattered most. This problem class has a specific failure mode. You have a rich sensor stream and a few hundred labeled observations. Time-series data invites feature engineering, so you generate derivatives, spectral components, rolling aggregations, and lagged values, and now you have hundreds of features against a few hundred rows. Some combination will fit the target. It will fit noise, and it will look like success.

The Pipeline

Ingestion. Data pulled from the operational database and from raw files into analysis-ready frames, with the sensor streams and reference measurements aligned on a common time base.

Time aggregation. A two-phase aggregation framework handling the high-frequency sensor stream and the lower-frequency reference signal separately, so neither collapsed into the other. Aggregation method and window are configurable, which turned “how should we summarize this data” from an assumption baked into a notebook into a parameter that could be tested.

Feature engineering. A library covering time-difference features for rate of change and momentum, principal component analysis for noise reduction across sensor streams, and wavelet and Fourier methods suited to physiological signals.

Target formulation. Support for framing the problem three ways: predicting the raw reference value, classifying clinically relevant states, and predicting an aggregate over a window. A noisy point estimate is frequently the wrong thing to ask a model for, and this made that testable rather than assumed.

Model benchmarking and validation. Linear baselines, tree ensembles, and a convolutional approach over the raw series, all evaluated through leave-one-out cross-validation so that comparisons between them meant something.

The pipeline was the durable deliverable. The experiments answered the question in front of the founder; the pipeline answers every subsequent one, and every future hardware revision runs through it.

What the Pipeline Revealed

The waveform has exploitable structure. Spectral analysis showed a clear fundamental with overtones corresponding to physiological features of the cardiac cycle. Locating those peaks and their relative amplitudes characterizes each beat far more robustly than raw amplitude does, which is a substantially better basis for features.

The predictive signal leads the reference by 35 to 40 minutes. Cross-correlation showed components peaking well ahead of the reference measurement, consistent with the known lag between blood glucose and the interstitial fluid the reference device samples. The sensor may be seeing something earlier than the ground truth used to grade it, which reframes what the model should be trained against.

Motion artifacts filter better on the vector norm. Using the Euclidean norm of the inertial data rather than its individual axes gave a cleaner distribution for outlier detection and better filtering of movement noise.

Heart rate at fifteen minutes prior was the most informative single feature. Useful directly, and a caution worth carrying forward: some of what presents as glucose signal may be cardiovascular signal correlated with it.

The feature-to-observation ratio was the binding constraint. With cross-validation in place, a random sample of twenty engineered features produced an R-squared near 0.5, which established the scale of the overfitting risk concretely rather than theoretically. No model reached statistical validation on the data available, and the pipeline is what made that knowable.

Where It Pointed

With the infrastructure in place, the constraint was legible: data collection, not method. We recommended prioritizing volume and diversity over precision at this stage, holding sensor hardware consistent across collection efforts so sessions stay comparable, running longer sessions to handle the high autocorrelation in the reference signal, and recording metadata so a messier corpus can be filtered into clean subsets later.

We also documented where the analysis had not been pushed to its limit: statistical methods better suited to sparse, high-dimensional data, refinement of the spectral work using cleaner phase information and harmonic amplitude ratios, and factor analysis in place of principal components as a likely better fit for this domain.

Outcome

The founder came out with the machine learning foundation the company had been missing: a reproducible pipeline from raw sensor data to cross-validated model comparison, a characterized signal, a ranked set of promising directions, and a measured basis for putting the next round of effort into data collection rather than modeling.

Client identity, hardware details, and implementation specifics are withheld under confidentiality.

Back to Case Studies Back to Results & Research