Main Reasons for Design Control and Risk Management Failures (Part 3)

This is the third installment of a series of posts that address the main reasons design control and risk management failures. 

First, let’s continue to highlight Jon Speer’s article.  In summary, his final 3 of the 8 reasons for DC and RM process fails are:

6.       Design Verification Misses the Mark — “Design verification will only be as good as the design input requirements. While that connection is clear, keep in mind that design outputs also contribute to successful design verification.  Finally, testing is considered to be synonymous with design verification. While testing is an acceptable method for conducting design verification, so are inspection and analysis.”  Without good requirements you are starting behind the 8 ball.  I would also add that design verification should adequately challenge the design.  It should not just be an exercise we complete to get out the door.  All throughout the design and development lifecycle we should challenge and learn about the design to ensure it is robust in the use environment.  If it is not good, I want to know as early as possible.  Worst cases, design windows and main factors should be well understood as well as the use environment.

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.”  I still find people that believe that design validation is a repeat of design verification but with a different user.  In design verification we assess if design outputs can adequately satisfy the inputs.  However, in design validation we are assessing whether the design meets the user needs or did we solve the problem as we have defined it. 

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 it 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 / post-production require design controls.”  It is imperative that people executing design changes understand the design and its intent well so they can adequately evaluate the impact of a design change.  The deliverables generated through the PDP process, design transfer deliverables and good product knowledge are required to execute this.

In addition to the reasons laid out by Jon Speer in his great article I believe there are key drivers that undermine great design control, product development and risk management execution.  These drivers are the following:

• ·         Chasing the short-term timeline vs the real customer driven goals – Moving forward from concept into design control without understanding New, Unique or Different (NUDs) items before leaving concept work.  We can fix it on the next stage.
• ·         Chasing the immediate instead of total lifecycle costs – Not addressing manufacturability issues or service issues during development to get out into the market faster because they will be addressed by the respective functions later.
• ·         Right resource not being available at the right time – For example No clinical representation during user needs and risk management but only at the end when the risk benefit analysis is done or blitzing projects during the second half to meet the timelines instead of putting adequate resources to do the work needed up front at the right stage.

Research has shown when these drivers are present, they produce a stable PDP solution that short changes all projects.  Meaning this not only is suboptimal for your project but almost dooms the next project to the same fate.  How many of you have been part of that massive effort to limp out the door on time only to find the issues that were supposedly solved or even others generated by fixes coming up when the product launches.

In the final; installment I want to spend some time delving into these drivers and conclude with some ways forward that will help more effective and efficient execution.

Main Reasons for Design Control and Risk Management Failures (Part 2)

This is the second part of a series of posts that will address the main reasons design control and risk management failures. 

First, let’s highlight Jon Speer’s article.  In summary his 8 reasons for DC and RM process fails are:

1.       Poorly defined Product Development Process – Jon states that, “A medical device product development process needs to 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, medtech 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).” In other words, too detailed and you risk the process being too burdensome or too vague and then the process is not helpful.  The PDP needs to be right sized to the products it serves.  I would add here it needs to work in the culture of your organization, resourcing levels and approaches and with the established QMS.  The output of the design process is an input to your QMS and will need to work with it.

2.       Poor understanding of user needs – Jon states 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.”  In addition, as engineers we are naturally inclined to build something so work steers to prototyping and if anything is documented it will be engineering requirements not user needs.  The natural tendency is to describe the prototype that may or may not achieve what the customer needs.  Customers hire our products to do jobs and enable them to accomplish end states.  It is paramount we first understand what those jobs and end states are before we go solve the problem.  The problem needs definition before it’s solved or we may be solving the wrong problem or one that does not exist.  This is the biggest cause of developed products that do not sell as expected.  The problem was not well understood or defined.  We end up with a technical solution looking for a problem, not a solved problem.

3.       Too Little Time Spent Defining Design Inputs — Jon states that, “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.”  I agree here FDA state it is not uncommon to spend 30% of your time in the design input stage.  I would add to that the following, getting things done must go hand in hand with doing the right thing.  As mentioned above solving the right problems for our customers is crucial and needs to be front and center at every stage of the development process.

4.       Starting Risk Management Too Late — Jon states that, “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.”  If we are to design out risks and design in safety risk management must start early and continue throughout the entire lifecycle of a device.  Completing risk deliverables as a paper exercise is wasteful and will not help drive inherent safe design.

5.       Poor Design Reviews — Jon states that, “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.”  I would add here that the design review must absolutely focus on are we meeting user needs, do we have the right requirements and are we appropriately addressing risks through design controls and our product development process at the given stage.  I will also point to the fact that the right resources must be present at the right time to adequately challenge the design in question and deliver a solution that addresses the customer’s problem effectively.

I will address Jon's reasons 6 through 8 and my additional reasons in the upcoming part 3 of the series.  Let me note that the drivers of issues I will add have already reared their ugly head in the first 5 reasons.  But that is a topic for our future post.  In general, you can begin to see how design control, risk management and the quality management system are interconnected and a decision in one impact all others.

Main Reasons for Design Control and Risk Management Failures (Part 1)

I have been asked numerous times what I believe are the biggest challenges to great design control execution.  Design Control when done correctly consistently ensures that the right device is designed with the patient’s health and safety in mind.  


There is a great article by Jon Speer titled 8 Reasons Design Controls And Risk Management Processes Fail by Jon Speer, founder & VP of QA/RA, greenlight.guru. It highlights some of the key issues that repeatedly plague Design Controls and Risk Management execution. 

I think this article is on point. However, I would add to these reasons the following:

• not having the right resources at the right time on projects, 
• focus on timelines above patient needs throughout development,
• focus on short term project cost instead of total lifecycle costs of the device.   

