---
title: Post-Market Service and Support Operations for Medical Devices
description: How to run post-market service and support for medical devices under MDR: servicing as a regulated activity, records, traceability, complaint capture.
authors: Tibor Zechmeister, Felix Lenhard
category: Team Building, Operations & Scaling
primary_keyword: post-market service support medical devices
canonical_url: https://zechmeister-solutions.com/en/blog/postmarket-service-support-operations
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Post-Market Service and Support Operations for Medical Devices

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Once a medical device ships, service and support stop being a customer-success function and become a regulated activity. Under EN ISO 13485:2016+A11:2021 clause 7.5.4 and MDR Articles 83 to 92, every service visit, spare part swap, help-desk call and training session is evidence the quality system must capture, trace and feed into post-market surveillance and vigilance.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Servicing is an explicit clause of EN ISO 13485:2016+A11:2021 (clause 7.5.4) whenever servicing is a specified requirement for the device.
- Every service event must generate records that link a trained technician, a traceable replacement part, and a specific device identity.
- Help-desk, service and support channels are the primary real-world route through which complaints and signals enter the post-market surveillance system under MDR Articles 83 to 86.
- Serious incidents detected through service or support interactions must be reported to the competent authority under the Article 87 timelines.
- A lean startup can run compliant service operations with one shared inbox, one ticketing tool and a written procedure, but not without them.

## Why post-market service is a regulated activity

The first time a field engineer swaps a battery pack on a Class IIa therapeutic device, the startup has crossed a line that most founders do not see. That visit is not a customer-success touchpoint. It is a production process performed outside the factory, on a device already placed on the market, under the responsibility of the legal manufacturer. Everything the engineer does, touches and writes becomes part of the device's regulatory history.

Founders who come from software or consumer hardware underestimate this. They assume that once the CE certificate is issued, servicing is someone else's problem, or that a Zendesk inbox is "good enough". Under MDR it is not. The manufacturer remains responsible for the device throughout its entire lifecycle, and servicing is one of the mechanisms the regulator relies on to detect problems before they become serious incidents. When a notified body arrives for a surveillance audit, the service records are often the first thing they ask for, because service records tell the truth about what is actually happening to devices in the field.

The good news: none of this requires a large service organisation. It requires clarity about which activities are service events, what each event must produce as a record, and how those records flow back into the quality system and the post-market surveillance plan.

## What MDR and ISO 13485 actually say

Three regulatory anchors set the requirements.

**EN ISO 13485:2016+A11:2021 clause 7.5.4** covers servicing activities. When servicing is a specified requirement for the device, the manufacturer must plan, perform and document service activities, and must analyse records of service activities to determine whether information should be handled as a complaint and whether it should feed into improvement. The clause is deliberately broad: if your intended purpose, instructions for use, or warranty implies service, the clause applies.

**MDR Articles 83 to 86** establish the post-market surveillance obligation. Article 83 requires every manufacturer to plan, establish, document, implement, maintain and update a PMS system proportionate to the risk class and appropriate to the type of device, and to use it as an integral part of the quality management system. Article 84 requires a PMS plan referring to Annex III. Articles 85 and 86 require PMS reports for Class I devices and periodic safety update reports (PSURs) for Class IIa, IIb and III devices. Service data is one of the primary inputs these documents are built from.

**MDR Articles 87 to 92** set the vigilance regime. Article 87 requires manufacturers to report serious incidents and field safety corrective actions within defined timelines. Article 88 requires trend reporting. Article 89 covers the analysis of serious incidents. If a service engineer encounters something that meets the definition of a serious incident, the clock starts at the moment any person in the manufacturer's organisation becomes aware, not at the moment the report reaches the regulatory affairs desk.

**MDR Annex I Section 23** (information supplied with the device) further requires instructions for use to include the information needed for safe servicing, such as the nature and frequency of maintenance and any calibration needed. If the instructions for use promise annual calibration, the service operation must be able to deliver and document that calibration.

## A worked example: a portable therapy device

Consider a startup that sells a Class IIa portable therapy device across five EU member states. Devices have rechargeable batteries with a documented two-year service life, a disposable applicator head, and firmware that the manufacturer updates annually. The instructions for use state that the battery pack must be replaced every two years and that the device must be returned to the manufacturer for firmware updates and functional check.

What does service operations look like, minimally compliant?

There is one written procedure, three pages long, that defines what counts as a service event (battery replacement, firmware update, functional check, repair, calibration), who is authorised to perform each, and what records each produces. There is one ticketing system that is also the complaint intake system: every service request creates a ticket, every ticket has the device serial number, and every ticket is reviewed within 48 hours by a named person to decide whether it is a complaint under clause 8.2.2 or a routine service event. The same person is responsible for escalating to vigilance if the ticket describes anything that might be a serious incident.

Replacement batteries and applicator heads are held in a single bonded stock location. Each batch has a lot number. When a battery is issued for a service event, the ticketing system records lot number against device serial number. This gives the traceability that MDR Article 25 and ISO 13485 clause 7.5.8 require, without a separate warehouse system.

Service engineers are internal for the first eighteen months, then a regional partner takes over two countries. Before the partner is allowed to touch a device, they sign a quality agreement that includes the service procedure, they receive documented training with a test, and the training record goes into the personnel file the notified body will read during the next audit. When the partner performs a service event, they generate a service report in the same ticketing system the internal engineers use. There is one source of truth, not two.

At the end of each quarter, the PMS data owner pulls a report from the ticketing system. That report feeds the PMS plan under Annex III and the PSUR under Article 86. Service data shows up as a named data source. The analysis drives two small labelling updates and one design change request in the following twelve months. The notified body auditor asks to see all of this, and it takes an afternoon to pull because everything lives in one system with device serial numbers as the primary key.

