What is the expected process you should follow for your medical device design planning and controls?
This is an area that often doesn’t get enough attention early on in a design and development project. Many companies miss the mark when it comes to their documentation and overall approach of it.
In this article I'll address design planning, the associated regulatory requirements, and how proper planning should be carried out to control the design of your medical device.
basics of Design planning
The purpose of design planning is to identify what needs to be done in your project, who needs to do it, and when it needs to be done. Your design plan should be treated as an ongoing activity that is monitored closely over time as your medical device progresses through the various lifecycle stages.
The most effective way to execute on the plan you put together is to have a clear understanding of the clinical needs your product intends to solve; in other words, the user needs of your medical device. From here you can establish a solid design plan for your medical device.
Many medical device professionals believe “planning” is simply about following a timeline or Gantt Chart, an approach that has become more and more common in design and development planning for medical devices.
The issue that crops up with such an approach is that the Gantt chart is now so commonplace that many companies will ONLY produce a chart, then assume they’ve fulfilled the design planning regulatory requirements. However, this is not the case — if you read through the guidelines, there is no mention of needing to produce a timeline or schedule at all.
What are the regulatory expectations for design planning?
The key regulatory requirements of medical device design and development planning can be found in section 7.3.2 of ISO 13485, the international quality management system standard for medical devices, and FDA 21 CFR Part 820.30 (b), the quality system regulation for medical devices.
Let's take a closer look at the specific guidelines outlined in each...
ISO 13485:2016 7.3.2 — Design and development planning
The requirements for design and development planning found under subsection 7.3.2 of ISO 13485:2016 are outlined as follows:
The organization shall plan and control the design and development of 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.
FDA 21 CFR Part 820.30 — Design and development planning
All medical devices marketed in the United States must comply with the requirements of (b) Design and development planning under Subpart C — Design Controls from FDA in 21 CFR Part 820 referenced here:
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.
As you can see, the ISO standard has slightly more information than the FDA regulation, but neither have an extensive amount of specific criteria. Perhaps this is one reason why there is often a lot of confusion on the topic of design planning and what this must entail.
There are a couple of key points derived from these requirements that a design plan must include:
A design plan must describe how Groups or activities will interface
A project has a lot of resources and you need to define your team. It’s widely accepted that you must define your core team and the different functional areas required (e.g. marketing, engineering). You need to describe how each of these core functions will interact with one another throughout the design and development of your medical device, as outlined in Part 820.30.
The good news is, while the wording in 21 CFR Part 820.30 (b) and ISO 13485 7.3.2 is not exactly the same, the intent behind the two of them is very much in-sync. Everything that one says is more or less defined in the other.
A design plan must define all activities that will take place throughout a project
This is often where companies will utilize the Gantt chart as a tool for defining such activities, but you also need to define the persons responsible. Scheduling is important and valuable, but remember there’s more to it. Look at it as defining the who from a resource and functional group standpoint, the what in terms of major activities and persons responsible for carrying out those activities.
Your design plan must reflect compliance with the design controls process and should be included as part of your design history file (DHF). Your completed DHF reflects compliance with the design controls requirements and your design plan.
An industry best practice is to construct a traceability matrix showing full visibility into all design control linkages that occur throughout a project. In addition to being a best practice, traceability is a requirement of ISO 13485:2016. Implementing a best-in-class QMS solution that's built to meet the unique regulatory needs of a medical device company can result in significant gains in design planning speed, while also reducing overall risk.
your design plan Narrative
A good way to think of your design plan is as a narrative — a document you could hand to someone for them to read and understand the story of your product. It should tell them about key milestones, what will be required to reach those, and who will be involved in that process.
Another key part of the narrative is when and how often you will conduct design reviews. This will be dependent on the scope and complexity of your medical device project. A schedule is important for you to run an effective project - but does FDA care about your schedule? Probably not. I’ve never seen an FDA inspector look over a schedule and comment that certain target dates were missed.
The important piece, from a regulatory perspective, is that you’re doing what you said you were going to do when you said you would do it. For example, if you said you were going to run a clinical study, but before you do that you need to run safety testing, then that would be the set expectation.
You should carry out these activities the same way you've described them in your design plan. If you suddenly decide not to run the clinical study and didn’t update your plan, that’s where companies often run into trouble. From a regulatory position, it could be assumed that the company was cutting corners and lead inspectors to take a closer look.
Whether you take a phased-based approach, commonly referred to as "waterfall" or use an agile methodology for a more complex device, your plan will be reflective of whichever methodology you choose. There’s no must-follow method, as long as you are demonstrating design and development planning as defined by FDA and ISO, as well as documenting what is required.
Treat your design plan as a living document
A common mistake made by many companies is treating the design plan as “one and done” activity. These companies compile their plan at the beginning of a project just to “satisfy a requirement,” but it's not kept up-to-date throughout the subsequent stages of the project.
In most cases, you tend to discover a lot of things as your project progresses. For example, a project might take three years to get to the point of market clearance — how many design changes might have occurred over that period of time? The point being that if you were to write up a plan at the beginning and leave it, it wouldn't take long before it becomes outdated and thus, inaccurate.
This is a common pitfall that companies will fall into when planning their design with tools, like Gantt Charts. I’ve worked on projects before where there were hundreds of line items on a Gantt Chart. We would spend a lot of time early in the project defining items, only for them to be wrong the minute we published the chart.
I recommend revisiting your design plan whenever you reach the end of a phase in your project in order to include additional details that are specific to the next phase you'll be entering. As such, an effective design plan evolves throughout the project.
It’s important to understand and define the key objectives that you are trying to accomplish and how they relate to one another. My approach is to define key objectives and work backwards to the current stage of the project. You could look at these milestones as chapters, developing the narrative of the story as you progress.
It's impossible to try to understand every possible thing that could happen right from the beginning. It’s okay for details to be fuzzy for later chapters that aren't yet applicable to where you're at in your story.
Depending on which approach you're using for your design and development, those following an agile methodology should be pretty clear about the next sprint that lies ahead. If you’re doing a phase or stage-based approach, you should be clear about that next phase you’re heading into, as well.
Just remember, however, if you’re only focusing on the schedule part of a plan, as so many companies do, you’re missing the bigger narrative you should be aiming to tell.
design Planning should be right-sized to your own processes
Design planning is one of those areas that can never be a “one size fits all.” The ultimate measure of how well your design and development is progressing or being addressed will come down to the contents of your design history file and the amount of traceability you're able to show between processes. Whether you operate as agile or in stages, there will always be a need to monitor, measure, and connect your design and development processes.
This is where the total lifecycle traceability capabilities of Greenlight Guru's QMS software can help medical device companies track and manage all major milestones and the subsequent activities that occur within a project, allowing product development teams to easily and successfully design, develop, and produce a True Quality medical device.
Looking for a design control solution to help you bring safer medical devices to market faster with less risk? Click here to take a quick tour of Greenlight Guru's Medical Device QMS software g