Efficient way to manage different country Medical Device Regulations

[QAengineer13]

I need some guidance pertaining to an efficient way of managing different countries regulations applicable to medical device, I would highly appreciate if you can share some ideas/suggestions about handling this!

Many thanks!

 

[Sarah Stec]

What do you mean by "manage"? What would you like to do? Do you want to monitor for changes in the regulations? Be able to incorporate as many regulatory requirements as possible into your system/product?

If you're new-new to the different regulations, it may be helpful to make a table of the different requirements (10k-foot view) to help see where the similarities and differences are - break it down into manageable parts. For example, everyone has quality system requirements (sometimes they call it different things), product documentation requirements (sometimes they call it different things), ongoing requirements, etc. Figuring out where you can re-use things and where you need to generate separate documents is a big part of it.

 

[Mark Meer]

I'd suggest either of the following 2 approaches (or combination, as suitable):

1. For any particular process, list all requirements for each market, and develop your system procedures to reflect the strictest requirements.
- An example of this is record-retention periods - our system procedures simply require the strictest requirements amongst all our markets (not a big deal, because most of our records are maintained electronically).

2. Create general procedures, and in an appendix or table specify any additional or particular requirements needed for specific markets. For example, our Post-Market Vigilance procedure has a general requirements for how we handle reporting, recall, advisory notices etc., and then an appendix describing any additional or variant instructions/forms/information/timeframes etc. that are unique to each market (Europe, US, Australia, Canada,...etc.).

 

[QAengineer13]

What do you mean by "manage"? What would you like to do? Do you want to monitor for changes in the regulations? Be able to incorporate as many regulatory requirements as possible into your system/product?

If you're new-new to the different regulations, it may be helpful to make a table of the different requirements (10k-foot view) to help see where the similarities and differences are - break it down into manageable parts. For example, everyone has quality system requirements (sometimes they call it different things), product documentation requirements (sometimes they call it different things), ongoing requirements, etc. Figuring out where you can re-use things and where you need to generate separate documents is a big part of it.

Hi Sarah,

Great questions! let me try to clarify my earlier post, Our QP's already have the key markets like US, Canada, EU, Brazil and Japan regulatory requirements hardwired ( for ex, the Design control, MDR, Recall, Complaints etc) this question is more about managing other countries except the major one listed above changing regulations from a process perspective. If you can help me out with your previous experience the figuring out " re-use matrix" kinda document, that will be really appreciated! Many thanks

 

[QAengineer13]

I'd suggest either of the following 2 approaches (or combination, as suitable):

1. For any particular process, list all requirements for each market, and develop your system procedures to reflect the strictest requirements.
- An example of this is record-retention periods - our system procedures simply require the strictest requirements amongst all our markets (not a big deal, because most of our records are maintained electronically).

2. Create general procedures, and in an appendix or table specify any additional or particular requirements needed for specific markets. For example, our Post-Market Vigilance procedure has a general requirements for how we handle reporting, recall, advisory notices etc., and then an appendix describing any additional or variant instructions/forms/information/timeframes etc. that are unique to each market (Europe, US, Australia, Canada,...etc.).

Hi Mark,

Great suggestions, thanks! If you don't mind can you share with me an example of the variant of regulatory drivers required for markets other than US, UK, EU and Japan.

 

[Mark Meer]

If you don't mind can you share with me an example of the variant of regulatory drivers required for markets other than US, UK, EU and Japan.

The MDSAP model is a great starting point.

It is essentially a complete audit model in which particular country deviations/variants (for US, Japan, Brazil, Australia, and Canada) are explicitly stated.

EDIT: Whoops, my bad. I see now you were requesting for markets other than the US, UK, EU & Japan. Unfortunately, these are the only markets I'm familiar with. As far as other ones, you may have to approach a consultant (as the regulations are often not available in English! )

 

[QA-Man]

Hi Sarah,

Great questions! let me try to clarify my earlier post, Our QP's already have the key markets like US, Canada, EU, Brazil and Japan regulatory requirements hardwired ( for ex, the Design control, MDR, Recall, Complaints etc) this question is more about managing other countries except the major one listed above changing regulations from a process perspective. If you can help me out with your previous experience the figuring out " re-use matrix" kinda document, that will be really appreciated! Many thanks

That is something I would really like to see.

Years ago I posted a correlation matrix on elsmar here. I would love to put together something along the lines of what your looking for. Where do we start?

 

[Sarah Stec]

If you can help me out with your previous experience the figuring out " re-use matrix" kinda document, that will be really appreciated!

That is something I would really like to see.

Sorry I was away. I don't really have one that speaks specifically to your purposes. But if I were going to make one that was more operational, the top labels would be all the different "requirements" at the different development and submission stages. So for example, thinking of the documentation requirements, some headings could be "DHR? DMR? DHF?," "Specific requirements for DMR/DMR/DHF/TechFile/STED," "Length of time to keep records after device off market," "Length of time to keep record for devices on the market," "Documents needed to register," "Documents needed for regulatory submission," and so on.

To me it would need to be broken up into different tables depending on the type of requirement (design, documentation, servicing, QMS, etc.) because otherwise it would be too nuts for even the most excel-minded of us.

You could start out by keeping it high-level (if you just need understanding instead of for operational purposes), but I personally would "feel better" going more granular since you really have to follow all the requirements for regulatory submissions instead of ballparking it. Or if you know your system well enough that a higher-level table would suffice, then cool.

I hope that this is helpful!

 

[QA-Man]

...So for example, thinking of the documentation requirements, some headings could be "DHR? DMR? DHF?," "Specific requirements for DMR/DMR/DHF/TechFile/STED,"...

I have always made the Tech File a simple 2-3 page reference document that points to the DHF, DMR, and declaration of conformity. Those three things cover everything that goes into a tech file.

 

[Sarah Stec]

Those three things cover everything that goes into a tech file.

That works as long as that's what the specific country's regulations say. I would double-check that, for the countries you're thinking of, that a STED = Tech File = DHR+DMR+DOC. Off the top of my head I have no idea if this is true or not, but I would still double-check. Especially for the countries that may require you to physically send in giant binders of information.