Discussion: How do you split up your Technical Documentation?

[EmiliaBedelia]

For companies with more than 1 technical documentation file, how do you divide up your devices into different files? As we prepare our MDR technical documentation, I've had multiple conversations about how many products we should have in each file, so I'm curious to hear how others are approaching it and what the pros/cons are for each approach. Do you divide by DHF? Product family? Classification? A combination? Are you just converting your MDD files and hoping for the best??? (relatable!)

Just to start off with my opinion/experience...
A lot of my experience has been with enormous TFs containing hundreds/thousands of devices, where files were split up only by classification or product family. It worked fine for clearly defined "systems", but throwing 1000+ SKUs into 1 file caused issues during the review, because there was just too much information for reviewers to get through. The advantage is the cost savings/time savings of having 1 review instead of multiple, and it reduces the total number of files you have to manage. The disadvantage is that the review process and file creation is a nightmare.
On the other hand, I'm now working with very small technical files where there are multiple files that cover very similar devices (same intended purpose/indications and generally similar design). The advantages here are that the documents are more straightforward to prepare and potentially more straightforward to review. It's also been suggested to me that this would reduce the risk in case 1 file is under extra scrutiny or has a post-market issue or whatever, and in the future, if we have a desktop audit there will only be 1 product "in jeopardy" at a time. The disadvantage is that there is duplicative work, and you have multiple expensive reviews.

There's a happy medium somewhere between 1 device per file and... way too many devices per file. Where do you think that line is?

 

[Ronen E]

Good question. I tend to think that the happy medium is one TD per device family, but I have to disclose I never participated in the preparation/auditing/updating of TF/TD that covered thousands (or even hundreds) of SKUs, each.

I would definitely not recommend one TD/TF per device model - OOS/RSI risk.

Maybe as a rule of thumb "one CER per one TD"?

 

[Raisin picker]

It seems to depend on device type.
What I often see is all dental implant systems (including abutments, instruments and tools) in one TD. Sometimes several thousand different devices (as by length/diameter/material/angle/surface/...), belonging to 4 or more families. Nightmare.
Then I see one hip implant system, divided in 2 TDs for stems (regular/revision), 2 for heads (metal, ceramic), 1 for liners and 2 for cups (cemented, not cemented). So, 7 TDs for one system, and every single one larger that the dental one.

I think these examples show the risk based approach you've described: dental implants are pretty close to "well established technology" (as defined in MDCG 2020-6), chances are that the file goes through without major issues. Hip implants (as class III implantable) are in danger of attracting CECP (article 54 consultation procedure), and are established, but not yet "well established".

One aspect to consider is also if there are devices that are prone to design changes in the future, and others that just need a regular update to the file every few years.

 

[EmiliaBedelia]

OOS/RSI risk.

I'm not familiar with these acronyms. What is this risk?

I do like the general idea of "If the same clinical evidence cannot support all of the devices, they should not be in the same technical documentation".

Then I see one hip implant system, divided in 2 TDs for stems (regular/revision), 2 for heads (metal, ceramic), 1 for liners and 2 for cups (cemented, not cemented). So, 7 TDs for one system, and every single one larger that the dental one.

Hip implant systems are the worst. No matter which way you go, compatible components and clinical evidence for the different combinations/indications is always an issue. I think that example shows that crafting the TD well is key, regardless of how they are divided - there is no way to make that situation NOT confusing.

 

[Cloud808]

To add to this topic - I have proposed technical file grouping based on a consideration of how these files will ultimately be assessed by the notified body. Certainly at minimum, the grouping should be logical - that is - the devices are of similar construction or share similar indications, etc (comparable to how ISO 13485 defines a medical device family). Beyond that, my understanding is that NBs will perform assessments based on risk, as previously suggested. In this context, I refer to the level of risk (or perhaps, level of clinical data/evidence required to satisfy GSPR) as conveyed by the device's classification.

MDCG 2019-13 details sampling for the assessment of technical documentation. This guidance provides definitions for 'category of devices,' 'generic device group' (also defined within the MDR), and 'device.'

Category of Devices is associated with MDA/MDN codes relevant to the devices
Generic Device Group is associated with 4th level EMDN
Device refers to the devices associated with a single Basic-UDI

Later, the sampling of technical documentation is described based on these terms with respect to different classes (IIa, IIb, etc). For example, prior to QMS cert - "For Class IIa .. the technical documentation of at least one representative device per category of devices [should be sampled]. This means that the NB should assess how many categories of devices (how many MDA/MDN codes) are covered by the mfg's application, select per category at least one representative device covered by a Basic UDI-DI (MDA/MDN Code) and assess the technical documentation for the device(s) selected."

This leads me to believe that IIa devices should be grouped in technical documentation based upon relevant MDA/MDN codes, IIb devices should be grouped based on 4th level EMDN, and I believe that Implantable devices will be individually evaluated per Basic-UDI.

I feel that this makes sense, given that MDA/MDN codes serve to categorize the expertise required by a given NB reviewer to ensure a proper review. (ie - if a tech file has 4 different MDA/MDN codes then a NB reviewer will need to be qualified for reviewing each of those codes (at least one device per code), or the NB will have to compile a number of reviewers to ensure each code/device is properly reviewed. So potentially a mfg could maintain 4 technical files for IIa devices with 4 unique MDA/MDN, each being sampled independently -OR- 1 technical file for IIa devices containing multiple MDA/MDN codes, that may be subject to scrutiny by multiple reviewers and may also be more confusing for each reviewer trying to find the info they need resulting in longer review time. The former seems more clean to me.)

I may be incorrect, but in the absence of any guidance that informs us on optimal TF/TD grouping this was my best take. However, this approach does not consider factors like future design change, as noted by raisin picker. I am somewhat new to regulatory affairs, so feel welcome to point out any flaws in my thinking.