1. What changes after CE mark — the maintenance lifecycle
Most SaMD teams spend 12–18 months focused on getting to CE mark. Very few spend equivalent effort designing what happens after. The result is predictable: a support model built for a standard software product collides with post-market obligations built for a medical device, and neither works well.
EU MDR does not describe how to run a support desk. But it creates a framework of obligations that your support model must fit inside:
- Complaint handling — every user complaint about safety or performance must be captured, investigated, and documented per your ISO 13485 QMS complaint procedure.
- Vigilance reporting — serious incidents must be reported to the relevant competent authority within defined timeframes.
- Change management — every software change must be assessed against the significant change criteria in MDCG 2020-3 before deployment.
- Post-market surveillance — support data is a primary input into your PMS plan, PSUR, and PMCF plan.
None of these obligations are compatible with an ad-hoc support process. They require a structured system where every support interaction is documented, classified, and routed according to predefined procedures. ISO 14764:2022 provides the framework.
2. ISO 14764:2022 — the maintenance standard for SaMD
ISO 14764:2022 (Software Engineering — Software Life Cycle Processes — Maintenance) defines the processes, activities, and tasks for software maintenance after initial deployment. It classifies all maintenance activities into four types, each with different regulatory implications for SaMD:
Fixing defects
Reactive modifications to correct discovered faults — bugs, errors, failures identified in production. The defect exists in the delivered software; the fix restores intended behaviour.
Adapting to environment changes
Modifications to keep software operational in a changed or changing environment — OS updates, new browser versions, API changes in connected systems, hardware upgrades at client sites.
Improving performance or usability
Modifications that enhance performance, maintainability, or usability without correcting faults or adapting to environment. Feature additions, UX improvements, performance optimisations.
Preventing future failures
Modifications that detect and correct latent faults before they become operational failures — code refactoring, security hardening, dependency updates before known vulnerabilities are exploited.
ISO 14764:2022 and IEC 62304 address the same lifecycle from different angles. IEC 62304 defines the development and maintenance processes required for medical device software specifically. ISO 14764:2022 provides the broader framework for classifying and managing maintenance activities. In a mature SaMD QMS, both are referenced: IEC 62304 Section 6 covers software maintenance processes, and ISO 14764:2022 provides the classification taxonomy your change management procedure uses to route each change to the appropriate regulatory assessment.
3. Support tier structure for medical software
Standard software support models (L1/L2/L3) apply to SaMD — but each tier carries responsibilities that go beyond what these tiers mean in non-medical software. The key difference is that every tier must have a defined interface with your QMS complaint handling procedure.
First response
- Initial contact, triage, basic troubleshooting
- Collect full incident description and context
- Log every interaction in the complaint system
- Apply severity classification (P1–P4)
- Provide workaround instructions where available
- Escalate P1 and P2 immediately to L2
- Communicate acknowledgement SLA to client
Root cause analysis
- Reproduce the issue in test environment
- Identify root cause and affected components
- Assess patient safety impact
- Determine if vigilance reporting is triggered
- Initiate change request in QMS if fix required
- Escalate to L3 for engineering fix
- Keep client updated on investigation status
Fix and compliance
- Develop and test the fix per IEC 62304
- Run significant change assessment (MDCG 2020-3)
- Update risk management file if needed
- NB notification if significant change confirmed
- Update technical documentation and SOUP list
- Deploy via release procedure with regression testing
- Close complaint with documented resolution
L1 and L2 tiers operate well in most SaMD companies. The critical gap is the L2→L3 handoff: L2 identifies a bug, raises a Jira ticket, and the engineering team fixes and deploys it — without anyone performing the mandatory significant change assessment before release. This is the most common QMS non-conformity found in post-market NB surveillance audits.
4. Incident classification and SLA by severity
Every support incident must be classified at intake. The classification drives both the internal SLA and the regulatory assessment path. EU MDR does not prescribe specific SLA timeframes, but your PMS plan and QMS complaint procedure must define them — and they must be consistent with vigilance reporting obligations.
| Level | Definition | SLA — response | SLA — resolution | Regulatory path |
|---|---|---|---|---|
| P1 | Critical. Patient safety at risk, clinical function unavailable, incorrect outputs affecting active clinical decisions. | 1 hour | Same day workaround or suspension | Immediate vigilance assessment. Potential serious incident report to competent authority within 15 days. FSCA assessment. |
| P2 | Major. Significant clinical workflow impact, degraded accuracy, data integrity issue without immediate patient harm. | 4 hours | 5 business days | Full complaint investigation. Vigilance assessment. Significant change assessment before fix release. |
| P3 | Minor. Limited clinical impact, workaround available, no patient safety risk identified. | 24 hours | Next planned release | Standard complaint record. Change request in QMS. Significant change assessment before release. |
| P4 | Enhancement / no clinical impact. UI issues, cosmetic defects, performance improvements with no clinical output effect. | 5 business days | Roadmap | Logged in product backlog. No mandatory complaint record unless customer formally raises as complaint. Change assessment at release planning. |
If a P1 incident meets the EU MDR definition of a serious incident (Article 2(65) — death, serious deterioration of health, or serious public health threat), the 15-day vigilance reporting clock starts from the moment your organisation becomes aware of the incident — not from when a fix is ready. Deploying a hotfix does not suspend or reset this obligation. The serious incident report to the competent authority must still be filed.
5. Change management: when a fix becomes a regulatory event
Every software change deployed to production — regardless of how minor it seems — must pass through a documented significant change assessment before release. MDCG 2020-3 defines the criteria for what constitutes a significant change under EU MDR.
The assessment is not a bureaucratic formality. It is the mechanism that determines whether you can deploy a fix immediately under your existing CE mark, or whether you need Notified Body involvement before the change goes live.
6. Client communication protocols
Communication with healthcare provider clients after CE mark has two layers that must not be conflated: commercial support communication and regulatory communication. Mixing them — or handling regulatory obligations through informal channels — creates compliance risk.
Support communication
Standard incident updates, workaround instructions, and fix ETAs. Delivered through your support system (ticketing platform, email, dedicated portal). The key requirement under ISO 13485: every substantive communication about a complaint must be documented and traceable to the complaint record. A verbal phone update that is not logged does not exist for QMS purposes.
Regulatory communication — Field Safety Corrective Actions
When a defect poses a risk of serious harm and a correction needs to be deployed across the installed base, this may constitute a Field Safety Corrective Action (FSCA) under EU MDR Article 2(68). An FSCA requires a Field Safety Notice (FSN) — a formal written communication to all affected customers, typically reviewed and approved by the competent authority before distribution.
An FSN is not a support email. It has mandatory content elements defined by MDCG guidance: description of the problem, affected device versions, risk to patient/user, action required, timeline for action, and contact details. If your team has never drafted an FSN, drafting one for the first time during an active safety event is not the moment to learn the format.
Software update notifications
Every software update deployed to clients must be communicated with sufficient information for clinical users to understand what changed and whether their workflows are affected. For significant changes (3B above), the update communication must include a summary of the regulatory assessment outcome. For AI/ML updates that change model behaviour, clinical users must be notified of any changes to the output characteristics or limitations that affect their use of the device.
Maintain a documented communication template library: incident acknowledgement, investigation update, resolution notice, software release note, FSCA notice, FSN draft. Templates that have been legally reviewed and QMS-approved reduce response time in a safety event from days to hours — and ensure regulatory language is correct from the first draft.
7. Connecting support data to EU MDR post-market obligations
Your support system is one of the richest sources of post-market data you have. Under EU MDR, this data must flow into your formal post-market surveillance system — not sit isolated in a ticketing platform that no one reviews for regulatory purposes.
Here is how support data maps to each EU MDR post-market obligation:
PMS plan and PSUR
Your Post-Market Surveillance plan must define how complaint and support data is collected, aggregated, and analysed. The PSUR (Periodic Safety Update Report) must include a summary of complaints, serious incidents, and FSCAs from the reporting period, and assess whether the benefit-risk profile remains acceptable. A PSUR that does not reference support system data is incomplete.
PMCF plan
Post-Market Clinical Follow-up gathers clinical evidence on device performance in real-world use. Support data — particularly patterns of unexpected use, unexpected clinical outcomes, or performance in patient subgroups not well represented in pre-market studies — is a mandatory input to PMCF analysis. If your support tickets consistently show a specific patient population experiencing different outcomes, this is a PMCF signal that must be investigated.
EUDAMED and vigilance
Serious incidents and FSCAs must be registered in EUDAMED from 28 May 2026 when the vigilance module becomes mandatory. Your support classification (P1 assessment) must be the trigger for the vigilance assessment that determines whether an EUDAMED report is required. If the serious incident assessment lives only in your support system and never reaches the regulatory function, the EUDAMED report will be late — which is a direct regulatory violation.
ISO 13485 Section 8.2.2 requires a documented complaint handling procedure that integrates with vigilance reporting. In practice, this means your support system and your QMS must share data — either through a direct integration or through a defined escalation procedure with documented handoffs. A Jira ticket that is never linked to a QMS complaint record, and a QMS complaint record that is never linked to the PSUR, are both non-conformities.