Post-market surveillance, vigilance, and CAPA are three MDR-required processes that only work when they feed each other. PMS under Articles 83 to 86 of Regulation (EU) 2017/745 is the proactive system that collects and assesses real-world data. Vigilance under Articles 87 to 92 is the reactive reporting channel that activates when a serious incident or FSCA threshold is crossed. CAPA, described in EN ISO 13485:2016+A11:2021 clause 8.5.2, is the corrective and preventive action process that closes the loop by eliminating root causes and updating the risk file under Annex I. A PMS system that does not feed CAPA is decorative. A vigilance report without a CAPA behind it is a finding. A CAPA that does not update the PMS plan is an open loop. Auditors check the integration, not the individual processes in isolation.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • PMS (MDR Articles 83 to 86) is the umbrella data-collection and assessment system. Vigilance (MDR Articles 87 to 92) is the subset that escalates to competent authorities when a serious incident or FSCA threshold is crossed. CAPA (EN ISO 13485:2016+A11:2021 clause 8.5.2) is the mechanism that acts on the findings and prevents recurrence.
  • The three processes are not separate universes. Article 83(3) explicitly names the use of PMS findings to identify needs for preventive or corrective action — which means the CAPA link is written into the Regulation, not borrowed from the standard.
  • The PMS-to-vigilance handoff is a decision rule: does the event meet the definition of a serious incident under Article 2(65), and does the reporting clock under Article 87 start. MDCG 2023-3 Rev.2 is the interpretive guidance auditors rely on.
  • The vigilance-to-CAPA handoff is automatic in any well-run QMS: every reportable event generates a CAPA record, root cause analysis, and effectiveness verification.
  • The CAPA-to-PMS loop is where most startups fail. CAPA outcomes must update the PMS plan, the risk file under EN ISO 14971:2019+A11:2021, and the clinical evaluation. An auditor who finds a closed CAPA without corresponding updates has found a systemic integration problem.

The arm strap that exercised all three systems at once

The sleep-device story we have told before is the clearest working example of PMS, vigilance, and CAPA operating as one system. A small MedTech company launched a sleep-monitoring device worn on the upper arm. Biocompatibility was tested against EN ISO 10993-1 before market. The notified body accepted the file. Then, weeks into real-world use, the skin-irritation complaints started.

What happened next is what the MDR requires but founders rarely see written out as a single sequence. The complaints landed in the PMS intake channel. The intake logged them, assigned an owner, and ran the assessment against the PMS plan. The trend was real. The assessment escalated the most severe cases against the serious incident definition in Article 2(65), and the reporting decision was taken under Article 87. Simultaneously, a CAPA record opened. Root cause analysis pointed at the textile-polymer interface under prolonged perspiration. Corrective action updated the material specification. The risk file under EN ISO 14971:2019+A11:2021 was revised — the hazard had been identified but the occurrence rate in real conditions was higher than the pre-market estimate. The IFU and labelling were updated. The PMS plan itself was updated with a new trigger criterion for the same class of complaints. Effectiveness was verified weeks later when the complaint rate dropped to zero.

One event. Three processes. One integrated response. That is the relationship this post is about.

The three processes, stated cleanly

Before looking at how data flows between them, fix the three definitions in place.

Post-market surveillance. MDR Article 83 requires every manufacturer to plan, establish, document, implement, maintain, and update a PMS system that is an integral part of the quality management system under Article 10(9). The system actively and systematically gathers, records, and analyses relevant data on the quality, performance, and safety of the device throughout its lifetime. Article 84 fixes the PMS plan as part of the technical documentation under Annex III. Article 85 governs the PMS Report for Class I devices. Article 86 governs the PSUR for Class IIa, IIb, and III devices. MDCG 2025-10 (December 2025) is the current operational guidance. For the starter guide, see what is post-market surveillance under MDR.

Vigilance. MDR Articles 87 to 92 govern the reporting of serious incidents and field safety corrective actions to the competent authorities, plus trend reporting under Article 88 and the Eudamed electronic system under Article 92. MDCG 2023-3 Rev.2 (January 2025) is the authoritative Q&A on vigilance terms and concepts. Vigilance is reactive and time-bound. For the reporting framework, see what is vigilance under MDR.

