Update DHF (Device History Record) when DMR (Device Master Record) changes?

[Watchwait]

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...!

 

[Al Rosen]

Re: Update DHF when DMR changes?

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 can reference the documents in the DMR that is located elsewhere. Otherwise you will constantly have to have update it.

 

[yodon]

Re: Update DHF when DMR changes?

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.

 

[Watchwait]

Re: Update DHF when DMR changes?

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.

 

[yodon]

Re: Update DHF when DMR changes?

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.

 

[Watchwait]

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.

 

[yodon]

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.

 

[Al Rosen]

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.

If you can achieve it in another way you don't have to. Basically it's a means of configuration management.

 

[javielo]

The FDA clearly gives you two options;

1- Create a DMR document for each finished good you have in your facility that includes all the different components of the finished good and you know this includes but it is not limited to, prints, labels, routings, material specs, quality specs, packaging specs, inspection procedures, fixtures, bill of materials, maintenance documents, etc... If your company has many finished goods this is a nightmare and I would use option 2.

2. Create one document and include a table that shows each specific document or component of the DMR in the first column and shows ITS LOCATION in the second column. i.e. Drawings > location could be a master file with hardcopies or it could be an electronic directory or attached to the Document Control Software Database (Oracle, Documentum, Agile, etc...) If you have over 100 finished goods go with this option is the easiest one.

The DHR and DMR are related since the documents in the DHR used to manufacture an item at a specific time must match the revision of the DMR at that specific time. i.e. If I have a DHR record of 1999 the documents inside the DHR record must match the revision listed for all the components at that same specific date in 1999. Its simple if you have any more questions contact me victorjlebron at hot

 

[Ronen E]

I think there's a bit of potential confusion in this thread and a clarification of terms would be in place.

DHF = Design History File = A compilation of the Design Control process(es) outputs, for a certain device / device family.
DMR = Device Master Record = The device's "recipe" (configuration and process specifications) for a specific device revision = The device's Design Transfer's output.
DHR = Device History Record = The evidence that a specific manufactured batch or lot conforms (or not) to a specific DMR revision + its final disposition record.

Each and all of the above can be an actual compilation of documentation / evidence, or just a collection of references to the identity and location of the relevant documentation / evidence, or any combination of these two (as long as clarity & unambiguity is maintained).