Software Maintenance plan by product OR Software Maintenance Process

[KiraKiwaKilowatt]

My colleagues and I are facing a dilemma, following a submission for EU MDR, one non conformity was regarding a missing SW Maintenance plan.
We have several SW lifecycle SOP one for each type of SW (FW, Smartphone APP, cloud SW..) but none are talking about SW maintenance.

In regards to the requirement the SW Maintenance plan in standards / guidance looks to be only connecte the dot between already existing SOP (change control, NC/CAPA, non confirming product, problem resolution ...) so an additional SOP/OP/WIN seam a bit too much.

But in regards of the Product itself, we have difficulty to set-up a dedicated maintenance plan for it, as most activities are quite generic and already well established in the R&D day to day activities.

Dear Fellow QARA/ MD eng. what is your opinion on the matter, what is the state of the art in this Matter. a high level SOP/OP of dedicated plan for the product ?

Also what about combining the support plan in the same process /document ? (how long we support the device, guaranteed support/ limited support / decommission & end of service )

 

[shimonv]

From my experience, software maintenance is covered in the SW lifecycle SOP.
Maintenance of the software is handled as a continuation of the software development life cycle.

Shimon

 

[yodon]

Our approach is a high-level SOP (Software Development Life Cycle). This addresses the requirements of the standards (62304) and relative guidance docs (including cybersecurity, by the way). Each product (not software item in a product) has a software development and maintenance plan (with the maintenance plan covering what we do to implement the maintenance requirements for that product).

An SOP at the corporate level would be fine if the maintenance activities are consistent across all products.

I mentioned cybersecurity in passing but I would also point out that cybersecurity monitoring SHOULD be part of your maintenance activities.

 

[Tidge]

I don't think @shimonv is wrong, but I think @yodon is closer to the answer.

The subtle point I'd raise is that generally submissions do not include Quality System SOPs, so even if there is a comprehensive set of SOPs that could be used to address the issue of a specific piece of software's maintenance (I'm imagining inter-related SOPs around things like risk management, change control, complaints/issue systems), I recommend a software-specific PLAN (as mentioned above) that calls out how the maintenance will be considered FOR THAT SOFTWARE, and then include the plan in the submission. This leaves a specific internal hook to check against (during periodic review, triage of issues, updates to the system, whatever).

This may seem like extra step, but the reviewers of the submission aren't going to want to have to audit the quality system, or pay attention if a company revises elements of its quality system SOPs.