CAPA. The MDR does not use the word "CAPA," but Article 10(9) requires the QMS to cover "management of corrective and preventive actions and verification of their effectiveness," and Article 10(12) requires immediate corrective action when a device may not be in conformity. The mechanics sit in EN ISO 13485:2016+A11:2021 clause 8.5.2 for corrective action and clause 8.5.3 for preventive action. For the full walkthrough, see CAPA under MDR using ISO 13485.

Three separate entries in three separate parts of the regulatory framework. One operational reality.

How data flows between them

The integration is directional and it is named in the Regulation. Article 83(3) specifies what the PMS findings must be used for. The list includes updating the benefit-risk determination, updating the design and manufacturing information, updating the clinical evaluation, updating the summary of safety and clinical performance where applicable, identifying needs for preventive or corrective action, and identifying options to improve the usability, performance, and safety of the device. "Identifying needs for preventive or corrective action" is the CAPA link. It is not a standard saying the manufacturer should probably do this. It is the MDR saying the PMS system must produce CAPA triggers as one of its defined outputs.

The flow, at its cleanest, has three hand-offs:

  1. PMS assesses an event and either handles it in-system or escalates. If the event meets the vigilance thresholds, the vigilance process takes over for the reporting obligation while PMS keeps analysing. If the event does not meet vigilance thresholds but represents a nonconformity or a potential nonconformity, CAPA takes over for the root cause and action.
  2. Vigilance generates its own CAPA automatically. A serious incident that triggers vigilance reporting is, by definition, a nonconformity or a signal of one. There is no scenario in which the vigilance report is filed and the CAPA record is not opened.
  3. CAPA outcomes feed back into PMS. The corrective and preventive actions, the effectiveness verification, and the updated risk analysis all become PMS inputs for the next review cycle. The PMS plan itself may be updated if the event revealed a gap in the data-collection or assessment process.

Draw those three arrows on a whiteboard and that is the integration. Everything auditors look for is whether those arrows are actually drawn in the documentation and actually walked by the team.

The PMS-to-vigilance handoff

The handoff from PMS to vigilance is a decision rule, not a process step. The decision rule is: given the event that PMS has logged and assessed, does it meet the definition of a serious incident under Article 2(65) of Regulation (EU) 2017/745, and does it therefore trigger the reporting clock under Article 87.

A serious incident is defined in Article 2(65) as any incident that directly or indirectly led, might have led, or might lead to death, serious deterioration in state of health, or a serious public health threat. The "might have led" language is the one that trips startups up — you do not wait for harm to materialise before reporting. The potential for the listed outcomes is enough. MDCG 2023-3 Rev.2 walks through 24 questions on how to read this definition in practice, including the distinction between incidents and serious incidents, user and use errors, indirect harm, and manufacturer awareness date.

The PMS plan under Annex III must specify how this decision is made. Who owns the decision. What documentation the decision produces. What the escalation path is if the decision is ambiguous. And how the timeline under Article 87 is started. An auditor who reads the PMS plan and cannot find the decision rule will treat that gap as the finding, even if no serious incident has happened yet. For the reporting mechanics themselves, see serious incidents under MDR — definition and reporting.

The vigilance-to-CAPA handoff

The vigilance-to-CAPA handoff should be automatic and explicit in the QMS procedures. Every serious incident report under Article 87 and every field safety corrective action under Article 89 generates a CAPA record. The CAPA record runs the full EN ISO 13485:2016+A11:2021 clause 8.5.2 sequence: nonconformity identification, containment, root cause analysis, corrective action definition, implementation, effectiveness verification, and closure.

What auditors watch for here is traceability. Given a vigilance report, can the team produce the CAPA record it generated. Given a CAPA record for a post-market event, can the team produce the vigilance report that triggered it or the documented decision that vigilance did not apply. Given a field safety corrective action, can the team produce the CAPA root cause that justified the action. Any break in this traceability chain is an integration finding, and an integration finding at audit is harder to close than a missing document, because it shows the system does not actually run as a system.

The CAPA-back-to-PMS loop

This is where most startups leak points at audit. The CAPA closed well. The corrective action worked. Effectiveness was verified. And then the CAPA record was filed and nothing happened to the PMS plan or the risk file. The loop did not close.

