Design controls - Inputs, outputs, V&V, DHF, DMR

duff999

Quite Involved in Discussions
I have a few questions regarding design controls.

Design Inputs: Are these my requirements I gather from users, regulatory, product requirements?
Design Outputs: I understand these are gathered from my inputs, in the end is my output the specific product specifications.
V&V (Verification and Validation): Is this separated from my outputs - or are my verification plans, protocols, etc included as a output.
DHF (Device Design History File): Is there a specific list that is documented somewhere to ensure I have all the appropriate documentation
DMR (Device Master Record): same as above

Thanks in advance
 

William55401

Quite Involved in Discussions
This is a broad topic. To keep it simple for an initial response, I suggest understanding the definition of terms in the QSR.

There is no prescribed list of Design documents you must create to be compliant. The design and development procedures, within your QMS, define what must be delivered to create a compliant DHF (as well as a safe and effective product) for your org and customers. Your original post did not mention Risk Management. The results of risk management may create design inputs that must be acted upon.

Here's a somewhat dated FDA guidance document (circa 1997) that may be helpful
https://www.fda.gov/media/116573/download
 

duff999

Quite Involved in Discussions
Thanks for the reply. Sorry for being so broad, I am in the process of creating our design control procedure and these are the areas I am struggling with.
 

Tidge

Trusted Information Resource
I'll take the easiest one: The Device Master Record is the actual (controlled) recipe for a built device.
A Device History File will contain the information for a device (or lot) built per a DMR.
 

yodon

Leader
Super Moderator
To even make things broader than you may have imagined, as @William55401 pointed out, risk management (ISO 14971) drive additional inputs and outputs as well as other, relevant standards that you'd be wise to follow (e.g., IEC 62304 if you have software, IEC 62366 for usability, etc.).

I noticed you posted in the 3485 forum but asked questions of which some are FDA-specific (DHF and DMR are FDA terms - but they have equivalencies in ISO 13485).
 

duff999

Quite Involved in Discussions
To even make things broader than you may have imagined, as @William55401 pointed out, risk management (ISO 14971) drive additional inputs and outputs as well as other, relevant standards that you'd be wise to follow (e.g., IEC 62304 if you have software, IEC 62366 for usability, etc.).

I noticed you posted in the 3485 forum but asked questions of which some are FDA-specific (DHF and DMR are FDA terms - but they have equivalencies in ISO 13485).
Thank you for the response and I will take your advice looking into the other standards mentioned. We are currently establishing our QMS, and I am at the design control stage and wanted to be sure I am looking at 13485 standards correctly.
 

silentmonkey

Involved In Discussions
Hi Duff,

There is an ISO13485 ANSI Guidance Document somewhere that explains the intent of each clause as well as examples of implementation. I strongly recommend getting your hands on this.

The inputs in your design model are actually your user needs which feed into your design inputs. The traditional design model as explained by the ISO 13485 ANSI Guidance Document is:

User Needs - business, marketing, stakeholders, customers, users, patients, regulatory, clinical
Design Input - what to design to meet user needs, can be categorised into system design, sub-system design (electrical, mechanical, software)
Design Output - what you have designed to meet design input (electrical schematics, mechanical drawings, specifications, software)
Verification - objective evidence to show Design Output meets Design Input
Validation - objective evidence to show end-product meets User Needs

Result = product has been designed that meets user needs.
 

Gisly

Starting to get Involved
How is your product development team working today? Are you following agile practices, SCRUM etc.? If yes, I would strongly recommend to look at the TIR45:

Guidance On The Use Of AGILE Practices In The Development Of Medical Device Software. Either way, I think (hope) you will find that you fulfil most of the requirements already and its more a matter of describing what you do. And ensure that you have in place adequate traceability as well as risk management (ISO14971), usability/human factors (62366), Cybersecurity etc. is part of your requirements inputs and design process. And if you do not have a test manager, consider assigning or recruiting one as this would make everything run smoother (to my experience).
 
Top Bottom