Need procedure for D&D inputs?

[kovardhani]

I am preparing documentation from 7.3.3 to 7.3.10 under ISO 13485:2016.

7.3.3 - Should I document all the sub-topics from 7.3.3? meaning, all together in one document? I am confused about how to start and where to start. I have supporting files such as PRD, SDRS, VOC. should I make a document that refers to all these files? including risk management? or I should have a separate document for each and every specification? Share me a sample document if you have any.
7.3.4 - Records such as schematic, PCB, BOM, Mechanical designs come under this clause? Should I form a document that refers to all the files that I mentioned previously? also share me a template if you have any.

All I am confused about is that should I form a document that refers to all the records I have? and should I have a procedure for each and every sub-clauses of 7.3?

 

[yodon]

7.3.3 - Should I document all the sub-topics from 7.3.3? meaning, all together in one document? I am confused about how to start and where to start.

A lot depends on the complexity of the device. There's nothing preventing you from having a single design input document but it can get rather unmanageable. Most products tend to have a User Needs document (high-level, basis for validation) and a Systems Requirements document (engineering's "answer" to the user needs, basis for verification). Traceability needs to be maintained between the requirements in these docs. Risk Management is usually done in parallel and the controls are considered requirements. Typically elaborated as (and traced to) system requirements. If the device is particularly complex, you often have an Electrical Requirements, Labeling Requirements, etc.

7.3.4 - Records such as schematic, PCB, BOM, Mechanical designs come under this clause? Should I form a document that refers to all the files that I mentioned previously?

Yes, those are design outputs. They are generally individually controlled; i.e., they have their own unique ID / revision.

By and large, most Design and Development Plans provide the road map for what documents you create. It won't drill down into, say, specific part drawings but can help you visualize the entire medical device file.

 

[indubioush]

You may want to read this to help develop a better understanding of design control. It is relevant even though it is about US regulations:
https://www.fda.gov/media/116573/download

 

[kovardhani]

A lot depends on the complexity of the device. There's nothing preventing you from having a single design input document but it can get rather unmanageable. Most products tend to have a User Needs document (high-level, basis for validation) and a Systems Requirements document (engineering's "answer" to the user needs, basis for verification). Traceability needs to be maintained between the requirements in these docs. Risk Management is usually done in parallel and the controls are considered requirements. Typically elaborated as (and traced to) system requirements. If the device is particularly complex, you often have an Electrical Requirements, Labeling Requirements, etc.



Yes, those are design outputs. They are generally individually controlled; i.e., they have their own unique ID / revision.

By and large, most Design and Development Plans provide the road map for what documents you create. It won't drill down into, say, specific part drawings but can help you visualize the entire medical device file.

Thank you so much!
I understand I can rather have multiple documents referring to that and it needs to be included in the traceability matrix?
I am preparing a document named design input document for D&D inputs where I have mentioned all the supporting documents that I have created is that right? or if you have any sample template for the documented procedure please share it.

Regarding 7.3.4 I have planned to make a separate history record file and mention it in the design output document. is that okay?

Since I am new to this help me out.

 

[kovardhani]

You may want to read this to help develop a better understanding of design control. It is relevant even though it is about US regulations:

Thank you! I will look into it and use it for my reference.