Post-Market Surveillance for Medical Device Software: What Your Team Owns After Launch

Post-market surveillance for a medical device is the ongoing review of real-world data from a product already on the market. FDA rules require incident reporting and complaint records, while the EU Medical Device Regulation (MDR) adds surveillance plans and periodic safety reports. For software, much of this work happens in engineering. Every release, dependency update, OS change, and security patch needs a regulatory impact review, and field data informs risk analysis. From launch, a large share of the regulatory workload runs through the codebase.

That workload shapes planning at two levels. CTOs must see which duties make it into the backlog, and founders must budget the people who handle them.

What Is Post-Market Surveillance for Medical Devices?

Post-market surveillance is the systematic, proactive review of experience with devices already on the market, aimed at identifying any need for corrective or preventive action. Article 2(60) of the EU MDR defines it as all activities manufacturers carry out, together with other economic operators, for that purpose.

In software products, medical device post-market surveillance follows the release cycle. Hardware changes arrive with a new device generation, while software updates can reach the field between generations. Each release can change how the device behaves in the field, so surveillance data and change control must keep pace. Field data from one release also shapes the next, because the MDR requires post-market data to update risk management and the device's design information.

Software also accounts for a steady share of field problems. IEEE Spectrum analyzed the FDA recall database and found that software problems lead to about 20 medical device recalls per month. Software design was the leading root cause.

What Does the FDA Require After Clearance?

FDA post-market surveillance rules require manufacturers of cleared devices to report adverse events, report corrections and removals that reduce a risk to health, and keep complaint records.

21 CFR Part 803

21 CFR Part 803 requires manufacturers to report within 30 calendar days of learning that a device may have caused or contributed to a death or serious injury. The rule also covers malfunctions likely to cause or contribute to such harm if they recur.

A 5-day report applies when an event requires remedial action to prevent an unreasonable risk of substantial harm. For every event, the manufacturer must keep an event file that documents how it decided whether the event was reportable. Because the clock starts at the moment of awareness, the team must retrieve logs, app and OS versions, and investigation notes within that window.

21 CFR 806.10

21 CFR 806.10 requires a written report within 10 working days of initiating a correction or removal that reduces a risk to health. Part 806 defines a correction as the repair, modification, adjustment, relabeling, destruction, or inspection of a device, so a software fix pushed to users can qualify. Fixes that only improve performance or quality are exempt, provided they neither reduce a risk to health nor remedy a violation.

A correction below the reporting threshold still requires a record under 806.20, including the justification for not reporting. The software team provides the device identifiers, change history, and rollout data for both outcomes.

Certain Class II and III devices whose failure would be reasonably likely to cause serious harm may also be subject to FDA-ordered Section 522 postmarket surveillance studies. Even manufacturers exempt from most of the Quality Management System Regulation must maintain records of medical device complaint handling.

What Does EU MDR Require? PMS Plan, PMSR, and PSUR

MDR post-market surveillance runs as a system inside the quality management system, scaled to the device's risk class.

The Post-Market Surveillance Plan

The post-market surveillance (PMS) plan outlines how a manufacturer collects and evaluates post-market data, and Annex III of the MDR specifies its contents. Required sources include serious and non-serious incidents, trend data, specialist literature, and complaints. Annex III also requires indicators and thresholds for reassessing benefit and risk, as well as tools to trace devices that might need corrective action. Crash rates, error logs, and in-app feedback can feed those indicators, and version tracking shows which installations a field action must reach.

PMSR vs PSUR by Medical Device Class

Class I manufacturers prepare a post-market surveillance report (PMSR), update it as needed, and share it with the competent authority upon request. Class IIa, IIb, and III manufacturers prepare a periodic safety update report (PSUR). Class IIa manufacturers update it at least every two years, and Class IIb and III manufacturers at least annually. For Class III and implantable devices, manufacturers submit the PSUR to the notified body via the EU's EUDAMED database.

Vigilance runs alongside these reports. Article 87 gives manufacturers 15 days from becoming aware of a serious incident to report it. The limit drops to 10 days for a death or an unanticipated serious deterioration in health, and to 2 days for a serious public health threat. Within those windows, the software team must pull affected versions, device identifiers, timestamps, and event logs.

