21 CFR Part 803 is the FDA regulation that establishes mandatory medical device reporting (MDR) requirements for manufacturers, importers, and device user facilities. The regulation requires these entities to report certain adverse events involving medical devices to FDA, creating a post-market surveillance signal that the agency uses to identify device safety issues, take corrective action, and protect patients.

According to the FDA’s MDR guidance, Part 803 contains mandatory requirements for reporting when a device may have caused or contributed to a death or serious injury, and when a device malfunctions in a way that would likely cause or contribute to death or serious injury if it were to recur. The regulation covers the full post-market lifecycle of a device from the point of distribution through the end of its commercial life.

Part 803 works alongside other post-market requirements. Manufacturers subject to Part 803 are also typically subject to 21 CFR Part 806, which covers corrections and removals (recalls), and to the quality system requirements of 21 CFR Part 820. Together these regulations form the post-market compliance framework that FDA inspects during Quality System inspections.

Who must comply with 21 CFR Part 803?

Part 803 applies to three distinct categories of entities, each with different reporting obligations.

Device manufacturers are the primary regulated entity under Part 803. A manufacturer for MDR purposes includes any person who designs, manufactures, fabricates, assembles, or processes a finished device, as well as any person who remanufactures, relabels, or reprocesses a device. Manufacturers have the broadest reporting obligations under the regulation.

Device importers are companies that import devices manufactured outside the U.S. and distribute them in domestic commerce. Importers have reporting obligations for deaths and serious injuries, though their obligations are narrower than those of manufacturers.

Device user facilities are hospitals, ambulatory surgical facilities, nursing homes, outpatient diagnostic facilities, and outpatient treatment facilities that use devices in the care of patients. User facilities must report device-related deaths to both FDA and the manufacturer, and device-related serious injuries to the manufacturer.

What events must be reported under Part 803?

Manufacturers must report to FDA when they receive or become aware of information that reasonably suggests a marketed device may have caused or contributed to a death or serious injury, or when a device has malfunctioned and that device or a similar device would be likely to cause or contribute to a death or serious injury if the malfunction were to recur.

The threshold for reporting is intentionally broad. FDA does not require certainty that the device caused the adverse event. The regulation uses the phrase “reasonably suggests,” meaning that if the available information indicates a plausible relationship between the device and the adverse outcome, reporting is required. Waiting to confirm causation before reporting is one of the most common MDR compliance errors FDA cites during inspections.

Serious injury under Part 803 means an injury or illness that is life-threatening, results in permanent impairment of a body function or permanent damage to a body structure, necessitates medical or surgical intervention to preclude permanent impairment of a body function or permanent damage to a body structure, requires in-patient hospitalization for more than 24 hours, or causes birth defects.

Malfunctions are reportable when the device did not perform as designed, intended, or expected, and that malfunction would be likely to cause or contribute to death or serious injury if it recurred. This means quality teams must evaluate each malfunction not just for what actually happened but for what could happen if the same failure recurred in a different clinical context.

What are the MDR reporting timelines?

Part 803 sets specific deadlines that manufacturers must meet. Missing these deadlines is itself a violation of the regulation, separate from any issue with the substantive content of the report.

For deaths and serious injuries, manufacturers must submit an MDR to FDA no later than 30 calendar days after the day they become aware of the reportable event. The 30-day clock starts when the company first receives or becomes aware of information that reasonably suggests a reportable event occurred, even if the investigation is not yet complete. A preliminary report is acceptable if the full investigation is ongoing.

For malfunctions, manufacturers must also submit within 30 calendar days of becoming aware of the reportable malfunction, with the same preliminary report option available.

For events that require remedial action to prevent an unreasonable risk of substantial harm to the public health, a 5-day report is required. These are urgent situations where FDA needs to know about the event immediately so it can take action. Five-day reports are rare but apply in situations such as device failures discovered during a public health emergency or failures that could affect a large patient population if not addressed immediately.

Annual or baseline reports were historically required for certain device categories but the current regulation as updated by FDA has moved primarily to a eMDR electronic submission system. All MDR submissions must now be submitted electronically through FDA’s MedWatch Plus system unless FDA has granted an exception.

How should MDR investigations be conducted?

Every potential MDR event should trigger a documented investigation in the quality management system. The investigation serves two purposes: it provides the information needed to complete the MDR submission accurately, and it feeds the CAPA system to determine whether a systemic corrective action is needed.

A well-structured MDR investigation starts with gathering all available information about the event. This includes the complaint record, device identification, lot or serial number, patient information as available, clinical outcome, and any physical evidence from the device if it was returned. The investigation should document the sequence of events, the device’s performance history, and any relevant manufacturing or distribution records.

The investigation must evaluate whether the event meets the reportability criteria. This evaluation must be documented, with a clear rationale for the reportability decision. FDA investigators will review this documentation during inspections and will cite companies whose reportability decisions are not supported by documented analysis. The adverse event investigation record is a core MDR compliance document.

If the event is determined to be reportable, the MDR submission must be completed within the applicable deadline. If the event is determined not to be reportable, the basis for that determination must be documented and retained. FDA reviews non-reportability decisions during inspections and can cite companies that have a pattern of under-reporting.

