5 Myths Engineers Believe About Quality (and what is really true)

A well run medical device company is cross-functional in nature. Engineering, quality, regulatory, manufacturing, sales, marketing, finances, and other business operations functioning together to design, develop, manufacture, sell, and distribute medical devices.

The best-of-breed medical device companies have embraced the concept of “true quality” across all functional areas; “true quality” is not just the quality department’s responsibility.

Unfortunately, the notion that quality is everyone’s responsibility within a medical device company is all too often cliché, not embraced, and sadly often times, altogether rejected. Unfortunately, the quality function is often viewed as the group that creates barriers and obstacles preventing things from getting done within an organization.

The same can be true for engineers who often carry around several myths about quality. I can admit that once upon a time early in my career as an engineer, I too, carried some of these beliefs.

Let me share some of the most common myths engineers believe about quality and how to dispel them if they exist within your company.

Myth #1: Quality is QA’s job

The first myth is that quality is the responsibility of the Quality Assurance department.

Non-quality functional groups within organizations frequently roll their eyes at Quality Assurance. Why?

Historically, the QA department has been a group that has adopted new tools, methodologies, and approaches with respect to measuring and ensuring quality throughout the organization.

Things like design for six sigma, house of quality, total quality management, and many other approaches have been rolled out over the past several decades as the latest, greatest approaches to quality.

Don’t misunderstand me. These approaches have their place and application within companies. Implementing such approaches to ensure consistent, repeatable, and scalable practices to help ensure and improve overall product quality definitely has merit in the medical device industry.

With that said, I think where these approaches has missed the mark has been in the adoption and implementation phases outside the QA department.

Visit the American Society of Quality for an overview of the history of the many and frequent changes in the field of quality. A plethora of rules, requirements, internal processes, and official procedures have been created in the pursuit of quality, which can be misconstrued as obstacles.

This can foster the belief that quality stifles an engineer’s ability to do his/her job. And honestly, if these approaches have not been implemented well, these quality practices can stifle an engineer’s ability to get their job done.

This doesn’t mean medical device engineers are off the hook regarding ownership of quality. Yes, I know, the term “quality” has almost become somewhat of a cliché these days.

But engineers must realize that they play a crucial role in the company’s quality culture.

Medical device engineers design, develop, and manufacture products that must be as safe and effective as possible because of their crucial importance. For medical device engineers, quality must be viewed as a top priority in the design and development processes.

After all, these medical devices are being depended upon by patients to live their daily lives, so safety and effectiveness are the two of the biggest measures used to gauge the quality of their work.

Myth #2: Design controls and new product development documentation provide little value

I have heard too many engineers tell me that they loathe design controls and product development documentation.

When I hear this, I rephrase this issue. Design controls are very much about ensuring that products being designed and developed are safe, effective, and meet indications for use. Engineers care very much about this.

When an engineer claims to loathe design controls, what is really being communicated is that they loathe the quality processes and procedures in place for product development documentation.

Unfortunately, many companies implement poor processes that are often perceived as menial tasks for engineers, taking them away from the actual development process. Said another way, it’s common for product development procedural criteria to be overly burdensome.

However, engineers must diligently go through the design controls and documentation process to see how true value is created. This tedious, yet vitally important process will be sure to yield an end result with high quality products. Ultimately, this work will help  device manufacturers to:

• Identify the indications for use.
  • What is this device intended to do?
• Identify the user needs and requirements.
  • What does the user need it to do?
• Identify the design inputs.
  • The user’s requirements will define specific product requirements.
• Identify the design outputs.
  • Determine components, parts, pieces, materials, drawings, specifications, and manufacturing instructions.

Documentation provides verification that a product meets all requirements and was designed correctly. A big part of that verification is documented safety testing and assured compatibility when a patient comes into contact with the materials. Documentation also demonstrates the product‘s safety and efficacy.

Verification is also confirmation that a product has gone through testing to ensure everything works as expected, and that the engineer has eliminated any bugs or product issues.

This design control process is wrapped up with design validation, which demonstrates the product meets the needs of the user. Design validation helps confirm an engineer has designed the correct product, and that it functions as intended so that it is safe and effective.

Myth #3: Risk management adds no value

Risk is a measure of areas where there might be safety and quality concerns with a product. Therefore, risk management needs to be an invaluable process for an engineer.

However, risk management is another common area where the established company procedures and processes are overly burdensome and miss the mark from an engineer’s perspective.

