ISO 13485 and DHF (Design History File) requirements

K

KoD_RP

Hi All,
I am working on a software house certified under ISO 13485:2012.
We have developed a product under these regulations. A customer now asks for the DHF document, which is not required for 13485.
1. Do you know whether the IEC32604 requires a DHF document?
2. Is there a template available just to get an idea?
3. Is there a correlation between 13485 procedures and the "Design control".

Frankly, I am a bit confused.
4 How do I track different versions of the some document?
5. We have a web based reporting system where the customer can report bugs/changes etc. Based on the request, we update SDS documents, perform test reports etc. Do we have to record the web based entries as well in the DHF?
Any help will be highly appreciated!
Paul
 

mihzago

Trusted Information Resource
take a look at this recent post: http://elsmar.com/Forums/showthread.php?t=68109&goto=newpost
it should answer some of the questions.
I assume you mean IEC 62304. IEC62304 does not require DHF, but DHF is nothing more than a collection of all documents, deliverables and artifacts generated during the course of the design and development activity. DHF is not a single document, but many companies create a DHFI (Design History File Index), which references all documents that are part of the DHF.

There is almost a 1 to 1 correlation between the FDA Design Control and ISO 13485, especially the 2016 version which added things like:
7.3.9 Control of Design and development changes
7.3.10 Design and development Files (essentially your DHF).

Any changes you make to your product, and documentation generated to support the changes, also become part of the DHF.
 

yodon

Leader
Super Moderator
Just to expand a bit more on what mihzago wrote, let me touch on your points 4 & 5.

Item 4 should be nothing more than your standard document control procedures. Can you provide any more information on why this is an issue?

For item 5, 62304 has some specific controls on issues reported from the field and how they are managed and closed out. There are also some requirements for communicating issues. And there are even more requirements for tying those issues into the risk management process as well as trending. Beyond that, QSR (FDA) requirements also expect you to capture web-based reports as feedback (and if they drive changes, they would be done under design [change] controls).
 
K

KoD_RP

Thanks a lot for the feedback Yodon,

Item 4 should be nothing more than your standard document control procedures. Can you provide any more information on why this is an issue?

I am mainly trying to understand the DHF logic. Is it a document where I have to just enumerate the project files or I have to track also the relationship between them e.g. web-based reported issue A led to the change of SDS file B (I am already doing the latter through traceability matrices, review protocols and reference documents).
Regarding your question: All our documents have a history section where we track changes/per version. Assuming that I have 4 versions of the same document, the first during design output phase, the second during validation and the last two after release. For each of these four versions, should the DHF document contain just the file name/location/version/release date or detailed descriptions of the changes as well? I also assume that the DHF document is sorted chronologically.

For item 5, 62304 has some specific controls on issues reported from the field and how they are managed and closed out. There are also some requirements for communicating issues. And there are even more requirements for tying those issues into the risk management process as well as trending. Beyond that, QSR (FDA) requirements also expect you to capture web-based reports as feedback (and if they drive changes, they would be done under design [change] controls).

Thanks for the clarifications. We cover the majority of the specs however we have to slightly alter our QMS to fit the needs of 14971 in order to comply with 62304. Going back to DHF, this means that inside the document we will have to add the actual web link to the corresponding web-based reporting system?

Many thanks,
Paul
 

yodon

Leader
Super Moderator
The DHF is, at least to me, more of a concept than a document. It's a collection of the entire design history with controls in place to allow you to see the current state of the design configuration (i.e., latest releases of all docs in the design). Your document control system maintains the previous versions for the required time so you are able to retrieve the latest plus the prior revisions.

In terms of having to "alter your QMS to fit the needs of 14971 in order to comply with 62304" - can you elaborate? Certainly 62304 requires some 'integration' with 14971 but I'm not sure how this would drive changes to your QMS.

