Here at Peercode, not only do we offer regulatory consultancy services for medical devices, we also have our own medical software products on the EU market. That means alongside extensive experience of helping companies get their medical devices MDR certified, we also have first-hand experience of our own — three, in fact. So what are our secrets for getting it right? Let’s find out.

Secret 1

It’s no secret that Peercode currently has three different software products on the market. The Notified Body checks one product each year. Although each product is different, with the first one approved, each subsequent product requires only limited supporting evidence across a 5-year cycle. As we said at the start, we’ve so far developed three pieces of software as medical devices certified under the MDR. Here’s a brief summary of each one:

• MASK-air App is designed for people with allergies and asthma. It helps patients to track their symptoms and sends an alert when there’s a possible warning sign. It’s a mobile application that provides helpful data that a patient can share with their physician.
• IMID Monitor supports patients with rheumatoid arthritis and inflammatory bowel diseases in a hospital setting. They fill in a scientifically-validated questionnaire while waiting for an appointment. The doctor can access this information from a computer, and use it to support discussion and decision-making around treatment.
• Our third piece of software, Atris, connects with sensors – such as a heart rate monitor – reads the data, and sends it to an application that tracks how much people move. The data also gets sent to a dashboard, where a physician has oversight of each patient. This can help inform and aid a suitable rehabilitation program.

As you can see, each product is very different in terms of users, functionality, and application. However, the documentation needed by the Notified Body is very similar. The dossier for each product follows a very similar structure.

For companies with more than one medical device software product, getting the first one over the regulatory threshold is key. After that, you know how to do it. You have the process, and you have the documentation in place. This includes:

• What the software will do
• Who it is for
• How you support the clinical claim

What that means is we can use a template to prepare the dossier for different types of medical software — not just our own, but for other companies as well. This makes putting together the required documentation much easier.

Secret 2

Compliance with the MDR requires a clear outline of the intended use, and intended users – typically doctors and/or patients, and a risk classification - what is the possible harm to a patient. This information determines the scope of your documentation, and what you need to include. Getting this first step right is crucial because it determines the direction of the rest of the documentation.

The second important factor is the medical benefit claim. The Notified Body needs to clearly understand how the software benefits the patient. Companies must quantify and qualify this, backing it up with evidence to support the claim. If the software claims to ‘save time’ this must be proved with feasibility studies, user feedback, and expert opinions.

For example, one of our software products remotely connects patients’ health data – via sensors at home – with a doctor using a connective device. Validating this type of distance monitoring required doctors’ input as to how it benefits their work, plus a usability study to provide evidence that the software is easy and safe to use.

Secret 3

Alongside clarity over the intended use and intended user, the documentation must be easy for the Notified Body to understand. Put simply, to get your medical software approved, it needs to be understood. At the same time, it’s important to use factual information to construct a persuasive argument summarizing what the product does and why it’s beneficial.

Again, unlike a physical medical device, with software these two things may not be immediately obvious. That’s why it’s important to break it down into layman’s terms, testify to the technical side of it, and support it with the evidence needed.

Secret 4

The great thing about medical device software is that development and production are the same thing. Another advantage over producing physical products is that evidence can be taken from external studies and literature – it’s not always necessary to conduct an internal investigation. This can help to speed up preparation of the dossier.

Secret 5

When you have software inside a physical medical device, that’s when things start to get more complicated. If the software and the hardware cannot operate separately, then both the device and the software must be proven to work together.

If standalone software as a medical device physically connects to a third-party physical device, then it’s imperative to validate the connection and transfer of data, but not the physical device itself. This guarantees that the input data is correct and there is no loss or manipulation between leaving the physical device and transferring into the software.

Counting The Regulatory Cost

Under the previous EU regulation – the Medical Device Directive (MDD) – software as a medical device could be self-certified. In effect, this meant that it was unlikely that the documentation would be examined by a Notified Body because it was considered low-risk.

Now, under the MDR, a Notified Body has to check software as a medical device pre-market. Once it’s on the market, the software is liable to inspection by the authorities because it’s considered a higher risk. This creates a push-pull effect.

On the one hand, healthcare providers increasingly rely on medtech devices, which require smart software solutions. On the other hand, medical device companies will start to think twice about investing in software due to the cost of meeting regulatory requirements. That’s why getting the right guidance and support is so important to keeping down costs.

Where To Get The Right Guidance

There are a number of sources for getting up to speed with the EU’s regulatory requirements for software as a medical device. Alongside the EU’s official communication on the MDR, there is also detailed structural guidance available from the MDCG.

However, with the official sources, you really need to go in and assess what you actually need for your product’s quality system. And that takes time. As well as these official channels, there are also communities on LinkedIn that can be followed and include links to post blogs and news about the MDR.

With the MDR and software as a medical device, there’s a lot to learn. Even if you have an in-house regulatory expert, it’s not always easy to get a full understanding of what’s needed and how to package it for the Notified Body. That’s why it’s worth speaking to us at Peercode Regulatory Consultancy.

Talk to a specialist today.