Technical file structure/content requirements for Class IIa devices & new MDR

[dpl2018]

I run a small software development company and we’ve had experience of developing mobile apps for clients that are classed as medical devices, so they carry the CE mark. All our experience to date has been on developing class 1 safety class A devices for Europe so we have complied with the EU MDD . We’re not certified to 13485 but our software development processes are aligned to harmonised standards like IEC 62304 and we have always produced the Technical File for such projects which has been handed over to the client so that they can register the device with the MHRA in the UK. We have an opportunity to develop some software which under the new MDR will be classified as a IIa device but we are not sure if the Technical File structure/content areas that we’ve used for developing class I devices would be sufficient and meet the compliance requirements for developing class IIa device software? We also want to transition to the new MDR and we’re currently unsure how to approach this and was wondering what practical steps we could take to begin the process. Any help and advice from someone more expert on all this than myself would be much appreciated.

 

[SK13485]

re: Technical file structure/content requirements for Class IIa devices & new MDR

Welcome to the field of Medical Devices I am not an expert in this matter. I believe when your device is categorized as a class-IIa according to MDR, like every other device, your device also has to go through the EN ISO 14971:2012 Risk Management standards bringing down all the risks to as far as possible and a Risk-Benefit analysis need to be conducted. An EN ISO 13485:2016 certification is required as well, when your company is planning to develop and market the device. it all starts with QMS planning, Design inputs, Design validation and so forth. The technical file structure and the content areas for the software of a class-IIa based device is much likely to be different, since the device is identified as IIa. Please verify the MDR requirements, as they varies for different medical devices. I am sure, there are great people out here and you will get the necessary help. Good day !

 

[Sulamistan]

For Class II devices, QMS is mandatory, which must be audited by a NB. Easiest way to achieve compliance would be by applying ISO 13485. The device technical file also needs to undergo audit by the NB. You should refer to Annex II and III of the MDR 2017/745 to assess if you have the technical documentation in order for your device.

A helpful source, according to me, for planning your strategy for transition to MDR can be the whitepaper published by Emergo (trusted source). EU_Transition_Timeline_whitepaper

 

[yodon]

In addition to the previous posts, note that IEC 62304 is the harmonized standard for medical device software (lifecycle). That will drive the bulk of your Technical File contents. The standard clearly defines the differences between (safety) class A and B (which is most likely the class of your software if it's considered IIa - but maybe not - it provides guidance for determining the software safety class).

 

[Heena Thakkar]

In response to taking practical steps towards MDR compliance, the recommendation would be conducting the gap analysis of Annex I requirements (as a starting point) to get an idea of how much change will it affect to you (your device). Being it a class IIa device, make sure it qualifies for the transition period unless you want to certify it by 26 May 2020.

Of course, Annex II will be helpful for understanding minimum contents required for Technical Documentation. Art. 52 and Annexes IX, X and XI will help figure out lodging NB application (NBs not yet designated for issuing MDR certification).

Hope it helps a bit!

 

[Yodelka]

Hi! I am a small software development company and we are now working on the product to collect surveys from medical device users for the purpose of feeding data to clinical evaluation. In my assessment I do not need any certification for this product under MDR. Do I need to be compliant with any international standard?
Thanks!

 

[yodon]

Compliance to a standard is typically voluntary. You need to determine what regulations (laws) may govern your offering. For example, if you're collecting data on medical device use, you may be collecting protected health information in which case you'd want to comply with the GDPR (EU) / HIPAA (US). There may be some standards that, if you comply, help ensure compliance to the applicable regulations. For example, ISO 27001 may be something for you to consider (irrespective of whether you fall under the MDR or not).

 

[Yodelka]

Thanks a lot, this is helpful. At this point I do not plan to collect protected health information but if it happens I definitely have to comply with GDPR

 

[Ronen E]

I run a small software development company and we’ve had experience of developing mobile apps for clients that are classed as medical devices, so they carry the CE mark. All our experience to date has been on developing class 1 safety class A devices for Europe so we have complied with the EU MDD . We’re not certified to 13485 but our software development processes are aligned to harmonised standards like IEC 62304 and we have always produced the Technical File for such projects which has been handed over to the client so that they can register the device with the MHRA in the UK. We have an opportunity to develop some software which under the new MDR will be classified as a IIa device but we are not sure if the Technical File structure/content areas that we’ve used for developing class I devices would be sufficient and meet the compliance requirements for developing class IIa device software? We also want to transition to the new MDR and we’re currently unsure how to approach this and was wondering what practical steps we could take to begin the process. Any help and advice from someone more expert on all this than myself would be much appreciated.

Hi,

The advice you received here isn't wrong for the most part, but it ignores the fact that you are not the brand owner (the legal Manufacturer). If I understood correctly, you are a supplier / a service provider (the service = product / software development) to a medical devices Manufacturer. This is true regardless of whether they actually "manufacture" or not. As such, most of the statements made above are applicable to your client, not directly to you. You may, of course, take on some of their tasks under contract (but they remain responsible, in regulatory terms).

With specific regard to Technical Documentation, BSI issued some worthy guidance (they call it a white paper) on the subject, under the MDR, so I'd have a look at that first. It's available from their website for free (no affiliation here). BTW, BSI is currently the only NB already designated under the MDR, but they are designated in the UK, by the MHRA, so not sure what's going to happen with that upon Brexit. Their NL branch is currently only designated under the MDD.

More generally, if you want to fully understand the obligations under the MDR, or the changes from the MDD, I strongly suggest reading the MDR itself. Contrary to common belief, it is accessible to intelligent beings... if you are really after a good understanding I wouldn't go to specific Annexes etc., but rather start from page 1 and read through. You can skip clearly irrelevant parts though, e.g. Articles relating to NB designation etc.

Good luck,
Ronen.

 

[Yodelka]

Hi,

BTW, BSI is currently the only NB already designated under the MDR, but they are designated in the UK, by the MHRA, so not sure what's going to happen with that upon Brexit. Their NL branch is currently only designated under the MDD.

I got the information that TUV SUD has been designated under MDR this week.