A very-high-up person from a Notified Body recently responded to my LinkedIn post about Notified Bodies sometimes having weird expectations:

Quality of application document is a critical point and not because NBs have weird expectations. The contents of a technical documentation are laid out in the MDR, Ax II and III, have a look at it or join a training of Team NB.

Without going into the sarcasm there (yes, I know the annexes, no, I don’t want to attend a training), this made me think: With our consultant clients, we do see some pretty insane auditor expectations. On the other hands, here’s this person, very high up in a notified body, thinking that audits are totally objective.

How can we improve this situation? As always at OpenRegulatory, the answer might be transparency.

So we went ahead and collected all instances in which auditors came up with weird expectations or even contradicated one another.

The goal here is not to rant (well, maybe.. a bit), but to hopefully arrive at some sort of consensus so that future medical device startups have to go through less of these irrational discussions.

“MDD Class I Legacy Devices Have to Sign New Declarations Of Conformity For Each New Release”

Source: Freelance auditor at a Notified Body

MDD Class I devices which are currently still on the market are so-called legacy devices. In simplified terms, the idea is this: If you were on the market before the transition “cutoff” date in May 2021, you can remain on the market for a few more years (I’ll omit a ton of details here) - but you can’t make any significant changes to your device.

The common understanding of all humans on the planet so far was that, well, your declaration of conformity has to be signed before the cutoff date in May 2021, and you must not create new declarations of conformity fur future versions while your device is still a “legacy device”.

If you have to make changes to your declaration of conformity (e.g. changing the versioning scheme of your software medical device), you can create an “amendment” to your declaration of conformity.

This understanding, and this procedure was confirmed in two (!) of our competent authority audits.

However, this one freelance auditor had opinions of their own. They expected each new product version of a MDD class I legacy device (no significant changes!) to result in a newly-signed declaration of conformity, dated after (!) the cutoff date.

It was impossible to convince this person, so the company went ahead and created such declarations of conformity. The probability that another auditor will give them a lot of trouble for this in the future is pretty much 100%.

“A MDR Quality Management System Must Have a Minimum Number of SOPs”

Source: Freelance auditor at a Notified Body

This is as insane as it sounds.

A quick primer: The various regulatory requirements require you to, well, do certain things, like handle customer feedback and notify the authorities if patients get hurt (many useful things!).

How you do things is up to you, but you need some proof for that. Typically, companies describe their processes in documents, i.e. as text or flowcharts. So you might create a flowchart for how you handle customer feedback and how you notify authorities, and show those to your auditor. So far, so good.

Now - how many flow charts or documents you create, that’s entirely up to you. You could create one large flowchart which covers both customer feedback and notifying authorities. Or you could create two separate flowcharts and somehow link them. Up to you. As long as you cover the regulatory requirements, you’re fine!

That’s the common-sense interpretation.

Unfortunately, this one freelance auditor had their own interpretation. Their interpretation was that you must have a one-to-one mapping of regulatory requirements to processes. So, in the example above, you must have two flow charts, and if you have less than two flow charts, you’re already not compliant, regardless of their content.

By now, it’s probably obvious that this is absurd and not rooted in reality. There’s also no regulatory requireents whatsoever to support this claim. We even have data to back this up: Our SOP Integrated Software Development, one of our free templates, actually combines regulatory requirements of (you guessed it) software development, risk management and usability evaluation, and it has passed multiple audits. And that totally makes sense, because those activities are intertwined.

But if you’re stuck with an auditor who holds these opinions, you’re screwed.

“Only Our Own Trainings Are Accepted As Proof For Qualification”

Source: A Notified Body in Northern Europe

Generally speaking, medical device manufacturers need to prove that their employees have the right qualifications for their jobs. And, for compliance people in particular, this might include having proof that they have knowledge about the relevant standards - you know, the ISO 13485, IEC 62304, and so on.

There are various way to prove this knowledge. The most common way would be to attend trainings and receive nice-looking PDFs as proof that you’ve attended those (we offer that via our Wizard, too!).

