Software as a Medical Device. Digital Health Interviews: Wessel Kooyman

We are back with our new episode of Digital Health Interviews, and we’re excited to introduce our today’s guest — Wessel Kooyman.

Introduction:

Wessel Kooyman: Independent consultant, a specialist in software development for medical devices and CE, FDA, and ISO 13485 certification. He has more than 20 years of experience in general software development. Worked as CEO, CTO, Project Manager, and developer in Amsterdam, San Francisco, Paris, and Brussels. Expert in managing development teams and processes, and roadmap management. Entrepreneur-in-residence in the imec.istart program as an expert in software development for medical devices. Startup mentor in the Start It software accelerator program.

What makes digital health development strongly separate from other fields? According to our expert, everything is decided here by clear rules: “In regular development, web or mobile, there are certain things you should do, such as testing or documenting, but you can get away without doing these things. In medical devices, you cannot do that: there are rules that you must follow. Otherwise, you cannot be on the market.”

Wessel worked with some of the startups: Moodbird (a device for breathing exercises) and Helpilepsy (Neuroventis) (software as a medical device in the neurological sphere) among others. We decided to discuss in detail what such term as SaMD (software as a medical device) includes.

Wessel Kooyman: “SaMD is a software which is a medical device. It can be a mobile app, or a web-based application. All of them follow the same rules as other medical devices. Just because you are software, not hardware, it doesn’t mean you are not a medical device. You still have to follow a million rules. It’s a very quickly growing space because software is growing bigger everywhere”.

We talked about the processes of developing a medical device and software for it. According to Wessel’s words, both in the EU and US there are a bunch of regulations that tell you what to do with all the requirements. First, you should write your specifications; second, you think about risks: what kind of safety risks your device has. Then you start coding — and on the base of that, you write test cases, test your software and finally release it. Your work depends on team size: usually, functional and business analysts write early requirements; design specifications are made by architect senior developers. You also need a product owner who thinks from the business point of view about what you need to build first. QA engineer who may not be in the development team will do the test-case writing based on the requirements you defined, and developers are fixing all the bugs.

Wessel Kooyman: “I recommend to everybody, who even not working in medical space, to spend time and money to have a QA engineer. You’ll find so many bugs that your client would not ever plan! I mean both manual and automated testing.”

If a new developer has joined the team, he must also go through and study all the necessary documentation for the processes: “In general, there’s a bunch of internal training you must create for your organization. People must follow it, and you must document them. To create more complex software products (something with many moving parts) it makes sense for them to work their way through the documentation.”

Everyone is talking about the agile, iterative approach, especially concerning startups. They can pivot several times in just one year and that’s normal for them. But when we talk about medical devices, especially some critical ones like insulin pumps, for instance, can we use an agile approach?

Wessel Kooyman: “People often think that the agile method is somehow dangerous because the safety requirements are so high but I’ve seen the opposite. Agile allows you to build features one by one. All the safety-related things have to be built but you can do it later when you have a perfectly functioning device. What’s also nice about agile is that you are reducing risk. Big waterfall projects tend to be the subject of your work for years and that’s demotivating; with agile you see the result very often. It manages to make your team much happier.”

Next, we brought up a very pressing question for every digital health startuper: should founders consider all the regulations and needed certifications while building the architecture from the very beginning of the development or it could be done later on?

Wessel Kooyman: “I don’t think I’ve ever seen a startup that started following the regulations created for bigger organizations. Just start building your product in a normal way — and later on, you’ll add the regulatory stuff. Is it a terrible thing to do? No, because it’s a money thing. If you want to follow the regulations, you need to spend money for regulatory consultants, and your investors may help you with it when they have an actual product to look at. They understand that regulations need money and co-founders probably won’t have them in their pockets. To start all over from scratch, if you did something wrong, is not a problem. Rewriting is probably always going to be a part of a startup’s development story.”

Wessel worked with two types of certifications — EU MDR (European Union Medical Device Regulation) and US FDA (Food & Drug Administration): “They are both really tough, but they should be so. They classify different medical devices and associate their risk level. They understand that saying “no” all the time is not useful either, so they try to be smart about how much they ask. All these regulations have been made for large companies that have been in business for many years. For startups following these rules the shoe never gonna fit: it will always be very painful and nonsensical, but this is a part of the process. They would have to rewrite the regulations for startups, but it won’t happen. Now it’s a system that works: it’s not great, but it works.”

FDA is more sensible: they have a whole set of guidance documentation that is super-helpful. In the US people tend to be more decisive, and they spend more money on businesses. In some ways, Europe is more modern, but it is less startup-friendly.

And traditionally, at the final of the episode, catch recommendations for startup founders in digital health.

Wessel Kooyman: “Don’t be discouraged! In HealthTech, you have the pitfalls like regulatory, clinical trials, etc. Keep in mind: it means that you have fewer competitors! It is easier to operate in this space: there are a lot of life-science investors who know all the obstacles better than you. Just be aware that your market differs from the general tech one. Do your thing, work hard, and focus!”.

Our previous episode was with Nick Guldemond: The Biggest Problem of Digital Solutions in Healthcare.