Regarding the web links to the reporting system, I wouldn't say actual hyperlinks are required (but certainly not prohibited if it would be useful!). I presume there's some kind of numbering system and so you could just reference the numbers. Typically we compile the list of changes (by number with brief description) in a software release into a Version Description Document (VDD). This supports the configuration status accounting requirement. We also use the VDD to list known open issues.
 
K

KoD_RP

Thanks for the feedback!

The DHF is, at least to me, more of a concept than a document. It's a collection of the entire design history with controls in place to allow you to see the current state of the design configuration (i.e., latest releases of all docs in the design). Your document control system maintains the previous versions for the required time so you are able to retrieve the latest plus the prior revisions.

It's clear now. I had in mind something similar, since all prior document versions are tracked, however the "History" term inside the DHF leads to misperceptions.

In terms of having to "alter your QMS to fit the needs of 14971 in order to comply with 62304" - can you elaborate? Certainly 62304 requires some 'integration' with 14971 but I'm not sure how this would drive changes to your QMS.

Our QMS is 13485:2012 certified. We have a Risk Management QP which describes the work flow. We follow a FMEA approach to identify risks and define corrective actions in order to minimize risks. However, we don't explicitly state the way we trace the corrective actions through out the project (risk control), even though at the end of the project we are able to verify that the corrective actions were performed. In addition, we don't evaluate the overall performance of our risk management system. According to 14971, and please correct me if I am wrong, the aforementioned procedures should be stated in the QMS.

Many thanks!
Paul
 

yodon

Leader
Super Moderator
Our QMS is 13485:2012 certified. We have a Risk Management QP which describes the work flow. We follow a FMEA approach to identify risks and define corrective actions in order to minimize risks. However, we don't explicitly state the way we trace the corrective actions through out the project (risk control), even though at the end of the project we are able to verify that the corrective actions were performed. In addition, we don't evaluate the overall performance of our risk management system. According to 14971, and please correct me if I am wrong, the aforementioned procedures should be stated in the QMS.

You may be mixing terms a bit which could be part of the confusion. ("Corrective actions" are most typically what would be done to address a nonconformity.) One of the outputs of risk management is risk controls or mitigations (what I think you're calling corrective actions). Indeed, you do need to demonstrate that the risk controls are implemented and effective (at the time they're needed). Per 13485, one of the design inputs is the output of risk management. Thus, you do need to demonstrate traceability from the risk control to verification.

Yes, you should have procedures that guide your risk management activities. Per 14971:2012, your risk file (the collection of risk management artifacts) contains, in addition to the analysis and evaluation, the (evidence of) implementation and verification of controls and the assessment of the acceptability of residual risk.
 

mscottf

Scott Fine
Hello, I realize this post is almost 2 years old, but the subject matter you've discussed is closely related to my question.
I understand the concept of DHF and it works fine for a company with a large set of controlled documents over a period of time.

I am consulting for a startup company in France that wants to be certified to ISO 13485:2016. They have over 2 years of uncontrolled documents, having never put a true quality system in place. They've been doing animal testing and have paper records for that. Should I be looking at scanning hand-written proof-of-concept ideas and photos of dry erase boards with drawings representing brainstorming? Should I be including e-mail conversations between early company members discussing their ideas for the product and its technology? All of that constitutes early design inputs and planning.
Thank you for your help.
Scott
 

yodon

Leader
Super Moderator
Can't say that's the tack I would take. Sounds like what they've been doing up to now is "research" (outside the scope of design). Certainly they've gathered good data (presumably) to prove the concept but without good controls in place (tests under approved protocol, proper record capture, etc.), the reliability of that data would likely cause that data to be dismissed.

It sounds to me like they're ready to move into design and need to properly establish the Design & Development Plan, do the required Risk Management activities, capture the design inputs, etc. and start building the DHF / Medical Device file. I do tend to take a conservative approach - I want my clients as bullet-proof as possible with their submissions / compliance.
 
Top Bottom