The loop has to close in at least four places. The risk management file under EN ISO 14971:2019+A11:2021 is updated to reflect the revised hazard, occurrence, or severity. The clinical evaluation is updated if the event has clinical implications under Article 61 and Annex XIV Part B. The PMS plan itself is updated if the event revealed that the data-collection or assessment process missed something. And the next PMS Report under Article 85 or PSUR under Article 86 reflects the CAPA outcomes in the summary of preventive and corrective actions taken.

Article 83(3) names these updates explicitly. The PMS findings must be used to update the benefit-risk determination, the design and manufacturing information, the clinical evaluation, and the SSCP where applicable. CAPA outcomes are PMS findings. The update is not optional. An auditor who finds a closed CAPA with no matching updates will open a finding for systemic non-integration — and that finding is often the one that expands into a deeper audit of the entire post-market file.

Common integration failures

Across the certifications we have supported, the integration failures fall into a small number of repeating patterns. Each one is avoidable with a single procedural fix.

  • Complaint intake is separate from CAPA. Complaints are logged in one system, CAPAs in another, and the link between them depends on someone remembering. Fix: every complaint assessment either produces a CAPA record number or a documented justification for no CAPA.
  • Vigilance reports are filed without a corresponding CAPA. The manufacturer meets the Article 87 reporting deadline, breathes out, and forgets that the reporting was not the corrective action. Fix: the vigilance procedure explicitly requires a CAPA record opened at the same time as the report.
  • CAPAs close without updating the risk file. The corrective action is implemented, effectiveness verified, and the record closed — but the risk file under EN ISO 14971:2019+A11:2021 still reflects the pre-event hazard estimates. Fix: the CAPA closure checklist includes a signed risk-file update entry.
  • PMS Report or PSUR does not reflect CAPA outcomes. The report is produced from a template that does not pull from the CAPA log. Fix: the report template has a mandatory section summarising CAPA activities during the reporting period.
  • Trend reporting under Article 88 has no owner. Trend analysis is not anyone's job, so it does not run, and the first time anyone thinks about it is when a notified body auditor asks. Fix: the PMS plan names the owner, the cadence, and the statistical method.
  • The PMS plan itself is never updated. The plan is treated as a pre-market deliverable and not as a living document. Fix: every CAPA that changes the intake, assessment, or escalation process triggers a plan revision.

Auditor expectations

A notified body auditor assessing integration does not start with the PMS plan in isolation, or the vigilance procedure in isolation, or the CAPA log in isolation. The auditor picks a single post-market event and asks the team to walk it end to end. Given this complaint, show me how the PMS system logged and assessed it. Show me the decision on whether it was a serious incident. Show me the vigilance report if one was required, or the documented decision not to report. Show me the CAPA record. Show me the root cause analysis. Show me the corrective action. Show me the effectiveness verification. Show me the risk-file update. Show me the clinical-evaluation update. Show me the PMS plan update if the event revealed a gap. Show me how the PMS Report or PSUR reflects the outcome.

If every step produces a documented record and every record links to the next, the integration is real. If any step cannot be walked, the integration is not real and the audit finding is written against the system, not the individual process. MDCG 2025-10 reinforces this by describing PMS as an interaction between QMS processes, not as a standalone discipline.

The Subtract to Ship angle — one post-market file, three named outputs

The Subtract to Ship framework for MDR applied to the PMS-vigilance-CAPA relationship produces a simple rule: run one integrated post-market process, with three named outputs, rather than three parallel systems that happen to share data. The outputs are the PMS Report or PSUR under Article 85 or 86, the vigilance reports under Article 87 when required, and the CAPA records under clause 8.5.2 of EN ISO 13485:2016+A11:2021. The process behind them is one loop that runs on one cadence with one owner in a small team.

What subtraction removes: duplicate intake channels, separate complaint and CAPA logs, redundant review meetings, parallel risk-file update procedures, and any process document that describes activities the team does not actually perform. What subtraction keeps: one intake channel, one assessment rhythm, one escalation rule, one CAPA record structure, one risk-file update path, and one report template per device class. A three-person startup can run that. A thirty-person startup without the discipline cannot.

