Update Technical File for EU Class IIa Medical Software Products

[joy.jian]

Hello,

During my process of putting together a technical file for an existing product but new software version, I started to doubt myself if I understand the concept of technical file correctly. We make Class IIa medical image processing software.

Here are my questions:

1. For the same software product family but new version, is it necessary to create a brand new stand-alone technical file?

For example, we have technical files for v2.1, v2.2, v3.1 etc, using the same format. Most contents are identical (ISO certificate, essential requirement checklists, intended use, etc.); some files need to be updated periodically (clinical evaluation report, risk management report, etc.); and some files are version-specific (IFUs, DMR, DHF, etc.)

My concern about keeping a non version-specific TF is that v3.1 does not replace v2.1 or v2.2 - they coexist on the market. The problem though is that the software evolves so quick that a new TF is required almost every few months.​

2. Is Technical File a living document? Or it only captures information at the time of creation?

Currently we create a TF when the new software version is picked for mass distribution. For instance, no TF was created for v2.3-2.9 since they are maintenance release.​

3. When is it necessary to submit a TH for notified body review?

NSAI reviewed our v2.2 TF, and v3.1 is decided to be the next major release accessible by all clients. Should we have NSAI approve our v3.1 TF before distributing it to customers?​

Any advice on the proper way of managing software Technical File is greatly appreciated! Thank you for your time.


Regards,
Joy

 

[Al Rosen]

The Technical File is a living document. The documents do not have to reside in the same location. You can create an index that lists or references the documents and their locations. If you identify the version information on the index, then each time you change the version, the index revision level will change. This can all be done according to your document control system.

 

[yodon]

Mr. Rosen's feedback is spot on but you included another question that probably warrants additional discussion.

NSAI reviewed our v2.2 TF, and v3.1 is decided to be the next major release accessible by all clients. Should we have NSAI approve our v3.1 TF before distributing it to customers?

This is a tricky question and the answer depends on the changes. Did the changes impact the indications for use? Did the changes impact the risk assessment?

I don't know if a full Technical File review would be required but I believe you're expected to at least inform the NB about the changes - especially if they are "significant."

 

[suildur]

The best way to decide is to contact your NB while the new version may differ in very different ways from the previous one. However there are some general answers to your questions.

(1) The product family is a tricky definition. Do you use it as a quality standard definition or a business definition? For instance, composite fillings (which are used instead of amalgams) are almost identical with composite bondings (ingredients are almost the same with different proportions), but the intended use and all other stuff are different. On the other hand, if you mean there is product family and there are types and models under this family, then it is okay to merge them in a single technical file. However, you must define every variation for each product. For example, you can even use 4 different brands for a single product, but you must submit 4 different IFU, label, packaging drawings etc for each brand in the technical file (you must also define that you use 4 different brands for that single product).

(2) It is a living documentation. It is so alive that sometimes it kills you to manage it

(3) If any info has to be changed in your technical file (including the QMS elements related to technical file documentation; for example a revision or a change in the production method), then you must contact your NB before making the change, so that they can approve it. Otherwise, you would be releasing a product to the market which is not approved by the NB which also means you violate the regulation.