Update of Technical Documentation

[Auxilium]

Dear community,
I recently started my career in the fields of Regulatory Affairs for a software as a medical and am responsible for the Technical Documentation.
Getting familiar with the most important standards such as 62304, 13485, 14971 and 62366 was definitely intense and there's certainly many things I don't know 100%.
Therefore, I lack some knowledge and have a few questions regarding more regular updates e.g.
For example, I wonder how exactly the decision whether a document for a newly released version of our medical device is done. E.g. most of the clinical evaluation and post market surveillance documents should face no update if there's more frequent software updates, right? They can just be left untouched whereas probably the Instruction for Use will probably always need updates alongside with software requirements, tests etc.
Certainly, the Technical Documentation has to be kept up-to-date alongside with product updates.
However, carefully updating everything and leaving no gaps at all slows down the process of releasing significantly and I am very interested about opinions whether or not it is too risky and "reckless" to sometimes leave gaps and don't update certain documents that are deemed "not essential".
There's definitely also different opinions at my job because of people who are way more careful than I wish I could act.
The questions I always ask myself are: are patient's endangered if I don't update this and will this cause a major non-conformity?
Because I feel like those should be the goals if you work in a working environment with a high pressure.

Sorry for the long explanation but I find regulatory work quite challenging though very interesting. Maybe someone can really pinpoint a section in the MDR or another standard regarding the update of documents? I also know that in some articles, there is explicitly stated e.g. "at least annually PSUR" or sth. But that doesn't apply for every document that needs to be part of the Technical Documentation, as far as I know.

 

[Cybel]

Hi, I try to answer you for something.
Because it seems to me that the core of your post is about significant changes, I suggest, at first, that you take a look to this document http://www.doks.nbog.eu/Doks/NBOG_BPG_2014_3.pdf which is used to define the "substantial" changes.

most of the clinical evaluation and post market surveillance documents should face no update if there's more frequent software updates, right? They can just be left untouched whereas probably the Instruction for Use will probably always need updates alongside with software requirements, tests etc.
Certainly, the Technical Documentation has to be kept up-to-date alongside with product updates.

Clinical evaluation: if it involves clinical investigation, you shall consider if results from clinical investigations are still valid after the SW update or if the SW changes introduces elements that may invalidate the clinical results. If you are speaking only about post-market clinical evaluation (so periodic review of literature for example, and PMFC), you will update it independently from the SW update. The same is for PMS documents.
(however, you should be able to identify, for some PMS activities, where - on which LOTs or S/N - the new SW has been implemented).

Generally, the need for updating the documents and for choosing what documents need to be update is related to the type of change, there is not a unique answer. For example, if the new SW release affects the Instructions for use, you have to update instructions for use. Otherwise, you leave them intact.

However, carefully updating everything and leaving no gaps at all slows down the process of releasing significantly and I am very interested about opinions whether or not it is too risky and "reckless" to sometimes leave gaps and don't update certain documents that are deemed "not essential".

I think the question is not if updating or not "not essential documents", but to understand what documents are supposed to be updated and what documents aren't.

 

[CreatureofCompliance]

All changes need to be documented in some way for traceability purposes and regulatory purposes. I am not very familiar with SaMD, but I do remember from doing an interesting course on the subject that the provider stated that SW changes are different to other types of changes, and that it can be very cumbersome to go through the same regulatory channels as non related SW changes. The most important thing is that when such changes are done, they are assessed for any impact to patient safety, how the product works, whether it introduces any new risk through the update, whether it introduces any new hazards etc-- you have to link the SW changes that happen in the technical side of things to Regulatory/Risk--through impact assessments. Even if all the outputs are N/A at least you are showing that you have assessed the changes as no impact. Traceability is the key- because how do you know if a SW update has not impacted patient safety (depending on the type of product)/ what testing was done to show the product still performs as intended/bugs etc?

 

[yodon]

slows down the process of releasing significantly

That, IMO, is not necessarily a bad thing. If you have a bunch of releases in the field, you may end up with a maintenance nightmare (extra overhead for managing all the releases). Even if it's just a service that everyone accesses the same version, a lot of release churn can be a challenge.

There's also customer perception. If they're seeing constant change, they may become hesitant to use. It drives me bonkers when MS pushes out updates that change the way I have to work.

risky and "reckless" to sometimes leave gaps

You are subject to audit / inspection at any time after you put a product on the market. Allowing bad habits to form tends to allow the bad habits to grow and that can result in regulatory action you don't want.