Risk Management

Watch Now: Move From a Documents-Based Design Control and Risk Management in Medical Device

By |

Documents-Based Design Control

Medical device companies are on the cutting-edge of advancing health care. Along with facing relentless pressures to innovate and release quality products, they also must comply with regulations and standards to remain competitive. And a big part of that is design control and risk management in medical device development.  

We recently held a webinar specifically designed for product and engineering teams building medical devices, demonstrating how to move beyond the frustrations of disconnected, document-based requirement systems, streamlining your design and development and risk management processes while maintaining compliance with applicable regulations and standards. 

Below you’ll find an abbreviated transcript and the webinar recording.  

 

Move from a Documents-Based Design Control and Risk Management in Medical Device 

If we consider two aspects of your work, the first being the processes and tools that define your methodology and support your work, and the second being the documentation generated to show compliance with applicable regulations and standards, what tends to drive your team? Although it is true that both are necessary, you may find that one carries more weight than the other. For many medical device manufacturers, the answer has been to prioritize the documentation needs of the quality system, especially when considering regulated design control and risk management activities.  

This is understandable given that the documentation serves as the evidence that’s needed to get a product cleared and into the market. But as we’ll see, there are challenges teams face when documentation starts to tip the scale. Our assertion here at Jama Software is that having to prioritize the documentation needs over the product definition and development process and tools is unnecessary. In fact, many times what feels like a prioritization of the documents over all else, is really just a symptom of using documentation tools like Word or Excel to manage product development activities.  

What tends to happen is the quality management system requires specific documents as evidence of proper design and development activities and to show alignment with regulatory requirements. And working backwards from those quality needs results in the use of documentation tools to support the product development life cycle. This may work for a while, but often does not scale.  

The problem here is that the opportunity to improve processes and to increase efficiency and quality is not found in the documentation improvements. There isn’t a better Word template or an Excel macro that can help. The opportunities to improve are in the product development processes and tools. And this is where teams gained value.  

The Challenge Medical Device Development Teams Face in Design Control  

The challenge, as we see it, is that teams are trying to balance the needs of meeting design control regulatory requirements with how they desire to work. And I call it specifically this idea of how teams desire to do work, because our customers are, more often than not, looking to modernize and see a lot of opportunities in new solutions and becoming more collaborative, really improving how they work.  

Design control and risk management activities and the resulting required artifacts are, many times, supported by existing document-centric processes and tools. And although they are difficult to work with, sometimes the confidence and the comfort in having them and not changing, outweighs the benefits of modernizing through supporting tools and introducing change. However, though, we would argue that this comfort and confidence is really in perception only. Behind that perception is the reality of teams struggling with the need to align to market and user needs, deliver quickly to market, and build efficiencies into how they work together. All the while working to produce and maintain the necessary design control and risk related artifacts. 

The issue is that how teams work, and the documentation needs are being at odds with one another. When, in fact, that doesn’t have to be the case. Beyond team members simply struggling to keep up with the documentation needs and create the trace matrix, there is real risk to quality and gaining clearance, especially as product complexity only increases. And while it may seem that the documents that go into submission, as long as they are polished in the end, should continue to be the focus, even more so, as the docs and spreadsheets need to manage more information. There is clearly a tipping point.  

At some point, the ineffective and inefficient use of tools to manage everything becomes a risk in itself. Things get missed, precious time gets consumed, rework overwhelms innovation. Now, this is not to say that compliance related design control and risk documentation is not important. It definitely is important. Especially considering the regulations and requirements behind them. The intention here is not to suggest that the documentation is not significant. It’s actually…we suggest that because of the significance, a keen focus on the work and the product development approaches from where these materials are generated, will increase the confidence in the content in those materials, while, at the same time, opening the organization up to opportunities for efficiency and process improvements.  

The Complexity of Design Control of Medical Device is Real  

To take just a couple of examples, here you can see that the median number of years to reach the initial 510(k) clearance has increased from three and a half years to just over five years. And that’s between 2007 and 2013. And if that’s not sign enough of increasing complexity, look to the increase in the number of pages in a 510(k) submission from 1983 to 2017. That is over a 2,000 percent increase. And consider this, that chart starts at 1983, and Microsoft Word, which many of the customers I work with are transitioning away from, was launched in 1983. And that’s when the 510(k) averaged about 50 pages.  

You may consider increasing complexity against productivity, or metrics around time to market, or even your organizations willingness to change and to adopt new tools. These might be places you find where the challenge manifests for your teams.  

Balancing the Requirements of the Quality System with Your Approach 

The shift, we see it, is not to eliminate or downplay the importance of the documentation supporting your regulated, auditable, design control and risk management activities. We see the shift as balancing the requirements of the quality system with your approach to product development. And this balance is found by constructing an approach to how you work, so that the needs of the quality system and the required documentation are actually byproducts of your work, not in themselves defining, or the constraining factor.  

By shifting or balancing, really, the focus toward your product development approach, we suggest that organizations can then look to improve their processes and modernize their tools without negatively impacting or neglecting the regulatory requirements driving documentation today. And the key to making the shift, one that balances product development and documentation needs, is Systems Thinking. And the shift and implementation of Systems Thinking, with it manufacturers can really begin to take advantage of systems engineering principles for developing complex products and find efficiencies in how they work, both cross functionally and in the solutions and tools they use to support their work. 

Watch the full webinar recording to learn more about implementing a design control and risk management approach informed by System Thinking, how Jama Connect for Medical Device Development can help, and more.  

WATCH NOW

Jama Software
Latest posts by Jama Software (see all)