How to Build a SaMD Postmarket Surveillance Plan: Template

Why SaMD Postmarket Surveillance Differs From Hardware Device Monitoring

Traditional postmarket surveillance for hardware devices is largely complaint-driven: a fixed product configuration generates adverse event reports, and surveillance activity centers on aggregating and reviewing those reports against a static baseline. SaMD does not fit this model cleanly. Software changes far more frequently than hardware, and each update can alter behavior, introduce new failure modes, or shift algorithm outputs without any physical change to the product. IMDRF's 2015 SaMD quality management system guidance recommends postmarket feedback loops that account for the full software lifecycle, including changes introduced through updates, rather than treating the device as fixed at the point of clearance or approval. This means a SaMD PMS plan must track performance against specific software versions, not just the device as a general category, and must treat update-related risk as a distinct surveillance category alongside traditional complaint and malfunction data.

Core Regulatory Obligations: FDA vs EU MDR

A SaMD PMS plan draws on several distinct regulatory anchors rather than one unified rule. The table below summarizes where each obligation originates.

Data Architecture for Software-Specific Signals

SaMD surveillance depends on data pipelines that hardware PMS systems rarely need. Version-tagged logging allows performance and complaint data to be traced back to a specific software build, which is necessary when multiple versions may be in active use simultaneously. Cybersecurity vulnerability monitoring, including CVE feeds and SBOM tracking, is expected as its own data stream under FDA cyber device requirements rather than folded into general complaint intake. AI-enabled SaMD adds a further requirement: real-world performance monitoring capable of detecting algorithm drift across deployed versions, which should be segregated from general software defect data so drift signals are not diluted or missed. A workable architecture unifies complaint records, telemetry, and cybersecurity intake into one traceable system, with an explicit interface between engineering release pipelines and the regulatory or quality review process.

Operational Practices for Running the Plan

• Assign clear data ownership across regulatory, quality, engineering, and cybersecurity functions for each data source.
• Align software release cadence with PMS review checkpoints so updates are never shipped ahead of a corresponding surveillance review.
• Establish a cross-functional PMS review board that meets on a defined schedule to evaluate aggregated data, not just individual complaints.
• Document the signal detection methodology in enough detail that an auditor can reconstruct how a decision was reached.
• Maintain a documented link between PMS findings and CAPA records so corrective action can be traced back to the originating signal.

Recent Regulatory Developments Affecting SaMD PMS

Two developments from the past two years directly affect how a SaMD PMS plan should be structured. FDA's cyber device requirements under Section 524B, effective March 2023, require manufacturers to include postmarket monitoring, coordinated vulnerability disclosure, and patch capability plans as part of premarket submissions, which means the PMS plan must show how vulnerability monitoring operates after release, not only how it was designed. FDA's related 2023 cybersecurity guidance describes postmarket expectations including SBOM maintenance and coordinated disclosure processes in more detail. Separately, FDA finalized guidance in December 2024 on Predetermined Change Control Plans for AI-enabled device software functions, describing how manufacturers can prospectively define planned modifications along with the monitoring data needed to support them after release. Where a PCCP is in place, the PMS plan should explicitly reference it so that approved modification pathways have corresponding postmarket monitoring commitments. It is worth noting that the US has no single unified SaMD postmarket surveillance regulation; obligations are assembled from MDR reporting, corrections and removals rules, cyber device requirements, and non-binding guidance, and manufacturers should treat guidance documents as current expectations rather than fixed law.

Where Runtime Governance Intersects With SaMD Monitoring

For AI-enabled SaMD, monitoring algorithm drift and change-controlled updates after release resembles a broader problem: knowing what an autonomous system is doing, under what permissions, and whether its behavior stays within approved boundaries over time. Runtime governance for AI agents applies similar principles, including permission scoping, audit logging, and continuous runtime monitoring, to systems that operate and change after deployment. Manufacturers building out algorithm drift monitoring as part of a PMS plan are solving a version of the same operational problem that runtime governance addresses for AI agents more broadly.