Michael, do you have a recommendation how to shift a culture in that direction? I like the thought. I wonder about the process.

Michael Chellson, RAC As with all significant cultural shifts it must engage the enthusiasm of the top of the organization. The leadership must champion the paradigm. Culture change is not a "quick fix" and will require some longer term strategic thinking to be effective.

When the paradigm is presented as achieving world class standing and better profitability through implementation of best practices, gaining rop level buy in is simplified.

To present the paradigm as compliance improvement will not gain much support, (unless the organization is in deep regulatory doodoo) as this does not speak to the short term needs of the organization.

Using real world data from the organization's compliance history (read, costs of failure, remediation, and lost opportunity costs) in conjunction with case studies from other organizations that have been through a significant compliance problem, it can be demonstrated that it is more cost efficient to utilize best practice.

David Didsbury It should also be apart of the recruitment process, as its very difficult to teach!

Berker Tas Thank you for bringing this thought up. Couldn't agree more! Compliance is necessary and a business critical need but it is a means to an end. We are all in the business for creating value for our diverse set of stakeholders. If a medical device company is not good at compliance they will not be able to extract optimum value from what they created. But equally a company that hasn't figured out a balance between compliance and the other needs of the business would not be able to optimise value. Imagine if we were discussing the same thing about product development or finance or really any other part of the business! Would a company succeed if they developed products only for the sake of developing products? Or if they balanced their capital expense only for the sake of balancing them? Or if they manufactured products only for the sake of manufacturing?

We need to drive towards a balanced approach through careful analysis of risks and rewards to all of our stakeholders; patients, clinicians, hospital administrators, employees, their families, suppliers, investors, and on...

All true but compliance has to be tempered with practical wisdom. This is not an all-or-nothing situation. Therefore, requiring compliance to be efficient and cost effective is a reasonable expectation. It also is something not easily achieved.

Carl Wyrwa I completely agree that focusing on compliance for compliance sake is not enough and can lead to many missed opportunities for product safety and quality – the real goal. A concentration on best practices focused on product safety and quality will yield the necessary results and in most cases will ensure a compliant process. This is not meant to diminish the importance of compliance as it is essential to any organization’s success in the medical device industry.

My experience has been in the medical device software area for over 40 years. Focusing on best practices to ensure product safety and quality can be challenging. Organizations focused mostly on compliance will sometimes find themselves having to push development folks to create required documents and perform required activities. Development folks can become very frustrated with this type of scenario as these activities might not be properly connected with achieving product safety and quality. They might only achieve the performance of a particular practice and feel compliant, but that is different than achieving the performance of a BEST practice.

This is where it gets challenging. It is all in HOW an activity is performed that differentiates it as a BEST practice. Implementing BEST practices requires management support and the willingness of development folks to implement proven BEST practices. In many cases it is advisable to implement simple measures that indicate the effectiveness of an activity – this helps an organization understand if the BEST practice is working properly or if people, with all good intentions, are just going through the motions. Development folks, when implementing effective BEST practices, will actually feel the benefits of the BEST practice and are often amazed at what some refer to as “automatic” compliance. And, when BEST practices are implemented correctly, they not only lead to higher safety and quality levels but to a much more efficient process with improved time to market. This is when it all comes together.

So what are the key BEST practice areas? I’ve had the opportunity to work with various companies and numerous medical device software projects over the past 40 years helping implement BEST practices and compliant processes. There are many activities that are important when developing medical device software, but there are certain key activities that make the most difference. As a good starting point, organizations should ensure that BEST practices in these areas are implemented effectively in a practical way. Here’s a recent article showing a basic model where essential compliance is a very important part of the overall picture but on the top a concentration on key BEST practices focused on product safety and quality is the real driver. Again, it is all in HOW these activities are performed that makes them a BEST practice, not just a practice.

https://www.medtechintelligence.com/feature_article/medical-device-software-safety-quality-and-compliance-what-really-makes-a-difference/