Which Post-Market Tasks Land on the Software Team?

Post-market work splits into a regulatory stream and an engineering stream. The regulatory lead decides what to report and when, and the software team produces the evidence behind each decision.

Founders should budget capacity for both columns, and a supporting partner should deliver the right-hand one each release.

Telemetry and Logging That Feed Surveillance

Telemetry is a direct source of surveillance data for software. Signals include crash rates by version, failed measurements, and connectivity drops. Each signal should include the app version, OS version, and a pseudonymous device identifier so an incident report shows which users a problem affected. AI features introduce model drift, which calls for monitoring AI model performance in production.

From Complaint to Ticket: Traceability Between Field Data and the Backlog

Medical device complaint handling starts outside engineering but can end in the codebase. A complaint that reveals a defect should open a ticket linked to the complaint record, the risk file entry, and the affected requirement. The fix closes the chain by linking to the commit, tests, and release. Auditors get answers from a single record, and engineers see which complaints cluster around a component.

Change Impact Assessment for Every Release

Each release needs a short written assessment first. It identifies what changed, which requirements and risk controls the change affects, and whether safety or performance could shift. The answer determines the regulatory path. Eargo's hearing aid apps we built show why. They support multiple hardware generations, from Eargo 5 to Eargo 7, so a single change can reach all three.

When Does a Software Update Need a New 510(k)?

Under 21 CFR 807.81(a)(3), a software update needs a new 510(k) when it could significantly affect the device's safety or effectiveness. A major change to the device's intended use also triggers one. FDA's guidance on determining when to submit a 510(k) for a software change helps manufacturers apply that threshold.

How the FDA Software Change Guidance Frames the Decision

The October 2017 guidance's flowchart asks whether a change introduces or modifies a risk that could result in significant harm and that existing controls do not already mitigate. A second question addresses changes that could significantly affect clinical functionality or performance specifications. AI-enabled devices can map out future model changes in advance through a predetermined change control plan.

Documenting Changes That Don't Need a Submission

Knowing when to submit a 510(k) includes recording each time the answer is no. Manufacturers must still document changes that do not require a new 510(k) under 21 CFR 820. The change impact assessment for each release can serve as that record, stored with the matching test reports. The guidance further recommends weighing the cumulative effect of changes since the last cleared version, and those records make that comparison possible.

Before some changes reach users, EU rules require manufacturers to involve the notified body. How depends on the type of change:

• Device changes in Class III and some Class IIb devices. Under Annex IX section 4.10, changes that could affect safety, performance, or the conditions of use need the notified body's approval before release.

• Quality system and device range changes. Under section 2.4, manufacturers inform the notified body of planned substantial changes to the quality management system or the device range, and the notified body assesses them.

Notification forms, such as NSAI's substantial change form, request a detailed description, the reason, and a timeline. Engineers provide the updated risk analysis and test results for each notification.

What Happens When the OS, SDK, or a SOUP Component Changes?

A change to the OS, an SDK, or a SOUP component calls for a risk review and regression testing before it reaches users. IEC 62304 defines software of unknown provenance (SOUP) as a software item that is already developed and generally available, or one with inadequate development records. Operating systems, mobile SDKs, open-source libraries, and runtimes fall into this category.

SOUP upkeep comes down to the following habits:

• Maintain a SOUP list with each item's name, version, manufacturer, requirements, and the website for its bug reports and changelogs.

• Track those sources throughout the device's market life and treat each new anomaly as input to risk analysis.

• Run compatibility and regression tests when iOS, Android, or a key library reaches a new major version.

IEC 62304 cites ISO 14971 as its sole normative reference and expects teams to assess the risk of each change. An OS update that alters Bluetooth behavior or background processing therefore calls for an updated hazard analysis and proof that existing controls remain effective.

Monterail's work on Elvie's breast pump apps offers a working example. An automated hardware-in-the-loop test rig connected real phones on both mobile platforms to an Elvie Pump and ran end-to-end regression tests on each build. Each build therefore came with fresh evidence that pump control still worked. Rigs like this belong to testing and QA for health apps that communicate with hardware.

