ISO 13485 and QMS related concepts Training - Small medical device startup company

[racglobal]

Hi everyone,

I would like some advice from this very helpful and informative community. I work in RA/QA at a brand new startup company. I would say none of the employees have had any exposure to ISO 13485 or any QMS related concepts. What is the best way to train a group like this? For example, I am struggling with explaining the importance of documentation as a good practice, not just a regulatory requirement. How can I explain the connection between a company's quality policy and objectives and the day-to-day documentation, whether it's DHF or DMR? As we know, ISO 13485 leaves room for interpretation, and it tends to be very grey so I don't have regulations to back me up when I require something to be done in a certain way because so much in the quality system comes from best industry practices. If somebody has suggestions on how I can develop a better training program to tie together these concepts, it would be great.

Thanks.

 

[Ronen E]

...so much in the quality system comes from best industry practices.

A. Not necessarily. Some does, but a lot is copy-paste without much thinking, or just inertia. It's usually easier and more comfortable to just "go with the flow" rather than to think critically and independently.
B. As a member of a "very small, brand-new startup company", I advise you to look for what is right for your company, not necessarily at "industry standards" (whatever those might be).

Don't overdo things and don't introduce measures that don't clearly contribute to the quality objectives. You can always expand later if necessary. If you keep value in mind at all times, you'll end up having easier time explaining to others why things are necessary. Ditch auto pilot. If the standard is grey about something, and you can make things easier and more sensible, do it. If things don't make sense to your team, they might have a good point.

 

[Tagin]

For example, I am struggling with explaining the importance of documentation as a good practice, not just a regulatory requirement. How can I explain the connection between a company's quality policy and objectives and the day-to-day documentation, whether it's DHF or DMR?

Where is top management at? Do they see quality as a necessary burden or are they embodying the sense that this new company exists to bring a high-quality product to market to help people? Their attitude creates a culture, for good or ill, that helps or hinders your efforts.

I see this part of your role as being a loremaster and champion (or, 'evangelist' is used these days) of quality. You are telling them a story, of sorts, of how they are there not merely to fill time, but to feel proud and fulfilled with accomplishment and pride at what they contribute and produce. The quality policy sets the theme of this story, and the objectives are the measurable milestones demonstrating how the company is progressing along this story's plot line. The good documentation is part of the characters' efforts being focused towards those milestones.

Now, you wouldn't necessarily explain it to them in those words, but I personally think it can be helpful to think in those terms. Bad/missing documentation is just going to cause grief, frustration, bad product, etc. - in short, wasted energy and effort; conversely, good documentation makes life smoother, easier and more efficient. So, good documentation is a quality-of-life thing: its making their life easier and less stressed, in the long run.

Since this is 13485, and presumably a medical device being made, then there is also the appeal to basic human conscience: they have to be aware they own the power to potentially harm someone if instructions are faulty or lacking. To be clear, this is taking the tack of awareness of their empowerment, not scolding them: they have the ability and power to do good, and feel good leaving at the end of the day (scolding, on the other hand, leaves them dis-empowered and grumbly).

Basically, I view this as company culture training, with the procedural details as the how-to for that culture.

 

[William55401]

Tagin, great comments. I am in a similar situation as an independent consultant helping a 10 person org (no device experience) develop a QMS for an outsourced product family. I am putting together my first general QMS training for delivery next week as a kick off to a QMS implementation project. As I prepare, I am keeping the following in mind. Keep it simple. I don't want to lose the group with subtle details. The worst reason I can give for doing anything is that "it's a QSR requirement" or "ISO says we must do it". I want the WHY to first come from my client QS management rep. They have to put it in their own words. I can supplement with QMS is really our business process on how we get things done. Don't just think about formal training as your way to influence the org. The 1:1 interactions (not officially documented as training) you have with the team members explaining WHAT and WHY may actually be a more effective way of teaching.

 

[kreid]

I try to 'sell' the concepts of regulations and standards as the promotion of good engineering practice by the regulators/standards writers, not as something designed to hinder us in our engineering pursuits.

