S
snoopy2017
Is an index necessary for DMR or DHF? In one of the companies, their SOP requires a DMR index but that has not been done. I don't think this is a requirement by regulations. Please clarify.
Sam Lazzara
Trusted Information Resource
I have not yet come across a medical device regulation or standard the requires an index for Device Master Records, Design History Files, Medical Device Files, Risk Management Files, Usability Engineering Files, or any type of file for that matter.
What is unfortunate is that since many companies maintain such indexes, auditors are accustomed to seeing them, and therefore they ask for them. That, of course, does not mean there is any such requirement.
Just another case where we need to direct our attention to "reading the words" in the regulations/standards, and avoiding over-interpretation.
And just because you have a controlled "index" does not mean the associated file is complete, appropriate, etc. It just means you have an index.
What is unfortunate is that since many companies maintain such indexes, auditors are accustomed to seeing them, and therefore they ask for them. That, of course, does not mean there is any such requirement.
Just another case where we need to direct our attention to "reading the words" in the regulations/standards, and avoiding over-interpretation.
And just because you have a controlled "index" does not mean the associated file is complete, appropriate, etc. It just means you have an index.
I agree with all that except with respect to the DMR. I'm not sure how you would effectively establish a DMR without a snapshot ('index'). I guess you could dump a lot of info into the DHR but that seems rather inefficient.
Maybe I'm not thinking outside my box. I'd be interested in hearing approaches without a DMR index.
Maybe I'm not thinking outside my box. I'd be interested in hearing approaches without a DMR index.
Sam Lazzara
Trusted Information Resource
Yodon, here is my method for ensuring that I have a complete DMR without needing to have a formally document-controlled index. I admit that my approach is unusual, but it works for me.
My document control SOP only allows controlled documents to go to "Full Release" - Rev A in my case, if all supporting lower level documents are also at Rev A or higher. Therefore, if my finished device specification (aka design output specification) is at Rev A+, then based on following that SOP, all lower level documents must be at Rev A+.
Typical audit scenario would be as follows.
AUDITOR: Show me your DMR index.
ME: I can show you our DMR but we do not require an index to be maintained.
AUDITOR: Ok, show me your DMR then.
ME: Ok, the DMR for what finished device? (REF/Catalog Number)
AUDITOR: REF 1234
ME: Ok, here is the top-level DMR document for DMR REF 1234.
AUDITOR: The DMR is just that document?
ME: No, the DMR is a compilation of documents containing the procedures and specifications for a finished device. If you want to see the entire DMR for REF 1234, you need to keep asking me for documents. You will notice in the top-level DMR document I just gave you, there are references to other lower-level parts and associated documents. You can review each of those documents, and those documents, in turn, may reference even lower-level documents.
AUDITOR: Ok then, let's keep going. Show me all of the documents referenced in the top-level DMR document.
ME: Ok. And as I show you each of those documents, you can request lower level referenced documents if you wish.
AUDITOR: Great! And by the way, this is pretty strange since most companies maintain a DMR Index, but I see now that there is no specific requirement to do so.
ME: It is a pain in the arse to maintain a "living" DMR Index document.
My document control SOP only allows controlled documents to go to "Full Release" - Rev A in my case, if all supporting lower level documents are also at Rev A or higher. Therefore, if my finished device specification (aka design output specification) is at Rev A+, then based on following that SOP, all lower level documents must be at Rev A+.
Typical audit scenario would be as follows.
AUDITOR: Show me your DMR index.
ME: I can show you our DMR but we do not require an index to be maintained.
AUDITOR: Ok, show me your DMR then.
ME: Ok, the DMR for what finished device? (REF/Catalog Number)
AUDITOR: REF 1234
ME: Ok, here is the top-level DMR document for DMR REF 1234.
AUDITOR: The DMR is just that document?
ME: No, the DMR is a compilation of documents containing the procedures and specifications for a finished device. If you want to see the entire DMR for REF 1234, you need to keep asking me for documents. You will notice in the top-level DMR document I just gave you, there are references to other lower-level parts and associated documents. You can review each of those documents, and those documents, in turn, may reference even lower-level documents.
AUDITOR: Ok then, let's keep going. Show me all of the documents referenced in the top-level DMR document.
ME: Ok. And as I show you each of those documents, you can request lower level referenced documents if you wish.
AUDITOR: Great! And by the way, this is pretty strange since most companies maintain a DMR Index, but I see now that there is no specific requirement to do so.
ME: It is a pain in the arse to maintain a "living" DMR Index document.
Interesting, thank you. What does this 'top-level DMR document' contain? (We may be closer to doing the same than I thought).
Sam Lazzara
Trusted Information Resource
The top-level DMR document is your finished device design output specification. It should include all packaging and labeling requirements, and directly provide or reference the device bill of materials. It can be a word-processing document with embedded drawings, or a CAD drawing with detailed notes or references to other specification documents.
Something I did not mention earlier - I do believe in having a design review deliverable called a DMR Status Report that provides the status for the DMR documents (and lists all of them and their current revision status at the time of the report). This is a "snapshot" deliverable, and is not regularly updated. It is a required deliverable for any design reviews that allow human use of the devices. My reasoning is that at those design reviews, we need to have evidence the DMR documents are at "full release" (Rev A or higher, for example) and build human-use devices utilizing that DMR. Once the DMR is at full release, the document control SOP ensures it stays that way.
Something I did not mention earlier - I do believe in having a design review deliverable called a DMR Status Report that provides the status for the DMR documents (and lists all of them and their current revision status at the time of the report). This is a "snapshot" deliverable, and is not regularly updated. It is a required deliverable for any design reviews that allow human use of the devices. My reasoning is that at those design reviews, we need to have evidence the DMR documents are at "full release" (Rev A or higher, for example) and build human-use devices utilizing that DMR. Once the DMR is at full release, the document control SOP ensures it stays that way.
Similar threads
