What a serious incident report has to decide before the clock starts

A device flagged in the field for an unexpected malfunction looks like one event, but EU MDR vigilance splits the question of what to do about it into two gates before a deadline even applies. Article 87 of Regulation (EU) 2017/745 requires manufacturers to report a serious incident to the competent authority of the Member State where it occurred — and “serious” is doing real work in that sentence, because it's a narrower category than the incident definition a quality system otherwise runs on. Once an event clears that bar, the deadline for reporting it isn't a single number. It's three, scaled to severity, and every one of them starts from the same moment: the manufacturer becoming aware that a causal relationship between the device and the incident is established or reasonably possible.

Incident and serious incident are not the same gate

Article 2(64) defines incident broadly: any malfunction or deterioration in the characteristics or performance of a device on the market, including use error tied to ergonomic features, any inadequacy in the manufacturer's supplied information, and any undesirable side effect. That definition is wide enough to cover most of what a complaint or nonconformance system already logs. Article 2(65) narrows the reporting trigger to a specific subset — an incident that directly or indirectly led, might have led, or might lead to the death of a patient, user, or other person; a temporary or permanent serious deterioration in someone's state of health; or a serious public health threat. Ordinary incidents feed the active post-market surveillance system Article 83 requires; only the serious ones trigger Article 87's individual report.

Three deadlines, one severity-scaled trigger

Article 87(3) sets the default at no later than 15 days after the manufacturer becomes aware of the incident. Two narrower categories run shorter clocks: no later than 10 days for an incident involving death or an unanticipated serious deterioration in health, and no later than 2 days for a serious public health threat. All three carry the same qualifier — reported immediately, with the numbered deadline as the outer limit — and the article allows an initial report that's incomplete, followed by a complete one, where necessary to meet the deadline rather than waiting on a finished investigation.

The clock starts at awareness, not at the fix

The trigger for all three deadlines is awareness that a causal relationship between the device and the incident is established, or reasonably possible — a deliberately lower bar than confirmed causation, so the clock doesn't wait on an investigation's conclusion to start running. That puts Article 87 on the same clock logic as a US complaint record's reportability test under 21 CFR 803.50, which also starts at awareness — and on the opposite logic from a US correction-and-removal record, whose 806.10 clock starts at the date the action was initiated in the field. A vigilance file built on the corrections-and-removals clock model is dating its EU reports from the wrong event.

A field safety corrective action is reported on its own logic

A serious incident and the field action taken in response to it are reported separately, on different timing rules. Article 2(68) defines a field safety corrective action as action a manufacturer takes for technical or medical reasons to prevent or reduce the risk of a serious incident related to a device already on the market. Article 87(5) requires that action to be reported without undue delay, in advance of the action actually being undertaken — not after, except in cases of urgency where the manufacturer needs to act immediately. A single serious incident can generate both records: the incident report, dated from awareness, and a separate field safety corrective action report, dated ahead of whatever field action follows from it.

Periodic reporting is the exception, and it needs sign-off

Article 87 lets a manufacturer substitute periodic summary reports for individual serious incident reports where the incidents are similar, occur with the same device or device type, and either the root cause has already been identified, a corrective action has already been implemented, or the incidents are common and well documented. That substitution isn't a default a manufacturer can adopt on its own reading of the pattern — it requires the coordinating competent authority to have agreed, in advance, on the format, content, and frequency of the periodic reports. A vigilance file that quietly rolls similar incidents into a periodic summary without that documented agreement is reporting on a shortcut Article 87 grants only by agreement, not by pattern recognition alone.

A vigilance record built around this structure — the incident/serious-incident gate, the three-tier severity clock, and the separate field-safety-corrective-action timing rule — is previewed in the launch catalog. If your program runs the periodic-reporting exception differently, the shelf takes that correction directly.