Documentation and Review of Technical Files

SaGaf

Registered
Hello CE community,
What is the best practice to combine the technical documentation? is it acceptable to save different sections of the technical file in different word documents? or should we combine them in one file, if the later is the way, then how it would look like if we update a certain section in the technical file, would we need to update the whole document? are we required to give the document version number and revise it in the same way we do with other QMS documents through CC? I personally think to create one file for each section is the way to go to make it easier to update and maintain different sections, please share your experience and thoughts.
 

CharlieUK

Quite Involved in Discussions
I don't it really matters whether you have one document or several.
The advantage with one document is that everything is in one place and whilst you might be updating (say) section 8 - doing so in a single document might better remind you that other parts needed updating as well.

Please note that when I refer to a single document, I'm referring to a single document that references 10's of other documents such as schematics, Risk Assessments; Manuals; Field Trial information, applied standards, regulatory guidance documents etc. etc.
All these documents are revision controlled and individually updated as required
 

Ed Panek

QA RA Small Med Dev Company
Leader
Super Moderator
Depending on volume you might want to create a table of contents for the review team. I have had reviewers give up and say "I looked for this but could not find it" After the first round you can request a meeting with the reviewers (Our NB allows it) and answer queries in real time. to knock out low-hanging fruit / communication issues
 

SaGaf

Registered
Thanks Charlie and Ed for the feedback, would you also answer the other part of my question as whether or not the technical documentation should be revision controlled as other QMS documents, so we have Technical Documentation version 01, 02...etc, or is there another common practice specific to this file when handling it's review and documentation?
 

Ed Panek

QA RA Small Med Dev Company
Leader
Super Moderator
We provide the latest documents from our controlled QMS to the technical file for review. After approval, the technical file should be updated with any new revisions... however we use an xls file master to simply identify the documents. If we have an audit or resubmit we will update them then. I would verify the regulations though. I am not sure if MDR changed that.
 

EmiliaBedelia

Quite Involved in Discussions
Thanks Charlie and Ed for the feedback, would you also answer the other part of my question as whether or not the technical documentation should be revision controlled as other QMS documents, so we have Technical Documentation version 01, 02...etc, or is there another common practice specific to this file when handling it's review and documentation?
The tech doc should be controlled, but it doesn't necessarily have to be in the same way that the rest of your QMS documents are. There aren't specific requirements about the organization, management, etc of the tech files, but you should follow the same general principles of controlling documents/records (appropriate approvers, clear source of truth for current documents, etc). As long as you put it in a procedure and follow it, the details of your process are up to you.

It is in your own best interest to have a good revision history for your technical documentation. Could be a separate rev history document, documented through your document change process, whatever, but you will want evidence to show that you made changes to your TD when you needed to.
 

Raisin picker

Quite Involved in Discussions
The MDR (regulation 2017/745 on medical devices) has a nice sentence in Annex II:

The technical documentation and, if applicable, the summary thereof to be drawn up by the manufacturer shall be presented in a clear, organised, readily searchable and unambiguous manner and shall include in particular the elements listed in this Annex.
Although the MDR contains a lot of ambiguous requirements, I quite like this one ;-)
 

SaGaf

Registered
Do we have to update the technical file after each batch release to add the batch records? or do we save separate documentation of batch records without updating the Technical Documentation?
 

Ed Panek

QA RA Small Med Dev Company
Leader
Super Moderator
AFAIK the technical documentation does not include production records. Those may be audited as part of the SOP/WI covering them though.
 
Do we have to update the technical file after each batch release to add the batch records? or do we save separate documentation of batch records without updating the Technical Documentation?
Agreeing with Ed Panek,

Production records constitute a separate 'file', what in the US is referred to as the 'Device History Record' and which indeed is important to control and protect against loss. Don't make this part of your Technical Documentation, unless you're under MDR Annex XI or something.

Regarding Technical Documentation, mine definitely holds example-batch/production records, such as protocol templates or example CoAs from early batches.

Concerning your original question:

Having learned from re-compiling entire technical files to MDR compliance (from the very bottom up, my friend), I now often dream of Technical Documentation taking the form of a single file. The primary reason to do this is that the pointless admin that goes into updating separate documents that 'interact' (e.g. RMPs, RMRs, CDPs, CEPs, CERs, PMSPs, PSURs, not to mention your overview of files and their status/compliance) is getting ridiculous.

I'm not calling it an idea that's fully developed yet, and obviously the first arguments against it are (A) how would you allow changes/updates being performed in parallel without conflict, and (B) what MS Office or Adobe program would be powerful enough to load such an immense file without issues... However, I feel like you could have cloud-based tools that would compartimentalize the overall technical file, tracking changes, and that would be able to export the entirety to a single read-only file (like a .DOC or .PDF) when prompted, i.e. when you wish to review and record.

As far as regulations are concerned, there would be nothing against this approach (so long as Documents are Controlled).

Don't steal this million-dollar idea without at least referencing me ;)
 
Top Bottom