Let me start off with this: The most efficient approach is to document your medical device software once it’s mostly done. That’s because your regulatory documentation, to a large extent, lists the features your software has and the ways you test those features. And given that software very commonly changes during development, you’ll be completely screwed if you start listing all your features and tests, only to see your software change again and having to catch up with your regulatory documentation again. It’s very inefficient.
That being said, after having consulted 150+ medical devices startups, I have observed that their founders generally fall into one of two categories:
- They hear our recommendation to do their documentation once their device is mostly done. They accept this recommendation. They disappear for ~6 months and come back when their device is done. We help them get their documentation done. Everything is very efficient, and everyone is very calm. A good outcome.
- They hear our recommendation to do their documentation once their device is mostly done. They do not accept this recommendation because they have a false sense of urgency and need to do something “right now”, even if it doesn’t make any rational sense. We advise them against this, but they want to do something anyway. They set off and create drafts of their product documentation. Now their product changes a few times during development and they have to re-write their product documentation multiple times. They end up spending 2-4x more time than the founders in scenario #1.
So yeah. Build your software first, then document it. If you fall into group #1, great! If you fall into group #2, well.. I hope I could convince you otherwise.
Next up, let’s look at a few things you can actually already get done, regardless of where your development stands.
Stuff You Can Get Done During Medical Device Development
Clarify Your MDR Class And “Regulatory Strategy”
I hate the buzzword of “regulatory strategy” because it’s used by consultants to organize weird workshops and charge you thousands of Euros for explaining regulations to you (just read all the free stuf on our website instead and check out our free templates).
But in this context, it’s valid to talk about regulatory strategy. Specifically, which medical device class (MDR class) you’re targeting and how you expect to enter the market. Let me give you a few examples so that you see what I mean!
- You’re targeting MDR class I: As a class I device, you don’t need to get audited by a so-called Notified Body. That means you simply create your documentation and, once you’re done, put your device on the market (yes, it sounds crazy).
However! The people who check this are so-called competent authorities. Who is your competent authority? That depends on where your company is located. In Germany, there’s a competent authority in each state (e.g. Berlin). Other countries have nation-wide competent authorities.
But here’s the important part: Different competent authorities have different “interpretations” of what a MDR class I device is. E.g. in Berlin, the authorities think that software can’t be class I, so you’re screwed. In that case, you should move your company somewhere else (yes, seriously).
So yeah. That’s something you need to consider during development if you’re targeting class I. - You’re targeting MDR class IIa or IIb: In that case, there are still some legitimate things you should think about. In some rare cases, when we work with such companies, we actually help them figure out a way in which their device could actually be class I. This is huge because it enables you to enter the market ~1 year earlier and saves you ~50k€ in auditing costs. And, of course, this can be done during development as long as you have a concept of what sort of device you’re developing.
Or, if you do end up as class IIa or IIb device, it makes sense to already think about which Notified Body you’re going to choose (link to our recommendations), reach out to them and set a hand-in date for your documentation in the future.
Start Documenting Your Quality Management System (QMS)
So, roughly speaking, you have to document two separate things for your medical device compliance: Your technical documentation, which consists of product-specific information (features, tests, risks, etc.) and your Quality Management System (QMS), which describes company-wide stuff, e.g. how you train your employees, how you develop software, etc.
So, while it might not be a good idea to start writing your technical documentation now, because your product is still changing, you could start setting up your QMS documentation.
How do you go about that? Check out our free ISO 13485 (QMS) templates and copy them to whatever tool you’re using for your regulatory documentation. Don’t have a tool yet? Check out our eQMS software Formwork which even has a free tier to get you started!
Find a Regulatory Person
Another thing you can do is to find a person for your team who will be handling all the regulatory stuff. In my experience, you do need a person who is accountable for this. Founders tend to get distracted as regulatory work is super boring (yup), so it’s very useful to delegate this.
In contrast to many other people in the regulatory industry, I have some rather unpopular opinions here: Just hire a smart person, regardless of regulatory experience. The best people are those who don’t have regulatory experience, because many people who already are in the regulatory industry have become, umm, weird people. The best hires I’ve seen were literally students fresh out of University (or still in University!) who, for some reason, were excited to learn more about regulatory work (weird) and join a startup (understandable). Here’s a longer post on hiring people.
Conclusion: And When Do You Start Documenting Stuff?
So the big question now is “well, when do you start documenting stuff?”. Here’s my recommendation: When your first software prototype is done. In other words, when you have a mostly-final concept of the features which will be included in your first version.
Then, sure, go ahead an document your software features, tests, etc. – and you likely won’t have to rework them again 🙂
You might also be interested in how long documentation takes and how much all of it costs. Good luck!
