ISO 13485:2016 – Clause 7.3.2 (Design Planning & Reviews) for MDSW

[sana7]

Hi everyone,

We are a manufacturer of Medical Device Software (MDSW). During a recent internal audit, we received a NC related to clause 7.3.2 – Design and Development Planning, specifically points b) and f). The auditor stated that: “The design planning does not include the necessary revisions at each stage of the design, nor the necessary resources (including, if applicable, the necessary competence of personnel).”

In our current system we have a Software Development Plan of the MDSW that includes a planning of each stage (its task, description, deliverables, responsible and estimated completion date), we perform design reviews at different stages (stk requirements, sw requirements, architecture...) which are documented within the TD, and we also maintain a project follow-up that covers initial development phases and releases of new versions including tasks, deliverables, participants, completed and pending actions.

However, the auditor's expectation seems to be that the SW development plan itself should explicitly include planned design reviews per each stage with the resources required for each stage (roles and maybe tools?), and a clearer planning of 'reviews', not only evidence that reviews happened elsewhere. In other words, although reviews are performed and documented, they are not clearly planned and linked to stages within the development plan (from what I understood).

1. How do you practically implement clause 7.3.2 for MDSW? Do you explicitly list the planned reviews in the development plan? For example, adding a review phase at the end of each stage?
2. When ISO 13485 refers to 'necessary resources', how far do you go? Is it generally sufficient to reference the roles and tools without detailing individual competencies already covered by HR/training procedures?
3. For those using Agile, how do you align iterative development (sprints, backlogs) with the requirement for design planning and staged reviews? Do you schedule formal design reviews at each stage (e.g., within every sprint), or do you map Agile ceremonies and sprint outputs to the design stages and required reviews retrospectively before release?

Our goal is not to over-document, but to make the planning intent of 7.3.2 clearer and defensible.

Any practical examples or approaches would be greatly appreciated. Thanks in advance!

 

[Ed Panek]

The NC reads like a format preference, not a true 7.3.2 gap. ISO 13485 does not require planning, planned reviews, and competence details to live in one Software Development Plan. It requires they are planned, controlled, maintained, and evidenced, which you already show across controlled procedures, the SDP, TD records, and project follow up.

Also, duplicating official content across multiple documents is bad practice. It creates two sources that can drift when one is updated and the other is not. Referencing the controlled source is valid and stronger because it preserves a single source of truth under change control.

The expectation that everything must be in one document for convenience is not a requirement of the standard.

 

[Tidge]

Hi everyone,

We are a manufacturer of Medical Device Software (MDSW). During a recent internal audit, we received a NC related to clause 7.3.2 – Design and Development Planning, specifically points b) and f). The auditor stated that: “The design planning does not include the necessary revisions at each stage of the design, nor the necessary resources (including, if applicable, the necessary competence of personnel).”

In our current system we have a Software Development Plan of the MDSW that includes a planning of each stage (its task, description, deliverables, responsible and estimated completion date), we perform design reviews at different stages (stk requirements, sw requirements, architecture...) which are documented within the TD, and we also maintain a project follow-up that covers initial development phases and releases of new versions including tasks, deliverables, participants, completed and pending actions.

However, the auditor's expectation seems to be that the SW development plan itself should explicitly include planned design reviews per each stage with the resources required for each stage (roles and maybe tools?), and a clearer planning of 'reviews', not only evidence that reviews happened elsewhere. In other words, although reviews are performed and documented, they are not clearly planned and linked to stages within the development plan (from what I understood).

It is quite important IMO to completely understand the auditor's concern... they should have provided an explicit example of the deficiency that will best help you address the NC (or challenge it).

I've typically had an overall SW development plan that sounds like what you describe. I have named individuals (generally) responsible for the activities, but I don't go into fine detail. I've also included a list of specific software tools we expect to use... this may be overkill but it is useful for planning, as well as making sure the tools are fit for their intended use.

The part about "necessary revisions at each stage" confuses me, at least as far as planning goes. Two (different) potential issues come to mind:

1. You may need to be explicit (in the plan) to state which (QMS) process documents you will use; when it comes time to use them if they have been updated then the plan needs to be updated and/or the revision (to the QMS process docs) needs to be accounted for at that point in the Software Development Process. I've explicitly checked at the phase reviews to make sure that nothing shifted under our feet that we missed.
2. The Software Development artifacts may be missing references to revisions (requirements, software versions, protocols, reviews, fishcakes); and if the plan doesn't explicitly call out this practice... the planning is deficient.

3. For those using Agile, how do you align iterative development (sprints, backlogs) with the requirement for design planning and staged reviews? Do you schedule formal design reviews at each stage (e.g., within every sprint), or do you map Agile ceremonies and sprint outputs to the design stages and required reviews retrospectively before release?

62304 does not forbid Agile development, but it does require a gated approach to software development. This is because subsequent elements of the 62304 "development vee" require approved/actionable predecessors... e.g. no meaningful verification can be done without approved requirements.

The practicality for Agile development is to restrict work to well-defined areas, with well-defined inputs to the "agile" work. Segregation via the architecture is very useful here. I've had to direct programmers with "this is the requirement, this is the ONLY part of the code where you are to work, this is how we judge this part to be done."

Some folks interpret Agile as meaning "we won't have requirements until we have code", which isn't great, but it does mean that the code can't been formally verified... or that the final product can be validated. Working without requirements is generally a sign of a poorly planned project.