What are the most common MDR compliance failures FDA cites?

FDA’s MDR-related inspection observations follow consistent patterns. Failure to report within the required timeframe is the most straightforward violation. Companies that receive complaint information, begin an investigation, and then allow the 30-day clock to expire without submitting a preliminary report are cited under 803.50.

Failure to report at all, because the company incorrectly determined the event was not reportable, is harder to detect during inspections but appears when FDA auditors compare complaint records to MDR submission records and find gaps. Companies with high complaint volumes but low MDR submission volumes draw scrutiny.

Incomplete MDR reports are cited when submitted reports lack required fields or contain insufficient information. Part 803 specifies the information that must be included in each report, and submissions that are missing device identification, patient outcome, or event description details can be rejected by FDA and must be resubmitted.

Inadequate MDR procedures are a systemic citation. Part 803.17 requires manufacturers to develop, maintain, and implement written MDR procedures. If an investigator finds that a company’s procedures do not address all the required elements of the regulation, or that employees responsible for MDR decisions are not following the procedures, this becomes an observation under 803.17.

How does a QMS support 21 CFR Part 803 compliance?

MDR compliance depends on the quality management system being able to capture complaint information, trigger investigations, track reporting deadlines, and maintain complete records in a single connected workflow. When complaint handling and adverse event investigation live in disconnected spreadsheets or paper files, deadlines are missed, reportability decisions are inconsistently documented, and the investigation records needed to complete an MDR submission are scattered across multiple systems.

Cloudtheapp provides an integrated cloud QMS with 60+ applications, including complaint management, adverse event investigation, CAPA, and audit trail capabilities built for the full 21 CFR Part 803 workflow. When a complaint is received, the system assigns it to the appropriate investigation workflow and starts tracking the regulatory deadline automatically. The investigation record captures all required elements in a structured format that maps directly to the MDR submission requirements.

The 21 CFR Part 11-compliant audit trail in Cloudtheapp ensures that every investigation entry, reportability decision, and submission record carries a timestamped, immutable record of who created it and when. During FDA inspections, investigators can be shown complete MDR investigation records in seconds, including the documented rationale for reportability decisions and the submission confirmation for each reported event.

Quality teams at medical device manufacturers use Cloudtheapp to manage their full post-market surveillance program, from complaint intake through MDR submission, CAPA closure, and trend analysis. The real-time dashboard view of open complaints, pending MDR deadlines, and complaint trend data gives quality directors the visibility they need to prevent MDR violations before they occur.

To see how Cloudtheapp supports 21 CFR Part 803 compliance in a medical device quality environment, schedule a demo.

How do MDR requirements interact with EU MDR vigilance reporting?

Medical device manufacturers who sell in both the U.S. and EU markets must manage two post-market reporting frameworks simultaneously. The EU Medical Device Regulation (EU MDR 2017/745) requires manufacturers to report serious incidents and field safety corrective actions to national competent authorities in EU member states. The timelines and definitions under EU MDR differ from those in 21 CFR Part 803.

Under EU MDR, serious incidents must be reported immediately, and no later than 15 days after awareness, when the incident poses an imminent risk to public health, 10 days for death or serious deterioration of health, and 30 days for all other serious incidents. These timelines are generally shorter than the standard 30-day MDR deadline under Part 803, and the “serious incident” definition under EU MDR has some differences from the “serious injury” definition in Part 803.

Companies with dual U.S. and EU obligations benefit significantly from a QMS that can manage both reporting frameworks in a single workflow. When the investigation record, the reportability analysis, and the submission tracking are all in one system, the quality team can complete both an FDA MDR and an EU serious incident report from the same underlying investigation without duplicating effort. The risk register and post-market surveillance program should document how the company manages dual-reporting obligations and how discrepancies between the two frameworks are resolved.

This post created by and appeared first on Cloudtheapp

This guide covers what a compliant PMS system looks like, what documents you need to produce for each device class, what data sources MDR expects you to use, and how to build a program that functions as a real quality system — not just paperwork.

What EU MDR requires for post-market surveillance

EU MDR Articles 83 through 86 form the legal framework for post-market surveillance. Each article covers a distinct element:

• Article 83 defines the manufacturer’s obligation to plan, establish, document, implement, maintain, and update a post-market surveillance system for each device
• Article 84 specifies what a Post-Market Surveillance Plan (PMSP) must contain
• Article 85 requires a Post-Market Surveillance Report (PMSR) for Class I devices
• Article 86 requires a Periodic Safety Update Report (PSUR) for Class IIa, IIb, and III devices

The European Commission’s Medical Device Coordination Group published MDCG 2025-10 guidance providing updated interpretation of these PMS requirements, reflecting findings from notified body audits across the EU. The guidance confirms that PMS must be a living, data-driven process — not a static document produced at certification time.

PMS plan vs PMS report vs PSUR: what each document is

Many quality teams conflate these documents. They serve different purposes and have different update frequencies.

Post-Market Surveillance Plan (PMSP)

