Besides curing cancer and achieving nuclear fusion, getting software certified as Medical Device is one of the most complex endeavours known to mankind.
For many knowledge-based tasks, the invention of the internet has been a huge blessing: It enabled humans to retrieve information on how to achieve things. Brew your own beer, create an investment portfolio, build a house in a jungle: All these are things which you can learn on the internet.
Certifying a Medical Device is not one of those things.
Why? Similar to the extinction of the dinosaurs, the truth is unclear. But there are a some plausible theories.
Firstly, not many people certify Medical Devices on this planet. Although many people work in Healthcare, only few companies manufacture Medical Devices and each company only has a select few people who deal with regulatory affairs.
Secondly, many of these people are consultants. And consultants usually have very weird incentives: They bill by the hour, therefore they try to bill many hours. And how can any consultant maximize his billable hours? By having knowledge which nobody else has, and ensuring that that knowledge doesn’t end up in anybody else’s brain. Information is held in silos and access through it is only possible by paying a lot of money.
Thirdly, the regulatory standards of Medical Devices are highly ambiguous and there’s a wide variety of 1) how manufacturers interpret them and worse, 2), how auditors interpret them. If you’re new to this and achieve successful certification for your Medical Device, you’re not very confident that your approach actually was objectively correct. Maybe other companies are doing it differently and that’s the right way?
These three reasons lead to humanity not having much public information on how to certify Medical Devices.
But why do we need more information on this?
Solving Healthcare’s Problems by Solving Regulatory Problems
While many industries have advanced into the digital age, abandoning punch cards, mainframes and fax machines, the Healthcare industry and hospitals in particular still lag behind. Unlike the dinosaurs, which to the best of our knowledge have gone extinct, the fax machine is alive and well within the hospital.
Using old and proven technology is a laudable strategy when ensuring patient safety, but it becomes a liability once the drawbacks outweigh the benefits. That point has certainly been reached - ten years ago?
Healthcare is in dire need of innovation.
Unfortunately, the incumbent companies haven’t delivered. Why? It’s unclear. Maybe they just forgot how to innovate. They’re earning enough money and not losing customers. It’s certainly very hard to lose customers in Healthcare - imagine a hospital trying to switch software systems. Impossible. Interfaces are proprietary or non-existent, lock-in effects are huge.
We need startups. Startups provide a fresh new look on problems which were considered unsolvable. They build a new product, enter the market and give customers a choice - either buy the old, established product or the new, shiny one. If the new one is better, customers are happy to buy it. That’s why people prefer to shop at Amazon instead of crappy online shops.
Unfortunately, entering the market is not easy in Healthcare: You can’t just upload your software to the internet and let people use it. You are shipping to patients, not customers. Any bug in your code may cause someone to get hurt or worse, die.
That’s where regulation comes in. Historically, regulation was introduced when people screwed up and harmed patients. Now, everyone has to comply. Generally speaking, that’s good. Building safe Medical Devices is good. If regulation is a way to achieve that, that’s good.
But for most startups, regulation is an insurmountable barrier to enter the market. There’s no information on how to do it, consultants are expensive and timelines vary wildly.
While we can’t solve all problems, we can solve one: Create more transparency. Let’s see how we get there.
Creating More Transparency on Regulatory Stuff
This should serve as a guide covering everything you have to do if you want to bring your Medical Software to market.
It is highly opinionated. From my experience, startups attempting to certify their software as a Medical Device don’t need more options, they need to know what to do.
Is is also simplified. I prefer covering regulatory requirements in a sane way which is realistic for any company. Instead of creating a ton of useless overhead, I rather risk a minor nonconformity with a picky auditor.
The Procedure
Here’s what you have to get done. This is based on Germany, but also applies to other countries in the EU; most parts also apply to the US.
Company-wide Requirements
You need to implement a Quality Management System in your company based on ISO 13485. That’s a standard.
What does that mean? The ISO 13485 is mainly about processes. It states that your company has to have certain processes which are described there. For example, a process to handle customer complaints. And a process to evaluate suppliers before purchasing things from them.
You need to set up those processes in your company and document them, maybe by having flowcharts or writing them down. You also need to prove that you’re actually adhering to those, so if your customer complaint process says that you always send flowers to your customers, you better do it.
That’s when you’re ready to get audited. An auditor will come in for a few days and check those two things: That you have those processes and are adhering to them.
Once you’ve succeeded, you have a certified Quality Management System and are ready to manufacture Medical Devices. Great!
(Stay tuned for a separate ISO 13485 article in the future)
Product-specific Requirements
For each product you want to certify, you need to create some documentation. Of course, there are more standards for that. The IEC 62304 for your Software Lifecycle, the ISO 14971 for Risk Management and the IEC 62366 for Usability Engineering.
While these standards also make you implement some processes, more importantly, they specify what the output of those processes should be. For example, you need to write a Software Development Plan. And you need to conduct User Testing with your (final) software.
(Stay tuned for separate IEC 62304, ISO 14971 and IEC 62366 articles in the future)
Further reading: