DeviceWatch now raises a critical alert as soon as a MAUDE report arrives coded by the FDA as a Death, without waiting for the narrative or AI analysis. An Injury the FDA published without a narrative alerts the same way once the product has completed a baseline ingest. A capped first collection does not count as one, and the batch that completes the baseline does not count itself. The analysis still runs, and when it does it sends a separate update to the initial alert.
Why the coding comes first
A MAUDE report arrives in parts. The coded fields, including the FDA’s event type, come with the first record. The narrative can follow days later, and sometimes never arrives at all. Last week’s update covered how DeviceWatch goes back for narratives published late.
Until now a critical alert followed the analysis, and the analysis needs a narrative. That tied a Death alert’s timing to when the FDA published text and how long the analysis queue ran. The event type was already on the record, so alerting on it directly removes both dependencies.
What the alert says
An alert raised at ingest reports what the FDA coded and nothing more. It reads “FDA-reported death” or “FDA reported an injury” across email, Slack, Teams and webhooks, and says there is no AI summary yet. It does not invent model fields to fill the space. Webhook payloads carry the alert’s source, so a receiving system can tell an FDA-coded alert from an analysed one.
Death is the only alert shown in red. Injury sits in the amber tier with serious reports.
When the narrative arrives and the analysis runs, DeviceWatch sends an update carrying the summary. Each event gets one initial alert, enforced in the database, so the ingest path and the analysis path cannot both raise one. If the FDA later changes an Injury to a Death, DeviceWatch sends one correction saying so, and an unreviewed alert can still escalate with a further notification.
The limits
The alert reflects the FDA’s coding, not an assessment of the event, so a reviewer still reads the report.
Initial alerts follow the FDA’s date for a report, not the time DeviceWatch ingested it, and only fire for reports the FDA received in the last 60 days. Updates and corrections follow a previously raised alert, so the window does not apply to them. They wait for that alert’s deliveries to finish before they go out. Loading a product’s history does not set off a flood of alerts for old events, and nothing fires retroactively: Injuries already stored without a narrative stay unalerted.
An Injury that arrives with a narrative keeps its existing path, where the analysis decides whether it alerts. Automated analysis covers Death and Injury reports, not every severity. The analysis coverage panel now shows how many reports the FDA coded as Death or Injury are still waiting on a narrative, and it does not count them as analysed.
Checking a product before you save it
The add-product form has a new Preview matches step. Before a product is saved, DeviceWatch asks openFDA how many MAUDE reports its product code, brand and manufacturer would match. It shows the five newest.
The preview uses the same 60-day lookback as the scheduled ingest, so the count reflects what monitoring will see. It warns when a product has no product code, when nothing matches and when the match count is large enough to suggest the search is too broad.
Also in this release
CAPA tracking has its own list and detail pages, with one CAPA per signal and a status, owner and due date for each. The CAPA summary report reads from those records.
Recalls now show extracted 510(k) fields where extraction has run. Plan switches, removing a notification channel and deleting a report template ask for confirmation and name what will change.
DeviceWatch monitors MAUDE, recalls and 510(k) clearances for device makers, using public openFDA data. More at devicewatch.app.