The PMSP, required under Article 84, describes how you will collect and analyze post-market data for a specific device. It must cover:

• The proactive and reactive data collection methods you will use
• Performance indicators and thresholds that would trigger action
• Reference to applicable standards and guidance documents
• Specific timelines for data collection and review activities
• How findings will feed back into your risk register, clinical evaluation, and technical documentation

The PMSP is part of your technical documentation and must be device-specific. A single generic PMSP for all products does not satisfy MDR.

Post-Market Surveillance Report (PMSR) — Class I devices

For Class I devices, Article 85 requires a PMSR that summarizes the results of your PMS activities, states whether corrective or preventive measures are needed, and confirms the benefit-risk determination remains favorable. There is no mandatory update frequency stated in Article 85 — the PMSR is updated when significant changes occur or when new information from PMS activities warrants it. Notified bodies have generally interpreted “when needed” to mean at least every two to three years.

Periodic Safety Update Report (PSUR) — Class IIa, IIb, and III

The PSUR under Article 86 has defined update requirements. Class IIa devices: PSUR updated at minimum every two years. Class IIb and III devices: PSUR updated annually. For Class III and implantable Class IIb devices, the PSUR is submitted to the notified body and assessed as part of the conformity assessment process.

The PSUR must include: a summary of PMS data, conclusions of benefit-risk analysis, a summary of any FSCA/field safety corrective actions taken, results of post-market clinical follow-up (PMCF) if applicable, and proposed corrective and preventive actions.

Data sources your PMS system must use

Article 83 MDR specifies that the PMS system must gather, record, and analyze relevant data from the post-production phase. Article 84(a) provides a list of data sources. Your PMSP should address each of these explicitly:

Complaints and feedback

Your complaint handling process feeds directly into PMS. Every complaint, whether from users, patients, healthcare professionals, or distributors, is post-market data. The PMS system should analyze complaint trends — not just individual incidents — to identify signals that may not be visible at the single-event level.

Vigilance and serious incident reporting

Serious incidents and field safety corrective actions (FSCAs) reported under MDR Article 87 are both inputs to your PMS system and outputs from it. If your PMS data analysis identifies a pattern that meets the serious incident threshold, that triggers the vigilance reporting obligation. The two systems are connected.

Literature surveillance

Article 84(d) requires manufacturers to monitor scientific and technical publications relevant to their device, including equivalent devices. This means a structured, documented literature search — not an informal awareness of publications. The MDCG 2020-6 guidance on clinical evaluation describes the search methodology in detail, and the same methodology applies to ongoing PMS literature review.

Registries and real-world data

For implantable devices and Class III devices, MDR expects manufacturers to draw on device registries where they exist. In practice, this means monitoring national registries in EU member states where your device is marketed, and documenting what that monitoring showed.

Social media and user feedback

MDCG 2022-21 confirms that social media monitoring can be a PMS data source — specifically for identifying safety concerns that do not reach you through formal complaint channels. This is not a major burden for most manufacturers, but it should be addressed in your PMSP.

Distributor and importer reports

If you have authorized representatives, importers, or distributors in the EU, they have obligations under Articles 13 and 14 MDR to pass information relevant to PMS back to you. Your quality agreement with these parties should specify what they are required to report and how frequently.

Post-Market Clinical Follow-Up (PMCF)

PMCF is a specific subset of PMS. It covers the ongoing collection of clinical data on a device already on the market, to confirm continued safety and performance, identify emerging risks, and monitor long-term outcomes.

PMCF is required for all Class III devices and implantable devices by default. For other classes, PMCF is required unless the manufacturer can justify why it is not necessary — and that justification must be documented in the PMCF evaluation report.

PMCF activities include device registries, post-market clinical studies, surveys of users and patients, and systematic literature review. The plan for PMCF goes into Annex XIV Part B of your technical documentation. Results feed into the PSUR and the clinical evaluation report.

How PMS connects to your broader QMS

PMS does not operate as a standalone activity. The outputs of your PMS system are inputs to multiple parts of your quality management system:

• Risk management — PMS data may reveal new hazards or change probability/severity estimates for known risks. Your risk register should be updated when PMS findings warrant it.
• Clinical evaluation — the PSUR feeds back into the clinical evaluation report. Changes in the benefit-risk assessment must be reflected in both documents.
• CAPA — when PMS identifies a trend or signal requiring action, that action is processed through your CAPA system.
• Design control — significant PMS findings may indicate that design outputs need to be revisited. This can trigger a design change review under your change management process.
• Labeling and IFU — if PMS reveals that users are misusing the device in ways that could cause harm, labeling changes may be required.

This interconnection is exactly why MDR requires the PMS system to be fully integrated with the quality management system — not managed by regulatory affairs as a separate workstream with no links to quality events or risk files.

Common gaps notified bodies find during technical documentation review

Generic PMS plans not tailored to the device

A PMS plan that applies identical data sources, indicators, and review timelines to a Class I bandage and a Class IIb active implant will not satisfy MDR. Notified bodies flag this repeatedly. The PMSP must reflect the specific risk profile, intended use, user population, and regulatory history of the device it covers.