The test, as always, is traceability. For every element in the integrated process, can you name the specific MDR article, annex, or harmonised standard clause it satisfies. If yes, keep it. If no, it is waste.

Reality Check — where do you stand?

  1. If a complaint came in tomorrow that might be a serious incident, who decides whether Article 87 reporting is triggered, and how long until that decision is documented?
  2. Can you walk a single post-market event from intake to PMS Report or PSUR entry, with every intermediate record linked?
  3. Does every vigilance report you have filed have a corresponding CAPA record with a documented root cause and effectiveness verification?
  4. When a CAPA closed in the last twelve months, was the risk management file under EN ISO 14971:2019+A11:2021 updated to reflect the outcome?
  5. When a CAPA closed in the last twelve months, was the clinical evaluation reviewed to determine whether an update under Article 61 was required?
  6. Does your PMS plan under Annex III explicitly describe the decision rule for escalating an event to vigilance, and the handoff to CAPA?
  7. Does your PMS Report or PSUR template have a mandatory section summarising CAPA activities for the reporting period?
  8. Who owns trend reporting under Article 88, on what cadence, and using what statistical method?
  9. Has the PMS plan itself been updated in response to a CAPA outcome in the last year, or is it still the pre-market version?
  10. If a notified body auditor picked one complaint at random and asked you to walk the full PMS-vigilance-CAPA sequence, would every step produce a record?

Frequently Asked Questions

Is CAPA required by the MDR or only by EN ISO 13485:2016+A11:2021?

Both. MDR Article 10(9) names "management of corrective and preventive actions and verification of their effectiveness" as a required component of the QMS. Article 10(12) requires immediate corrective action when a device may not be in conformity. EN ISO 13485:2016+A11:2021 clause 8.5.2 provides the harmonised mechanics. The legal obligation sits in the Regulation; the implementation blueprint sits in the standard.

Does every vigilance report require a CAPA?

In practice, yes. A serious incident that meets the Article 87 reporting threshold is a nonconformity or a signal of one, which triggers the clause 8.5.2 corrective action process. Filing the vigilance report is the reporting obligation; the CAPA is the root cause and action obligation. Both must happen.

Can PMS findings trigger a CAPA even when no serious incident occurred?

Yes, and this is one of the most important ways PMS earns its keep. Article 83(3) names "identifying needs for preventive or corrective action" as a required use of PMS findings. A trend, a non-serious complaint pattern, a literature signal, or a similar-device observation can all trigger a CAPA without any Article 87 reporting.

Where in the PMS plan should the vigilance decision rule live?

Annex III requires the PMS plan to describe methods and protocols to assess collected data, manage events subject to trend reporting under Article 88, and identify and initiate appropriate measures including corrective actions. The vigilance decision rule — when does an event become a reportable serious incident — is the bridge between assessment and measure, and belongs in that section of the plan.

What is the most common integration finding at audit?

A closed CAPA with no corresponding update to the risk management file or the clinical evaluation. The CAPA worked in isolation, but the loop back into PMS and the other post-market deliverables was never closed. This finding shows the manufacturer runs three processes instead of one integrated system.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(9) and 10(12) (QMS obligations and corrective action), Articles 83 to 86 (post-market surveillance system, plan, PMS Report, and PSUR), Articles 87 to 92 (vigilance, trend reporting, electronic system), Annex I (general safety and performance requirements including risk management linkage), and Annex III (technical documentation on post-market surveillance). Official Journal L 117, 5.5.2017.
  2. MDCG 2025-10 — Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices. Medical Device Coordination Group, December 2025.
  3. MDCG 2023-3 Rev.2 — Questions and Answers on vigilance terms and concepts as outlined in Regulation (EU) 2017/745 and Regulation (EU) 2017/746. Medical Device Coordination Group, first publication February 2023; Revision 2, January 2025.
  4. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes, clause 8.5.2 (corrective action) and clause 8.5.3 (preventive action).
  5. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.

This post sits inside the Post-Market Surveillance & Vigilance series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The integration between PMS, vigilance, and CAPA is the single most audited aspect of the post-market file — the companion posts in this cluster walk each of the three processes in depth, and this post is the map that shows how they fit together.