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 concept to the start of development and beyond.
Design controls are a set of management practices used to control the process of design and development of medical devices. They ensure that your process delivers a blueprint for a safe and effective product, that functions exactly according to documented specifications.
Design controls ensure deliverables are continually checked against specifications and relevant regulations. They are intended to reduce the risks of omission and the amplification of mistakes as you develop your product.
This iterative, phased approach is a regulatory and 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.
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:
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.
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:
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.
But adopting these controls not only helps you meet the regulation, but they can also make you more efficient and productive as an organisation.
Design controls ensure that you are focused only on meeting customer requirements; finding the most effective way to meet their demands and preventing developers from over-delivering and wasting time.
This 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, halting unprofitable activity early on and helping to deliver project phases on time and on budget.
Documenting your design processes generates an invaluable record of all the decisions you have made, helping you solve problems faster. They are a resource that can be used for training and further research, ensuring more efficient processes are developed in the future.
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.
The regulatory and quality consultants that we work with, 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.