MDR for DiGA manufacturers
This article may be a bit different than my usual ones as it’s a summary of a recent presentation on Jan 25, 2021. While generally a good practices, providing my slides to the attendees seemed quite useless to me, given how minimal my slides typically are. If you find this experiment of summarizing the talk in a blogpost useful, please let me know, e.g. by commenting or liking/clapping.
The presentation was themed with introduction to medical device certification within the scope of DiGAs (the new reimbursement scheme in Germany, in case you’re unfamiliar with it). The second talk of the event was on data privacy/security. So at least that could be excluded from my talk. Still a huge topic. I decided to focus on a few meta topics that are relevant for MDD but even more for MDR devices (whenever I say device, I mean medical device).
European conformity or Chinese export
Last things first: at some point of time you’ll put the CE mark on your device. That means everything else is done, the technical documentation (TD) is created, a quality management system (QMS) setup, and the notified body certificate(s) is/are issued, if applicable. Please know the difference between the European Conformity CE mark and the similar looking Chinese Export. Well, just use it from an official source. Also, “The CE marking must be affixed visibly, legibly and indelibly […]”: please don’t hide it somewhere in the settings. That’s clearly not visible to the typical user.
MDD vs MDR and thoughts on transition period
Second topic was the current state of MDD vs MDR for devices already on the market or in development. Everyone has heard by now that there is a transition period under MDR (Art. 120(3) MDR). Also nearly everyone seems to have come up with the magic trick of getting around that deadline. One of the recurring ideas is to include more indications or features in the intended use and just add them to the actual device later. The argument is that it’s not a significant change because it’s already covered in the intended use. Well, no. That would be too simple. Another recurring idea is to register shell devices where the device is heavily based on content. So you may not change much in the code but add in 95% of the content later on. Well, again, no.
In short: whenever it seems like you’ve found a magic trick consider this to be a significant change. You can surely still do changes to the device after May 26, 2021. But that is restricted to security fixes and maintenance in general. While not every trick may get caught right away, I wouldn’t build a business on this. It will also make your MDR certification harder than necessary.
Talking about MDR: that’s surely a motivation to still finish a marketable device before May 26, 2021 under MDD. Simply because you MDR doesn’t just mean a few weeks or months more of work. You likely don’t have clinical data and a full QMS at that point. Also your TD may not be up to MDR standards. And the 8 months of the certification process with the notified body shouldn’t be forgotten. So, depending on your device and company setup, if you don’t manage to finish your device under MDD, you can likely work/wait another 1–2 years without a device on the market. Pre-revenue they may call it. But it’s more than that. It’s pre-anything in user’s hands. If you read this now without already having started development, you may be running out of time.
Classification of SaMD under MDR
Until recently it seemed that everyone is content with accepting risk class IIa (or higher) for their devices. The discussion to justify all kinds of devices as class I had faded. Well, until recently. Now several people ask again why their device wouldn’t fall class I under MDR. Some argue that their device is not different to the MDD device. Well, that’s true. The different risk class simply comes from different classification rules under MDR. So for the very same device, you will likely have different classifications for MDD and MDR, especially for SaMD/DiGA. The current general interpretation of rule 11 (for standalone software) of MDR Annex VIII is that any device that is used on patients with an existing indication/disease is classified as IIa (or higher). Only devices that are being used on humans without an indication would classify as class I, in other words devices for prevention. So if you have for example a software that helps people treat insomnia, it would likely be class IIa. While if you have a device that helps people with good sleep to maintain their good sleep, that would likely classify as I.
Startup vs medical device manufacturer
That being said, the main part of the talk was about the transition of a startup to being a medical device manufacturer, focus on process, and the manufacturer’s own responsibility. Being considered a medical device manufacturer instead of a startup may sound abstract. One good example that may make it more tangible is the aspect of releases. Some startups care more than others about that. Some have strict processes setup, others don’t. Especially once you enter the transition period as mentioned earlier, you will want to explicitly approve every single change/release of your device to not accidentally release something that may be considered significant. And if the device is listed as a DiGA, you have additional requirements which are actually even stricter (or at least more ambiguous). If you make a release that BfArM considers significant (see checklist) but you released it regardless, you are risking to be delisted.
Importance of processes
Once you prepare for a MDR class IIa process, things will change even more. your notified body will expect you to have a full QMS. That’t not necessarily a bad thing. But it surely means that the “traditional” approach of having one person in the company that “does medical device certification” is finally over. If the auditor would speak to the same person for every process, he would likely be surprised/confused. And he may ask what happens when that person is on vacation.
No one is expecting you to have overcomplicated lengthy processes, actually to the contrary. You should take this as a chance to align your team and setup effective processes.
No one expects that the TD a is magic byproduct or, even worse, something produced after the fact. A good device development process has the creation of the various elements of the TD built in the same way it contains the actual building. Two examples: with a bit of discipline you can setup/use Jira in a way that the user stories that you create anyways for software development would also be regarded as software requirements from an IEC 62304 perspective. And who develops software without thinking about the architecture? Yes, IEC 62304 does not require you to define a software architecture for software safety class A. Still, you likely do it anyways. And, assuming you have not just one deployable (e.g. frontend and backend), then how do you do versioning? So, you may not need an architecture by itself, but you need it to fulfil configuration management requirements. But again, it’s to your own benefit. And it’s not a lot of work.
Responsibility of the device manufacturer
Own responsibility. What does that mean? Basically everything. You as the manufacturer decides (1) what you consider to be a significant change, (2) what norms you consider applicable, (3) the clinical data that you consider sufficient, (4) the necessary expertise in your team, for employees and freelancers/consultants/experts, and a lot of everything else. Of course there are a lot of best practices. Please don’t start questioning whether IEC 62304 is relevant. But what approach are you following for IT security? Especially when you do something new, there may not be any best practices yet. One good examples for this is the DiGAV checklist, which covers topics such as data privacy, data security, accessibility, interoperability to name some. Some of those are pretty specific. But others are terribly vague. No one has the right answer right now. Standards are still to be established. Hopefully soon so that DiGA companies can focus on delivering great devices and establishing them in the market instead of interpreting vague requirements. But still, it’s your obligation as a company to make decisions here. Well, making decisions under uncertainty is a crucial element of entrepreneurship.
About the author
After having worked on medical apps in a startup (software development as well as regulatory) for various years, I currently work with various SaMD/DiGA manufacturers, mostly on regulatory compliance and product strategy. Please let me know if you have any questions or feedback on the article.
Photo by Markus Winkler on Unsplash