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

[glork98]

In Reply to Parent Post by Mondo 22

How would/ are you managing legacy code against the requirements of 62304?

Using the SOUP approach has benefits, to be sure. Does that black box do what it needs to? This could be a difficult thing to rationalize if it was the entire product in a Class B or C product. I wouldn't feel comfortable doing that.

The details to make a decision would involve the quality of the software itself (coding approach and standard compliance, internal documentation) and the quality of external documentation (design, arch, requirements). A big plus if there are unit tests for the code.

The issues of verification vs. validation and how you can do either to software without a full system are always present. The first is a symantic battle to get people in the product team and company to agree. I know whats "right" but getting unified thought is tough.

Verifying software without a system is a technical challenge. We're covering 85% of our Class B requirements with an off-line simulation. This is pure software and not a functional simulator. The simulator has been validated. 15% of the requirements need manual tests on the actual product and we want that to show real functionality, too.

The simulated tests eliminate dependencies on misbehaving sensors and intermittent development hardware and allow a pure software test. Of course, we provoke those conditions through the simulation to show the risk mitigations as stated in the DFMECA work.

A lot of work? Not so bad, really, as far cheaper than doing the manual tests repeatedly and far, far cheaper that creating a functional simulation that applies real conditions to the hardware. (E.g., a LabView-based simulator) The ability to cut a release knowing the code works and the test engineer will only needs to document success is a huge benefit to this approach.

And we run 90%+ of our unit and integration tests in the simulator as well. Some things have to be done on the hardware but all the "business logic" can be tested in the simulator.

[wrodnigg]

I just looked into SC 62A @ IEC about Project: IEC 62304 Ed. 2.0

There is still no 1CD available, does anyone know more (who possibly attended the last meeting)?

[Marcelo Antunes]

There is still no 1CD available, does anyone know more (who possibly attended the last meeting)?

The last working draft was circulated to the WG members some weeks ago.

The next meeting will be next week in Germany. After this one the first CD will be circulated.

[Marcelo Antunes]

Another update. JWG 3 met in Germany last week, and we finished the comments on the working draft of IEC 62304. As mentioned before, the first CD will be circulated shortly to NCs.

Regarding IEC 80002-2 - Medical device software Part 1: Validation of software for regulated processes, it was noted that we need some leveling of expectations regarding the revised requirements for software in the ISO 13485 revision (done by WG 1) and JWG 3. So we will discuss it further in the next meeting of WG 1 in October in the US (and as I am a member of both groups I will perform this info exchange).

Another document of interest is IEC 82304 - Healthcare Software Systems (it's in fact being developed by ISO TC 215 / IEC TC 62 JWG 7 instead of JWG 3).
It was discussed in the last meeting of JWG 7 which ended yesterday. The WD was circulated before the meeting and there were some discussions, and it will also be circulated in CD form in the next few months.

[Marcelo Antunes]

JWG 3 met in China last week to analyze the comments of CD1 of the revision of IEC 62304.

The focus was to discuss the classification scheme, legacy device annex and some other specific topics because those were the focus of the comments.

Regarding classification, it's my impression that we finally have a way to make it more clear to everyone. After a LOT of discussion, my suggestion to create it in a procedural format (changed to a flowchart) was accepted, and it seems to me that this solution is the best one we have. Let's see how the comments goes...

A second CD will be circulated in a while.

[Marcelo Antunes]

Below is my original suggestion to the revision of the classification scheme (as I mentioned it has been changed to a flowchart and streamlined).


1 - Identify hazardous situation where software failure can be part of the sequence of events

2 - if 1 is 0, class A

3 - If 1 not 0, verify if non-SW risk control measures already designed for the SYSTEM mitigates the risk to an acceptable level

4 - If 3 is yes, the class A

5 - Verify if you can apply and apply non-SW risk control measures to mitigate to acceptable level

6 - If 5 is yes, class A

7 - If no for 4 or 6, identify resulting harm

8 - If 7 is non-serious, class B

9 - If 7 is serious, class C


Note: you can always apply non-SW risk control measures to down-classify risk class

[Marcelo Antunes]

Some changes from my recent update due to discussions and decisions at the IEC SC 62A plenary meeting.

The revised classification scheme and legacy annex will now be dealt with in an Amendment to IEC 62304 Ed. 1. This will be developed together with the continuing work on Ed. 2.

IEC 62304 Ed. 2 will have a scope expansion. It will be applied for health software, instead of only medical device software, to align with the development of IEC 82304.

[sagai]

It is difficult to make my head around this standard in general and it is also true for this classification stuff as well. More quite often looks for me like an academic level white paper rather than the real world driven best practise guide.

Before going any further, can I ask a clarification what actually "software failure" and "acceptable level" refer to in the context of this classification please?

Many thanks.
Cheers!