No defined action thresholds

Article 84 requires the PMSP to specify performance indicators and threshold values. Many manufacturers describe data collection activities but never state what result would trigger a response. If you collect complaint data but never defined the rate at which complaints become a signal, your PMS system cannot generate actionable output.

Literature searches that are too narrow

MDCG guidance confirms that literature surveillance must cover equivalent devices, not just your own device. A search limited to your own product name will miss clinical evidence on comparable devices that may be relevant to your benefit-risk assessment.

PMSR and PSUR not updated after significant events

If a serious incident occurred, an FSCA was issued, or a complaint trend was identified and resolved, the PMSR/PSUR should reflect it. Documents that look unchanged from the original submission despite real-world events in the interim draw immediate scrutiny from notified bodies and national competent authorities.

No documented connection between PMS and risk management

Notified bodies look for evidence that PMS outputs actually influenced risk management decisions. If your PMS reports are produced and filed but never change anything in your risk file or CAPA system, auditors will question whether the system is active or purely procedural.

Building the PMS system in your QMS

The practical challenge for most manufacturers is that PMS data flows in from multiple sources — the complaint system, vigilance reports, literature searches, registry monitoring, distributor reports — and needs to be consolidated, trended, analyzed, and documented in a format that produces the PMSR or PSUR on a defined schedule.

Paper-based PMS systems fail at this. Data sits in separate folders for each source, trending requires manual compilation, and producing the PSUR involves weeks of document assembly. By the time the document is ready, the analysis is already outdated.

Cloudtheapp’s quality management platform connects complaint handling, CAPA, adverse event tracking, and risk management in a single system. PMS data collected through complaints, deviations, and adverse event records feeds automatically into dashboards that support PMSR and PSUR preparation. When a CAPA is opened in response to a PMS finding, it is linked to the originating PMS record — giving you the audit trail MDR requires showing that findings drove action.

Want to see how Cloudtheapp handles post-market surveillance documentation for Class IIa, IIb, and III devices? Book a demo to walk through the system with a specialist.

Notified body and competent authority access to PMS data

Under MDR Article 83(4), national competent authorities have the right to request access to post-market surveillance data. For Class IIb and III devices, the PSUR is submitted to your notified body and subject to formal assessment. This means your PMS records need to be retrievable, coherent, and complete — not reconstructed when a request arrives.

The EUDAMED database, as it reaches full functionality, will include modules for vigilance and post-market surveillance data. Manufacturers are expected to upload incident reports and summaries of safety and clinical performance (SSCPs) for implantable and Class III devices directly to EUDAMED. The timeline for full EUDAMED go-live has shifted several times; confirm current requirements with your notified body.

Summary

A compliant EU MDR post-market surveillance program has five elements that all need to work together: a device-specific PMSP with defined data sources and action thresholds, active data collection from complaints, vigilance, literature, registries, and distributor networks, a systematic analysis process that produces trend data and signals, PMSR or PSUR documentation produced on the correct schedule, and documented connections between PMS outputs and risk management, CAPA, and design changes.

The companies that struggle with MDR PMS compliance are generally those that treat it as a documentation obligation rather than a quality function. The regulation is designed for manufacturers that actually use post-market data to improve their devices. Build the system around that intent, and the documentation follows naturally.

Cloudtheapp’s 60+ quality and compliance applications cover complaint management, CAPA, adverse events, and risk management — all of the functions that feed your PMS system. Schedule a demo to see how it all connects.

This post created by and appeared first on Cloudtheapp

Complaint handling sits at the intersection of patient safety, post-market surveillance, and regulatory accountability. For medical device manufacturers and pharmaceutical companies, a complaint is not simply a customer service matter. It is a formal quality event with specific documentation, investigation, and reporting obligations that FDA inspectors review on nearly every site visit.

Getting this wrong carries real consequences. In FY2025, complaint handling deficiencies ranked among the top three FDA 483 observations for medical device manufacturers, trailing only CAPA gaps in frequency. FDA Form 483 observations tied to complaints have appeared in recent warning letters to companies including Noah Medical Corporation (April 2025) and Royal Philips (September 2025), where outsourced complaint handling functions lacked adequate oversight and MDR reporting timelines were missed.

This article covers what complaint handling requires under the current regulatory framework, how complaints connect to MDR obligations and CAPA, and where most organizations run into problems.

How the FDA Defines a Complaint

Under 21 CFR Part 820 (the Quality Management System Regulation, or QMSR), a complaint is any written, electronic, or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, safety, effectiveness, or performance of a device after it is released for distribution.

That definition is intentionally broad. A call from a hospital biomedical technician saying the device "didn't perform as expected" during a procedure qualifies as a complaint. An email from a distributor noting that packaging arrived damaged qualifies. A sales rep relaying that a customer mentioned difficulty calibrating the device qualifies — even if the customer never contacted the company directly.

The breadth of this definition is where many companies undercount their complaint volume. Organizations that only log formal written complaints from end users routinely miss verbal and field-reported events, which then surface as uncaptured complaints during FDA inspections.

