Eight Reasons Why Your Design Controls and Risk Management Processes Fail

Embrace the total product life cycle

Published: Tuesday, July 5, 2016 - 17:01

Design controls and risk management processes should be tools to ensure that medical devices are designed, developed, and manufactured to be safe and effective, and to address indications for use, too.

All too often, however, design controls and risk management are viewed as a pile of “stuff” that the U.S. Food and Drug Administration (FDA) and other regulatory bodies require during the design and development process.

The FDA design control regulations have now been in place for 20 years. They should be aids to guide medical technology professionals, but an overwhelming percentage of the medical device community approaches these activities as checkbox, low value-adding tasks.

Year after year, design control deficiencies rank as the single biggest reason medical device companies receive form FDA 483 observations; such deficiencies also rank in the top three reasons for warning letters.

Despite “risk management” only being officially cited as part of 820.30(g)—“Design validation,” the FDA requires medical device companies to implement risk management processes to analyze, evaluate, assess, and control risks throughout the entire product life cycle.

In fact, according to 2015 FDA data, 32 percent of design control form 483 observations and 27 percent of design control warning letter citations relate to 820.30(g).

Most, if not all, of the above FDA actions were avoidable. Let’s dive deeper into eight reasons why your design controls and risk management processes may be failing, and discuss what you can do about it.

1. Poorly defined product development processes

A medical device product development process must establish the major stages, deliverables, and milestones from project initiation through market launch. Design controls and product risk management should be integrated within that development process.

However, medical technology companies commonly err in one direction or another during product development, making the process too detailed and overly burdensome, or too vague (or maybe not defined at all).

The overly burdensome process is difficult to follow. Too many tasks and actions are required. Following a lengthy, detailed process often presents numerous opportunities for nonconformances and increases risks for noncompliances. The vaguely defined process is also problematic. Lack of clearly defined stages and deliverables leads to possible nonconformances and noncompliances with regulatory expectations.

Your product development process needs to be “right-sized,” according to the type and size of your company, as well as the types of medical devices you design and develop. Use 21 CFR 820.30 and ISO 13485 (section 7.3) as guides to determine minimum design control deliverables requirements.

Use the requirements of ISO 14971 to identify minimum risk management requirements. Then, build your product development process around the design controls and risk management requirements you've defined.

If your company has additional business needs, add these to your process, erring on the side of minimal deliverables.

2. Poor understanding of user needs

Medical device development often is triggered by a desire to address unmet clinical needs, or to improve upon current treatment options. Identifying a clinical issue to solve lays the groundwork for defining intended use and indications for use for your medical device.

Often, a prototype is involved in the process at this stage, used to help further define and articulate user needs. For many product development engineers, this early discovery is one of the most thrilling parts of the medical device process—so much so that it is common to go full speed ahead once the prototype seems to be sufficient and satisfactory, even though the end-user’s needs may not be fully understood.

But who is the “end-user?” Is it the patient? Is it the clinician? Usually, the answers to these questions is “yes”; however, these are the easy users to identify. Are there other users, though? Typically, yes. End-users can include distributors, doctors, nurses, biomed technicians, patients, patient caregivers, reprocessing personnel, and so on.

Consider all the steps that occur between a medical device leaving your facility, through point of use, and ending when the product is no longer in use. Each end-user likely has a list of needs, each of which you need to document. User needs feed the design and development process and are the precursor to establishing your device’s design input requirements.

3. Too little time spent defining design inputs

Design inputs are the most important part of product development, establishing the foundation of a medical device.

Often, there is a rush to get through the design inputs stage so that additional prototypes can be built, tested, etc. I get it. Just about every product development project I have ever worked on had the target completion date defined before the project ever officially began, so getting everything done sometimes seemed to take precedence.

But design inputs are a continuation of user needs, as well as a precursor to design verification. When defining design inputs, you need to consider exactly how the design outputs will confirm that design inputs have been met. By rushing through design inputs, you risk producing requirements that are not readily verifiable.

To avoid this scenario, use your desire to prototype to your advantage. Mini-tests or experiments performed with your prototypes can help determine how to verify.

4. Starting risk management too late

Many medical device product developers engage in formal product risk-management activities way too late in the process. The right time to start documenting risk management activities is when you are defining user needs and design inputs, so that identified risks can guide those requirements, as well as improve your ability to manage design verification and validation.

Understanding possible hazards, hazardous situations, and possible harms will help you improve your medical device design. By incorporating risk management earlier, you will be able to leverage later-stage product development activities, such as design verification and validation, to support risk-based decision-making regarding product development.

5. Poor design reviews

Design reviews are important opportunities, conducted at appropriate stages throughout product development, to assess progress with respect to overall product design and development.

Design reviews should be constructive and introspective, and design-control activities should be included and reviewed. Design review attendees should vary, depending on the design review’s focus during a particular development stage. Common design review mistakes include a lack of review documentation, failure to represent all appropriate functional areas, and/or omission of objective evidence verifying that action items identified during design reviews have been completed.

Another common issue is trying to cram too much into a single design review. Although this technically might be considered acceptable (provided it aligns with your design and development plan), a design review that includes too many design controls and product development stages is likely to add little overall value and be ineffective. Plus, more information included within a design review will correlate to a longer meeting and more action items.

I recommend having more frequent design reviews, each focusing on a finite set of information, and trying to limit your design review to under an hour.

6. Design verification misses the mark

Design verification will only be as good as the design input requirements. Although that connection is clear, keep in mind that design outputs also contribute to successful design verification.

Design verification demonstrates that the design outputs meet the design inputs, serving as proof that you designed your product correctly. Your design verification acceptance criteria may be captured as part of design outputs or inputs, and you must ensure that acceptance criteria have been defined before conducting verification.

Finally, testing is considered to be synonymous with design verification. Although testing is an acceptable method for conducting design verification, so are inspection and analysis.

7. Design validation is ineffective

Design validation should demonstrate that the medical device meets the needs of the end-user, who must be clearly defined and identified. Failure to do so can lead to design validation that is haphazard and misses the mark.

Furthermore, design validation needs to involve those end-users, and products built for design validation need to be from production-equivalent materials and processes.

8. Poor design change practices

Chances are, your medical device product will change. The design may change, or the manufacturing processes may change. If so, you need to document these changes and ensure that the design controls are updated accordingly. Additionally, you likely will need to have design reviews for the changes.

Even after the medical device is transferred to production, changes may continue to happen, making design controls a continuous process.

Sometimes, this is not clear: Conventional wisdom states that design controls are a set of historical records describing design and development, and then archived after design transfer. But any changes you make to a medical device in production or post-production require design controls.

You also need to determine if verification and/or validation is required for your design change, as well as evaluate the effect on user needs and design inputs. The design outputs you established during product development now become the basis of the product device master record.

Thus, design controls are a continuous, total-product life cycle process. As the medical device world continues to move toward risk-based approaches regarding quality management systems, I would expect there to be more scrutiny when it comes to product life cycle risk management, too. By keeping these two ideals at the forefront of your product development process, you both insulate yourself from regulatory repercussions and better your chances of market success.

First published June 20, 2016, on the greenlight.guru blog.

About The Author

Jon Speer

Jon Speer is the founder and vice president of quality assurance and regulatory affairs at Greenlight Guru, a software company that produces the only medical device quality management software solution. Device makers in more than 50 countries use Greenlight Guru to get safer products to market faster. Speer has served more than 20 years in the medical device industry and helped dozens of devices get to market. As a thought leader and speaker, he regularly contributes to numerous industry publications. He is also the host of Global Medical Device Podcast.