When it comes to medical device development, the absence of comprehensive design and development documentation covering all stages of the design of a product, is not just a setback, it can be a permanent barrier to getting to market.
For those serious about developing a medical device that can make it through to launch, giving early consideration to the overall governance of the design elements of your project and how it will be recorded is essential.
This includes creating a functioning system of ‘design controls’ before you begin that will guide, manage and document the progress of your project from ideation to the start of development and beyond.
Why are process controls important in the med dev design industry?
Design controls are a set of management practices used to control the process of design and development of medical devices. They should ensure that your process delivers a blueprint for a safe product, that will function according to documented specifications.
These controls should provide for an iterative design process with regular checks against specifications and relevant regulations, meaning that you can reduce the risks of omission and the amplification of mistakes as you go along.
In fact, this iterative, phased approach is not only best commercial practice, it is a legal requirement. The FDA, the MHRA, ISO 13485 all require that med dev design is undertaken like this, meaning that you cannot legally launch a device in any major market, without proving that you have been working in this way.
Fig 1: Navigating Design Control requirements in the medical device development cycle
3 Reasons You Need to Control and Document your Med Dev Design Processes
1. It’s a requirement of ISO 13485
ISO 13485 is clear about what is expected from a design process:
“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 message is clear, set up your design process so you can review against requirements at regular stages and document that you have done so.
These regular design reviews need to involve key stakeholders who can identify any actions that need to be taken - and all of these details need to be logged so they can be tracked and audited later.
2. It’s a requirement of the FDA and MHRA
The FDA are also in alignment with ISO when it comes to your approach to design.
In order to get to market in the US, the FDA require that the record of your adherence to these processes is logged and stored in a Design History File which contains the following:
- The design and development plan that outlines the design tasks and deliverables
- Documents proving the design was carried out according to that plan
- Activities of the different phases of the design process
- Documentation of design reviews
- Design input and output documents
- Validation documentation
- Copies of controlled design documents and change control records
In the same way, in the EU your Technical File and Design Dossier will need to refer to and link back to your design logs, including the User Requirements and Design Documentation, as well as the ‘history’ of your process to date.
For certain classes of device, your Design Dossier will need to be audited by a notified body before you can be granted the CE mark to launch the product.
Without a fully controlled and documented design process it will be difficult or impossible to get to this stage.
3. It will improve your efficiency and productivity
It’s important to note that imposing design controls on your process is not about ‘jumping through hoops’ or just making life easier for the regulator.
Adopting these controls will also ensure that your business can better manage and keep track of the complex process of requirements gathering and design which medical device development entails.
They can feed into and support a PRINCE2 approach to project management, which in turn ensures a more cooperative and efficient model of design and development overall, halting unprofitable activity early and helping to deliver project phases on time and on budget.
Documenting your design processes properly will also generate an invaluable record of all the decisions you have made and will help you with internal streamlining. These will include the way decisions have been arrived at, as well as the dead-ends you have explored and the mistakes you made along the way. This resource can be used for training and further research, as well to ensure time is not wasted in the future and more efficient processes are developed.
Flexible tools for design control
The good news is there are many solutions available on the market designed to help you administer, track and log the kind of iterative design process outlined above. Digital tools that can help you gather and group documents together around a particular design phase, then seek feedback, changes and approval from specified stakeholders. These tools can help you implement a digital document control process, ensuring that iterations of design documents aren’t released, or further work started, until every team has agreed on their content and direction.
Why design controls come first in medical device dev
The regulatory and quality consultants that we work with, constantly tell us about the device developers they meet who come to them with a prototype already built, but no supporting design documentation to show how they got to that point.
It’s no easy task to backsolve the design compliance requirements of a dev process that has not previously been adhered to. And for medical devices the compliance bar is understandably high. For this reason, depending on how far down the development line you are, it may be too expensive, complex or otherwise unfeasible to do so retrospectively.
For developers with a strong vision for a product and a passion for their solution, there is a strong temptation to ‘get stuck in’ and start building straight away. However, the regulatory environment requires you to take a more measured approach than this, mitigating the risk of failure or making dangerous errors by developing a systematic approach to your design process first.