Regulatory Framework: What the Rules Actually Require

Medical Devices — QMSR (21 CFR 820.35)

The FDA's QMSR, which took effect on February 2, 2026, replaced the legacy QSR under 21 CFR Part 820 and harmonized U.S. requirements with ISO 13485:2016. Complaint handling now lives at 21 CFR 820.35, which incorporates ISO 13485 clause 8.2.2 by reference.

The QMSR requires manufacturers to maintain procedures for receiving, reviewing, and evaluating complaints. Specifically, the regulation requires:

• A designated unit with written complaint handling procedures
• An evaluation of every complaint to determine whether it warrants investigation
• Documentation of the reason when a complaint is not investigated
• For complaints that are investigated: documentation of the device name, lot or batch number, date received, name and address of the complainant (if obtainable), nature of the complaint, reply to the complainant (if any), the dates and results of the investigation, and any corrective action taken
• Evaluation of whether the complaint represents an event that must be reported under 21 CFR Part 803 (Medical Device Reporting)

Complaints involving possible malfunction, injury, or death that fall under MDR criteria must be reviewed against reporting thresholds. Under 21 CFR Part 803, manufacturers must submit a 30-day MDR for deaths and serious injuries, and a 5-day report for malfunctions involving a device likely to cause or contribute to serious injury or death if it recurs.

Pharmaceuticals — 21 CFR Part 211 and ICH Q10

For pharmaceutical manufacturers, complaint handling requirements appear in 21 CFR Part 211.198 (for drug manufacturers) and are reinforced by ICH Q10, the pharmaceutical quality system guidance that FDA formally adopted.

21 CFR Part 211.198 requires:

• Written procedures for handling written and oral complaints about drug products
• Designated responsibility for review and evaluation of complaints
• Investigation of any complaint involving the possible failure of a drug product to meet its specifications, or any complaint involving contamination or an unexpected adverse reaction
• Review of complaint records at regular intervals to identify trends that may require corrective action
• Retention of complaint records for at least one year after the expiration date of the batch or lot

ICH Q10 places complaint management within the pharmaceutical quality system's continual improvement framework. Section 3.2 of ICH Q10 lists complaint, deviation, deviation CAPA, and change management processes as core elements of the quality system. The guidance makes clear that trending complaints for signals is expected behavior, not an optional practice.

ISO 13485 Clause 8.2.2

For medical device manufacturers operating under ISO 13485:2016, clause 8.2.2 covers complaint handling as part of feedback from post-production. The standard requires organizations to establish a procedure for handling complaints that includes:

• Determination of whether the event requires reporting to regulatory authorities
• Timely handling of complaints
• Root cause investigation and corrective action where appropriate
• Communication with regulators when required

ISO 13485 also connects complaint handling to post-market surveillance (clause 8.2.1), which requires manufacturers to collect and analyze data from post-production experience, including customer complaints, field service reports, and publicly available data.

The Five Core Steps of an Effective Complaint Handling Process

Regardless of whether a company operates under QMSR, 21 CFR Part 211, or ISO 13485, an effective complaint handling process follows the same logic:

1. Capture and intake. Every complaint must be logged, regardless of source. This includes verbal reports from sales reps, field service technicians, customer support calls, distributor feedback, and social media reports where they can be tied back to a product performance issue. The intake record should capture the date received, product identity, lot or batch, and nature of the event.

2. MDR/regulatory reportability determination. For device manufacturers, every complaint must be evaluated for MDR reportability before investigation begins. The review should be documented. If the complaint does not meet MDR criteria, the reason must be recorded. MDR evaluations have specific clock starts — for death or serious injury events, the 30-day window begins from the date the manufacturer becomes aware, not the date the complaint is formally logged.

3. Investigation decision. The QMS must document whether each complaint warrants full investigation. When the decision is "no investigation required," the reason must be explicitly recorded. FDA inspectors look specifically at not-investigated complaints to check whether companies are using that designation appropriately or using it to suppress inconvenient events.

4. Investigation and documentation. Investigated complaints require documentation of findings, the device or lot involved, any adverse event investigation performed, and any corrective action taken. Investigation timelines should be defined in your procedure. An open-ended complaint investigation with no closure date is a common 483 finding.

5. Trending and CAPA escalation. Individual complaints feed into periodic trending reviews. When trend analysis identifies a pattern — same failure mode, same product family, same market geography — the QMS must have a mechanism to escalate that pattern into a formal CAPA process.

When a Complaint Becomes an MDR

Not every complaint triggers an MDR submission. The MDR threshold under 21 CFR Part 803 requires the event to involve a device that may have caused or contributed to a death or serious injury, or a malfunction that would likely cause or contribute to serious injury if it recurred.

In practice, the MDR evaluation is where complaint files most often fail during inspections. Common failure patterns include:

• Events logged as complaints but MDR evaluation never documented
• MDR evaluation performed but the 30-day clock calculated from the wrong date (investigation close date instead of awareness date)
• Complaints closed without MDR review because they were categorized as "use error" rather than device malfunction, without documented rationale
• Outsourced MDR functions where the contract manufacturer performed the submission but the device manufacturer lacked oversight documentation — the Royal Philips situation in September 2025

