Suggestions for putting together a DHF (Design History File)

racglobal

Involved In Discussions
Hello,

Does anyone here have suggestions for putting together a DHF (Design History File)? Suppose your device consists of many modules (it's also electromedical device consisting of hardware with software). Is there a best practice to structure this DHF? Starting with the user needs document, design inputs, and all the way to V&V documents. Is it a recommended practice to break this DHF into sub-DHFs? Or can we keep the inputs, verification and validation for the entire system in one folder? Does it make sense to break up the DHF into modules? My concern with this is that the modules are connected, so you can't really do V&V on one module but really on the entire system. If somebody can shed some light on this issue, I'd appreciate it.

Thanks.
 

davishont02

Starting to get Involved
Hello,

Does anyone here have suggestions for putting together a DHF (Design History File)? Suppose your device consists of many modules (it's also electromedical device consisting of hardware with software). Is there a best practice to structure this DHF? Starting with the user needs document, design inputs, and all the way to V&V documents. Is it a recommended practice to break this DHF into sub-DHFs? Or can we keep the inputs, verification and validation for the entire system in one folder? Does it make sense to break up the DHF into modules? My concern with this is that the modules are connected, so you can't really do V&V on one module but really on the entire system. If somebody can shed some light on this issue, I'd appreciate it.

Thanks.

Hi racglobal,

I am not aware of a best practice for the structure of a DHF. Many times how the DHF is structured is dependent on the type of electronic document storage system being used and the complexity of the product. In this case, because products with software and hardware elements generate so much documentation, you want to make sure whatever approach you use allows for you to easily a) identify all documents are there and b) allows for quick retrieval. Based on your question, it seems you are storing your documents in electronic file folders and not using an electronic document management system with metadata search capabilities - which means both file organization and file naming is important.

I have structured a DHF in such a way that the DHF was in 1 folder and created subfolders within the DHF file. For example, I had a product that was made of 1 hardware and 4 software modules. The DHF file was structured similar to the list below (not all inclusive), where A, B, and C were subfolders within the DHF folder:

I. DHF (Product) Folder
A. Plans Folder
1. Project Plan.pdf
2. Software Development Plan.pdf
3. Regulatory Plan.pdf
C. Design Input Folder
1. SRS module 1.pdf
2. SRS module 2.pdf
3. HRS.pdf
D. Design Output Folder
1. SAD.pdf
2. SEAD.pdf
E. V&V folder
1. V&V plan
2.Traceability Matrix.pdf
F. Usability folder
1. Summative.pdf
2. formative.pdf
G. Risk Folder

As Ronen mentioned, it would definitely be your preference as long as it worked for your business needs. Hopefully I understood your question.

LaDahvia
 
Last edited:

Teyla

Posts Moderated
I came across on this topic maybe a bit late. But it's never too late to share the experience. :)

We're using a tool that is integrated part of the QMS software we're using to organize our DHF. Columns in a Traceability Matrix can represent functional attributes of the device. For example, one column could be design inputs and other testing. The main purpose of it is to ensure that columns capture the details of how the device was developed and tested and provide an overall view of that process.

Since it has a various type of the element that can be included, for the files that we already have, we created a simple form with the description field where we explain what is the content of the file (that we add as an attachment). For the files that are yet to be created, we can issue a task to certain team member to perform. Later, that member attach the file within that task. For the validation, we collected data directly within the web form (that we built). The great is that can be exported to PDF.

Traceability Matrix map out and organize all issues, processes, and forms as references and connect them into a whole.

It's very easy to find my files. I know where to look. :)

Cheers
 
Top Bottom