Using Design Controls to Undermine Medical Device Development – Part 2

Excellent design control procedures won’t guarantee that your project will be successful, but bad design controls will guarantee that everything will take more effort and more time throughout development (like driving through deep mud). In this blog post, I’ll continue the list I started in the previous post on some specific ways we undermine good product development with poorly designed or misapplied design control procedures

Forcing a Linear Development Sequence

“We love waterfalls!”

First up: forcing a linear development sequence or “waterfall” approach for new product development. Design controls are typically presented as a waterfall-ish diagram, but that shouldn’t be your blueprint for new product development.

 

Many people interpret diagrams like this one to mean that a product team should first gather User Needs, then define the Design Inputs, then design the medical device, and then document the Design Outputs, etc. The reality of developing an innovative new medical device is quite different and involves many iterations and some false paths. Forcing a linear, waterfall approach on product teams is typically counterproductive. For example, if your design control procedures demand a completed, released Product Requirements document upfront before design work begins, then product teams are forced to make key decisions early in development without sufficient information. It may feel reassuring to release the Product Requirements early, but that official-looking document can easily create an illusion of confidence, masking many unknowns in the product definition. In reaction, some product teams may defer design controls altogether until after most of the development is complete (at that point, it’s straightforward to write Product Requirements, but this defeats the purpose of Design Inputs driving development).

The primary job of the product team early in development is learning. There are always knowledge gaps in new product development that must be investigated and resolved. This should be the focus of the team until the knowledge gaps are closed. Postponing learning leads to expensive changes late in development (or worse, to recalls after product launch). Design control procedures should provide sufficient flexibility on the front end to support rapid learning with many design iterations, while still ensuring rigorous controls for the final device. For more information on this learning-first paradigm, see Two Mindsets for Successful Product Development.

Design Transfer is another area where a linear, waterfall approach to development will undermine product teams. Design Transfer of a new medical device involves the coordination of many complex tasks involving multiple groups in the organization: selecting and qualifying suppliers, designing manufacturing processes and equipment, training manufacturing staff, etc. This takes a long time, even for very experienced professionals. Many design control procedures describe Design Transfer as a phase at the end of development (e.g., “Phase 5 – Design Transfer” out of 6 phases). Presenting Design Transfer this way implies that we should start work on manufacturing after all product development work is completed. The reality is that product teams must consider manufacturing and supply chain issues throughout development. Design Transfer activities should occur throughout development to optimize the design for manufacturing (modifying designs as needed to match production capabilities and minimize costs) and to avoid huge delays at the end of development. If the design control procedures treat Design Transfer as a phase at the end of the project, then manufacturing resources may only be allocated at that point, losing many months of preparation time in developing suppliers and robust manufacturing processes.

Follow the Plan No Matter What

“Who said you could make changes?”

Design controls are intended to ensure that development projects result in a medical device that is safe and effective. But they cannot eliminate uncertainty in development. Developing a new medical device always involves many unknowns. In contrast, design control procedures are often written as though we can know and plan everything needed from the beginning of development. This leads to spending a lot of time up front in creating very detailed plans and requiring excessive effort by product teams to deviate from those plans. The philosophy seems to be that any problems encountered during new product development must be due to insufficient planning.

In my experience, new product development never goes according to plan. That doesn’t mean we shouldn’t plan. It means that at the beginning of a project, we should understand that we have incomplete knowledge and that we will need to adjust and adapt as the project proceeds. For example, at the beginning of a project, we can know whether or not a clinical study will be required or whether sterilization validation will be needed. But we cannot know whether a new battery technology from a new supplier will work successfully in the product or whether users will like the first UI design (or the redesign of the UI, or the re-redesign of the UI). Therefore, we want planning to be high-level, and make sure design control procedures are flexible enough to to accommodate many changes along the path to product launch smoothly. This includes keeping the cost of change minimal in early development, where rapid iterations are needed to converge on a successful product design (later stages of development need more robust change control).

Years ago, when I was starting work with a new client, one of their senior engineers showed me their newly developed medical device and pointed out some known design flaws. I asked when they would be fixed and he said they wouldn’t be because it would be too much paperwork! Their design control procedures were so intricate and cumbersome that they ended up preventing corrections to design flaws (change prevention instead of change control).

Procedures Intended for Products that Never Change

“Stop complaining! We only have to do this once.”

As a consultant, I’m often brought in to fix problems with DHF documentation, so I’ve learned to take a longer-term view of how design controls operate and how the resulting DHF documentation is structured. An approach that may have seemed OK during initial product development can result in many problems (and audit findings) years later after many changes and upgrades to the medical device. For example, recording the same information in multiple documents or including excessive cross-references within a document will make them harder to maintain. These DHF documents may all be correct at the initial launch of version 1.0 of the medical device, but they are likely to grow outdated and inconsistent years later after multiple upgrades (which is just about the time an auditor starts going through them).

Re-entrant Design Controls: For capital equipment and any medical device with software, I recommend structuring the design control procedures to support multiple upgrades during the life of the product. This means clear processes to follow for a team making a product upgrade, describing whether a subset of design controls apply (for a minor upgrade) or all design controls apply (for a major upgrade). This also means good document management for long-term record retrieval. Defining when to revise an existing DHF document and when to create a new document during an upgrade project. And making sure that even after 6-8 years it’s still clear which DHF records apply to which versions of the product.

Ambiguous Procedures

“What’s needed is what I say is needed.”

Of all the problems I’ve seen over the years with design controls, perhaps the worst is when the procedures are written ambiguously. Whether this is done intentionally or not, I can’t tell, but the result is that it’s up to the Head of Quality to decide what’s ultimately required for each development project. This leads to repeated arguments, lots of unnecessary meetings, and a feeling amongst the product team that compliance is just an arbitrary game. And what happens if that person leaves the company and is replaced by someone else? Does that mean there’s a different set of design control requirements that the product team needs to follow? Good design control procedures should provide appropriate flexibility to product teams but must always be crystal clear about the process and the requirements the teams must fulfill.

Conclusion

The development of a new medical device is too important to be undermined by poorly designed or mismatched design controls! Keep in mind these considerations when revising or re-writing design control procedures:

• Fundamentally, design controls should be focused on the activities and controls for producing safe and effective medical devices. Releasing a complete set of DHF documents is not the same as releasing a safe and effective medical device. Don’t define design controls just by the documentation produced.
• Avoid falling into the “checklist mentality.” Checklists can be useful, but the development of new medical devices is way too challenging and varied to be reduced just to a checklist of tasks or documents. Every product development project will be unique.
• Learning first, then implementation: It’s tempting to think that completing design control phases and releasing the required DHF documentation shows the product team’s progress but this can easily mask some serious problems that will blow up later if not resolved. Focus on closing those knowledge gaps and then the remaining work will be predictable.
• Clarity and alignment: The design control processes and the resulting design control documentation should be clear to all the stakeholders. Everyone involved needs to understand and agree on the processes.

It’s hard work to modify quality system procedures, but even small changes to SOPs can have a big effect if you analyze your processes carefully. And you don’t have to tear down everything and start over to make significant improvements. Help your product teams to get out of the mud and drive rapidly to product launch!