There are no formal requirements for which provider you have to choose for these trainings as long as you get some sort of proof (again, a nice-looking PDF) that you’ve attended the training and that it covered the relevant standards (IEC 62304 etc.).

But the “medical device compliance training” industry is huge and notified bodies don’t want to be left out of the action. Accordingly, they also offer trainings. You think it sounds shady that the same entity offers both training you and auditing you on regulatory requirements? No, it’s totally legit, because the notified bodies have created separate “sub-companies” which offer the trainings which are “totally independent” even though bearing the same name. I suppose you have to take their word for it.

But you don’t have to choose a training from a notified body. Again, you could attend any training by any person or company which covers the relevant topics.

At least that’s how most people see it. One notified body in Northern Europe however had their very own opinion on this and they only accept it if you attended trainings at their own company. You attended a training at a different company or even notified body? Bad luck, you’ve got to do it again at this notified body to pass your audit.

“A Manufacturer of a SaaS Medical Device Is Not a Medical Device Operator”

Source: Competent Authority auditors

Germany seems to have a knack for adding additional requirements to already-complex EU requirements (that’s why our employment contracts are still on paper, but that’s a story for another day). In this case, there are additional laws for operators of medical devices (MPBetreibV).

First off: We’re not lawyers, so I won’t state what our opinion on this is. But the question is this: The law mainly targets hospitals as those clearly are “operators of medical devices”. So far, so good.

But what about a company which brings a SaaS (Software as a Service) medical device to market? Something like a cloud-hosted software which isn’t hosted locally in hospitals?

Intuitively, that would make the manufacturer the operator of the medical device. That makes sense, because, well, those are the people who maintain the servers, push the updates, etc. And this is also the opinion of an auditor of a notified body who we discussed this with. Let’s call this the “common-sense opinion”.

Now, somewhat surprisingly, we recently met auditors from a competent authority who had an interpretation which was the exact opposite. In their opinion, only hospitals can be medical device operators.

So, if it’s a SaaS, each hospital which would be using would become a medical device operator, while the manufacturer would not be one. Weird interpretation, but it still could make sense. Or can it?

No - because, if the SaaS is targetted towards patients (like.. all DiGAs), who is the operator then? Patients are clearly not hospitals, so they’re not the operator. But the manufacturer is, according to the competent authority, also not an operator. So, in this case, there simply would not be an operator at all. What?

“Connection Adapter Software Is Part Of The Medical Device”

Source: Lead Auditor at a Notified Body

Medical device software almost always has to interface with other software like electronic health records. This creates a conundrum: If you sell your software to many different hospitals, you have to create many different “connection modules” to connect to their systems, many of those after your actual medical device software is certified. Are those connection modules part of your medical device?

Interpreting the guidance documents, the answer likely is “no”. The short version here is that if those connection adapters only do “stupid” forwarding of data without any logic of their own, they are not medical devices at all, and therefore also not part of the medical device.

Unfortunately, it seems to be a free-for-all when it comes to interpreting this. We’ve literally seen all possible interpretations here: A lead auditor at a notified body said they are part of the medical device because “the medical device can’t exist without it” (hm). Another auditor at the same notified body (yes, seriously) said they’re not part of the medical device because, well, they only do simple forwarding (likely the correct answer). Finally, we’ve heard of startups which either described them as “class I acccessory” devices, or even included them in their class II devices. It’s a gigantic mess.

Can This Mess Be Cleaned Up?

So, there you have it. Those are some of the weird aspects we’ve encountered in which auditors come up with their own interpretations and contradict each other.

In a perfect world, we would collect them here, have a constructive discussion and come up with a consensus on what the “ground truth” would be. I’m not sure if that’s possible.

In the meantime, remember these things and be prepared for when your auditor might come up with their own ideas. It’s always good to ask them what the exact regulatory requirement for their opinion is, i.e. “where does the standard state this?”. But, sometimes, even that won’t help. Good luck.