DeviceWatch now shows one recall card per FDA recall event, with the FDA class where matching enforcement records have one. Analytics counts recall events too. A recall filed once per affected product no longer shows up as several identical listings. The same week brought a simpler navigation and fuller signature details in review history.
Recalls grouped by event
FDA files a device recall as an event, then gives each affected product its own recall number. One labelling error across two catalog numbers becomes two records with the same reason, the same firm and the same date. DeviceWatch used to show them as two identical cards.
The Recalls page now lists one card per event and names every product recall number in it, such as Z-0674-2024 and Z-0675-2024, with a product count and a link to each displayed recall record. Paging and counts run by event.
Grouping never hides a difference. Within an event, the card shows the most serious class. Status, firm and reason show the one shared value, or every distinct value when products differ. A recall with no event number stays its own card.
Counting by record repeats the same listing once per product. Counting by event removes that duplication. An event is still a filing, not a verdict: two events can share a cause, and one event can cover several.
FDA class on recalls
Recalls now show their FDA class (Class I, II or III) where it is available from matching FDA enforcement records. DeviceWatch reads the class from openFDA’s device enforcement data, matched by recall number. A recall with no matching record, or a matching record with no class, shows none. Earlier versions read the recall endpoint, which has no class field, so stored recalls showed none. Existing recalls pick up a class on a successful weekly rescan, written through the same audited sync as any other change.
The recall reason is clamped to four lines with Show more only when text is hidden, and one line carries the number, firm, status, a link to the FDA record and the labelled initiation date. 510(k) clearances use the same layout.
Signature details in review history
Event review history now shows the stored signer, the meaning of the signature, the full server timestamp and the server’s verification result. It tells verified, mismatched, historical, unsigned and unavailable signatures apart, so a reviewer can see what was signed without leaving the event.
Simpler navigation
The main navigation is now Overview, Surveillance, Insights and Reports.
- Surveillance holds review, events, investigations, recalls and CAPAs.
- Insights holds competitor analysis and historical analytics.
- Reports holds exports. Weekly briefs stay separate and arrive on their own schedule.
Managing your own and competitor products moved to Settings > Monitoring. Existing record URLs still work, and plan and role access are unchanged.
Smaller changes
- The event page is one column: AI summary, event details, then review. Every Event Details field shows inline, and the FDA narrative appears once, inside the review’s source evidence.
- Event PDFs no longer overlap long summaries with the next field and now include confidence.
- The review queue sorts by AI severity by default, and Next pending moves through the queue you selected.
- Signals, Analytics and the dashboard state each data caveat once, with the rest behind “About this data”.
AI summaries and severity ratings help a reviewer decide what to read first. They are not determinations, and the review decision stays with your team. Adverse event data comes from MAUDE through openFDA, and recall data from openFDA’s recall and enforcement records.
Recalls and the review queue are part of every plan, starting with Growth.
More at devicewatch.app.