Companies that manage MDR evaluations inside their complaint handling workflow — rather than as a separate manual process — have fewer 483 observations in this area. When MDR evaluation is a discrete documented step in the complaint record itself, with a checkbox and a date, it is much harder to miss.

Complaint Trending and Its Role in CAPA

Trending is where complaint handling moves from a reactive documentation task to an actual quality management function.

Under both QMSR and ICH Q10, manufacturers are expected to analyze complaint data at defined intervals to detect signals. That means periodic reviews — typically monthly or quarterly — that look at complaint volume by product, complaint type, failure mode category, market geography, and lot.

A single complaint about a catheter detaching during use may not trigger a CAPA. Fifteen complaints about the same catheter lot over six weeks should. The question FDA asks is whether your trending process would have caught that pattern and whether your procedure defines the threshold at which a trend escalates to formal corrective action.

The risk register for a product should also be updated when trending data reveals failure modes not anticipated during the original risk analysis. Complaint data is a post-market input to risk management under both ISO 13485 and QMSR.

Trending records belong in the audit trail. If you review complaint data monthly and make documented trend decisions, those decisions need to be preserved with timestamps and review signatures. An undocumented verbal review of complaint trends satisfies no one during an FDA inspection.

Where FDA 483 Observations Come From

Based on FDA inspection data and published warning letters from 2024 and 2025, the most frequent complaint handling deficiencies observed by inspectors cluster around five failure patterns:

Undercounting complaints. Companies that train only their quality team to recognize complaints — rather than field service, sales, and customer support — routinely miss events. FDA inspectors specifically ask to interview non-quality employees to test whether the intake training is working.

Inadequate investigation documentation. Investigation records that say "complaint reviewed, no action required" without documenting what was reviewed, what data was examined, and what rationale was used for the no-action determination. The Noah Medical Corporation warning letter in April 2025 cited procedures that described investigation steps but lacked documented evidence those steps were performed.

MDR timing failures. Complaints evaluated for MDR reportability with the clock starting from investigation close rather than date of awareness. FDA calculates MDR timeliness from when the manufacturer had information suggesting the device may have caused the event.

Closed complaints with open CAPA. Complaints marked closed in the system while the associated corrective action is still in progress. The complaint record should remain open or linked until the corrective action is verified effective.

No complaint trending program. Companies that evaluate individual complaints but have no documented periodic trend analysis. This is most often found in smaller manufacturers where QA resources are limited and trending is handled informally.

What a Well-Functioning Complaint Handling System Looks Like

Organizations with low complaint-related 483 observations share a few structural characteristics. Their complaint intake process reaches every customer-facing function, not just quality. Their MDR evaluation is a documented step within the complaint record, with a checkbox and a date, not a downstream process that runs parallel and disconnected.

Their investigation timelines are procedurally defined — typically 30 or 45 days for standard complaints, shorter for potential MDR events — and complaint records do not close without documented investigation outcomes. Trending runs on a fixed calendar with documented outputs that connect directly to the CAPA process when thresholds are crossed.

The QMS captures all of this in one system. When complaint handling, MDR evaluation, CAPA, and trending live in separate spreadsheets or disconnected databases, the linkages break down, and that is exactly what FDA inspectors find.

Complaint Handling in Cloudtheapp

Cloudtheapp's Complaints application within the eQMS platform manages the full complaint handling workflow from intake through MDR evaluation, investigation, and CAPA escalation. All records include a complete, tamper-evident audit trail that meets 21 CFR Part 11 electronic records requirements.

The platform's built-in analytics surface complaint trends by product, lot, failure category, and time period, so trending reviews produce documented outputs rather than informal summaries. When a trend crosses a defined threshold, a CAPA can be initiated directly from the trend record, preserving the link between post-market signal and corrective action.

For teams managing both medical device and pharmaceutical complaint obligations, Cloudtheapp supports configurable workflows that match the specific procedural requirements of QMSR, ISO 13485, and ICH Q10 environments.

If your complaint handling process is built around spreadsheets and manual MDR tracking, request a demo at https://www.cloudtheapp.com/demo/ to see how a purpose-built QMS handles the workflow from first report to closed corrective action.

This post created by and appeared first on Cloudtheapp

EU MDR Regulation (EU) 2017/745 transformed post-market surveillance from a passive reporting activity into an active, data-driven lifecycle obligation. Articles 83 through 86 define a mandatory system structure: a documented PMS system, a device-specific PMS plan, periodic PMS reports for Class I devices, and Periodic Safety Update Reports (PSURs) for Class IIa through III devices. The December 2025 MDCG 2025-10 guidance provides the most detailed official interpretation of these obligations to date, clarifying how to build, operate, and integrate a compliant PMS system within your QMS. This guide covers everything manufacturers need to know.

What Is Post-Market Surveillance Under EU MDR?