A number of engineers treat risk as a “checkbox activity,” partly because risk management has been thrust upon us in recent years, leading to varying levels of understanding of how to apply different standards.

In previous decades, there was very little to no guidance for medical device professionals about application of risk management. Companies had to go other places for guidance and suggestions on how and what to do. We borrowed concepts from other industries and implemented successful tools and methodologies into our field—and while some were a good fit, others weren’t.

Engineers often prefer a tool like FMEA, a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service. The FMEA tool historically gained acceptance by engineers because the application of this tool evaluates failure modes. If something fails, we can identify the cause, determine the effect, and address the issue from there. FMEA is a good tool to address a single fault failure. 

However, FMEA is not an efficient tool for assessing the overall risk of a product. And ISO 14971 was introduced to specify risk management requirements for the medical device industry.

FMEA can sometimes be an exercise in checking boxes as well: some people can attest to being tasked with a 28-page FMEA containing 300+ line items. Instances like this make it difficult to use something so unwieldy as a meaningful tool to assess and evaluate risks associated with your product. If that isn’t hard enough, imagine trying to also keep such a lengthy document up to date throughout the entire product lifecycle.

There are instances when a FMEA is the most appropriate option. However, engineers need to take a holistic approach to the risk management process, which is exactly what ISO 14971 does.

For a risk-based approach, it helps to follow this process:

• Understand how the product is to be used.
• Identify potentially hazardous situations.
• Identify events that lead to those hazardous situations.
• Identify the harm that can come from those situations.

That’s a top-down, patient-focused risk management process that focuses on the quality of the products, as well as the processes designed and developed by engineers.

An engineer needs to understand not only how the product is to be used, but also the potential side effects of the product being used both correctly and incorrectly. This understanding allows a project developer to control and mitigate risk earlier in the product lifecycle, prior to market release or transfer to manufacturing. By taking this approach, it will undoubtedly yield significant value for the engineer, the company, and ultimately the patient.

Myth #4: Post-market product events are not an engineer’s concern

Should an engineer worry about the quality of a product once it is transferred to manufacturing and in the marketplace? Absolutely!

Post-market product events include:

• Changes to the product or manufacturing process
• Customer Feedback
• Complaints & Adverse events
• Non-conformances
• Product deviations

All of these pose huge concerns because they’re indications of product and process quality--of how well an engineer executed the design and development process.

Every change order post-launch has ramifications that demand accountability. If a product has a half-dozen changes in its first month, it’s an indicator that the engineer’s process is not as robust as needed. Multiple post-launch changes have a direct impact on product quality.

If an in-market device receives a high volume of complaints, it may be a result of the engineer’s lack of understanding the user needs going into development.

If there are multiple non-conformances during the manufacturing process, that’s another indication the engineer didn’t properly define certain design outputs. These, too, have a direct impact on product quality.

Companies manufacture products with similar indications, such as predicate devices. They do this by studying any post-market events, which provides a wealth of invaluable information to a developer. If a similar device has had a number of changes, then it’s essential to evaluate those changes.

Don’t repeat issues; learn from them. Do your homework to uncover any known complaints, so that when it comes time to design and develop your own product, you’ll be able to mitigate and address those known issues.

Taking this information into account early in the design and development process will help improve the overall product quality and ensure its safety and efficacy.

Myth #5: Regulations create burdens and more hoops to jump through

Regulations for medical devices are constantly changing and being updated. There are many different regulatory bodies, each with different rules and requirements. There is a concerted effort to simplify this process, and progress has certainly been made—but it doesn’t always feel that way if you’re in the midst of it, does it?

The most successful engineers will be those who leverage changes in regulations to streamline their products and processes, while embracing a “true quality” mindset.

You can resist these (inevitable) changes as much as you want, but it’s just going to make the process more painful, your outlook on quality more tainted, and ultimately, you’ll still be required to adhere to them. Our advice - embrace the changes!

Final Takeaway

You are fully capable of architecting quality management systems, new product development processes, and risk management practices in a way that’s more effective and promotes continuous improvement.

There’s almost always a way to improve a process. Sometimes that requires an engineer to shift their mindset and embrace industry-specific tools like Greenlight Guru, which allows for the freedom to focus on quality rather than compliance.

Ultimately, this shift will lead you back to what you’ve been trying to accomplish in the first place: Developing the safest, most effective products that improve the quality of life for the patients who use them.