Source: Elvie Pump Case Study

How Does Medical Device Cybersecurity Work After Launch?

Medical device cybersecurity after launch works as a continuous cycle of monitoring, risk assessment, patching, and disclosure for as long as the device is on the market. Cyber devices run sponsor-validated software and can connect to the internet. For them, section 524B of the FD&C Act requires a plan to monitor, identify, and address postmarket vulnerabilities, including coordinated vulnerability disclosure. FDA's 2016 postmarket cybersecurity guidance recommends monitoring third-party software for new vulnerabilities and acknowledging receipt of each vulnerability report.

Section 524B also requires an SBOM listing the device's software components. FDA's June 2025 premarket cybersecurity guidance recommends including third-party and open-source components and their dependencies, along with each component's support level and end-of-support date. Generating the SBOM in CI keeps it aligned with the release users run. The architecture for secure OTA updates for connected devices determines how quickly a fix reaches the field.

Routine patches addressing a controlled risk of patient harm typically do not require a Part 806 report under the 2016 guidance.

With an uncontrolled risk, the FDA does not intend to enforce that reporting when the guidance's four conditions hold:

• No known serious adverse events or deaths.

• Customer contact within 30 days.

• A fix within 60 days.

• Active membership in an information sharing group (ISAO).

A patch made solely to strengthen cybersecurity is, in many cases, unlikely to require a new 510(k). One that also changes clinical functionality goes through the 510(k) decision process.

How Can Regulatory Evidence Stay Current With Every Release?

Regulatory evidence remains current when CI generates it with every build. IEC 62304's software maintenance process requires the team to evaluate each problem report for safety impact and to confirm every change through regression testing.

These records cover most of that evidence:

• Traceability. Link each requirement to its design, code, tests, and risk controls.

• Test evidence. Archive CI test reports for every release, tagged with the exact build version.

• Change records. Write release notes as records that list what changed, why, the risk impact, and the covering tests.

Teams that treat architecture as regulatory evidence before clearance only need to keep the same habit after launch. These records also support working within your ISO 13485 QMS, which requires every design change and its verification to be documented.

A chronic pain wristband from Remedee Labs underscores the stakes. It carries CE marking as a Class IIa device, so the MDR requires a PSUR at least once every two years. Companion apps pair with the wristband via Bluetooth Low Energy, and insights from ongoing clinical studies kept shaping the product. Monterail shipped continuous updates to those apps without compromising the integrity of the trials.

Source: Remedee Labs case study

What Should You Build Into Your MVP to Prepare for Post-Market?

Build post-market foundations before launch, alongside the earliest features. The EU's December 2025 guidance, MDCG 2025-10, notes that PMS planning begins during design and development.

Planning for post-market duties is part of a broader question: when regulatory work on a SaMD product should start. In our webinar, Piotr Zając, HealthTech Director at Monterail, and Janet Kwiatkowski, founder and CEO of MAE Group, discuss when to start that work under FDA and EU MDR rules.

A post-market-ready MVP should include these foundations:

• Version and device identifiers in every log line and support ticket.

• Telemetry for the signals the PMS plan will name, reviewed for privacy.

• A SOUP list and an SBOM generated in CI.

• A change impact template linked to the requirement and risk files.

• CI test runs that archive their reports for each release.

This groundwork supports the duties covered earlier, from incident reports to release evidence.

Adding these foundations after launch requires retrofitting logging, CI, and records into a live product, which increases technical debt in regulated products. The reporting load also varies by device class, which depends on how SaMD is classified in each target market. Founders still unsure whether their product is a medical device need to resolve that first.

Run Each Release as a Regulatory Event

When each release includes an impact assessment, a current SBOM, and archived test evidence, post-market surveillance becomes routine. Where evidence lives only with the consultant, missing records surface during an incident or an audit. A development partner that maintains the product after launch should deliver all three with each release.

Elvie and Eargo both worked with Monterail's healthcare software team for years after the release. Check your readiness with the SaMD checklist or contact our team and find out how we support medical devices after launch.