A few thoughts on design control

To ensure our safety, regulatory bodies require that medical devices (among other products) not only pass specific test criteria, but that they are also designed, developed, and maintained within a design control program ¹. In some cases this has resulted in rigorously pedantic corporate programs that everybody views as a necessary evil, and in some cases this means that design control isn’t actually used and the documentation is thrown together at the last second to hopefully satisfy the reviewer. It seems to me that the key is to find a balanced approach which realizes the benefits of design control activities without overburdening the engineers who are far more interested in solving problems and innovating. To that end, I have found that understanding the following four points helps me find that balance.

1. Understand the benefits

The design control regulations didn’t appear out of thin air. These were and are distilled from best practices that have been employed by companies who adopted design controls to maximize the quality and success of their products, which ultimately translates into profitable outcomes (regardless of whether you measure profit in monetary or more altruistic terms). We should seek to understand the design control program as a benefit and aid that is worth including in the design and development effort regardless of whether some regulatory body requires it. If the benefits are difficult to recognize, that’s probably a sign that something needs to change.

2. Understand the scope of the regulations and standards

Despite what is sometimes implied, the design control regulations and standards are not impenetrable walls of legal jargon. They’re typically fairly readable and intentionally vague (yes, there is no shortage of exceptions). The goal is not to make everybody conduct their design efforts according to the exact same process; the goal is to get everybody achieving quality (i.e., safe and effective products) in whatever way works best for your team and project.

After reviewing the design control mandates, you may discover that the pedantic process your company has been using goes far beyond what is actually required. It probably got that way by accumulating incremental changes in response to investigations and audit findings, coupled with a fear of breaking something by making a change. There may very well be value and good reason for some of those elements in your program, but I’ve come to realize that we also shouldn’t be afraid to question that assumption and “refactor” when it makes sense. The design control program, as part of the overall quality system, is included in the goal of continuous improvement – and sometimes improvement comes by streamlining or simplifying.²

3. Understand the opportunities for integration

Nobody ever said that everything has to live in Word documents instead of residing a database with relational links, or that your software design descriptions can’t be extracted from your self-documenting code, or that your junior engineer can’t contribute to the design outputs as a natural consequence of doing their job. In the internet age, it is not difficult to find ways to incorporate easy and accessible tools which integrate the design control activities into the engineering workflow – whether that be a PLM suite or just a fancy spreadsheet.

Even so, there will still be a need for good old fashioned documents. But documents can also be an easy to use and accessible tool. Instead of having your design control program just prescribe the creation of a document with some obtuse description and list of what it should contain, take the best examples of that kind of document, along with the knowledge of how the document relates to the regulations, standards, and the design control program as a whole, and build a template that include examples, questions, explanations, and suggestions that guide the author through the construction of the content. Then the design control procedure can just say something like “use the attached template to create Document X”.

4. Understand the big picture

As I see it, the traceability matrix is the centerpiece of a design control program. It ties everything together, and it’s useful to start with this perspective when working with the design control program. Instead of seeing the section headers of the regulations and standards as individual silos to be addressed separately, identify the relationships between risk management, requirements, verification, usability, etc… and structure the program to exploit those relationships by eliminating redundancy and encouraging integration between related elements. For example, the medical device usability standard IEC 62366-1 requires establishing a user interface specification. Instead of building out an entirely separate document, you could just add a field to your requirements specification database for “user interface”. Now you have a user interface specification by just filtering your requirements database to entries where “user interface” field isn’t blank.³

In the end…

if a development effort is going to comply with the regulations and standards, we’re going to need documents and formal processes. But a design control program shouldn’t be a burden or an afterthought. I have found that if we embrace the benefits of the regulations and standards, focus on building processes that help the engineers do their job, and avoid redundant documentation and over-burdensome practices, the program can be an asset for guiding the successful development of safe and effective products.

1. See FDA CFR 820.30 and ISO 13485 § 7.3
2. Adding footnotes to explain why something is important, or cross-references to standards, guidances, and regulations can help avoid regressive changes.
3. The standard explicitly allows for this when it says “the USER INTERFACE SPECIFICATION may be integrated into other specifications”.