What counts as software as a medical device?
The term software as a medical device, or SaMD, describes software intended to perform a medical purpose without being part of a hardware medical device. The International Medical Device Regulators Forum coined the term, and the FDA adopted it. The practical test is the intended use: if software is meant to analyze a physiologic signal and inform a clinical decision, it generally meets the definition of a medical device, whatever platform delivers it.
PulSentry sits squarely in that definition. It takes the photoplethysmography (PPG) waveform that a standard pulse oximeter already produces, measures the respiratory variation in that waveform, and computes a pulsus index, the ratio of the respiratory spectral peak to the cardiac spectral peak in the frequency domain of the signal. The output is information about a signal, pulsus paradoxus, that can accompany cardiac tamponade. Producing that information for a clinical purpose is what makes the software a device. According to a review of medical-device law, this signal-to-decision link, rather than the code itself, is the trigger for oversight (Pesapane and colleagues, 2018).
How an algorithm on an existing pulse oximeter is classified
Medical devices in the United States are sorted into three classes by risk. Class I devices are low risk and mostly exempt from premarket review. Class II devices are moderate risk and usually reach the market through a 510(k) clearance. Class III devices are high risk and require premarket approval with clinical evidence. A historical analysis of FDA device regulation from 1976 to 2020 traces how these pathways grew more numerous and more varied over time, with most devices reaching the market through the moderate-risk route (Darrow, Avorn, and Kesselheim, 2021).
For a signal-analysis algorithm, the class follows from two questions. What is the clinical situation the output speaks to, and what would a reasonable user do with that output? A tool that offers a non-diagnostic flag to prompt a clinician to look more closely sits at a different risk level than one that drives an automatic treatment. The intended-use statement, written carefully and matched by the evidence, is therefore the center of the whole exercise. As a commentary in Clinical Chemistry put it, the first question for any clinical software is simply whether it is a medical device at all, and the answer turns on what the software claims to do (Jackups, 2023).
510(k), De Novo, and the role of a predicate device
Two routes matter most for moderate-risk software, and the difference between them is worth stating plainly.
The 510(k) route
A 510(k) is a premarket notification. It clears a device by showing it is substantially equivalent to a legally marketed predicate device, meaning a device already on the market with the same intended use and similar technological characteristics. The applicant does not start from scratch; it demonstrates that its product is as safe and effective as the predicate. The same historical analysis records that 510(k) clearances are by far the most common authorization, numbering in the thousands each year, while novel premarket approvals are far fewer (Darrow, Avorn, and Kesselheim, 2021).
The De Novo route
When a device is novel and low to moderate risk but has no suitable predicate, forcing a 510(k) would be a poor fit. The De Novo request exists for exactly that case. It asks the FDA to create a new classification for the device based on its own risk profile, and once granted, that classification can serve as a predicate for later products. De Novo is not a shortcut and it is not a lower bar; it is the correct path when equivalence to an existing device cannot honestly be claimed.
Which route fits PulSentry depends on whether an appropriate predicate exists for the specific intended use of detecting and trending the pulsus paradoxus signal in the PPG waveform. That determination is made with the FDA, and it can shift as the field of cleared signal-analysis software grows.
What a notification-and-triage tool looks like to a regulator
How software frames its output changes how a regulator views its risk. There is a meaningful distinction between software that makes a diagnosis and software that notifies and triages, that is, software that surfaces a finding and prompts a person to act, while leaving the clinical decision to that person. The respiratory and cardiac spectral peaks PulSentry measures are reported as a trend and a flag, not as a verdict. The clinician remains the decision-maker.
This framing matters because clinical decision support has a specific regulatory history. Authors writing in BMJ argued for sensible, risk-based oversight of clinical decision support software as a medical device, calibrated to how much the user can independently review the basis for the software's output (Mori and colleagues, 2022). Earlier legal analysis traced how the line between informational support and regulated diagnosis has long shaped FDA thinking on this kind of software (Karnik, 2014). A tool designed so that a clinician can understand and act on a flag, rather than defer to it, fits the lower-risk end of that spectrum.
The triage-software precedent: how alerting tools have been cleared before
PulSentry is not the first software intended to watch a signal and raise a flag for a time-sensitive condition. Computer-aided triage and notification software has reached the market in other areas of acute care, where an algorithm analyzes data already being collected and alerts a clinician to a finding that warrants prompt attention. The role of such software is to shorten the time to a human review, not to replace it.
That precedent is useful because it establishes a recognizable category: a quality-assurance and triage function, sometimes abbreviated QAS, that flags a possible finding for confirmation. A persistent pulsus paradoxus signal trended over time fits this notification-and-triage shape well. The existence of cleared software in adjacent triage roles is part of what informs the predicate analysis, and the broader record shows the FDA has built specific pathways to handle novel software-driven functions as they emerge (Darrow, Avorn, and Kesselheim, 2021). None of this implies that PulSentry is cleared. It is not. It describes the category the product is designed to fit.
Validation evidence a submission rests on
Whatever route a device follows, the submission stands on evidence. For a signal-analysis algorithm, the core questions are concrete. How well does the pulsus index separate the signal of interest from normal variation and from artifact? How does it behave across skin tones, motion, and the range of pulse oximeters in real use? How stable is the output over time, and how often does it flag when it should not? Substantial equivalence in a 510(k), or a new classification through De Novo, is supported by analytical and clinical performance data that answer these questions for the stated intended use.
Commentators on clinical software stress that the rigor of this evidence, and the transparency of how it was gathered, is what separates trustworthy tools from the rest (Mori and colleagues, 2022). PulSentry's validation program is described separately on the how we are validating PulSentry page; it is built around retrospective signal analysis and a prospective clinical arm, with the disclaimer that the work is ongoing and the product is investigational.
Why no new hardware simplifies the pathway
One feature of PulSentry shapes its regulatory story more than any other: it adds no new sensor. The PPG waveform comes from a standard pulse oximeter already cleared and in clinical use. The submission therefore centers on the software and its validation rather than on a new physical component with its own biocompatibility, electrical-safety, and sensor-accuracy testing.
This does not remove the need for rigorous software validation, and it does not change the fact that the algorithm is the device. What it does is narrow the scope of what must be evaluated, and it lets the analysis concentrate on the question that actually matters: does the software reliably do what its intended use claims? As the SaMD framing makes clear, the intended use, not the hardware, drives both the classification and the evidence required (Pesapane and colleagues, 2018). Re-using accepted hardware keeps the focus there.
Where PulSentry sits today
PulSentry is investigational. It has not been cleared or approved by the FDA, and nothing here should be read as a regulatory claim. The purpose of laying out the pathway is to be honest about what the road looks like: a SaMD classification driven by intended use, a 510(k) or De Novo route decided by whether a suitable predicate exists, a notification-and-triage framing that keeps the clinician in charge, and a validation package that earns whatever clearance is sought. To understand the signal underneath all of this, see the pillar on FFT and power spectral density of the PPG waveform. For the basics of the source signal, see pulse oximetry 101, and for why a continuous signal is worth having, see why TTE misses post-surgical pericardial hematoma. A plain-language overview for patients and families lives in the patient guide.
Frequently asked questions
Is a pulse-oximeter waveform algorithm regulated as a medical device?
Yes. Software that analyzes a physiologic signal to flag a possible clinical condition is generally treated as software as a medical device (SaMD) by the FDA. The regulatory class depends on the intended use and the risk of the information it provides. PulSentry is investigational and has not been cleared or approved by the FDA.
What is the difference between a 510(k) and a De Novo submission?
A 510(k) clears a device by demonstrating it is substantially equivalent to a legally marketed predicate device. A De Novo request is used when no suitable predicate exists and creates a new classification for a novel, lower-risk device. Which route fits depends on whether an appropriate predicate is available for the specific intended use.
Does running on an existing pulse oximeter change the regulatory picture?
It can simplify it. Because the algorithm uses signals from hardware already in clinical use rather than introducing a new sensor, the submission centers on the software and its validation rather than on new physical components. The intended use, not the hardware, drives the classification and the evidence required.