Update on IEC 62304 revision - May 2012 - 2013 (TBD)

I am still struggling with the whole concept of this standard, more precisely with the fact that the determination of the safety classification should occur at the beginning of the development, whereas my experience is (could be only mine) that it will be accurate only at the end of the R&D, a wee before commercialization (if any).

Click to expand...

I do agree with you that it is more accurate on the end of development, and it?s in fact expected that you perform it at that moment too, however, the "initial" classification (we have remove this term from the standard because it was causing much more confusion than helping") which should guide the development efforts needs to be made after design. However, the problem that you mentioned do exist (I classify it as A and after development it?s C) and there?s no easy solution the way the classification is done right now.

Probably should think about a solution for the next draft.

I think the main problem regarding this that no ones seems to talk about is:

If you think about good practices for software design and development, it might be argued that all activities required by IEC 62304 might be required for general any software, but the effort in each activity should be based on a general idea of the problems the software might cause - this is something that the manufacturer should do better than any standard.

Click to expand...

I agree. Manufacturers, however, need guidelines. This is the purpose of IEC 62304. But this is also its weakness, the requirements can be seen sometimes as too "vague". They need a work of interpretation in the technical context of the manufacturer.

people sees the safety classification of Class C as too much work and keep trying to avoid it.

Click to expand...

So, it?s really impossible to have a standard like with requirements that everyone agrees.

Click to expand...

Yes, but unfortunately, it's not possible to have safe mission-critical software without applying class C requirements. People (I would say managers or the management) should understand that it's possible to do a lot of things with software, but it has a cost.
On the opposite side, I've seen manufacturers putting themselves in class C while their software deserved only class A.
So, yes, there is a lot of confusion.

Another better solution would be to let the manufacturer decide on the level of effort.
We?ve suggested this to the ISo 13485 requirement on software validation

Click to expand...

An open system is perhaps a good idea, but this is not the trend of FDA, EU NB's and the like. They tend to prefer a closed system with safety class.
As you said, in an open system, some manufacturers wouldn't have the capability to choose the right SW development process.

Yet, I've already seen a NB auditor giving his/her advice off-the-record about the SW classification and make the manufacturer decrease its class from C to B.
One solution would be perhaps the possibility to ask authorities about the SW classification, as it is possible to do for MD classification.

That said, IMHO I prefer a closed system to an open one. And I prefer a system with 3 (or more like in aeronautics) classes.

Marcelo,
As I read here you are involved with revising IEC62304:2006. Is there still an opportunity to influence the changes being made? I know the team stopped receiving suggestions.

I have helped several companies interpret this standard in revision of their software development procedures. I would say some were smoother than others.

A question I have for you is in regards to SOUP and legacy software. Up to now the software standards have yet to define legacy software, although I do see references to legacy subsystems in IEC60601-1. The current definition for SOUP in IEC62304:2006, particularly after the “or” seems to suggest that one can treat legacy software as software of unknown provenance. I have seen many take this and apply this as a remediation approach.

I am interested if this was the intent in the 2006 version or not and any thoughts you have on this.
Thanks

Hello INEABOB and welcome to the Cove!

Is there still an opportunity to influence the changes being made? I know the team stopped receiving suggestions.

Click to expand...

The revision of IEC 62304 was separated in two fronts, one - create the amendment to IEC 62304:2006, and two, create a new version of IEC 62304:2006. Both are at the CD stage right now, so there?s still time for changes . But if you are not part of JWG 3 (or JWG 5 as the standards are changing to that JWG), your only formal way of commenting is thru the National Committee of your country.

Regarding SOUP, yes, the original intent was to include legacy software in SOUP, however, due to some developments (in particular the amendment to IEC 62366 to deal with legacy usability), amendment 1 to IEC 62304 will include an alternative pathway to legacy software which is a little different than the SOUP approach (because basically the SOUP approach would be - throw the software away and begin anew :-().

Marcelo:

I have question about SOUP as well. I noticed this phrase "including standard libraries" in section 8.1.2 of the draft seems to include standard libraries. This brings up the following issue. Our code is written in C. Using a commercial compiler (in this case Keil' 8051 C compiler.) The compiler generates calls to various internal routines held in the keil libraries. for example there are calls to case switch handlers, signed and unsigned divide and multiply routines, and on and on. There are intrinsic functions as well that are generated in line..

Do we have to treat the compiler's internal libraries as SOUP? There is a presumption here that the compiler is simply a tool. The compilers manufacturer (in this case Keil) has refined these functions over the years, and they are very reliable, but the LINKER pulls in bits and pieces as it sees fit, and the compiler generates calls as it sees fit.

These are embedded into the code that we write and ultimately run on our medical device.

What level of testing is required for compiler libraries, and how does 62304 intend for them to actually be handled. My opinion is that standard compiler libraries should not be treated as SOUP, but merely as a side effect of the compiler. It gets worse with ADA and Java. Java is interpreted. Is the Java VM that might be running on some tablet under the OS, SOUP? It is handling the byte codes generated by the Java code that was written to implement the program. For any given tablet, the version may vary, as these things are updated from time to time.

Updating the Java VM behind the software's back, would seem to me to cause problems, because to be 62304 compliant you have to know the title, manufacturer and unique soup designation, and include that in your documentation.

Has the committee thought about, or discussed this issue, and what is the conclusion about compiler libraries, and base line interpreters.

The existing standard also requires libraries to be included, but the expectation is simply to keep a record of the libraries used and watch for updates and notices from the supplier of the library. There is no expectation to actually test the library, this would be impractical.

For a high risk medical device, the construction should be such that no single failure can lead to serious harm, and this includes a software bug in a third party library. No-one can guarantee a library to 99.9999% confidence which is what would be expected if the software was used to control a function the failure of which could lead to patient death or serious injury.

A high risk system would normally have a separate protection system, which if this involves software would ideally be implemented in a separate processor of a different type, software and compiler. If a single processor is used with both control and protection function, the protection software should at least use a vastly different method to calculate parameters and judge if something unexpected is happening, to reduce the risk that a library causes trouble for both control and protection. Even then the residual risk of a library function causing an issue would have to be formally recognized with someone taking responsibility for decision in the risk management file.

Again this only applies to a high risk system where failure can directly cause high severity harm with a high probability (for example, temperature control in an infant incubator).

For most medical devices, just keeping a record of the library used and monitor the supplier for updates is enough.

Hi All,

A question related to the last two posts. When using a commercial IDE such as Keil, IAR, or CCS, how does one exactly find and record the needed information for the compiler libraries to comply with 8.1.2. What does "complete and correct" actually look like that would pass muster with a knowledgeable auditor?

Thanks!

8.1.2 is pretty straight-forward: title, manufacturer, and unique designator (e.g., release number). Those should be readily obtainable from the manufacturer / website. Not sure where "complete and correct" is coming from.

Much more difficult is the SOUP anomaly list (7.1.3). For something like an IDE, there could be a large number of related issues and sifting through those just for relevance is challenging.

What is this "knowledgeable auditor" thing you speak of? ;-)

Thanks Yodon!

'Complete and correct' is just me and how I think ... "How can I self-verify my work?" so to speak.

I agree that 8.1.2 as a clause is very simple and in theory be readily obtainable.

However the Help menu item of the list of software that makes up the IDE is quite long. My question is (due to inexperience), how am I sure that I'm looking at the correct ones that may get into my firmware through the compiling and linking process into the .hex file. By my reading of 62304, you need to have this awareness and know when those libraries have changed....plus other stuff associated with SOUP.

Med_Eng said:

'Complete and correct' is just me and how I think ... "How can I self-verify my work?" so to speak.
[...]
However the Help menu item of the list of software that makes up the IDE is quite long. My question is (due to inexperience), how am I sure that I'm looking at the correct ones that may get into my firmware through the compiling and linking process into the .hex file. By my reading of 62304, you need to have this awareness and know when those libraries have changed....plus other stuff associated with SOUP.

Click to expand...

My expectation is that the developer is completely aware of what all elements of the (software) design are accountable for; i.e. why did I even add this to my design? This is true for self-developed code and also true for SOUP.

Setting aside subtle questions about the lower burden of strictly required (for compliance, independent of "best development practices") deliverables per 62304 for class A software, I expect that the software requirements should make it obvious what sorts of testing are required, either during initial development or in the event of a newly revealed anomaly. I also expect that a software architecture should make it straightforward to determine what level of assessment needs to go into the SOUP elements.

Anecdotally: I would not be a priori concerned with tracking anomalies in a complier, if I've already validated the performance of the output of the compiler. I would want to know if an included library has been found to have anomalies, but I should be able to know which elements of the library are used in my package, and if so I ought to be able to do testing to see if there is any impact to my design.