design control Archives

Tag Archive for: design control

Design Controls have been an FDA Quality System Regulation since 1997. Having worked on developing products in the regulated medical device industry for over 35 years, I have compiled a list of the five key takeaways for implementing design controls and achieving success in commercializing medical devices:

Design Controls not only help achieve regulatory compliance, they help develop better products
Design Inputs lay the foundation for product development, building a good foundation
Don’t underestimate the power of Bidirectional Traceability
Know the difference between Verification and Validation
Risk Management is a vital part of Design Controls

#1 – Design Controls not only help achieve regulatory compliance, they help develop better products

Many companies think that design controls are a burden to development organizations imposed by the FDA, and it’s the price to pay for playing in the medical device field. However, what is often overlooked is that design controls only define the basic minimum requirements necessary to develop a product that can…

…meet the needs of the user.
…be designed to be safe and effective.
…be reliably manufactured.
…be verified and validated.
…maintained and updated throughout the product lifecycle.

These are all things that any development organization should do to successfully deliver products to market. I like to say that if you are doing the right things in product development, compliance comes for free!

#2 Design Inputs lay the foundation for product development, building a good foundation

The FDA defines design inputs as the physical and performance requirements of a device

that are used as a basis for device design. To generate adequate design inputs, the foundation upon which product development is built, the user needs must first be well understood. These needs, ideally written with the voice of the user, must then be translated into design requirements. In contrast to the user needs, these design requirements should be written using the voice of the engineer, and as such should be measurable and testable. Furthermore, design requirements should be traceable to a specific user need, risk control, or standard that necessitates the existence of said design requirement.

Research has shown that, on average, companies that are successful at developing products spend about 25% of the product development time on the generation of user needs and the subsequent design requirements. The return on this investment of time and resources reduces the need for rework and redesign, and ultimately leads to higher customer satisfaction. Failing to make the investment ensures that design inputs are complete and correct is analogous to building a house on quicksand, where the flaws in the foundation can cause issues throughout the construction and subsequent (likely short) lifetime of the house. Issues with requirements will impact development, verification, validation, and user acceptance of the product, so spending the time to get requirements right will be well worth the effort.

RELATED: Three Ways to Proactively (vs Reactively) Incorporate Design Controls in Medical Device Product Development

#3 Don’t underestimate the power of Bidirectional Traceability

In an audit, the trace matrix should be valued as a friend! Having and maintaining bi-directional traceability throughout the product lifecycle provides a number of benefits:

Effecting project tracking
Thorough change impact analysis
Ease of making future changes
Re-use of elements of the design
More effective issue resolution

To derive these benefits, the relationship between the following entities should be established:

User Needs and Design Requirements
User Needs and Validation
Design Requirements and lower-level requirements
Design Requirements and Verification
Lower-level requirements and verification
Lower-level requirements and Design Outputs
Risk Controls and Design Requirements

In creating a trace matrix that has views to show all the bi-directional relationships of each of the elements described above can help answer most questions from an auditor. With this level of traceability, I can trace from a user need all the way through implementation and test.

#4 Know the difference between Verification and Validation

The terms “Verification” and “Validation” often get combined and abbreviated to V&V; however, these activities are vastly different.

Verification is confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. It is design-centric and answers the question “Did I build the product right?” Verification also entails gathering objective evidence that the design behaves as intended through the use of observation (visual inspection), measurement (values and tolerances), testing (function) or analysis (reviews).

Validation is confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled. Unlike Verification, this is a user-centric term, and answers the questions “Did I build the right product?” and “For whom is this the right product?” Validation entails gathering objective evidence that the design satisfies the user needs through the use of Usability Studies/Human Factors Studies, Clinical Evaluation/Clinical Studies, Customer Surveys, and through Analysis of Verification Data.

Knowing the difference between Verification and Validation is of quintessential importance for ensuring customer satisfaction and regulatory acceptance of the product.

#5 Risk Management is a vital part of Design Controls

The elements of design controls are Planning, Design Inputs, Design Outputs, Design Reviews, Design Verification, Design Validation, Design Changes and the Design History File. So, what happened to Risk Management? Risk is mentioned in Design Control Regulation (QSR 820.30) all of one time, under Design Validation. The statement simply reads “Design validation shall include software validation and risk analysis, where appropriate.”