Post-market surveillance is the ongoing, proactive process of collecting and analyzing real-world performance data from medical devices once they are placed on the EU market. Under EU MDR (Regulation 2017/745/EU), PMS is not a reactive complaint-handling function. It is a systematic, proactive process integrated into the manufacturer's Quality Management System to continuously verify that devices remain safe, perform as intended, and meet general safety and performance requirements throughout their entire market lifetime.

Article 10(10) of the MDR mandates that every manufacturer establish, document, implement, maintain, update, and improve a PMS system appropriate to the risk class and type of device. This obligation applies regardless of device class, from Class I to Class III.

The critical shift from the predecessor Medical Device Directive (MDD) is one of intent. Under the MDD, PMS was often treated as a periodic reporting exercise. Under MDR, it is a living system that feeds back into clinical evaluation, risk management, design control, and technical documentation updates continuously.

Why EU MDR Raised the PMS Bar

The increased PMS rigor under MDR was a direct response to real-world device safety failures. The PIP breast implant scandal, metal-on-metal hip replacement complications, and surgical mesh problems all revealed a systemic failure: devices with deteriorating real-world performance stayed on the market too long because post-market data was not systematically collected, analyzed, or escalated to corrective action.

MDR's response was structural. Under the regulation:

• PMS plans are device-specific, not general system documents
• Notified Bodies have expanded oversight access to PMS reports and PSURs during surveillance audits
• PSUR update frequencies are defined by risk class with firm deadlines
• Post-Market Clinical Follow-Up (PMCF) is required for most devices unless explicitly justified otherwise
• Proactive data gathering from multiple defined sources is mandatory

Manufacturers who build rigorous PMS systems gain a measurable advantage in Notified Body interactions and demonstrate the kind of proactive safety governance that regulators now explicitly expect.

The 4 Core PMS Articles: 83 Through 86

Article 83: The PMS System

Article 83 defines the foundational requirement: every manufacturer must establish, document, implement, maintain, and continuously improve a PMS system. This system must actively gather post-market data from defined sources, analyze it for safety signals and performance trends, and feed findings back into risk management, clinical evaluation, and QMS processes.

The PMS system is not a document. It is a connected operational process that links complaint handling, vigilance reporting, PMCF, field safety corrective actions, and CAPA into a coherent feedback loop.

Article 84: The PMS Plan

Article 84 requires a documented PMS plan for each device, specifying:

• What data will be gathered and from which specific sources
• The methods and processes for data collection, storage, and analysis
• Defined threshold criteria that trigger CAPA or field safety corrective action
• Explicit reference to the clinical evaluation and risk management processes that PMS data feeds into

The PMS plan is a living document. When PMS data generates new risk insights, the plan updates accordingly. Notified Bodies review PMS plans during initial certification audits and at every surveillance audit, making plan quality a direct factor in certification outcomes.

Article 85: The PMS Report (PMSR)

Article 85 applies to Class I devices. Manufacturers must document PMS findings in a Post-Market Surveillance Report that summarizes results, analyzes conformity with general safety and performance requirements, presents a benefit-risk determination, and records any CAPA taken. The PMSR must be updated when PMS activities generate new relevant findings and must be available to competent authorities upon request.

Article 86: The Periodic Safety Update Report (PSUR)

Article 86 applies to Class IIa, IIb, and III devices and represents the most rigorous PMS reporting obligation under MDR.

PSURs must be updated at the following minimum frequencies:

• Class IIa: At least every 2 years
• Class IIb and III: At least annually

Each PSUR must include: the conclusions of the benefit-risk determination, main findings from PMCF, volume of sales and estimated population using the device, and a complete summary of PMS data analyzed with rationale for any corrective or preventive actions taken.

Class IIb and III PSURs must be submitted to the Notified Body. Class IIa PSURs must be available to the Notified Body on request. Both are reviewed during Notified Body surveillance activities.

What Data Sources Feed a PMS System?

A compliant PMS system draws from a defined, broad set of data sources. MDCG 2025-10 provides detailed guidance on the minimum expected inputs:

Reactive data sources:

• Customer complaints and device user feedback
• Vigilance reports from competent authorities
• Post-market adverse events reported by users, patients, or healthcare institutions
• Field safety corrective action (FSCA) data from similar devices on the market

Proactive data sources:

• Systematic literature searches covering the device type, equivalent devices, and relevant clinical areas
• PMCF studies, device registries, and structured patient or user surveys
• Market surveillance data from competent authorities and Notified Bodies
• Analysis of returned, repaired, or scrapped devices
• Feedback networks from distributors and healthcare providers

Every data source must be described in the PMS plan, including search methodology, frequency, responsible person, and the process by which findings are assessed against defined threshold criteria.

Post-Market Clinical Follow-Up (PMCF)

PMCF is a subset of PMS activities focused specifically on post-market clinical data collection. Under EU MDR Annex XIV Part B, PMCF is required unless the manufacturer explicitly justifies why it is not applicable to a specific device.

PMCF activities include:

• Prospective clinical investigations using the device in its intended patient population
• Clinically relevant data from literature reviews, device registries, or structured user surveys
• Structured feedback programs with healthcare institutions using the device