These show up as deficiencies in design inputs, risk management and design review that cascade further and are the root drivers of numerous execution mishaps.  I have mentioned in the past organizations need to re-evaluate the way they do business.  They must assess Quality Systems to look for opportunities to help stay ahead of the changes effectively and efficiently.  This is a key area that impacts the entire product lifecycle and must be addressed to survive in the future.  

I will dive further on this take and explain why these are key in a series of upcoming posts.

Rapid Regulatory Changes will impact Medical Devices and Diagnostics

The Medical Devices and Diagnostics are experiencing rapid regulatory changes. To deal with these changes there are certain key areas that need to be addressed so we can thrive rather than just survive. Quality Systems need to account for that, deal with the rapid pace and help us manage it.

New standards, regulations and guidance will have a significant impact in our industry. The International Organization for Standardization (ISO) published ISO 13485:2016. This represents the requirements for a comprehensive quality management system for the design and manufacture of medical devices. ISO 13485:2016 has a 3 year transition period with no new accreditation issued to the 2003 version after year 2. ISO Technical Committee 210 just approved changes to ISO 14971, Application of risk management to medical devices and an update to the accompanying ISO TR 24971 and a new Technical Report (TR) for Post Market Surveillance.

For its part, the US FDA issued multiple guidance documents late last year on Benefit Risk Analysis for Pre and Post market and drafts for deciding when to submit a 510K for device changes and another for software changes. The MDD to MDR and IVDD to IVDR changes are slated for May 2017 with full implementation deadlines of 2020 for MDR and 2022 for IVDR. 

The ever increasing rate of change seems to have been sent into overdrive. Triggeres by the MDD 2007 updates implementation date of 2010 or some may argue after the update of ISO 14971 in 2007, this rapid pace was set and is here to stay. Regardless of which date triggered it we are now in a state of rapid regulatory changes. Our quality systems need to account for that, deal with the pace and help us manage it.

In order to deal with this change there are certain key areas that need to be addressed so we can thrive rather than just survive. These key areas are:

• Risk based Quality Management Systems (QMS) and Processes – There is an ever-increasing need to efficiently act on a safety signal or an issue impacting quality, whether the impact is positive or negative. The updated ISO 13485:2016 calls for the QMS and its associated processes to take risk into account during its design. Managing risks and data is paramount to successful compliance and quality improvements. Risk management is now solidly entrenched throughout ISO 13485:2016 and both FDA and notified bodies are driving for risk management of product and processes to help drive the Safety and Quality of products and processes.
• Regulatory Intelligence - The pace of change is here to stay. Is your organization prepared to stay ahead of it to avoid costly remediations and hurried haphazard implementations? Fumbled or delayed implementations cost time and money you could deploy elsewhere. Proactive change management is needed the days of reactive change management should be behind us.
• Predictive Analytics – The Case for Quality is coming. FDA will eventually set the systems to look at healthcare manufacturers through the lens of a quality scan. Is your business prepared to monitor and act in the same way FDA is gearing to look at it? Is the EU registry database driving at the same thing? Forward looking systems are key to help you thrive in this regulatory environment.
• Digital Transformation Strategy and Robust Systems - Well thought out and integrated electronic systems will be a minimum requirement to deal with the massive data and be able to make sense of it and turn it into actionable information. As Daniel Matlis of Axendia puts it do you have a DRIP (Data Rich Information Poor) problem and how are you going to fix it. That requires a vision of a robust system aided by integrated digital platform.

This is your wake-up call!

It is clear that the Medical Device and Diagnostics are experiencing rapid regulatory changes. While this article is not intended to provide a comprehensive road map or set of instructions, it is intended as wake-up up call!   

In order to thrive in this changing regulatory environment, the Medical Device and Diagnostics Industries need to adapt to the new landscape. We need to re-evaluate the way we do business and assess our Quality Systems to look for opportunities to help stay ahead of the changes effectively and efficiently.

Post Market Surveillance Strengthening by FDA

Recently the FDA issued a report that called for the strengthening the national system for medical device post market surveillance. The areas it’s focusing on for changes are:

1. Establishing a unique device identification system and promoting its incorporation into electronic health information system.

2. Promotion of the development of national and international device registries for selected products.

3. Modernization of adverse event reporting and analysis by:
3.1 developing automated adverse event reporting systems
3.2 increasing the number of MDR’s received electronically
3.3 developing a mobile application for adverse event reporting
3.4 modernizing the medical device adverse event database 3.5 rapidly identifying safety signals

4. Development and use of new methods for evidence generation, synthesis and appraisal in the areas of:
4.1 quantitative decision analysis to evaluate benefits and risks
4.2 evidence assessment by combining data from diverse data sources
4.3 automated signal detection
4.4 refinement of processes for signal detection and management

All of these are significant changes that will impact the level of activity and should be inputs to updates to the quality systems for all FDA regulated industry.

Another Class 1 Recall!

From the FDA Medwatch on 9/15:

BagEasy Manual Resuscitation Devices by Westmed, Inc.: Class 1 Recall

AUDIENCE: Risk Manager, Emergency Medicine

ISSUE: Westmed, Inc. is initiating a nationwide recall of 24,384 units of BagEasy Manual Resuscitation Devices. The BagEasy device have been found to have a potential for disconnection at the retention ring of the patient port manifold. Disconnection causes the unit to be inoperable, which potentially could result in treatment delays while another unit is obtained or technician switches to a different method of resuscitation.

Recalls on the Rise?

The Class I (and some II and III) device recalls listed by FDA have gone from 18 in 2008 to 31 in 2009 to 30 to date as of 09/08/10. That begs the question are recalls on the rise? It will be interesting to see how FDA reacts to this data. Stay tuned. We will be exploring this development in weeks to come.