Whether your device depends on ECG, neural activity, respiratory signals, pressure data, motion sensing, or other physiologic input, capturing the signal reliably is an important step, but it’s only step one.

It does not mean the data is ready for algorithm development, verification, or regulatory submission.

Raw biologic signals are often noisy, incomplete, inconsistent, artifact-heavy, or difficult to compare across sources. And two devices that appear to be capturing the same physiologic event at the same time may, at the data level, be capturing something meaningfully different.

Before you can use a signal for analysis, your team needs to understand what was captured, how it was captured, what context came with it, and what limitations may apply.

That means tagging, cataloging, indexing, and organizing signal data in a way that preserves meaning. It also means keeping track of details that may matter later: source, configuration, sampling rate, filters, timestamps, known artifacts, patient or test context, and relationships to other signals captured at the same time.

Here are five issues medical device teams should watch for when using physiologic signal data to develop algorithms, therapy decisions, diagnostic outputs, or verification-ready datasets.

Trap #1: Assuming simultaneous signals are aligned

When two systems are recording signals at the same time, it is tempting to assume those signals can be compared directly.

That can be a costly assumption.

Different devices have different time bases and may timestamp data differently. One may record continuously while another records data in segments. Both may have timing deficiencies that are compensated for by backend software that is not accessible when the raw data is gathered.

The result is that two devices that are presumably gathering the same data at the same time rarely do so in exactly the same way.

For some analyses, that may not matter much. If you are comparing a broad average, small timing differences may be tolerable. But for high-resolution signal analysis, timing can become the central problem.

If you are comparing heartbeat morphology beat by beat, a one-second error can mean comparing the wrong heartbeat, while sample-level timing errors can distort the morphology of the signal itself. If you are trying to validate therapy-triggering logic, misalignment can lead to false conclusions about whether the device responded correctly.

The finer the comparison, the more important it becomes to understand not just when each recording started, but how each system constructs and maintains its time base throughout the recording.

Trap #2: Over-conditioning—or training on data that is too clean

Signal data often needs to be segmented, filtered, aligned, normalized, reformatted, or cleaned before it can be analyzed. Artifacts may need to be detected or removed. Signals may need to be mathematically restructured so relevant features can be measured consistently.

But signal conditioning creates its own risk.

The real world does not deliver perfect signals. Patients move. Sensors shift. Contact quality changes. Noise is always present. Signals vary across physiology, use environments, and clinical conditions.

If the development process removes too much of that reality, the resulting algorithm may perform well only under artificial conditions.

A filter can remove noise while also removing information that matters. A preprocessing step can make development data easier to work with while making the algorithm less robust to real-world variability. An algorithm trained primarily on highly conditioned signals may never learn how to handle the artifacts and variations it will encounter in actual use.

The same issue applies to the breadth of the training data. An algorithm developed on a narrow or unrepresentative dataset may appear to perform well during development but fail when exposed to a broader patient population or different signal conditions.

The goal of signal conditioning is not to make the waveform look ideal. It is to reduce interference while preserving the characteristics and variability that matter to the intended clinical use.

Trap #3: Choosing the wrong source of truth

Most signal-based device datasets eventually need to be compared against some type of reference.

That reference may be an approved device, a known-good dataset, a clinical measurement, a manually reviewed annotation, or a previously characterized signal library.

Selecting the wrong reference can create a major development burden.

A reference source may have been designed for a different purpose. It may capture data differently, apply different filtering, use a different time base, or store data in a format that obscures important characteristics.

It may also contain gaps that were irrelevant to its original use but become critical for yours.

For example, a physician reviewing a series of short waveform segments may not require a perfectly continuous recording. But a development team attempting a sample-by-sample comparison against a new device may need exactly that.

A reference dataset can be entirely fit for its original clinical purpose and still be a poor source of truth for your intended analysis.

If the reference data is not directly comparable to your data, the team may have to manipulate one dataset extensively to match the other. Some normalization is reasonable. But the more extensive the manipulation, the greater the burden of demonstrating that the comparison is still meaningful.

Before choosing a source of truth, teams should ask:

• Is the reference data captured in a way that supports the comparison we need?
• Is raw data available, or only a processed view?
• If it has been processed, what filtering or transformation has already been applied?
• Is it truly continuous, or is it composed of time-sliced segments?
• Are there gaps, dropped samples, duplicate samples, or timestamp issues?
• Can we compare our data against it with minimal manipulation?

Whenever possible, request sample reference data before committing to a protocol or validation strategy. Even a small anonymized example can expose problems with format, continuity, timestamps, and signal quality before they become embedded in the development plan.

The wrong reference can turn what appears to be a straightforward validation strategy into months of avoidable data science work.

Trap #4: Failing to preserve independent verification data

In most cases, the datasets used to develop or fine-tune an algorithm should not also be relied upon to verify its performance. Doing so is the analytical equivalent of teaching to the test.

An algorithm will naturally tend to behave as expected on the dataset used to develop it.

That means some portion of the raw data needs to be set aside for independent verification, or new data must be gathered later specifically for that purpose.

This requires planning early in the program.

Data needs to be organized so development and verification samples can be separated. Signal libraries need to be characterized. Context needs to be preserved. Known flaws need to be documented. The team needs to know which datasets are appropriate for exploration, which can be used for algorithm development, and which will remain untouched until verification.

If that work is not done up front, teams may discover late in development that they do not actually have the independent data needed to support their performance claims.

The result can be new data collection, late-stage rework, or a weaker evidence package.

Trap #5: Starting data science too late

Perhaps the biggest mistake is treating biosignal data science as a downstream analytics task.

It is not something to add after the signal has been captured and the algorithm concept has already been defined. The intended use of the data should influence the development plan from the beginning.

The intended analysis should inform the signal requirements and acquisition protocols.

The validation strategy should influence the choice of reference source.

The verification plan should shape how signal libraries are built, labeled, characterized, and preserved from the earliest stages of development and discovery.

When those decisions are made too late, teams often find themselves trying to reconstruct context, compensate for incompatible datasets, or rescue data that was never collected with the eventual comparison in mind.

Sometimes non-ideal data can be salvaged. Good data science can extract significant value from difficult datasets. But rescue work takes time, adds complexity, and increases the burden of explaining and justifying what was done.

A better approach is to design the data chain intentionally from the start: capture the right signal, preserve the right context, understand the time base, choose the right reference, condition the data carefully, retain real-world variability, and build independent verification assets along the way.

Getting the signal is only the beginning

Reliable signal acquisition is essential. But what happens to that signal afterward determines whether it can ultimately support a product claim.

Medical device teams should be asking early:

• Are we capturing the signal in a way that supports the analysis we ultimately need?
• Do we understand the context and limitations behind the data?
• Do we understand the differences in timing and signal format between the sources we intend to compare?
• Are we preserving clinically relevant information and real-world variability during conditioning?
• Is our source of truth appropriate for the comparison?
• Are we protecting independent datasets for verification?

Addressing these questions early takes discipline, planning, and experienced guidance. Failing to address them can ultimately prolong both development and approval at significantly greater cost.

Learn more

Transforming Biosignals into Clinical Insights

Mastering the Medical Device Data Explosion

Get Help with Your Medical Device Data