Skip to content

How every number here is computed

DeviceSignal publishes counts, medians and expected ranges derived from FDA's public data. This page states the arithmetic behind each one, in enough detail that you can reproduce it or argue with it. Where a method has a known weakness, that is written down here too.

Last updated

Counts

A clearance count is a count of rows in FDA's device/510k dataset with that product code. A recall count is a count of rows in device/recall. An adverse-event count is a count of reports in device/event. None of them is adjusted, weighted or estimated — if the number here differs from one you get from FDA directly, the likeliest reason is that we loaded a different bulk export, and the retrieval time beside every figure tells you which.

"Last 12 months" means the 365 days before the most recent ingest, not a calendar year. A count labelled all-time goes back to 1976, when the Medical Device Amendments began.

The expected range for adverse events

Expected range is an exponentially weighted moving average of the twelve consecutive months before the month in question, plus or minus two standard deviations, computed on counts divided by corpus-wide monthly volume and scaled back into real reports. A month missing any of those twelve returns insufficient_history rather than a bound.

Two consequences worth being explicit about. First, the comparison is against the code's own history, not against other codes — a busy month in a busy code is not a finding, and a code with three reports a year can be flagged for having six. Second, dividing by corpus-wide monthly volume is what stops an FDA reporting-system change from registering as a spike in every code at once; it means the range answers "unusual for this code" rather than "unusual for MAUDE".

A month without twelve unbroken months behind it gets no range at all, and is drawn without one rather than compared against a shorter window. A gap in the window describes a change in our coverage, not a change in the device.

Review time

The median is a true median (Postgres percentile_disc, not an average) of elapsed calendar days between FDA's date_received and decision_date. The spread is the 10th to 90th percentile of the same figure.

This is not FDA's own "MDUFA days" or "review days" metric, which excludes the time a submission spends on hold awaiting an answer from the applicant. Elapsed calendar days is a longer number and is the one that matches a project plan, so it is the one we publish — labelled as such everywhere it appears, because quoting it as FDA review time would be wrong.

Crowding

A 0–100 index, computed as the log of the number of distinct companies holding a clearance in the code, scaled against the most crowded code in the corpus. Logarithmic because the distribution is extremely skewed — the busiest code has over a thousand makers and the median has fewer than twenty, so a linear scale would put almost every code at zero.

It counts companies after entity resolution, so four spellings of one manufacturer count once. That is the figure that answers "how many competitors"; the raw count of FDA applicant strings is larger and answers nothing.

How serious a finding is

Findings are ordered by consequence, not by date: a recalled predicate outranks a routine clearance whichever arrived first. The order is predicate risk, recall, adverse-event spike, new entrant, review-time shift, crowding, clearance, and last a quiet code.

A quiet code ranks below everything, deliberately. It is the only finding that is not an event — nothing happened, and that is the observation — so it can never be the reason to open an email.

Where FDA has published a recall class we show the class rather than our own band, because Class I is a fact FDA published and "most serious" is a word we chose. Recall class I is the most serious kind of recall; device class I is the least risky kind of device. The two are unrelated and are never mixed on the same line.

Company names

FDA publishes the applicant as free text, so one manufacturer appears under many spellings. We normalise punctuation, legal suffixes and casing, block candidates with a trigram index, score the pairs, and merge automatically above a threshold; the largest few hundred are reviewed by hand.

Every resolved name is shown beside FDA's raw spelling rather than instead of it, and the number of spellings merged into each is published. If you think a merge is wrong you can see exactly what was merged.

Predicate ancestry, and why it is thin

FDA does not publish the predicate a device was compared to as data. The reference exists only inside each 510(k) summary PDF, and the document server does not serve automated clients. So our ancestry is sparse, and every surface that shows it says so.

Where we hold no chain for a device we say "no predicate chain recorded" and explain why. We never render an empty tree, because an empty tree reads as "this device cites nothing", and we never describe a chain with no recalled ancestor as clean — ours is partial by construction, so the honest phrasing is that none of the ancestors we hold has been recalled.

What we will not do

We do not put a language model between you and an FDA record. Every figure on this site is a query result, and every one carries the record id it came from. Nothing is summarised by a model, inferred, or filled in.

We do not estimate. Where a number is unknown the page says so rather than showing zero — "not counted yet" and "class not published" are different statements from "none", and conflating them is how a gap in our data becomes a finding about a device.