Cons and Flaws in AAMI 62304

[Aaria]

Hi, I read few of your threads related to IEC 62304. I would be glad if you can help initiate a discussion which would be related to the 'cons'/flaws in 62304. Is the fact of the confusion to determine the safety classification of the software, and the amount of documentation that follows, is unnerving for manufacturers? Not to forget this standard being integrated in the 60601-1 3ed. I am still naive about this standard, but any such key points from you to discuss would be very helpful.
Thanks for your help in advance.

 

[yodon]

Re: Cons/Flaws in AAMI 62304

Without exaggerating too much, that's almost like asking to discuss the pros and cons of democracy. So how about if we turn it around. What do YOU think are the cons / flaws with the standard? What do YOU feel is unnerving to manufacturers?

Personally, I find it to be a fairly decent standard to guide establishment of a sound software lifecycle and a means to establish a standard safety rating with rational arguments for accompanying documentation.

No doubt there are imperfections and no doubt there will be zealots on both the pro and con side.

 

[JSambrook]

Re: Cons/Flaws in AAMI 62304

With respect to the OP, I also think it's a pretty good standard.

I'd be interested in hearing any specific concerns people have. Good topic for discussion!

 

[glork98]

Re: Cons/Flaws in AAMI 62304

I fairly like 62304. A good balance of breadth while not being prescriptive in depth. I think it reflects the maturing of software as a true discipline and not the domain of secretive geniuses. (Although I enjoyed that immensely!)

One thing I find unhelpful is the integration test work. This comes naturally as modules or objects of greater scope are unit tested. Unless you've got "mocks" for every dependency the higher-level code on the class diagram (or lower if you draw it that way) pull in other objects. It's hard and not worthwhile to create, say, 3 programs that are each 1/3 of the project in order to test partial sets of code before doing the system-level tests.

Perhaps other types of work are more suited to this. I work on small (5K sloc) embedded devices so creating partial integrations is difficult conceptually and not really valuable practically.

 

[c.mitch]

Re: Cons/Flaws in AAMI 62304

Hi all,

As I consider myself as citizen of elsmar.com democracy, here are a few remarks.

Pros:
This is a minimum standard, which cooperates well with 13485 and 14971. You may apply what you need against your software risk class A B or C.
It is easy to make a comparison with 12207, the most used software development process standard.
It is "configurable" to agile development methods with minimum efforts.


Cons:
Class of risk of software and class of risk in MD regulations (CE FDA ...) are sometimes difficult to reconciliate.
It lacks some more requirements about system architecture and system/software integration tests and delivery. But this is justified in the annexes of the standard.
It is a bit light about software project management. Again justified in the standard.
It lack on or two minor things required by FDA GPSV, like code review (only present in annex B).

I wrote more cons than pros. But the pros overpass easily the cons. This is a very good frame for software dev process for MD industry.

Regards.

 

[dirkr]

Re: Cons/Flaws in AAMI 62304

Hi all,

I am new here, but like to contribute.

To my opinion a minor inconsistency is the missing demand for any testing of class A software. For class A not even system testing is required while the problem resolution chapter (9.8) requires full test documentation also for class A.

Personally I would never release a software without testing, but according to the standard it is not required and this can make it difficult to argue and justify effort against management.

However from a overall perspective the standard was of course a big step ahead, especially compared to the undefined state we had before (in Europe).

 

[c.mitch]

Re: Cons/Flaws in AAMI 62304

Hi Dirkr,
Thanks for pointing out this inconsistency.
I think this is absolutely impossible to release software without thorough testing phase as well.

However from a overall perspective the standard was of course a big step ahead, especially compared to the undefined state we had before (in Europe).

I think the situation is quite clear now in Europe. It's true that the 60601-1 standard, which is "in service" since a long time, wasn't enough for software lifecycle. 62304 deals with software and section 14 of 60601-1 3rd edition deals with system and system-software integration.

Mitch.

 

[glork98]

Re: Cons/Flaws in AAMI 62304

Personally I would never release a software without testing,

62304 calls for verification against requirements but no unit or integraiton testing.

I agree it's a bit light in that way, but a very practical approach. If there's no chance of actual harm, only harm to customer opinion, leave it to the companies to decide what's right.

It's not practical to do thorough unit testing of complex GUI code in a "civilian" operating system. Having it work to suit users' needs is the essential part.

 

[Peter Selvey]

Re Class A testing:

I had assumed the reason software system testing is missing for Class A was that they considered full system validation tests (including hardware, mechanical etc) to be enough. Since validation is excluded from the standard, and expected to be picked up under other design control standards (e.g. ISO 13485), there are no tests for Class A software.

For example, scales to measure patient weight in a low risk environment (Class A software) can validated by actually putting a weight on the scales and checking the display reads as expected. No need to pull the software out as a separate object and test it separately.

It's probably an important distinction even for higher risk systems, as they often include lower risk functions that can be pulled out as Class A and tested under "system validation" instead of "software testing".

 

[glork98]

Re: Cons/Flaws in AAMI 62304

62304 calls for verification against requirements but no unit or integraiton testing.

I should update this. There's no mandate for verification against software requirements. It rolls up into system-level testing.