Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo including content not in the forum - Search results with No ads.

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

Marcelo Antunes

Addicted to standards
Staff member
Admin
#21
Re: Update on IEC 62304 revision - 4 May 2012

I would also want to get more clarification on Verification vs validation in IEC62304. Section 1 tells that Validation and final release in not covered in the standard. Secondly, appendix talks about Software System Test to be confused with definition of Validation.
My understanding is System Test is Verification as those are against software requirements. Validation is against user needs and intended use and needs to be done at simulated environment and making sure product is build correct and not just meet the requirements (which can be faulty).

I have had several discussions but I am always in the dilemma about difference between System testing and Validation. I don't think its same but many people does.
Please clarify too.
Testing is usually related to verification.

The problem with validation and IEC 62304 is that this validation has to be done at the system (medical device) level. Some confusion arises because the standard defines software system, but this not the same as the medical device system.
 

sagai

Quite Involved in Discussions
#23
Re: Update on IEC 62304 revision - 4 May 2012

I am always in the dilemma about difference between System testing and Validation
For me ...
Validation is a collection and the deliberate interrelation of activities done in order to ensure the device safely and effectively fulfills its intended use.
Verification is a subset of validation, system test is a subset of verification like code review, document review, test code and test documentation review, etc.
User site user test is a subset of validation, and is not fully the subset of verification.
Configuration management, defect management for example also the subset of validation.

All the aboves are in my dumb universe. :tg:

Cheers!
 

sagai

Quite Involved in Discussions
#24
Re: Update on IEC 62304 revision - 4 May 2012

Quote:
How would/ are you managing legacy code against the requirements of 62304?
Well, formally you have to treat it as SOUP.
It is always giving me hard moments to understand why would we state anything without knowing its full background, anyway.
 

glork98

Involved In Discussions
#25
Re: Update on IEC 62304 revision - 4 May 2012

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.
 
W

wrodnigg

#26
Re: Update on IEC 62304 revision - 4 May 2012

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

Addicted to standards
Staff member
Admin
#27
Re: Update on IEC 62304 revision - 4 May 2012

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

Addicted to standards
Staff member
Admin
#28
Re: Update on IEC 62304 revision - 4 May 2012

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

Addicted to standards
Staff member
Admin
#29
Re: Update on IEC 62304 revision - 4 May 2012

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

Addicted to standards
Staff member
Admin
#30
Re: Update on IEC 62304 revision - 4 May 2012

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
 
Top Bottom