PMCF findings must feed directly into the clinical evaluation and Clinical Evaluation Report (CER), the technical documentation, and the risk management file. MDCG 2025-10 reinforces this closed-loop requirement: PMCF is not a standalone project but a continuous input into the full technical documentation ecosystem that sustains the device's CE marking.

Vigilance: Serious Incidents and FSCAs

Vigilance reporting under EU MDR (Articles 87-90) operates in parallel with PMS but responds to specific triggering events. Manufacturers must report to the competent authority of the relevant Member State:

• Serious incidents (events that led or could lead to patient death, serious deterioration in health, or serious public health threat): within 15 days of becoming aware
• Field Safety Corrective Actions (FSCAs): reported through a Field Safety Notice (FSN) before implementation wherever possible

An adverse event investigation that identifies a device-related root cause must trigger both a vigilance report and a CAPA. MDCG 2025-10 makes clear that the PMS system must define explicit processes for identifying potential serious incidents within complaint and feedback data streams, with documented escalation criteria and named responsible persons.

Vigilance data is also a required input into the PSUR. Unreported or delayed incidents create gaps not only in vigilance compliance but in the accuracy of the periodic safety update analysis itself.

MDCG 2025-10: What the December 2025 Guidance Adds

The Medical Device Coordination Group published MDCG 2025-10 in December 2025, providing the most comprehensive official interpretation of EU MDR PMS requirements to date. Key guidance elements that manufacturers must address:

• QMS integration: MDCG 2025-10 reinforces that PMS must be embedded within and connected to the full QMS, with defined interfaces to risk register processes, clinical evaluation, CAPA, and technical documentation. Standalone PMS binders do not meet MDR intent.
• Active, not reactive, surveillance: Guidance emphasizes that waiting for complaints to arrive does not satisfy the MDR's proactivity requirement. Manufacturers must design systems that actively seek real-world performance data.
• Quantified thresholds and triggers: MDCG 2025-10 expects manufacturers to define quantitative or qualitative threshold criteria that trigger CAPA or FSCA initiation when breached. Vague assessment language is not sufficient.
• IVD applicability: The guidance covers both MDR (2017/745) and IVDR (2017/746), applying the same PMS framework to in vitro diagnostic devices.
• Proportionality: PMS plans, reports, and PMCF scope should be proportionate to the device's risk class, intended population, and complexity of clinical use.

Manufacturers who have not yet reviewed and updated their PMS plans in light of MDCG 2025-10 face potential major findings at their next Notified Body surveillance audit.

Integrating PMS Into Your QMS

A PMS system that operates in isolation produces compliance artifacts but not compliance outcomes. True MDR conformity requires PMS to function as a connected element within the full QMS.

PMS findings must have documented pathways to:

• Risk management: New safety signals and threshold breaches update the risk file and the benefit-risk determination in the CER
• Clinical evaluation: PMCF data and real-world evidence feed into the CER on the cadence defined in the PMS plan
• CAPA: Identified trends or threshold breaches initiate formal root cause investigations and deviation CAPAs with defined timelines
• Technical documentation: Updated risk files and clinical evaluations require corresponding updates to the technical documentation supporting CE marking
• Management review: PMS trend data and PSUR conclusions should appear as standing agenda items

Managing these connections across disconnected spreadsheets, email threads, and shared drives creates version control failures, traceability gaps, and missed escalation windows. An integrated QMS platform that connects PMS data to CAPA, clinical evaluation, risk management, and document control removes these gaps structurally.

How Cloudtheapp Supports EU MDR PMS Compliance

Building a compliant EU MDR PMS system on manual tools is both time-consuming and structurally fragile. Cloudtheapp's AI-powered QMS platform provides medical device manufacturers with an integrated environment for every PMS obligation:

• Complaint and adverse event capture linked directly to PMS analysis workflows and threshold monitoring
• PMCF data collection modules connected to clinical evaluation and CER management records
• CAPA initiation triggered automatically from PMS threshold breaches with full traceability
• PSUR and PMSR report generation with audit-ready traceability back to underlying PMS data
• Risk management integration: PMS findings update risk assessments in real time
• Management review dashboards surfacing PMS trends alongside CAPA performance and audit results

Because Cloudtheapp is validated per FDA QMSR, ISO 13485:2016, and ISO 9001, every PMS record generated in the platform meets both EU MDR and global QMS standards. Manufacturers operating in EU and US markets maintain a single compliant record set rather than parallel systems.

Ready to build a PMS system that holds up under MDCG 2025-10 and Notified Body scrutiny? Request a demo to see how Cloudtheapp connects every EU MDR PMS obligation end to end.

Conclusion

EU MDR post-market surveillance is a mandatory, proactive, and deeply interconnected compliance obligation. Articles 83 through 86 define the structural requirements. MDCG 2025-10 clarifies what "good" looks like in practice. And an integrated QMS is the only architecture that sustains these requirements without creating unsustainable manual overhead.

Manufacturers who treat PMS as a living system rather than a periodic reporting task produce better safety outcomes, pass Notified Body scrutiny more consistently, and build the real-world evidence base that the next generation of clinical evaluation demands.

This post created by and appeared first on Cloudtheapp