Problems implementing ISO 13485 for Software-Only Medical Device Manufacturers?

[Marcelo]

I know there´s some Covers working for software-only medical device manufacturers (when the manufacturer produces only medical devices which are software).

Have you had any problem when implementing ISO 13485? For example, are there clauses/requirements which might be non-applicable/difficult to implement/weird?

 

[c.mitch]

Hello Marcello,
I think you ask this question because the ISO 13485 is going to be updated

Software in medical devices is the heart of my job. We had problems when setting up the standard with:
-purchases:the clause 7.4.1 is not easily applicable when your purchase only CD's for production. So we have a purchase procedure but it is not often used.

-production: clause 7.5 and its subclauses, we did an extensive interpretation of these to stick to the problems of deployment of software in heterogeneous environments of our customers.

-post market: clauses 8.x, we did the same interpretation to stick to the #1 problem of soft : bugs, and #2 problem : enhancements. Procedures about change control, NC and CAPA are adapted to software maintenance. They are strongly linked to the problem resolution requirements of IEC 62304.

The best way to implement ISO 13485 to software is to have two senior people: a senior quality manager and a senior soft project manager. The first explains to the last the goals of each clause and they find the way to interpret these clauses to software.
The TR 80002-1 is a guidance on ISO 14971 for software.
We miss the TR xxxxx, the guidance on ISO 13485 for software!


Obrigado

Mitch.

 

[Marcelo]

Hello Mitch

Yes, that´s why I´m asking this.

Thanks a lot for your input.

Can i ask you some question to clarify some points?

- 7.4.1 - is it not easily applicable (meaning, you have difficulties applying the requirement) or is the only problem is that the procedure required is not used very often (and thus seems like a document burden, but can be easily implemented)?

- 7.5 - I can understand the problem you have, but not the link to the standard. Which clauses are you referring to? Can you give some example?

- 8.x - yeah, that´s a very interesting point, and it´s a complex interaction. You will really need to make a strong link to IEC 62304. But it isn´t again very clear to me, I don´t in principle see any problems because the general requirements of ISO 13485 can accommodate any other more detailed requirement, for example of IEC 62304 (at least this is the idea). I would say that it does require a lot of work, but not that it is problematic. Or have you noticed something really problematic, meaning, you needed to remove an ISo 13485 requirement due to a requirement of IEC 62304 or something like that?

Again, thanks for all your feedback!

 

[c.mitch]

- 7.4.1 - is it not easily applicable (meaning, you have difficulties applying the requirement) or is the only problem is that the procedure required is not used very often (and thus seems like a document burden, but can be easily implemented)?

Just a document burden. We seldom use it when we have to sell hardware (like a PC) with our software. For software, the challenge is more in selecting and purchasing the right software development tools and libraries during conception. We use FDA guidances for that.

7.5 - I can understand the problem you have, but not the link to the standard. Which clauses are you referring to? Can you give some example?

Indentification and traceability. We don't have the notion of lot or batch, neither the notion traceability of lots. But it's very important to know the versions of software deployed in customers facilities. We interpreted the requirements of identification and traceability with amplified procedures to manage the deployment and traceability of software versions.

8.x - yeah, that´s a very interesting point, and it´s a complex interaction. You will really need to make a strong link to IEC 62304. But it isn´t again very clear to me, I don´t in principle see any problems because the general requirements of ISO 13485 can accommodate any other more detailed requirement, for example of IEC 62304 (at least this is the idea). I would say that it does require a lot of work, but not that it is problematic. Or have you noticed something really problematic, meaning, you needed to remove an ISo 13485 requirement due to a requirement of IEC 62304 or something like that?

Thanks god, no! Doesn't ring a bell, did we miss something?
Software activities are disproporsionate, with big conception, tiny production and immense maintenance. So, NC, CAPA and change control really matter. Once again, the real problem is the mental gymnastics to interpret the 13485 requirements in the light of usual problems of software life-cycle.

A TR about implementing 13485 for soft would help, like the TR 80002-1 about 14971 for soft.

Hope it helps.
Mitch.

 

[Marcelo]

Thanks again Mitch.

Just as a general comment, in the case of clause 7, ISO 13485 permits that you deem some requirements non-applicable due to the nature of the device:

If any requirement(s) in Clause 7 of this International Standard is (are) not due to the nature of the medical device(s) for which the quality
management system is applied, the organization does not need to include
such a requirement(s) in its quality management system

It´s generally thought that this applies to the requirements to implants/sterile, but in fact it´s for all of Clause 7. Ans software, in my opinion, has a nature in which some of the requirements of clause 7 might not apply (not saying that yours is the case here) 9and yes, you will have a good time arguing with a certification body on that)

I liked the idea of a TR, but I´m not sure there´s enough discussion here to create a whole document.