I’m currently being approached by many startups who want to bring their medical software to market while the MDR is not yet in effect. So here’s a quick write-up of what needs to be done.
MDD, MDR, Wait What?
Okay, let’s start from the beginning and simplify things greatly, as always.
In the EU, software as a medical device (see the MDR definition of medical devices) was regulated under the “old” regulation called MDD. Based on certain criteria, medical devices are classified into distinct classes (I through III). For classes II and III, your company and product needs to be audited by a so-called Notified Body (TÜV SÜD, TÜV Rheinland, Dekra, etc.). For class I however, that’s not the case - you just create the required documentation and apply the CE label to your product yourself.
Sounds insane? Well, that’s the way things are. Now, obviously, if you tell all those class I companies to write their regulatory documentation but don’t check on them, they will commonly revert to the predictable human behaviour of not doing it. Not sure if the EU people in Brussels noticed this, but in any case, they added the so-called “Rule 11” to the MDR which up-classifies almost every medical software from class I to class IIa.
So, again: For most medical software, including apps, this will mean that they will move from class I (MDD) to class IIa (MDR).
Why is this a problem? Firstly, you now need a Notified Body which is expensive and time-consuming (long wait times). Your product release cycle will be much slower as you now have to get substantial changes to your software approved by them first. And that’s assuming you got the initial QMS (company) and technical documentation (product) audit done already in the first place.
And, to add some real-world experience, if you’re class I now, chances are, your documentation is somewhere on the spectrum from “not too great” to “non-existent”. That’s the larger problem. Creating compliant documentation and processes for a new startup is doable in a reasonable amount of time; cleaning up documentation of months or years of an existing, larger company is really painful.
But here’s the upside: If your software would have been class I under MDD, you can still do the self-certification dance until May 25th, 2021, 23:59 o’clock. And it gets better: You can continue placing that software on the market (i.e., shipping it) until May 25th, 2024.
MDD - MDR Transition Problems
It’s not all great though. Here are the problems you’ll be facing:
1. You need to get everything done by May 25th, 2021. That means placing your software on the market (at least the first version), getting all documentation done and submitting it to the regulatory product database (in the EU probably soon EUDAMED, currently still DIMDI in Germany). So if you don’t have any chance of meeting that deadline, you’re out. Don’t get bogged down by documentation though - the main factor here should be how fast you can finish development of your product.
2. You can’t make substantial changes after May 25th, 2021. This is the bigger problem. While you can happily make substantial changes to your product before May 25, 2021, you can’t do so afterwards. What is a substantial change? Not super well defined. You could probably write a PhD thesis about it. [Here’s my assessment][substantial-change].
I’d apply common sense to the “substantial change” situation while trying to be conservative. If your Intended Use changes, that’s always a substantial change. So, if your app is targeted towards patients with insomnia, you can’t publish an update which helps with their diabetes. Most cases aren’t that clear-cut though. What happens if it’s a major update from a technical point of view (e.g. due to switching hosting providers), but the actual user-facing part remains the same? Ugh.
Will Anyone Check Your Documentation?
In theory, being class I means that you have to adhere to the same regulation and create the same level of documentation e.g. a Quality Management System (QMS) as per ISO 13485, software development and documentation as per IEC 62304. In practice however, things are a bit different. Most companies don’t have very thorough documentation and take the gamble of not being surprise-audited.
Because you “self-certify” and don’t hand in your documents to any Notified Body, there’s no one who will check them. However: You can get surprise-audited by the local authorities. In Berlin, that’s the LAGeSo.
I haven’t had the pleasure of sitting in such an audit myself but know many people who did. From what I’ve heard, the auditors are friendly and reasonable. That doesn’t mean you can get away with having no documentation at all, but it does mean that they may not shut down your business if one or two documents are missing. Instead, they want to see that you’ve understood the regulatory requirements and have a concept of implementing them at your company.
And I think this makes sense: Startups building class I devices typically have a ton of other concerns besides being compliant, and class I software often can’t cause major harm to patients. It’s therefore good to prioritize product quality in general (Is our software well-tested? How do we handle documentation? Do we do user testing?) instead of getting into all the nitty-gritty details of a Quality Management System (Have we tested our email software? Do we have CVs of all employees to prove that they’re qualified?).
MDD Class I “Self-Certification”: The Steps
So, let’s get right to it. Here’s what you need to do. This is essentially a very similar list as the one in the Blueprint for Certifying Medical Software, but it’s been reduced to cater to class I - specified needs :)
Write Your Intended Use
Super important, even for class I. You should have a document which clearly states what your software does and by whom it will be used. I’d suggest you to keep it as generic as possible to make sure that you won’t have to change it after May 25, 2021.
Buy and Read Standards
You should have at least one person in your company who has read the standards and has a high-level understanding of them.
Do Clinical Evaluation
This is probably the biggest pain point and most significant blocker. You still need to write a Clinical Evaluation. As described in the article, you should compare yourself to existing devices. The alternative of getting clinical data before May 2021 will be very, very hard.
Hire or Train Regulatory People
Based on the MDD, you need a Safety Officer - you don’t need the “Person Responsible for Regulatory Compliance” as that’s MDR. In theory, anyone who sells your software and/or talks to customers needs to be trained as Medical Device Consultant, but I’m not sure how thoroughly this is checked.
But you definitely need the Safety Officer as you have to provide that person’s contact details in your DIMDI / EUDAMED registration.
Company-Wide: Quality Management System
You need an ISO 13485 - compliant Quality Management System. From experience, you don’t have to implement all its nitty-gritty requirements but you still should have a high-level understanding of it and cover most parts, e.g.:
- Document control: Is all your documentation in one place and do you have a (useful) way of naming them?
- Development: What’s your development process? Where does your design input come from?
- Verification: Do you test your software?
- Validation: Do you do user testing?
- Complaint and problem handling: What happens if things go wrong?
You might get away with not doing these things or only doing them very superficially:
- Software Validation (= the software which is used during development, not the one which you’ll be shipping): Just list what software you use.
- Employee Qualification: You probably don’t have to prove that all of your employees are qualified.
Disclaimer here: I’m not saying you should skip them, but apply common sense. Your priority should be to understand the ISO 13485 requirements and apply them in a way in which your company can ship higher-quality product.
Product-Specific: Technical Documentation
The documentation above was company-wide, but of course you also need product-specific documentation. Similar as above, this is a condensed version of the more detailed list shown in writing Technical Documentation. At minimum, you should have:
A written-down software development process with documentation. This can be rather simple, but again, apply common sense: Describe where your software is stored (GitHub, GitLab, etc.), your (git) branching strategy, how you do testing (Continuous Integration?), how and where you document code, where you deploy, etc. Think of it like what you tell a newly hired developer when they join.
So, you need two things here: A document or flowchart which describes your process, and the documentation which results from that - GitHub / GitLab issues, pull requests, Continuous Integration test reports, code documentation, etc.
Here’s the full 62304 walkthrough which is much more detailed than what I listed above. So apply caution and don’t get lost in details:
A risk analysis. In theory, you also need a documented process here. Personally, I’d heavily prioritize understanding it and actually doing risk analysis regularly instead. So, I’d have an up-to-date risk table in which the most important risks of the product are analyzed. I’d guess it should have 15-40 entries or so. Not less than 15, and definitely not 100.
Again, the walkthrough here is more detailed. Priotize understanding what a risk analysis is and actually doing it.
Usability Testing. Again, in theory, you need to be fully IEC 62366 - compliant, but in practice, you should understand what that means. The biggest part (in my opinion) of 62366 compliance is the actual user test (which also covers the validation requirement of the 13485), so that’s what I would prioritize heavily.
Once your product is mostly done or you have a similar prototype, do a user test to see whether people can actually use your software properly. Most importantly, you’re also trying to detect risks here - do they use it in a wrong way which results in hazardous situations?
Coming soon: IEC 62366 Walkthrough
Declaration of Conformity
Finally, fill out a declaration of conformity and sign it. I’ll upload a template for this some time, but feel free to find your own. You’re done! :)
After Class I “Certification”: What Can You Do?
Now you’re done, but what does that mean? Simple:
Before May 25, 2021, you can happily make changes to your product (including its Intended Use) and ship it. Don’t forget to adhere to the regulatory requirements though (user testing etc.).
After May 25, 2021, you can only make changes which are non-substantial. You can’t change the Intended Use. Again, what this means on a technical level is up for interpretation. To be on the safe side, you could only ship bug fixes and minor improvements. Or, if you’re sure a new feature still falls within the scope of your Intended Use (you did keep it generic, I hope?), you can ship that, too. It’s tricky.
Clearly, after May 25, 2021, you are locked in and can’t change your product substantially. I wouldn’t go as far to say that this can kill your company, but it can definitely put you in the hazardous situation of either “we don’t change our product any more” vs. “we risk changing it and going against regulations”. That doesn’t sound like a good place to be in.
Also, there’s the hard deadline of May 25, 2024, after which you must take your MDD class I product off the market.
It therefore would make a lot of sense to prepare your documentation and audits for a class IIa product under MDR in the meantime. See the Blueprint for the more in-depth guide on that. As soon as your product is certified under MDR, you can happily ship it even after 2024. And you’re free to make substantial changes now, but you have to get them approved by your Notified Body first.