Berker Tas Thanks Carl, good points. Especially I like your point about creating non-value added documentation solely for compliance. I believe we can always find more productive ways to achieve compliance. I start to think creating separate regulatory departments are to blame? Maybe regulatory department has to be educational and quality / development teams have to ensure compliance and be accountable. Or regulatory should be a part of development organisations or connected to the operations of the company somehow? Any thoughts?

There is a lot of food for thought on the issues of compliance, but one quote I've heard that's stuck with me is, "Compliance and quality should be built in, not tested for afterwards." Keeping these in mind at the start and throughout the design process is easier said than done, but would have a big impact across the industry.

Aaron Liang Carl has a great point about non-value added documentation. Compliance is harder to achieve when you create unnecessary work for the rest of the team because people will behave in a manner that serves their interests and attempt to take the path of least resistance. Reducing busywork certainly will win you points in terms of ensuring compliance. I think education and training to promote the benefits of compliance helps relate the message more closely to everyday activities which hopefully helps staff better understand the purpose of compliance. In addition flexibility in terms of how compliance can be achieved (this may be easier at smaller organizations) can help increase compliance activities (e.g. V&V, design transfer).

However at the end of the day, it is the responsibility of your compliance group to ensure that business operations are compliant and the product is safe and effective regardless of good intentions and creative efforts to promote compliance. The best way to do that is to have compliance be a part of the organization's DNA as the original poster said and have that commitment filter down from management to every member of the team. If your management doesn't believe in compliance, it won't matter how well your system is built as people will just go around it. Even if your organization establishes a strong system acts its commitment to quality and compliance, human nature often means people try to take the path of least resistance (especially when you aren't looking) so you will always have to redirect traffic back to the right path.

Ee Bin Liew are there examples of non-value added documentation, that's not classified as redundant/duplicated documentation?

Marcelo Antunes The goal should be do the what's is right. By doing the right thing, you will automatically be in compliance or you will only needs tweaks to be in compliance. Regulations and standards are written by people based on past experience - meaning, there should be nothing new there if you know what you are doing.

Carl Wyrwa Berker, you are bringing up some excellent points!

In order for an organization to achieve compliance in an effective (high safety and quality levels) and efficient way (meaningful process steps with natural artifacts being delivered) the people doing the work (software development folks in my case) need to take primary accountability for compliance at their own personal level. Compliance is something that must be in place every moment of every day by every person doing the work. It’s like driving a car. Every driver of a car is fully responsible for complying with the rules of the road every moment they are driving (e.g. drive at the allowed speed, stop at stop signs and red lights, follow at a safe distance, etc.) Someone somewhere else cannot be responsible for the driver’s actions – that simply doesn’t work. Software development compliance is exactly the same – each development individual must take responsibility and be compliant every moment of the day in everything they do.

Quality and regulatory organizations should be partners with development in the achievement of the safety, quality, and compliance goals. Things work best when the quality and regulatory groups play mostly a coaching role (80%) but also a necessary oversight role (20%). The coaching role entails being fully aware of and keeping up-to-date on regulatory requirements and expectations. Coaching involves teaching and training development personnel on exactly WHAT is expected from a compliance standpoint. With the proper compliance coaching, development then needs to take responsibility and convert the WHAT into the HOWs so that the HOWs are meaningful, effective, and efficient. Development should implement BEST practices when addressing the HOWs. The oversight role is important as an on-going check that things are still where they need to be and that compliance gaps have not formed – but this is best done on an on-going basis, not as an occasional event.

It is critical for the goals and responsibilities of the development organization and the quality and regulatory organization to be clearly defined and aligned. When they are, safety and quality become the focus while compliance becomes second nature – this is the way it should work. If goals and responsibilities are not clear and aligned compliance is usually compromised along with safety and quality. When there is tension between the development folks and the quality and regulatory folks, it is usually a sign of misalignment. Common symptoms of this include development rushing to meet an overly-aggressive schedule demand, often skipping key activities and related artifacts while the quality organization is constantly stressed by watching compliance gaps emerge and remain open. Then there is an attempt to “catch up” on compliance issues.

