A medical software company launches a diagnostic algorithm that performs exceptionally well in clinical validation studies. Six months after market launch, the company's customer support team notices an uptick in clinician complaints about "unexpected results." Investigation reveals that the algorithm's performance has degraded when processing images from a newly popular imaging device whose output characteristics differ subtly from training data. No individual case resulted in documented patient harm. The company faces a series of uncomfortable questions: Should these cases have been reported as vigilance events? Does degraded algorithm performance constitute a "serious incident"? When did the manufacturer's obligation to act arise: when individual complaints arrived, when the pattern became apparent, or when the root cause was identified? The answers carry significant regulatory consequences.
1. Beyond Reactive Complaint Handling
Post-market surveillance under the MDR encompasses all activities manufacturers undertake to proactively collect and evaluate experience with their devices after market placement. Art. 83 and Annex III MDR establish PMS as a continuous process throughout the device lifecycle, not a reactive response to identified problems.1Regulation (EU) 2017/745, Art. 83 and Annex III. Manufacturers must establish, document, implement, maintain, and update a post-market surveillance system proportionate to the risk class and type of device. For SaMD, this framework creates particular challenges because software failures may not manifest through the physical malfunction patterns that traditional device surveillance systems are designed to detect.
The PMS plan required under Annex III MDR must address how the manufacturer will collect post-market data from multiple sources: feedback and complaint systems, publicly available information on similar devices, clinical investigation registries, and proactive data collection activities. For software, relevant data sources extend to app store reviews, social media discussions, healthcare IT system logs, and algorithm performance metrics that traditional medical device manufacturers rarely monitor. The PMS plan must specify how collected data will trigger investigation and, where necessary, corrective action.
Swiss requirements under the Medizinprodukteverordnung (MepV; SR 812.213) substantially mirror MDR PMS obligations through incorporation of Chapter VII MDR principles. Swissmedic expects manufacturers to maintain surveillance systems adequate to detect safety and performance issues that may emerge post-market. For software placed on both Swiss and EU markets, a unified PMS system typically satisfies both regulatory frameworks, but manufacturers must ensure reporting flows to both competent authorities when incidents occur and must address jurisdiction-specific timing requirements that may differ.
The Swiss-EU mutual recognition agreement ceased to cover devices placed on the market under the MDR when the Regulation took effect on 26 May 2021, its medical devices chapter never having been updated to the new regime, adding a structural dimension to PMS planning. Swiss-based SaMD manufacturers are now third-country manufacturers under the MDR, requiring EU Authorized Representatives who bear their own PMS oversight responsibilities.2Art. 11 and Art. 13(7)–(8) MDR, establishing AR and importer PMS responsibilities. Incident reporting flows must account for this structure: the AR receives and transmits vigilance reports to EU competent authorities while the manufacturer simultaneously fulfills Swissmedic reporting obligations. Manufacturers operating under this dual structure must ensure their PMS systems generate outputs compatible with both regulatory channels without creating gaps or duplications that could expose compliance failures.
Post-market surveillance for software requires detecting failures that may not resemble traditional device malfunctions. Degraded algorithm accuracy, performance variation across populations, and emergent behaviors from software updates all demand proactive monitoring.
2. When Software Failure Becomes Reportable
Vigilance reporting obligations require manufacturers to report serious incidents and field safety corrective actions to competent authorities within defined timelines. Under Art. 87 MDR, manufacturers must report any serious incident involving devices they place on the market, defined under Art. 2(65) MDR as an incident that directly or indirectly led, might have led, or might lead to death, serious deterioration of health, or serious public health threat.3Art. 2(65) and Art. 87 MDR, defining "serious incident" and establishing reporting obligations. Reporting timelines depend on incident severity: immediately and not later than 2 days for serious public health threats, within 10 days for death or unanticipated serious deterioration, within 15 days for other serious incidents.
For SaMD, the threshold question (when does degraded software performance constitute a "serious incident") lacks clear guidance. An algorithm that provides incorrect diagnostic recommendations could lead to serious health deterioration if a clinician acts on those recommendations without independent verification. But if clinicians routinely verify algorithm outputs before acting, does an incorrect recommendation constitute a reportable event? The MDR definition focuses on what "might have" occurred, not merely documented outcomes, suggesting that potential for harm triggers reporting obligations regardless of actual clinical consequences.
The "might lead" language creates particular challenges for software manufacturers. The MDCG has addressed some of these threshold questions through updated vigilance guidance (MDCG 2023-3 on vigilance terms and definitions), which replaced the older MEDDEV 2.12/1 framework.4MDCG 2023-3 Rev.2 (January 2025), Questions and Answers on Vigilance Terms and Concepts as outlined in the Regulation (EU) 2017/745 on Medical Devices, superseding MEDDEV 2.12/1. This document clarifies the treatment of "near misses" and establishes expectations for trend reporting that are directly relevant to SaMD scenarios, particularly cases where an algorithm produces an incorrect output that a clinician overrides before patient harm occurs. The updated guidance confirms that near misses meeting the "might have led to" threshold remain reportable, even when clinical workflows prevent actual harm.
Art. 88 MDR imposes a distinct obligation that may be the most operationally significant reporting requirement for SaMD manufacturers: trend reporting.5Art. 88 MDR (Trend reporting): statistically significant increases in non-serious incidents, or in expected undesirable side-effects affecting the benefit-risk analysis, measured against the foreseeable rate in the technical documentation. Manufacturers must report any statistically significant increase in the frequency or severity of incidents that are not individually "serious" but that, in aggregate, may represent a systematic safety concern. The opening scenario of this article illustrates precisely this obligation: an uptick in clinician complaints about "unexpected results," no individual case resulting in documented patient harm, but a pattern suggesting systematic performance degradation. Under Art. 88, the manufacturer must report this trend to the competent authority and include an assessment of the risk and any corrective or preventive actions taken or planned. For SaMD, trend reporting demands statistical monitoring infrastructure capable of detecting aggregate patterns, not merely individual incident tracking, and the analytical capacity to distinguish genuine trends from noise in complaint data.
Swissmedic vigilance reporting for manufacturers under Art. 66 MepV follows similar principles with jurisdiction-specific procedures. Manufacturers must report serious incidents involving devices placed on the Swiss market through the Swissmedic vigilance portal, with timelines corresponding to MDR requirements. For manufacturers operating in both markets, a single incident may trigger parallel reporting obligations to multiple competent authorities, and slight variations in reporting forms, classifications, and follow-up requirements demand attention to jurisdiction-specific details.
Field safety corrective actions (FSCA) for software raise practical questions that differ fundamentally from hardware recalls. Under Art. 2(68) MDR, an FSCA encompasses any corrective action taken by a manufacturer for technical or medical reasons to prevent or reduce the risk of a serious incident. For SaMD, this typically involves a remote software update rather than a physical product recall, but the conceptual mapping is not seamless. Whether a mandatory software update constitutes an FSCA under the MDR definition, whether users can refuse safety-critical updates, and what regulatory obligations arise when users continue operating outdated software versions are questions the MDR does not directly address. Manufacturers must define in their PMS plans how software-based corrective actions will be deployed, tracked, and verified, including procedures for managing the residual risk created by users who do not install mandatory updates.
3. Monitoring Without Ground Truth
Software that incorporates algorithms, whether rule-based, statistical, or machine learning, requires monitoring approaches that traditional device surveillance does not contemplate. Algorithm performance may degrade over time as real-world data distributions diverge from training data, a phenomenon sometimes called "model drift" or "data drift." Surveillance systems must detect such degradation before it manifests in patient harm, which requires defining performance metrics, establishing monitoring infrastructure, and setting thresholds that trigger investigation.
The technical challenge lies in continuous performance measurement without access to ground truth. Training and validation studies compare algorithm outputs against known correct answers: expert diagnoses, confirmed outcomes, annotated reference standards. Post-market deployment lacks this reference: when the algorithm produces an output for a patient, the "correct" answer may not be immediately known or may never be definitively established. Manufacturers must design proxy metrics that correlate with clinical performance and can be measured in operational deployment.
Distribution monitoring examines whether input data characteristics remain consistent with training data assumptions. If an algorithm was trained on images from specific equipment types and clinical settings, deployment to different equipment or populations may produce unreliable results even if the algorithm itself functions correctly. Monitoring systems can detect distributional shifts (changes in input data characteristics that exceed training data bounds) and flag cases where algorithm outputs warrant additional scrutiny.
Monitoring results must feed back into the manufacturer's risk management process. Under ISO 14971:2019 (harmonized as EN ISO 14971:2019+A11:2021 for MDR purposes), post-market information constitutes an input to the risk management system that may trigger re-evaluation of residual risk acceptability.6ISO 14971:2019, Medical devices – Application of risk management to medical devices, Clause 10 (Production and post-production activities); EN ISO 14971:2019+A11:2021 (harmonized standard under MDR). For SaMD where algorithm drift changes the risk profile, this feedback loop is the formal mechanism linking PMS findings to regulatory consequences: a detected performance shift → risk management file update → reassessment of whether residual risks remain acceptable → potential need for corrective action or new conformity assessment. The connection between monitoring and risk management is not merely procedural; it determines whether a manufacturer can demonstrate ongoing conformity with MDR essential requirements when challenged by a notified body or competent authority. Device classification itself drives the scope of PMS obligations: as examined in Insight 07, SaMD classification under MDR Rule 11 determines PSUR frequency, the level of notified body scrutiny, and whether PMCF is required, making classification the foundational determinant of surveillance burden.
For machine learning systems that update or retrain post-market, monitoring obligations acquire additional complexity. Each update potentially changes device behavior in ways that prior clinical evidence may not support. While the MDCG has issued guidance on significant changes in the context of MDR transitional provisions, EU-level guidance specific to AI/ML change management remains under development; manufacturers often look to FDA's predetermined change control plan (PCCP) framework as a reference point.7MDCG 2020-3, Guidance on Significant Changes Regarding the Transitional Provision Under Art. 120 of MDR (European Commission 2020).8FDA, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions (Final Guidance, December 2024). The EU is developing its own approach through Art. 72 AI Act post-market monitoring requirements for high-risk AI systems, which will apply to medical AI alongside MDR obligations, creating potential divergence from the FDA's PCCP model and requiring manufacturers to maintain parallel change control frameworks for EU and US markets. Manufacturers must establish predetermined change control plans that define acceptable performance variation and procedures for validating updates before deployment.
Post-market cybersecurity monitoring represents an increasingly prominent PMS dimension that the plain language summary of this article flags but the MDR framework does not explicitly segregate from general PMS. MDCG 2019-16 (Guidance on Cybersecurity for Medical Devices) addresses post-market cybersecurity monitoring as a specific PMS activity: manufacturers must monitor for newly discovered vulnerabilities, assess whether known vulnerabilities in third-party components affect their devices, and implement security patches within timeframes proportionate to risk severity.9MDCG 2019-16 Rev 1, Guidance on Cybersecurity for Medical Devices (July 2020), §5 (post-market surveillance and vigilance); IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security, Clause 6 (software maintenance process). The forthcoming alignment with IEC 81001-5-1 makes cybersecurity monitoring a formal component of PMS for SaMD, requiring coordinated vulnerability disclosure processes and security update management that integrates with the broader software lifecycle. The practical implications for PMS architecture are examined in greater detail in Insight 18, which addresses the intersection of MDR cybersecurity requirements and IEC 81001-5-1 obligations.
4. Periodic Reports for Software That Changes
Periodic Safety Update Reports synthesize post-market surveillance data into comprehensive assessments that manufacturers must proactively prepare at defined intervals. Art. 86 MDR requires PSURs for Class IIa, IIb, and III devices, all of which must be prepared regardless of any request, while Class I devices fall instead under the lighter post-market surveillance report of Art. 85 MDR. The distinction lies in the delivery mechanism: once the relevant EUDAMED modules become fully operational, PSURs for Class III and implantable devices are to be transmitted to the notified body through EUDAMED, while PSURs for other devices (Class IIa and non-implantable Class IIb) are made available to the notified body and, upon request, to competent authorities.10Art. 86(1) MDR. Class IIb and Class III devices require annual PSUR; Class IIa devices require PSUR at least every two years. As of the article's publication, EUDAMED modules are being deployed in phases and the vigilance module is not yet fully operational; in practice, PSURs are transmitted directly to notified bodies pending full EUDAMED deployment, a transitional arrangement whose evolution will affect PSUR submission procedures.
The MDCG has issued template and methodology guidance (MDCG 2022-21 provides a PSUR template establishing the expected structure and content) that clarifies what regulators expect beyond the MDR's statutory minimum.11MDCG 2022-21, Guidance on Periodic Safety Update Report (PSUR) According to Regulation (EU) 2017/745; the template requires a structured benefit-risk re-evaluation, not merely a data summary. The template requires a structured benefit-risk re-evaluation, not merely a data summary, including quantitative analysis of incident rates, comparison against the state of the art, and an assessment of whether the benefit-risk determination underlying the conformity assessment remains valid. For SaMD manufacturers, this means the PSUR must address whether algorithm performance metrics remain consistent with clinical evidence supporting market authorization, and whether post-market data reveals populations or use contexts where the benefit-risk balance may have shifted.
For SaMD manufacturers, PSUR preparation requires aggregating data from diverse sources: complaint systems, vigilance reports, algorithm performance metrics, customer feedback channels, literature monitoring, and proactive clinical data collection. The benefit-risk assessment must address software-specific considerations that traditional device PSURs rarely confront. Observed algorithm performance may have diverged from clinical evidence supporting market authorization, particularly where deployment has expanded into use contexts or user populations not anticipated at launch. Competitive and technological developments may also have shifted the device's relative benefit-risk profile in ways that alter the state-of-the-art comparison the PSUR must address.
Post-Market Clinical Follow-up under Annex XIV Part B MDR extends beyond passive data collection to proactive clinical evidence generation.12Annex XIV Part B MDR (post-market clinical follow-up); MDCG 2020-7 (PMCF Plan Template) and MDCG 2020-8 (PMCF Evaluation Report Template), European Commission 2020. Manufacturers must plan PMCF activities to continuously confirm that clinical evidence remains valid throughout the device lifecycle. For SaMD, this obligation has particular significance: the clinical evidence generated during development (the regulatory expectations for which are examined in Insight 11) reflects algorithm performance on historical data, but real-world deployment introduces variables that controlled studies cannot fully anticipate. PMCF activities may include registry participation, user surveys, algorithm performance audits against clinical outcomes, and prospective clinical studies addressing questions that post-market experience reveals.
The relationship between PMCF findings and regulatory status requires careful management. PMCF activities that reveal performance concerns may trigger vigilance reporting obligations, corrective action requirements, or reassessment of the device's conformity with essential requirements. Manufacturers must design PMCF activities with clear protocols for escalating findings that suggest safety or performance problems, ensuring that clinical evidence generation does not create regulatory exposure through delayed identification of issues.
5. Can Surveillance Keep Pace With Software Development?
How Should Surveillance Be Built Into Development?
The data collection mechanisms, performance metrics, escalation procedures, and reporting workflows required for effective PMS demand technical integration with the software product itself. Manufacturers that launch software without embedded performance monitoring face surveillance blind spots that are costly to address post-launch; retrofitting monitoring infrastructure into deployed software creates both technical debt and interim compliance gaps that competent authorities may scrutinize. The software lifecycle standard IEC 62304 provides the framework within which PMS-relevant monitoring should be architected, with maintenance processes (Clause 6) explicitly requiring that feedback from production and post-production inform software change management.13IEC 62304:2006+A1:2015, Medical device software – Software life cycle processes, Clause 6 (software maintenance process); the standard requires documented procedures for monitoring, evaluating, and implementing changes based on post-market feedback.
What Resources Does PMS Require?
Resource allocation for ongoing PMS activities deserves attention in business planning. Traditional medical device manufacturers typically budget for post-market activities as a modest percentage of revenue; software manufacturers accustomed to minimal post-sale support may underestimate the ongoing investment required. Staff with regulatory expertise must review complaint data, assess vigilance reporting obligations, prepare PSURs, and coordinate corrective actions. Technical staff must maintain monitoring infrastructure, investigate performance anomalies, and implement approved changes. The recurring cost of these activities continues throughout the device lifecycle.
How Does the AI Act Intersect With MDR Surveillance?
For SaMD incorporating artificial intelligence, the EU AI Act (Regulation (EU) 2024/1689) introduces additional post-market monitoring obligations that operate alongside MDR requirements.14AI Act (n 8), Art. 72 including the integration option in Art. 72(2) and the plan template under Art. 72(3); Art. 6(1) and Annex I, Section A (medical-device AI as high-risk); Art. 113 (high-risk obligations apply from 2 August 2027). High-risk AI systems, a category that includes many medical AI applications under Annex I, Section A, must implement post-market monitoring systems capable of collecting and analyzing relevant data on performance throughout the system's lifetime; for AI that constitutes or is a safety component of a medical device, these obligations apply from 2 August 2027. The convergence between MDR PMS and AI Act post-market monitoring creates architectural questions. Art. 72(2) AI Act expressly permits providers to fold AI Act monitoring into the post-market surveillance system already maintained under the MDR, but only where doing so achieves "an equivalent level of protection," a standard the AI Act does not define and which the Commission's implementing-act template for the monitoring plan, envisaged by Art. 72(3), had not clarified as of publication. Whether a single integrated system suffices or parallel infrastructure is required therefore remains unresolved. PMS architecture for AI-enabled SaMD may therefore need to support compliance demonstration under both frameworks through coordinated but potentially distinct evidentiary pathways. For products deployed under sandbox or derogation mechanisms, PMS obligations apply in full; regulatory flexibility on market access does not reduce surveillance requirements.
How Should Change Control Balance Speed and Compliance?
The relationship between software updates and PMS obligations creates strategic tension. Agile development practices favor frequent, incremental updates that improve functionality based on user feedback. Regulatory frameworks treat each update as a potential modification requiring change impact assessment and, in some cases, new conformity assessment. Manufacturers must establish change control procedures that distinguish performance-neutral updates from modifications affecting safety or performance, documenting the rationale for each classification and maintaining evidence supporting the determination.
What Competitive Pressures Affect Surveillance Decisions?
Competitive dynamics may pressure manufacturers toward surveillance approaches that prioritize speed over thoroughness. A manufacturer that deploys updates rapidly gains market advantage over competitors following more deliberate change management processes. But competitive speed creates regulatory risk if updates introduce performance problems that surveillance systems fail to detect. The strategic question (how much surveillance is enough) lacks a universal answer; the appropriate level depends on device risk classification, clinical context, update frequency, and organizational risk tolerance, balanced against competitive positioning and resource constraints.