What you will learn
By the end of this topic, you should be able to define the service team’s product-lifecycle responsibilities; influence serviceability during design; establish a risk-based service strategy; prepare tools, parts, instructions and competence before release; control installation, maintenance and repair; preserve configuration and data integrity; create useful service records; identify complaints and reportable events; protect privileged service access; and support decommissioning and end-of-support.
The service team’s role
Service teams sustain the safety, performance and availability of released devices through installation, maintenance, calibration, diagnosis, repair, update and technical support. They also observe real products in real environments. Their evidence may reveal design weakness, use difficulty, process variation, supplier failure or emerging safety and cybersecurity risk earlier than formal complaint trends.
Design contributor
Make access, diagnostics, replacement and recovery safe and practical.
Configuration custodian
Know what hardware, software, parts and settings are installed in each device.
Field decision-maker
Apply authorised limits for return to service, escalation and quarantine.
Post-market observer
Convert field symptoms and repairs into structured product feedback.
Design serviceability into the product
Review physical access, diagnostic coverage, replaceable units, calibration, cleaning, contamination control, safe isolation, lifting, connectors, software logs, backup and recovery. Identify service errors that could create harm, including incorrect parts, settings, calibration, software or reassembly. Prefer design features that prevent or detect incorrect service.
Connect service needs to MTL-103 — User Needs and Design Inputs and system decisions to MTL-105 — Systems Engineering, Architecture and Interfaces.
Define a risk-based service strategy
- Determine which activities users, distributors, field staff or depot specialists may perform.
- Define preventive-maintenance and calibration intervals with rationale.
- Specify tools, fixtures, software, reference equipment and environmental needs.
- Identify parts, consumables, licences and knowledge needed over the support life.
- Define remote-support boundaries and privileged-access controls.
- Set return-to-service criteria and independent checks.
- Plan support, obsolescence and decommissioning before launch.
The strategy should reflect device risk, complexity, use environment, installed-base geography and the consequences of unavailable service.
Make service readiness part of product release
Service deliverables and unresolved constraints should be reviewed through MTL-121 — Design Transfer, not discovered after commercial release.
Control installation and acceptance at the use site
Confirm environmental, electrical, network, space, accessory and facility prerequisites. Record device identity, location, configuration, installation checks, safety tests, connectivity, user handover and outstanding actions. Installation evidence should demonstrate that the supplied system is complete and operates as intended in its actual context.
Perform maintenance and repair within authorised limits
Use approved procedures, parts, tools and acceptance criteria. Record observed condition before intervention, diagnosis, work performed, parts and software changed, measurements, anomalies and final disposition. Where work departs from the approved method, stop and escalate rather than improvising a field redesign.
Return-to-service checks must address the functions and risk controls potentially affected by the intervention. A device that powers on is not necessarily safe to release.
Preserve device configuration and traceability
Maintain the association between serial number, hardware revision, software and firmware, options, accessories, calibration, repairs, safety updates and location. Control service-software versions, parameter files and diagnostic tools. Assess compatibility before replacing a part or loading software, and record the resulting baseline.
Create records that support technical and regulatory decisions
Use structured symptom, cause, action, part, measurement and outcome fields while retaining useful narrative. Distinguish customer report from technician observation and confirmed root cause. Record unsuccessful visits and no-fault-found events; repeated ambiguity may itself indicate a design or diagnostic weakness.
Service metrics should include recurrence, time to repair, replaced-part trends, calibration drift, repeat visits, unresolved cases and configuration-specific patterns—not only closure speed.
Recognise complaints, adverse events and emerging risk
Service personnel need clear criteria and rapid routes for escalating allegations of deficiency, injury, malfunction, cybersecurity concern or potential reportable event. Do not wait for root cause before forwarding a possible complaint. Quality and regulatory teams determine formal classification and reporting; service provides timely, factual evidence.
Connect field information to MTL-127 — Post-market Support and risk reassessment to MTL-114 — Medical-device Risk Management.
Make service access secure and supportable
Control service identities, privileges, credentials, remote sessions, tools, logs and data handling. Avoid shared permanent passwords and undocumented back doors. Authenticate update packages, protect keys, define offline procedures and test recovery from interrupted updates. Remove temporary access and customer data when work is complete.
Use MTL-109 — Medical-device Cybersecurity for the wider lifecycle framework.
Common misconceptions
“Service starts when the warranty claim arrives.”
Serviceability, tools, evidence and support capability must be designed and ready before release.
“A successful repair closes the issue.”
The service action may restore one device while the underlying product, process or field risk remains.
“Only the complaint team needs to recognise complaints.”
Service personnel are often the first to receive allegations of product deficiency and must escalate them promptly.
Authoritative starting points
Service is part of the controlled medical-device lifecycle—not an after-sales repair activity
Design for safe service, preserve configuration, verify return to use and ensure every field observation can reach the people responsible for product risk and improvement.