Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

Medical Device Design Control Auditor Recommentations

#1
I'm soliciting recommendations for a certified lead auditor qualified to perform a multi-day internal audit of my company's medical device design controls in the California bay area within the next month or so. The ideal candidate would have significant practical experience developing and auditing class 2 software controlled electro-mechanical medical devices against US FDA 21 CFR 820 medical device regulations, ISO 13485, ISO 14971, and other global design-related standards and regulations. Experience with CE marking and technical files would be a plus.
 
#2
Why audit the design controls only, and not the design process (including design controls) as a whole? Experience shows that the problems with design controls usually happens because the design process is not understood or followed correctly.
 

yodon

Staff member
Super Moderator
#4
You might consider reaching out to the local ASQ group. They might have an audit group that could identify some candidates.

I have a few contacts in that area and would gladly get you connected with them. Send me a private message if you want to try that route.
 

Watchcat

Quite Involved in Discussions
#5
I like it that you just want to focus on design controls. What is your reason for auditing them? Do you want to confirm that all is well prior to a regulatory submission or in anticipation of a postmarket regulatory audit?
 

Watchcat

Quite Involved in Discussions
#7
You might consider reaching out to the local ASQ group.
That would be an excellent source if the local ASQ group has a tilt toward medical devices, but I'm not sure how many ASQ groups do. RAPS has an active chapter in the Bay area, which I would usually expect to be a more reliable source for medical device RA and QA experts.
 

Watchcat

Quite Involved in Discussions
#9
I don't know that I've ever seen either one, nor if would recognize them if I did. What little I understand of them, I associate them with design projects in which different design teams may work separately on different parts of the system. I think they are essentially approaches to assuring that the requirements are usefully articulated and in a way that everyone can understand them? I've always worked with a single design team, so the requirements sort of ended up being articulated in a way that everyone could understand them, because everyone was involved in establishing them.

I think we may just be looking at the same thing from different perspectives., maybe me seeing the scope of design controls more broadly, and you more narrowly. Since requirements are part of design controls, I would consider any problem with the requirements to be a problem with design controls, and therefore a design control audit would include whether they used a controlled requirements syntax or contained natural language.

I will further speculate that you encountered design before you encountered design controls, where I encountered both at the same time. Therefore you can see the two separately, but for me they are bound up together.
 
#10
I don't know that I've ever seen either one, nor if would recognize them if I did. What little I understand of them, I associate them with design projects in which different design teams may work separately on different parts of the system. I think they are essentially approaches to assuring that the requirements are usefully articulated and in a way that everyone can understand them? I've always worked with a single design team, so the requirements sort of ended up being articulated in a way that everyone could understand them, because everyone was involved in establishing them.

I think we may just be looking at the same thing from different perspectives., maybe me seeing the scope of design controls more broadly, and you more narrowly. Since requirements are part of design controls, I would consider any problem with the requirements to be a problem with design controls, and therefore a design control audit would include whether they used a controlled requirements syntax or contained natural language.

I will further speculate that you encountered design before you encountered design controls, where I encountered both at the same time. Therefore you can see the two separately, but for me they are bound up together.
No, requirements engineering is not related to different design teams, it's just good design practice. You can see a glimpse of it when regulation or standards say to address incomplete, ambiguous, or conflicting requirements - these are examples of a "characteristics of a good requirement" that any good requirements engineering process will include.

And no, I did not encounter design first, then design controls. I encountered design controls first, noticed that it's not engineering design, and then studied the engineering design literature (and then it was obvious that design controls are simply a name created by regulators to specific certain milestones that any good design process should have anyway).

In fact, the term "design control" does not seem to exist outside the regulatory world, so, from an engineering design perspective, design controls do not even exist (what is called "design controls" by regulators should be already part of any good design practice).
 
Top Bottom