## The Subtract to Ship playbook

The operating principle is brutal: every service and support activity must be capturable, traceable and reviewable, but the infrastructure to do that should be as small as possible. Here is the minimum that survives a notified body audit.

**One written service procedure.** Name every activity that counts as a service event. For each, define who is authorised to perform it, what training is required, what records must be created, and what feeds back into complaint handling, PMS and vigilance. Three to five pages is enough for a startup. Reference EN ISO 13485:2016+A11:2021 clause 7.5.4 explicitly.

**One ticketing system that is also the complaint intake.** Do not maintain separate tools for service tickets, support emails and complaints. The MDR does not care what tool you use, but it cares that nothing falls between the cracks. Every inbound contact. Email, phone, portal, partner report. Becomes a ticket with the device serial number attached. A named person triages within a defined timeline (48 hours works for most startups) and classifies the ticket as complaint, routine service, or information request.

**Replacement part traceability tied to device identity.** Whenever a part is consumed in a service event, the lot number and the device serial number are recorded in the same record. This is the minimum to meet Article 25 traceability obligations and to support a field safety corrective action if a part lot turns out to be defective.

**Training records for every person who touches a device.** Internal engineers, external partners, and help-desk staff who triage complaints all need documented training against a named procedure. The training record must show who was trained, on what version of the procedure, when, and by whom, and must include a competence check (a test, a supervised first service, a sign-off).

**A monthly service data review that feeds PMS.** Once a month, the PMS owner looks at service data for signals: rising failure rates on a specific part, unexpected use patterns, safety-relevant complaints. This review generates a short written record. Quarterly, the record is summarised into the PMS plan update and the PSUR input folder.

**A vigilance escalation path that any service person can trigger.** Every engineer, every support agent, every partner must know the rule: if you suspect a serious incident, escalate within 24 hours to the named person who owns vigilance reporting. The escalation path is one line in the procedure and one trained reflex.

## Reality Check

1. Does your written service procedure name every service activity and reference EN ISO 13485:2016+A11:2021 clause 7.5.4?
2. Can you, right now, produce a list of every service event performed in the last 90 days with device serial number, engineer, parts consumed, and outcome?
3. Is your service ticketing system the same system that captures customer complaints, or do you have two systems that need reconciling?
4. For every spare part batch shipped in the last year, can you trace which devices received which lot?
5. Do you have a dated training record for every person authorised to perform a service event, including external partners?
6. Does your PMS plan under Annex III explicitly list service data as a data source?
7. If a service engineer identified a serious incident today, how many hours would pass before it reached the named person responsible for Article 87 reporting?
8. When did you last test the service data flow into a PSUR or PMS report end-to-end?

## Frequently Asked Questions

**Is servicing always required under MDR?**
No. Servicing is a regulatory requirement when it is a specified requirement for your device, meaning your intended purpose, instructions for use, maintenance instructions under Annex I §23, or warranty conditions create the obligation. If your device is single-use and not serviceable, clause 7.5.4 does not apply in the same way, but complaint handling and PMS still do.

**Can we outsource all service to a partner?**
Yes, and many startups do. But you remain the legal manufacturer. The partner must work under a written quality agreement, trained against your procedures, producing records you own and can audit. The notified body will ask to see evidence you control the partner.

**Is help-desk data really part of PMS?**
Yes. Customer contacts are one of the explicit data sources your PMS plan should list under Annex III. If a user calls to ask how to clean the device and the question reveals confusion caused by unclear instructions for use, that is a PMS signal.

**What if a service event reveals a serious incident?**
The Article 87 clock starts when your organisation becomes aware. The service engineer is your organisation. Train every engineer and partner to escalate suspected serious incidents within 24 hours to the person responsible for vigilance reporting.

**Do we need a separate service management software tool?**
No. A single ticketing tool with custom fields for device serial number, lot numbers and classification is sufficient for most startups until you are servicing thousands of devices a year. Simplicity is a regulatory asset.

**How do notified bodies test our service operations?**
They sample service tickets, trace them to device serial numbers, check training records for the engineer, check the parts traceability, and verify that any complaints found in the sample were handled under the complaint procedure. If the trail breaks at any point, you get a finding.

## Related reading
- [Customer complaint handling under MDR](/blog/customer-complaint-handling-mdr) – how service data enters the complaint pipeline.
- [MDR Articles 83 to 86: the PMS framework](/blog/mdr-articles-83-86-pms-framework) – the statutory basis for using service data as PMS input.
- [PMS data sources](/blog/pms-data-sources) – full list of inputs your PMS plan should name.
- [Field service engineering for medical devices](/blog/field-service-engineering-medical-devices) – the engineer side of the same operation.
- [MDR traceability requirements](/blog/mdr-traceability-requirements) – how parts and device identities must be linked.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 25, 83, 84, 85, 86, 87, 88, 89, Annex I Chapter III Section 23, Annex III.
2. EN ISO 13485:2016+A11:2021. Medical devices. Quality management systems. Requirements for regulatory purposes, clause 7.5.4 (servicing activities), clause 7.5.8 (identification), clause 8.2.2 (complaint handling).
3. MDCG 2023-3 Rev.2 (January 2025). Questions and Answers on vigilance terms and concepts as outlined in the Medical Device Regulation.
4. MDCG 2025-10 (December 2025). Guidance on post-market surveillance under the MDR.

---

*This post is part of the [Team Building, Operations & Scaling](https://zechmeister-solutions.com/en/blog/category/team-operations) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*