The following is an edited transcript of JAMA Software's interview with Sat Ketkar, Principal System Architect & Engineer here at Velentium, regarding the EU's new Medical Device Regulation (MDR). This post is also available on JAMA's blog.
In what Deloitte is calling the most significant change to medical device regulation since the mid 90s, the new European Medical Device Regulations (EU MDR 2017/745) implementation date is fast approaching.
The new regulation, which emphasizes patient safety, traceability, and transparency, will impact medical device developers, manufacturers, and suppliers of all sizes across Europe, and will require fundamental changes throughout the entire device lifecycle.
In order to better understand the regulation and its impact on our medical device customers, we sat down with Satyajit Ketkar, Principal System Architect & Engineer at Velentium, to learn more about what MDR is, what medical device developers can expect, and what they should be doing to prepare prior to the May 26, 2020 implementation date.
Jama Software: What is EU MDR and what can medical device developers in Europe expect?
Satyajit Ketkar:
MDR stands for Medical Device Regulation. It combines and replaces the existing directives. Once the MDR goes into effect (on May 26, 2020), the existing directives will be obsoleted and invalid. All medical device manufacturers will be required to comply to the MDR. Right now, there are three different directives: The Medical Device Directive (MDD), the Active Implantable Device Directive (AIMDD), and the In Vitro Diagnostic Devices Directive (IVDD) — The EU governing body took two of those —the MDD and the AIMDD — combined them together and brought it to the next level to make it a regulation, which means that it’s extremely explicit and binding. There’s also the IVDDR, like the MDR and will replace the IVDD. The MDR is also harmonized with a lot of the latest standards. EU MDR is supposed to provide the medical device manufacturers a much more comprehensive regulatory guidance on how to manufacture a medical device. But it goes way beyond that, it goes from phase-zero feasibility, all the way through end-of-life (EOL) of the device. There’s a lot of emphasis on clinical, post-market surveillance, how to handle complaints, auditing, review cycle – whether it’s three-year or five-year. There’s a lot more content in there. It’s a pretty large document. It’s supposed to be in the same line as the data protection regulation (GDPR).
Jama Software: Why are they implementing new regulations around medical device development?
Satyajit Ketkar:
They’re basically pushing these regulations up to a level where the ambiguity and the ‘legalese’ is taken out. In the past, a directive was set out through the EU legislative body from Brussels, and then each competent authority for each country would interpret it in their own way. Each of the notified bodies, like BSI, TÜV, or DEKRA, had their own interpretation of the directive. So, if you’re a legal manufacturer, you could go to each one of these bodies and get a different implementation of the directive. What this new EU MDR regulation is supposed to do is to clear that up. Everybody now operates in the same manner, in the same language. And because of that, the regulation is large. Whereas the MDD about 60 pages and has 23 articles and 12 annexes, the MDR is about 175 pages and consists of 123 articles and 17 annexes.
Jama Software:
What are the top things that you suggest medical device companies do to prepare for the new regulation?
Satyajit Ketkar:
Overall, one of the first things I would recommend any medical device manufacturer do is to read the articles that talk about device classification and understand where they fit in.
If you’re an existing manufacturer of a product that’s already out in the market that falls under either the MDD or AIMDD, you’ll need to understand where you fall on the new spectrum. You must understand if your medical device still falls under the same classification, or if it has changed.
Most likely, they’ve gone up in classification. If they were Class 1R or Class 1M, now they’re Class 2A. If they were Class 2A, they’re now Class 2B. If they were Class 2B, they’re now Class 3. And of course, the current or future AIMDs remain as Class 3.
So, what does that mean? That means that the rigor of their development processes and the evidence that they must maintain, the DHF (Design History File) records and what they must provide has just gone up by quite a bit. When these directives were originally written back in the ‘90s, a lot of the technologies we’re working with today didn’t exist. So, to capture a lot of that, they have up classified (changes to the rules for a device classification, see above). This is especially true for electrical hardware, firmware, software, cybersecurity, and the mobile applications. The rules and expectations for these areas have gotten more explicit and stricter.
Jama Software:
It seems like a big part of MDR is that there’s going to be more traceability needed, unique identifiers, and more labeling for each device. Do you see that impacting the way organizations develop medical devices? And what’s the best way to capture that information, or anything else related to post-market surveillance?
Satyajit Ketkar:
So, for the UDI implant card, etc., that’s new, and wasn’t there before. So, everyone’s starting from scratch.
Some people were kind of doing UDI (Unique Identification Number) labeling in the Instructions for Use (IFU) or maybe the eIFU, but it wasn’t to this level of rigor. You must now maintain vigilant records for all of this, for the entire life of the product including part of the post-market. There’s supposed to be a whole database that they’re putting together to keep track of all the vigilant reporting and the post-market reporting, that’s called EUDAMED. There are now updates to the Med Dev guidance(s) on clinical and post-market that are going to be referred to within the regulation. So, I would recommend that manufacturers continue to follow and comply to that. Beyond that, it’s pretty much the same thing.
What’s changed significantly is the clinical follow-up. There’s a whole new guidance on clinical safety and performance that they must maintain, which is part of this UDI tracking and vigilant tracking. Also, there is a periodic clinical evaluation that must be conducted. There’s a periodic safety and performance report as well that needs to be updated that must be included in the vigilance and post-market surveillance. These, and the UDI, are all new with MDR. Before, you would do this once in your three or five-year review cycle, and then that was it. Now, you must basically maintain these all the time as part of your post-market surveillance.
This doesn’t introduce a development burden, but it is a lifecycle burden. You must maintain these throughout the life of the product, which could be 15, 20 years, especially if it’s an active implantable, a pacemaker, or any sort of a therapy device.
One of the other things that I would recommend on the regulatory side or the system side is to review Annex 1, which contains the safety and performance requirements called GSPR (General Safety and Performance Requirements). The MDD has a set of 13 Essential Requirements (ERs), and the AIMDD has 16. The MDR has 23 GSPRs. This might seem less overall but each one of these requirements has 10 to 30 sub-sections that you must adhere to. So, in reality, the requirements have more than doubled.
Typically, what happens is that when somebody in a regulatory group or clinical group puts together their submission package, they’ll review all these essential performance and safety requirements to make sure that they’ve got all the documentation or all the deliverables. They’ve gotten very explicit as to what you need to provide. One example, specifically Section 17.2, which talks about electronic programmable systems and software. They’ve gotten specific about cybersecurity. They’re catching up with the FDA on cybersecurity and software lifecycle. That’s just one example, but there’s a whole bunch of other ones in there. These are new. So, that is something that they need to be aware of as they do their preliminary risk assessment and overall risk management to comply with ISO 14971. These will be additional inputs for decomposing their system requirements. They need to be aware of the new and existing requirements.
Jama Software:
Do you think MDR will have an impact on the way people create and approve requirements? Do you have any thoughts on how the requirements management process might change?
Satyajit Ketkar:
I’m moderately confident that when it comes down to a very specific phase(s) of the development lifecycle, where you’re decomposing requirements and creating your traceability, from design, implementation, through to verification, that it should stay the same. It’s just the details of what you’d have to maintain that are going to change. The process should stay the same. Because remember, there are two parts of what you do: You create a DHF to maintain for yourself as a manufacturer, and then there’s a subset of that that you send to a notified body. The burden of what you must maintain for your own records goes up quite a bit. The process stays the same. It’s just what you must keep track of now that has gone up. The traceability is going to go up a little bit, but the process of decomposing requirements to subsystem, technical, and doing the architecture design, etc., all the current and standard processes should stay the same.
Jama Software:
Do you see this impacting the way global companies communicate or collaborate as part of MDR?
Satyajit Ketkar:
Yes: it’s going to require quite a bit more communication. You must stay aligned a lot more closely because there’s a lot more burden. There’s a lot more meat on the bone you must provide. So, if you have a distributed team across multiple regions, you need a central repository to maintain all these documents.
Jama Software:
You mentioned the DHF and that burden of proof is going to really be on the company. Does it impact the way folks adhere to ISO 13485 or Quality Management Standards at all?
Satyajit Ketkar:
No, it should not. Since it is a brand-new regulation, one of the things they’ve done with the MDR is adopt all the latest harmonized standards. That includes the latest QMS standard, latest risk management, etc. So, if you’re up to date on those, then you should be fine. You should not need to change your QMS to adhere to the MDR as long as you are maintaining the state-of-the-art.
Jama Software:
You mentioned doing earlier risk management following ISO 14971. Are there any impacts to the risk management process?
Satyajit Ketkar:
No. It’s kind of the other way around. MDR has taken account for the updates to all these other standards, especially the updates to risk and QMS. So, if you follow the MDR and you’re up to date on your revision of these other standards, you should be fine.
Jama Software: Is there anything else that you think we missed, or you think should be top-of-mind related to MDR?
Satyajit Ketkar:
I want to be very specific about what I just said earlier in following the harmonized standards and maintaining the state-of-the-art. If you’re not up to date on the latest standards, for example, if you’re not following ISO 14971:2012, or if you’re not following QMS:2016, if you are behind and you want to jump up to the MDR, you’re going to have a pretty heavy lift because you must comply to the latest revisions as well. It’s all included in the harmonized standards list now as this list has been updated. So, if you’re already doing it (not just complying to the current harmonized standard but aware of the state-of-art), then you’re fine. If you’re not, there’s going to be some uphill climbing that may be required.
What’s typical in my experience is that people try to keep up with the standards more often than the regulations. But they’ll see a big jump in the regulation, and they don’t want to jump straight into the regulation and find out that they’re still back in 2006, they haven’t revved up to the latest one (typically the state-of-the-art), and they’re stuck. So, just want to make sure that manufacturers are aware of that.
Jama Software: How do you think a dedicated requirements management platform like Jama Software fits into all of this?
Satyajit Ketkar:
If you’re already using Jama Software, you won’t have to change the process too much. The only thing that this new regulation is going to change is that people are going to want to use Jama Software more because it’s going to become necessary. There’s just too much from a QMS perspective and a development process perspective to try to do manually.
Because of this new regulation, it’s going to slow down their development lifecycle at first, because they are now learning about this new regulation. On top of that, if you’re doing things manually, if you’re using Excel spreadsheets or Word documents, whatever it may be... You might have a very simple project, but now you must add that manual process burden on top of this new regulation. So, it would reduce that process burden greatly if you had a solution like Jama Connect that would handle a lot of this for you. If you could just enter in all your requirements into a lifecycle management tool that then allows you to create trace tables, allows you to create upward, downward decomposition, and presents that in a very clean way where you can export it to a DHF artifact. That saves time and effort.
That’s the whole point, is to save time, because you already are in a process and a regulation change. Tools like Jama Connect will accelerate that because I do foresee a major slowdown in the lifecycle of medical devices with this new regulation... especially for startups. They’re going to have a tough time picking this up. So, to have a platform like Jama Connect out there to aid in this is going to be very important.
Jama Software: What resources are available to people that you know of to help them comply with the new standards?
Satyajit Ketkar:
Most of the approved, certified, notified bodies in Europe — some of the ones that I mentioned before like BSI, TÜV SÜD, DEKRA — are a great resource. They should have a quick cheat sheet on their website. You can also go online to any of the medical device journals, and they have a pretty good high-level breakdown of MDR. It’s more on the regulatory side than a development-process side, but it gives you the breakdown of what articles are necessary, what annexes need to be reviewed, and what order to do it in.
Satyajit “Sat” Ketkar’s career encompasses nearly twenty years of electrical, firmware, software, and systems engineering experience, including seven in medical device design and two with a European Union notified body conducting device reviews and audits for safety, quality, performance, and security.
