Training in D&D for engineers with no medical device experience

[SSchoepel]

Hello, I am working at a small medical device company that has hired engineers with no previous medical device experience and usually from companies where a formal design and development process was not necessary. We have process in place and it passes audits but there is such a gap between knowledge and experience that I am basically performing project management, and now I am attempting to get them more skilled in their own process. I think an external training would help so they can get the information from more than just one place (me).

Does anyone have recommendations of good online or group training in design and development? It would preferably be for medical devices but at this point any training would be helpful. I'm hoping for something that covers gathering user requirements, setting system requirements, design specifications, the different types of design meetings/reviews, the standard phases of a design and development cycle, phase checklists/milestones, and all the types of documents and records that get created along the way.

 

[yodon]

What you mentioned (gathering user requirements, setting system requirements, design specifications) is mostly basic systems engineering. To me, where it gets interesting is when you factor in standards compliance. For example, you didn't mention Risk Management at all yet that's going to be huge in any submission. Others with tremendous influence include biocompatibility (10993), safety (60601-1 and ALL the relevant collateral standards), usability (62366), software (62304). I'm sure I'm missing some key ones.

If your process is compliant with 13485 then that would be a good place to start. That will touch on all the items you mentioned.

There are, of course, consultants that will gladly come in (or remotely) provide training.

 

[SSchoepel]

We are compliant and our QMS addresses the additional applicable standards (like 62366, 62304 and 14971). It's not really about training to our own processes, it's that the general methodology of how a design and development cycle works is not understood by the engineering team. I'd like a general engineering cycle/project cycle training from outside.

 

[indubioush]

If you have a good understanding, you would be the best person to train them.

 

[DannyK]

I agree with indubioush.
Training on your Design & Development procedures would be a good start.
As for training courses, I believe that MedicaDevice HQ provides a course on Design & Development.
I have taken some of their courses and found them to be well done.
I do not have any financial or commercial interest with Medical Device HQ.
Hope this helps.
Danny

 

[Ronen E]

CDRH Industry Basics: Design Controls

Jump to 1:00:05

 

[Hi_Its_Matt]

...We have process in place and it passes audits but there is such a gap between knowledge and experience that I am basically performing project management, and now I am attempting to get them more skilled in their own process...

This isn’t really an answer to your question, but I feel it’s worth mentioning…

It is better in my mind to have great processes and mediocre employees than great employees and mediocre processes.

A rudimentary process can “pass audits” if it meets the bare minimums and is adequately followed. But a great process will help insulate you from swings in quality based on the individuals executing it.

If you have a robust design and development process, with clearly defined stage-gates and deliverables, where it is clear when certain items should be started and ended, when initial drafts should be complete, when they should be reviewed, how the various items interact, etc, and you have the forms and templates for employees to use that guide them (see also “just in time training”) in creating the content, then this greatly enables your ability to hire less experienced engineers while still obtaining good outputs.

It sounds to me like right now (and don’t take this personally), that YOU are the great employee shepherding a mediocre process. Of course, get your employees training, or provide it to them. People have already provided good advice in that regard. But at the same time, please look into fortifying your processes, so that as your organization grows, it can rely on the processes themselves, rather than training.

 

[Ronen E]

@Hi_Its_Matt, great post!
I'd like to add one bit though.

this greatly enables your ability to hire less experienced engineers while still obtaining good outputs.

This will be true if the hired individuals have the tendency to follow prescribed methods closely, and are detail-oriented, thorough and diligent. Too many otherwise-good engineers tend to skim over prescribed processes (be they the best processes) and return poor results in the bigger scheme of things. For example, a good process, integrating a lot of lessons learned, might seem excessive and inefficient to a well-intentioned but inexperienced engineer.

 

[SSchoepel]

This isn’t really an answer to your question, but I feel it’s worth mentioning…

It is better in my mind to have great processes and mediocre employees than great employees and mediocre processes.

A rudimentary process can “pass audits” if it meets the bare minimums and is adequately followed. But a great process will help insulate you from swings in quality based on the individuals executing it.

If you have a robust design and development process, with clearly defined stage-gates and deliverables, where it is clear when certain items should be started and ended, when initial drafts should be complete, when they should be reviewed, how the various items interact, etc, and you have the forms and templates for employees to use that guide them (see also “just in time training”) in creating the content, then this greatly enables your ability to hire less experienced engineers while still obtaining good outputs.

It sounds to me like right now (and don’t take this personally), that YOU are the great employee shepherding a mediocre process. Of course, get your employees training, or provide it to them. People have already provided good advice in that regard. But at the same time, please look into fortifying your processes, so that as your organization grows, it can rely on the processes themselves, rather than training.

Sorry for the delayed response, I don't get on here often. This is very good advice. Right now I am trying to champion a more robust process but getting pushback. There is reluctance to make the process more resilient and robust, though there is evidence to support the argument that we need to update it given things that are bumpy and missed. The startup wants to stay "nimble."