Fortunately, the FDA Design Control Guidance elaborates on requirements for risk management. The guidance includes this paragraph:

Risk management begins with the development of the design input requirements. As the design evolves, new risks may become evident. To systematically identify and, when necessary, reduce these risks, the risk management process is integrated into the design

process. In this way, unacceptable risks can be identified and managed earlier in the

design process when changes are easier to make and less costly.

The takeaway from this is that although risk management is just cursively mentioned in the QSR Design Control regulation, the intent of the regulation is that Risk Management be practiced starting from the point where design inputs are known and practiced throughout the product life cycle. You cannot be compliant to the design control regulation without having an adequate risk management file.

Conclusion:

Design Control regulations have been around since 1997, but many manufacturers still have problems complying with design controls. Focusing on the best practices outlined above will derive the most benefit from implementing Design Controls, will lead to a more predictable development cycle, and ultimately result in higher-quality products that can be enhanced and maintained throughout their lifecycle.

Incorporating Design Controls can be a daunting task for medical device product development teams. For a variety of reasons, including unfamiliarity of regulatory expectations, inexperience with implementation, or viewing them as a burden preventing innovation, too many teams incorporate Design Controls reactively instead of proactively.

Here are three ways to proactively and practically incorporate design controls in your medical device development process that results in better market adoption, faster time to market, and regulatory compliance.

1. Plan for it

Design controls is not a singular activity or simple set of static deliverables that can be accomplished at the last minute successfully. Planning how your organization will incorporate design controls throughout the product development life cycle is key for a successful medical device product. At the highest level of planning is an organization’s standard operating procedure for device development that incorporates the major aspects of design controls. At the next level is the project plan for the development of a particular medical device. The complexity of the plans is scaled with the risk and complexity of the medical device being developed. Higher risk and higher complexity devices require higher sophistication of planning processes and tools than lower risk and lower complexity devices.

2. Incorporate risk management as part of your requirement setting process

Risk management is expected to be incorporated throughout the product development life cycle. One best practice is to perform the application risk analysis concurrently with determining user needs and the top level design inputs; not after development as a check-the-box activity. As risks associated for foreseeable misuse are uncovered, the team can proactively decide how the risk will be addressed, whether safety by design, protective measures, and/or information for safety and create a corresponding user need and/or design input. Now the team has a comprehensive list of requirements at the beginning of detailed design and development, not at the end.

3. Organize user needs, design inputs, and risk management information

Maintaining and organizing user needs, design inputs, sub-requirements, and individual risks is key to proactively incorporating design controls. In addition to the high number of items, there is the common scenario of many-to-one or one-to-many relationships that must be kept clear as well. For example, one design input can address multiple user needs or vice versa.

Thus, without proper organization, it is possible to miss creating a corresponding design input to a user need, linking a risk item to a corresponding design input, or missing the actual development of a design input during the development phase; all leading to unwanted, reactive last-minute development efforts. In addition, once the user needs, design inputs, and risk management are well organized, tracing the corresponding design verification and design validation efforts is much easier.

Choosing the appropriate tool can simplify these requirements management efforts. For lower complexity devices, management of design inputs and risk may be sufficiently organized using a word document or spreadsheet. Note that even a ‘simple’ device can create a list of requirements and risks of notable length. I’ve worked on a plastic sub-assembly that sat over a nasal spray pump as part of a drug-device combination device. With no mechanical moving parts or software, the list of design inputs still spanned a dozen pages, and the risk analysis FMEAs numbered hundreds of line items.

As the medical device or technology being developed increases in complexity, so does management of the requirements and risks. In contrast to a drug-delivery sub-assembly, I’ve also been involved with the development of a robotic surgical system. With a handful of sub-systems, embedded software and software user interface, the resulting requirements, sub-requirements, and sub sub-requirements were a challenge to manage via simple word docs and spreadsheets, to say the least. These days, software tools such as Jama Connect® allow for visual management and traceability of user needs, design inputs, risk management, design outputs, design verification, and design validation. With all items in an integrated platform versus disparate spreadsheets and documents that are linked manually, teams can spend less time on the requirements management, thus leading to faster, better product development with high confidence in meeting regulatory compliance.

These are just three of the ways to integrate design controls proactively into your organization’s medical device product development process. Proactive integration done practically adds value and enhances, not hinders, innovation.

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