Karen Boyd, ASQ CQA Ideally, "compliance" would equate to "best practice" and vice-versa. Sometimes, what's considered "best practice" is actually in "compliance", but other times not. "Best practice" can be much more subjective, whereas "compliance" often cannot. Regardless, "compliance", (where compliance is necessary / mandated and in the best interests of the organization and its stakeholders), comes first and hopefully leads to "best practice".

Michael Chellson, RAC Karen, Other than documentation, what quality concept in QSR is not best practice?

Karen Boyd, ASQ CQA Michael, I view "best practice" much more subjective or not as concrete as "compliance". What is considered "best practice" to one individual or organization may not be "best practice" to another. It seems more opinion-based, which could be skewed to an individual or organization's motives and/or perception. Not to say that "best practice" does not equate or cannot be in conjunction with "compliance", but I see it as a more subjective concept and term than a definitive "compliance". Just my opinion! :)

Michael Chellson, RAC Karen, I absolutely agree about the subjectivity of the phrase best practice. My point remains though, that the preventive product and safety QMS requirements in QSR & ISO are arguably best practices.

Also, while documentation burdens are somewhat excessive (I'd say overburdensome) the premarket and technical product requirements (standards compliance and S & E verification) are again arguably best practices to ensure patient safety.

Of course organizations must determine which standards apply to their products and operations,and not implement innapropriate requirements as that is just non-valu added waste. (Of course only with documented data driven justification)

Guys, this is definitely an important topic. Let me share my opinion - I have the feeling that the general opinion is, there is something outside of our company, like "compliance" or "best practice" and we have to look at it and try compare with or even to catch up.
What about taking another angle of view?
A company makes and sells a medical device. So the company has to proof that it is still efficient, it still keeps pace with the development and requirements of medicine / health care and it is safe.
"Safe" includes also that the company can predict potential harms and does maximum possible to prevent it by permanent analysisi of its own processes and permanent discussion with customers/doctors/consumers. That´s all.
May be, by using this view, YOU will be setting the best practice and comply somehow unintentionally?

Michael Chellson, RAC Complete agreement

Geoff Hummel Milan, nice theory however the FDA (and other international regulatory bodies), look for objective records that show you are in compliance with the published regulatory requirements and referenced standards (see Karen’s comments). Best practices have to first be in compliance with the regulatory requirements, otherwise they are not, regardless of how good the medical device companies SOP’s (and how good the teams compliance to those SOP are), best practices. Also, you should be able to demonstrate that (1) your “best practices” cover the relevant regulatory section #’s & standards (IEC 14971, IEC 52304, IEC 60601-1-n, etc) and (2) also show that all relevant regulatory requirements are covered (two way mapping). “Relevant” being those that apply to your device class.

Geoff Hummel On other topics brought up in this discussion here’s some of my thoughts. Michael, I agree that compliance is not something that you have to do, it has to be infused into the company culture (i.e. DNA), nobody working at the company would not even question not following the currently published version of the procedures – they should however question them; are there more effective, less risk, better quality, faster ways of doing the same work while still compliant. I.e. Continuous Improvement of the documented, approved, and compliant best practices.

Geoff Hummel I also when possible make the SOP’s adaptable to the specific device being developed, based upon the result of the risk assessment. A simpler process can be used for lower risk devices or the low risk areas of the device. Similar to the concept of the software classification described in IEC 62304; segregate the high risk components from the rest. I include (when it makes sense!) a checklist in SOP’s that identify which sections can be skipped depending on device risk (impacted documents include rationale). This becomes part of the “best practice” for the company by reducing “unnecessary” work; focusing resources of higher risk areas, and reducing costs and time to market.