Post-market Support

Release begins the real-world evidence phase

Development evidence is necessarily bounded. After release, devices encounter wider populations, users, environments, combinations, durations and failure mechanisms. Post-market support provides the organisation with the means to detect what was not known before, confirm assumptions and act when the benefit-risk profile changes.

Support is broader than complaint handling. It combines user assistance, service, surveillance, vigilance, clinical follow-up, cybersecurity monitoring, production feedback and corrective action.

Plan a proactive post-market system

The plan should reflect device class, novelty, population, expected lifetime, distribution, residual risks and the availability of comparable data.

Use multiple sources—and understand their limitations

• Complaints, adverse events, returns, repairs and service reports.
• Technical support contacts, training questions and observed use difficulties.
• Production, supplier, nonconformance and distribution information.
• Clinical follow-up, registries, studies and published literature.
• Public incident, recall and safety databases.
• Cybersecurity vulnerabilities, threat intelligence and supportability information.
• Sales, installed-base, exposure and utilisation data needed to interpret rates.
• Feedback from users, patients, distributors, importers and authorised representatives.

A count without exposure can mislead. Ten events among one hundred devices mean something different from ten among one million, and reporting behaviour may change independently of product performance.

Capture complaints and service evidence consistently

A complaint alleges a deficiency in identity, quality, durability, reliability, usability, safety, effectiveness or performance after release. A service record may reveal the same facts without being labelled a complaint. Triage should therefore examine content, not the channel or terminology used by the reporter.

Do not postpone regulatory assessment until the technical investigation is complete. Reporting timelines can begin when the organisation becomes aware of the event.

Detect signals before they become obvious failures

Individual cases and aggregate trends both matter. Define meaningful coding, denominators, review intervals and escalation criteria. Analyse severity, frequency, detectability, time-to-event, configuration, use environment, geography and affected populations.

Statistical alerts are aids, not automatic conclusions. A rare serious event may require immediate action without a trend, while a numerical increase may reflect reporting campaigns or installed-base growth. Use MTL-128 — Statistical Methods and Measurement Assurance to make rates and trend evidence interpretable.

Coordinate vigilance, correction and field action

When information indicates a potentially reportable event or unacceptable risk, involve regulatory, quality, clinical, technical and management functions promptly. Determine affected devices and markets, stop-ship or quarantine needs, customer communication, regulatory reports, corrections or removals, and whether a field safety corrective action is required.

Decisions should be documented separately for each applicable jurisdiction. A technical conclusion that the device met specification does not automatically remove a reporting obligation; foreseeable use, harm and regulatory definitions still need evaluation.

Feed learning back into controlled lifecycle processes

• Update hazard analyses, risk estimates, benefit-risk conclusions and residual-risk information.
• Reassess clinical or performance evaluation and post-market follow-up needs.
• Initiate corrective and preventive action where systemic causes exist.
• Change design, software, labelling, training, manufacturing or supplier controls.
• Update cybersecurity monitoring, vulnerability handling and patch plans.
• Revise service instructions, spare-parts strategy and maintenance intervals.
• Inform management review, quality objectives and future product development.

Any resulting product change should follow MTL-127 — Configuration and Change Management.

Make ownership and escalation unambiguous

Define who owns surveillance planning, complaint decisions, vigilance reporting, trend review, clinical updates, cybersecurity response, field action and final closure. Ensure coverage across time zones, leave and supplier boundaries.

A periodic cross-functional review should consider new cases, open investigations, signals, regulatory reports, corrective actions, risk changes and whether post-market plans remain suitable. Senior management needs visibility of unresolved safety issues, overdue actions and changes in the benefit-risk profile.

Common misconceptions