FDA has stated that the although the DMR is a subset of the DHF, the DHF does not necessarily need to contain the actual DMR (whew!). However, if I choose to include the actual DMR in the DHF, do those documents (by default) then need to be constantly updated within the DHF (a maintenance nightmare)? Or - can I indicate that current revisions of those documents are controlled by 820.40 (Document control) and as such are maintained elsewhere? Seems to make sense to me...!

FDA has stated that the although the DMR is a subset of the DHF, the DHF does not necessarily need to contain the actual DMR (whew!). However, if I choose to include the actual DMR in the DHF, do those documents (by default) then need to be constantly updated within the DHF (a maintenance nightmare)? Or - can I indicate that current revisions of those documents are controlled by 820.40 (Document control) and as such are maintained elsewhere? Seems to make sense to me...!Yes you can. The DHF (http://www.fda.gov/cdrh/qsr/03desgn.html#design_history_file) can reference the documents in the DMR (http://www.fda.gov/cdrh/qsr/08dmr.html) that is located elsewhere. Otherwise you will constantly have to have update it.

It's my understanding that the DMR is a 'snapshot' of the configuration for a particular configuration. For example, revision A of the device is built according to drawing 1 rev A, drawing 2 rev B, etc. If you transition to revision B of the device and change, say, drawing 1 to revision B, you would update the DMR to reflect the new configuration.

So from my perspective, it would not suffice to say "current revision" of referenced documents in the DMR. You have no basis, then on how to completely identify the configuration for a particular device revision.

Thanks Al & Yodon: so here's my "take-away" on both of your inputs..

If we elect to include the DMR in the DHF (either as a list of documents with revision dates, or the actual documents themselves), then the list, or the documents, within the DHF would need to be constantly updated.

Sounds like a great reason for NOT including the DMR in the DHF. Or - if doing so - do so as a list of documents without revision dates. Then the only time the DHF would need to be updated is when we added or removed a document from the DMR (a situation that occurs far less frequently than the revision of existing documents).

If requested, we could always provide the current revision of any document on the DMR though our normal document control process.

The Design *History* Folder (DHF) is just that - the history of the design of the device. Indeed, it's not revision controlled, but you do need to know what the current release of any particular document (referenced) in the DHF is. The DHF is updated constantly - with any design change.

The DMR is, in essence, a recipe for building the device. If you list the ingredients (documents, etc.) without listing the amounts (revisions), you would not be able to "bake your cake" correctly. The DMR is updated whenever you change the recipe.

There is considerable overlap between the DMR and DHR but they serve different purposes. The DHF is focused on design whereas the DMR is focused on manufacturing.

Yodon, I've asked this question before but I'll ask it again.

Do you revision control the DMR itself? I know all about DMR Indices, but if I maintain a seperate document listing all the components of a particular device, does this document itself need to be revision controlled? I've never gotten a clear answer back from anyone on this...so hence my continued curiosity! FYI, we do NOT maintain a seperate, physical DMR. Instead, we only reference a DMR Index in an SOP that "points" to the location of all controlled documents.

I say (a definitive) yes. The DMR identifies a particular configuration of a device. If you change that configuration (via drawing change, manufacturing process change, etc.), you need to change the DMR. This provides the necessary linkage for the device pedigree.

Take a look at:

http://www.fda.gov/cdrh/qsr/08dmr.html

To me, the implications in this guidance are quite clear that revision control is needed and expected.

Consider this example. You have a device with 5 different configurations in the field. All of a sudden you start getting complaints / returns. What can you use to identify the EXACT configuration of each device? The DHR might help but may not take you all the way back to the complete configuration. In my world, you would be able to identify the device by serial number, go to the DHR to find the DMR revision, and then have the complete and exact configuration of that device.

I believe that's the intent for the DMR. If you can achieve those results otherwise, then maybe you don't need to revision control the DMR.

I believe that's the intent for the DMR. If you can achieve those results otherwise, then maybe you don't need to revision control the DMR.:agree1: If you can achieve it in another way you don't have to. Basically it's a means of configuration management.