With specific regard to the generation of documentation (I often work with software developers, and this is a particular thorn for them) I 'sell' the task of documentation as the 'persistence of knowledge'. The engineer often knows everything about the design he/she has created but for it to be usefully maintainable in the future we need to create documentation. The engineer should consider this as part of his/her legacy

 

[Ronen E]

I try to 'sell' the concepts of regulations and standards as the promotion of good engineering practice by the regulators/standards writers, not as something designed to hinder us in our engineering pursuits.

I very much agree. The problem is that many times something of that efficiency/elegance gets lost in the translation from standards/regulations to company SOPs. So it's crucial to keep watch and ensure that at no point the org is creating documents for the sake of creating documents, where no one can actually point to some added value.

With specific regard to the generation of documentation (I often work with software developers, and this is a particular thorn for them) I 'sell' the task of documentation as the 'persistence of knowledge'. The engineer often knows everything about the design he/she has created but for it to be usefully maintainable in the future we need to create documentation. The engineer should consider this as part of his/her legacy

Easy: Just let each such engineer work on fixing a problem in a code they created 3 or 5 years ago. They may have an epiphany

 

[kreid]

I very much agree. The problem is that many times something of that efficiency/elegance gets lost in the translation from standards/regulations to company SOPs. So it's crucial to keep watch and ensure that at no point the org is creating documents for the sake of creating documents, where no one can actually point to some added value.

Agreed. It is very difficult to write simple, clear and concise procedures (I keep on trying), but one thing that can help is to understand the stds/regs to which you are trying to show compliance, and ensure you include the minimum viable compliance within your procedures in language that is understandable for the audience.

 

[Ronen E]

one thing that can help is to understand the stds/regs to which you are trying to show compliance

Spot on.
I see a lot of orgs not taking that path at all (or hardly), and instead regurgitating procedures that they "believe are right", ending up generating a lot of extra, non-value paperwork (and work), not being able to explain how or why it is important when challenged, other than "Isn't this what everyone is doing?"

 

[j4zzQ]

They have to put it in their own words. I can supplement with QMS is really our business process on how we get things done.

I couldn't agree more with you. It is up to every organization to develop their procedures and help them contribute to the company culture.

 

[Enternationalist]

From an educational perspective, you need to get ISO 13485 in their hands, and have them start interpreting the standard and attempting to satisfy it in a procedure. Depending on your scope, you'll probably want to start them on a small subset (e.g. task them with having a crack at some minor SOP). It is essential they get a taste of this - the way the standard is worded, what is flexible and what is not. Work with them on making that subset valuable and lightweight - emphasise clarity and conciseness, and then road-test the procedure. A baptism in ISO 14971 and what a risk-based approach can look like is a good idea at this point to help ensure your activities are flexible and don't force you into overdoing things.

As someone who has had to work hopping between the quality trenches and the other trenches, you do not want to impose your "best practices" on them without seeking input. It is exceptionally tempting as a quality professional to look back on the past and want "to do it right this time!", which often entails a fairly specific architecture and format. Do not leap straight to this. Quality personnel refusing to bend outside of their rigid preconceptions is a good way to create an us-and-them situation which you desperately do not want in this situation. You will step on toes and create unnecessary work if you do so blindly. This is especially true if you are coming from a large company's established QMS to a tiny startup fledgling QMS. Promote models you know work, and guide them to an interpretation that aligns well with what you know, but make sure it is collaborative, and ensure you are getting real value beyond just "compliance".

Firstly, for social reasons, you need their genuine buy-in and seeking their input is a good way of doing so.
Secondly, companies and their structure and capacity vary greatly - your first implementation, no matter how masterfully concocted, is guaranteed to need substantial modifications after it gets some time on the road, and you will want it to be as lightweight and low-cost as possible to do so. Crafting an elaborate masterwork straight up will hamper you in this endeavour.

Having them implement at least a part of it themselves enhances buy-in and instils a basic sense of what quality is attempting to do - it communicates the correct philosophy, so that when you inevitably need to make improvements and streamline things your staff are able to articulate things in a way that is more helpful to you as a quality professional.