How to deal with documentation requirements MDD/MDR under 2023/607

Pzimmermann92

Starting to get Involved
Situation:



Medical device currently under MDD will be lodged for appliance to MDR without any changes.

Thus, currently a legacy device.

How shall we deal with the documentation requirements? For example: Legacy devices do not have to fullfil some labelling requirements, but the technical documentation where the MDR certification applies to, has to include all aspects regarding labelling etcetera.

If we update our technical documentation to MDR requirements, but still make available the legacy devices “as is”, then this does not correspond tot he requirements in our technical documentation.

Do people make a 2nd technical documentation / technical file for the products to be MDR certified? And update their TD when certification is being done?

For example:

Our legacy device is currently accompanied by a device manual (MDD). The TD for MDR devices requires an IFU with more specific content in all union languages where the device will be marketed on.

The IFU will supersede the device manual as soon as the MDR devices can be made available(after certification), but fort he time being of legacy devices being made available, we must have both documents final (because 1 is used, and 1 is “final” in the TD file to be assessed by the MDR NB. But as the 1 supersedes the other this is not really workable….

I hope you understand the question… as per 26.5.2024 we must have a MDR compliant QMS and a lodged application, i wanted to know if documentation on labelling etctera can be finished after 26.5.2024 (but before the TD is being reviewed).

Thank you in advance!
 

shimonv

Trusted Information Resource
Hi @Pzimmermann92
Not sure I completely understood your question, but what you can do is prepare the MDR documentation (IFU, SOPs, etc.) and submit them to the notified body for review. Once the review cycle is completed you can formally release them to production / DMR / DHF through a change order process.

Shimon
 

Pzimmermann92

Starting to get Involved
Thanks for your answer :)

The thing i am struggeling with is, that because the device "to be certified under MDR" is our legacy device (with then updated labelling).

If....... i make a MDR compliant set of TD documentation, and untill date of review these documents has to be submitted, it can be that SOP's and other documents, are slightly updated over time, and then the "updated MDR" documentation is not in line any more version control wise (superseded revisions etcetera)..... or is it in that case the best to not let the MDR documentation supersede the MDD documents, but assign new Document numbers instead of new revisions of existing documents?
 

shimonv

Trusted Information Resource
Changing the revision or assigning new document numbers are two valid forms of document control.
You have to make changes before submitting documents for review, but you don't have to implement (release) these changes to production until you are MDR certified.
Most likely the NB will have observations and you will need to make some more changes to your documents. So best to release after the certification process is complete.
 

Pzimmermann92

Starting to get Involved
Lets assume..... the device label has to be updated (MDR compliant). So i update the technical drawing, and specification documentations by adding UDI carriers etcetera) under a new revision of the currently MDD legacy label documents. does this MDR compliant documentation stay "draft" untill submission? because else, the drawings and specifications do not represent the current "made available on the market" legacy products anymore.
 

shimonv

Trusted Information Resource
It is still not 100% clear to me... I guess you have some serious concerned about the current product's compliance with MDR requirements. That is way staying with "draft" version is a good approach until compliance with MDR is reached.
 

Pzimmermann92

Starting to get Involved
i do not see any concerns of the legacy product itself being MDR compliant (in the end) but.... if the technical file and QMS needs to be MDR compliant for certification, then it means, product drawings etcetera (labelling / packaging) also need to be MDR compliant. this thus needs updating those documents... in a good way, it would be the best to update these things on the product itself also directly (new product label, updated packaging box label)... but.... as the change on "real component level" is not feasible for us now, we want to further make available the legacy devices as is... and implement these product/packaging changes on a later moment (if certified before making available those MDR compliant devices).

i hope that clarifies it a little bit.... thus what i am thinking of is....how we can update the documentation and without being it in conflict to the current product.
 

EmiliaBedelia

Quite Involved in Discussions
i do not see any concerns of the legacy product itself being MDR compliant (in the end) but.... if the technical file and QMS needs to be MDR compliant for certification, then it means, product drawings etcetera (labelling / packaging) also need to be MDR compliant. this thus needs updating those documents... in a good way, it would be the best to update these things on the product itself also directly (new product label, updated packaging box label)... but.... as the change on "real component level" is not feasible for us now, we want to further make available the legacy devices as is... and implement these product/packaging changes on a later moment (if certified before making available those MDR compliant devices).

i hope that clarifies it a little bit.... thus what i am thinking of is....how we can update the documentation and without being it in conflict to the current product.
Leave it in "Draft", or "awaiting release" or "Approved Not Effective" or whatever else your system allows. If this is a significant hurdle that you can't handle in your doc control system or with your procedures, then you may want to change the document number for clarity.

As for the technical documentation, you should have a separate MDD file and an MDR file. You could have them in 1 file if you really wanted, but you need to be able to show compliance to MDD specifically (eg, reference to MDD-harmonized standards, the directive itself, ERC) if you are audited on the MDD technical file in the meantime. It is much easier to just build a separate MDR file.
 
Top Bottom