The regulatory requirements for medical device design and development planning can be found in 7.3.2 of ISO 13485 and FDA 21 CFR Part 820.30 (b).
7.3.2 of ISO 13485:2016 states:
The organization shall plan and control the design and development of a product. As appropriate, design and development planning documents shall be maintained and updated as the design and development progresses.
During design and development planning, the organization shall document:
a) the design and development stages;
b) the review(s) needed at each design and development stage;
c) the verification, validation, and design transfer activities that are appropriate at each design and development stage;
d) the responsibilities and authorities for design and development;
e) the methods to ensure traceability of design and development outputs to design and development inputs;
f) the resources needed, including necessary competence of personnel.
While FDA 21 CFR PART 820.30, also shows how planning is a vital part of establishing required design controls:
Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed, updated, and approved as design and development evolves.
But there are other planning requirements in ISO 13485 which specify how you should prepare to realise the product, in order to minimize the risk of product failure.
7.1 states:
7.1 Planning of product realization
The organization shall plan and develop the processes needed for product realization. Planning of product realization shall be consistent with the requirements of the other processes of the quality management system.
The organization shall document one or more processes for risk management in product realization. Records of risk management activities shall be maintained (see 4.2.5).
In planning product realization, the organization shall determine the following, as appropriate:
a) quality objectives and requirements for the product;
b) the need to establish processes and documents (see 4.2.4) and to provide resources specific to the product, including infrastructure and work environment;
c) required verification, validation, monitoring, measurement, inspection and test, handling, storage, distribution and traceability activities specific to the product together with the criteria for product acceptance;
d) records needed to provide evidence that the realization processes and resulting product meet requirements (see 4.2.5).
The output of this planning shall be documented in a form suitable for the organization’s method of operations.
The design and development plan should indicate how all required risk management activities related to the:
will be integrated into the product realisation process.
When you’re putting together your plans, there’s no regulatory requirement to show expected delivery dates or create Gantt charts with timelines - although, clearly, businesses will want a schedule of some kind to refer to.
In fact, what’s notable about these requirements is that they are often light on detail about format - they are agnostic about how activities and duties should be listed or presented - only saying that they should be documented and regularly updated. This gives businesses the scope to create a plan that fits their way of working and they can shape with the specific digital tools they like to use.
As it states in ISO 13485 7.1:
The output of this planning shall be documented in a form suitable for the organization’s method of operations.
Because the plan can only really be an effective organisational and risk management tool if it is a shared repository of planning information that everyone in the business can understand and refer to.
A good graphical document management system can help you achieve this. It can help you build out highly visual and dynamic plans defining the phases you need to go through and the way design controls should be implemented throughout the process.
It’s been said that a design and development plan really needs to work like a narrative. You should be able to read it and understand:
We would argue that if that narrative can be ‘visualised’ then the plan will be easier to grasp and follow. And if the tasks listed in the plan dynamically link to specific documentation and workflows within a DMS then it will naturally help implement the ‘controls’ that it specifies.
The plan should show you the distinct stages of your design and development process. A good eQMS will let you create a visualisation of these phases and list the tasks, outputs and documentation that need to be completed within each stage, before it can be marked as ‘done’.
The regulation requires that the completion of each phase should end with the review of documentation to check that it has all been completed according to plan. As it states in ISO 13485:
“At suitable stages, systematic reviews of design and development shall be performed in accordance with planned and documented arrangements to:
a) evaluate the ability of the results of design and development to meet requirements;
b) identify and propose necessary actions. Participants in such reviews shall include representatives of functions concerned with the design and development stage being reviewed, as well as other specialist personnel. Records of the results of the reviews and any necessary actions shall be maintained and include the identification of the design under review, the participants involved and the date of the review.
The plan needs to show which teams and which people in those teams are responsible for delivering each part of the plan - plus also what resources they will require to do so.
In a graphical eQMS can you create a plan that shows the tasks that each team/team member will responsible for. It was also let you list the output they will need to deliver. You can group the tasks and documentation they will need to complete together in the plan. You can dynamically link to templates relevant documents in the document management system, that will be populated as the process continues. When each set of required documentation is finalised, reviewed and approved they can be shown as complete in the plan.
The plan should show the order in which activities need to take place, including defining contingencies. Doing this in a visual way can help you clearly see team and time dependencies.
Design controls are the most important aspect of any medical device build. They ensure you work in a cycle of ‘plan, act, do, check’, and then record evidence that you have done so.
In the design and development cycle, controls ensure ‘design outputs’ match the ‘inputs’ - for example that you have:
The plan should reflect those activities and demonstrate where the ‘breaks in the circuit’ happen to implement those reviews.
This will demonstrate how you contain the risk of failure and mistakes in your designs and product realisations by the application of a structured sequence of reviews.
A medical device plan is not a set-and-forget activity. A plan needs to be a living document because your plans will inevitably change as you go along - particularly as some devices take several years to complete.
Make sure you choose a QMS robust enough to clearly document and visualise the tasks, goals and objectives that will define the project, but one flexible enough to update easily to ensure it’s an accurate reflection of what the project is going to deliver.
As the plan will be scrutinised by the regulator as part of your design history, it needs to show that what you intended to deliver was delivered.
The eQMS can prompt you to update a plan when changes to specific documents are made - but it can also record changes you make, the reasons for those changes and archive previous iterations so you can explain all your decision-making to the regulator if you need to.
Last updated on 08/11/2022