Update on IEC 62304 revision - May 2012 - 2013 (TBD)
- Thread starter Marcelo
- Start date
M
Marc_G
Re: Update on IEC 62304 revision - 4 May 2012
Hello Marcelo and thanks for your involvement in this forum.
It will take some time to read this document, so how can we access to our national committees ?
On the website of the ISO, I only found links to Technical Committees.
Thanks in advance,
Marc
Hello Marcelo and thanks for your involvement in this forum.
It will take some time to read this document, so how can we access to our national committees ?
On the website of the ISO, I only found links to Technical Committees.
Thanks in advance,
Marc
Re: Update on IEC 62304 revision - 4 May 2012
Hi
Here is the list of ISO members - https://www.iso.org/iso/about/iso_members.htm which are the NCs for each country (you can click on them for more info).
You need to contact them on how to participate in meetings and TAGs.
Hi
Here is the list of ISO members - https://www.iso.org/iso/about/iso_members.htm which are the NCs for each country (you can click on them for more info).
You need to contact them on how to participate in meetings and TAGs.
Last edited:
Re: Update on IEC 62304 revision - 4 May 2012
It's been mentioned about the problems of the waterfall model in some of the posts.
Recently I had a "light bulb" moment on this point. During design there will be many versions or configurations of the software. I realized that the law and design control standards like IEC 62304 literally only apply to the version which is actually placed on the market (i.e. the "medical device"). The law does not and cannot apply to many pre-release versions of software versions that appear during development.
The catch in using this extreme interpretation is that only testing on the final version can be considered valid, i.e. every time the software is changed, no matter how small the change, 100% of tests need to be repeated.
The other extreme is to use design controls from the earliest stage. But at the early stages, the design changes so much that any tests performed at that stage have little meaning as evidence for the final version. The burden of full design controls can get in the way of development.
It makes sense then start formal design controls at an efficient point between these two extremes.
For example, a manufacturer could apply a informal evolutionary model without design controls until the design is stable, and then switch to a waterfall model with formal design controls at the last stage only. This would comply with IEC 62304.
It's been mentioned about the problems of the waterfall model in some of the posts.
Recently I had a "light bulb" moment on this point. During design there will be many versions or configurations of the software. I realized that the law and design control standards like IEC 62304 literally only apply to the version which is actually placed on the market (i.e. the "medical device"). The law does not and cannot apply to many pre-release versions of software versions that appear during development.
The catch in using this extreme interpretation is that only testing on the final version can be considered valid, i.e. every time the software is changed, no matter how small the change, 100% of tests need to be repeated.
The other extreme is to use design controls from the earliest stage. But at the early stages, the design changes so much that any tests performed at that stage have little meaning as evidence for the final version. The burden of full design controls can get in the way of development.
It makes sense then start formal design controls at an efficient point between these two extremes.
For example, a manufacturer could apply a informal evolutionary model without design controls until the design is stable, and then switch to a waterfall model with formal design controls at the last stage only. This would comply with IEC 62304.
G
Gert Sorensen
Re: Update on IEC 62304 revision - 4 May 2012
Interesting thoughts, Peter. I do believe that pursuing the extreme as you describe here is doable, but it will require very committed personell, and agile as well as robust documentation solutions. But, the thought is interesting, and I would like to hear the experiences of anyone trying to utilize it.
Interesting thoughts, Peter. I do believe that pursuing the extreme as you describe here is doable, but it will require very committed personell, and agile as well as robust documentation solutions. But, the thought is interesting, and I would like to hear the experiences of anyone trying to utilize it.
Re: Update on IEC 62304 revision - 4 May 2012
Well, this is clearly true on the normal "design controls" waterfall model (from QMS standards) where´s there´s a plan and a design input, and nothing defined between them.
As the design input are the related to device requirements or characteristics of product device, if you use a development model, for example, in which you do not have a definitive design until later in the cycle (for example, a model where on your initial phases you design concepts and at the end of the concept phase you decide on one - the requirements for those would be your design input), the it´s obvious that the design controls would really just start after you have clearly defined your device. This is really what separates research (usually related to the creation of concepts) from development (usually applying the info from research to create one or more of the concepts).
This is also true to 62304, meaning, if you have a "research" phase on software, you would only need control of the one which has the final requirements.
However, you comment
I do not totally agree; The standards and laws do not apply to versions or configurations. Their base is the device requirements. So the controls begin when you have defined the requirements for the device (even if there are more than one version).
I would totally agree with you if by "many versions and configurations' you are saying, in my lingo, many concepts (meaning, the device requirements are not yet fully defined and you are using those initial steps to defined them).
Well, this is clearly true on the normal "design controls" waterfall model (from QMS standards) where´s there´s a plan and a design input, and nothing defined between them.
As the design input are the related to device requirements or characteristics of product device, if you use a development model, for example, in which you do not have a definitive design until later in the cycle (for example, a model where on your initial phases you design concepts and at the end of the concept phase you decide on one - the requirements for those would be your design input), the it´s obvious that the design controls would really just start after you have clearly defined your device. This is really what separates research (usually related to the creation of concepts) from development (usually applying the info from research to create one or more of the concepts).
This is also true to 62304, meaning, if you have a "research" phase on software, you would only need control of the one which has the final requirements.
However, you comment
I do not totally agree; The standards and laws do not apply to versions or configurations. Their base is the device requirements. So the controls begin when you have defined the requirements for the device (even if there are more than one version).
I would totally agree with you if by "many versions and configurations' you are saying, in my lingo, many concepts (meaning, the device requirements are not yet fully defined and you are using those initial steps to defined them).
Re: Update on IEC 62304 revision - 4 May 2012
I think perhaps an example illustrates the issue best.
I developed test equipment for ECG standards like IEC 60601-2-27, simulating signals and test circuits and so on. There's software for both the PIC micro and the PC, total about 3,000 lines of code. Let's assume this was a medical device under IEC 62304.
Versions 2.x used RS-232 communication with the PC, with waveforms stored in the PIC micro. That version was never "placed on the market" so to speak.
Versions 3.x use USB communications, with waveforms calculated "on the run" by the PC. Version 3.3 the first released to market (current is V3.4).
The high level input/output specifications did not change, and there are many common aspects between V2.x and V3.x. But, internal differences are enough that any tests done on V2.x have no meaning for V3.x. Every verification / validation test should be repeated (which is what actually happened).
Since V2.x is never sold, I think there is no legal requirement to keep any records for V2.x, even though it is obviously part of the design evolution.
In fact, only V3.3 needs design control records, being the first placed on the market.
But, I did detailed evaluation of the pacemaker pulse circuit on V3.2. Since that part is not changed, I simply refer to the test data for V3.2 in the records for V3.3. In this situation, it is not that the law applies to V3.2. Rather, what I am saying is that the test on V3.2 is representative of V3.3. As such I am obligated to have at least some form of document control, qualification, specification (at least for the tests), configuration management etc in place in order to be confident the test is really representative of the version that was sold. In effect, by referencing data from V3.2, I have to make sure design controls extend back to V3.2.
If I wanted to, I could choose to do all the tests again for V3.3. In that case, then there is no obligation to have any design controls for V3.2.
It was mentioned:
I don't think this is correct. The law applies when the device is first place on the market. At that point in time, specifications, risk management, verification, validation should be complete according to IEC 62304. It does not matter when these documents and activities take place, as long they are complete at the time of placing on the market.
To say otherwise creates a legal mess. For example: I made a specification for V2.0. But I decided to start from scratch with a blank sheet for V3.0. Do I have to keep V2.0 specification? I think not. For that matter, I could decide again to start from scratch with V3.3 and throw everything else away. Company A could buy a design from Company B that is 99% complete, but has no design controls. They can also start with a blank sheet. That is perfectly legal, and in many cases more efficient.
It all depends on the complexity of the system as to what approach is more efficient. But that is a matter for the manufacturer to decide. The law simply requires everything to be complete at the time of placing on the market.
I think perhaps an example illustrates the issue best.
I developed test equipment for ECG standards like IEC 60601-2-27, simulating signals and test circuits and so on. There's software for both the PIC micro and the PC, total about 3,000 lines of code. Let's assume this was a medical device under IEC 62304.
Versions 2.x used RS-232 communication with the PC, with waveforms stored in the PIC micro. That version was never "placed on the market" so to speak.
Versions 3.x use USB communications, with waveforms calculated "on the run" by the PC. Version 3.3 the first released to market (current is V3.4).
The high level input/output specifications did not change, and there are many common aspects between V2.x and V3.x. But, internal differences are enough that any tests done on V2.x have no meaning for V3.x. Every verification / validation test should be repeated (which is what actually happened).
Since V2.x is never sold, I think there is no legal requirement to keep any records for V2.x, even though it is obviously part of the design evolution.
In fact, only V3.3 needs design control records, being the first placed on the market.
But, I did detailed evaluation of the pacemaker pulse circuit on V3.2. Since that part is not changed, I simply refer to the test data for V3.2 in the records for V3.3. In this situation, it is not that the law applies to V3.2. Rather, what I am saying is that the test on V3.2 is representative of V3.3. As such I am obligated to have at least some form of document control, qualification, specification (at least for the tests), configuration management etc in place in order to be confident the test is really representative of the version that was sold. In effect, by referencing data from V3.2, I have to make sure design controls extend back to V3.2.
If I wanted to, I could choose to do all the tests again for V3.3. In that case, then there is no obligation to have any design controls for V3.2.
It was mentioned:
I don't think this is correct. The law applies when the device is first place on the market. At that point in time, specifications, risk management, verification, validation should be complete according to IEC 62304. It does not matter when these documents and activities take place, as long they are complete at the time of placing on the market.
To say otherwise creates a legal mess. For example: I made a specification for V2.0. But I decided to start from scratch with a blank sheet for V3.0. Do I have to keep V2.0 specification? I think not. For that matter, I could decide again to start from scratch with V3.3 and throw everything else away. Company A could buy a design from Company B that is 99% complete, but has no design controls. They can also start with a blank sheet. That is perfectly legal, and in many cases more efficient.
It all depends on the complexity of the system as to what approach is more efficient. But that is a matter for the manufacturer to decide. The law simply requires everything to be complete at the time of placing on the market.
Last edited:
Re: Update on IEC 62304 revision - 4 May 2012
Hello
I like your lightbulb because this is what I already experienced.
FDA and CE NB's are not always software specialists and they feel more cmfortable with the canonical waterfall model. I already had seen prototypes/demonstrators developed outside any constrained frame.
My policy, when people eventually think to get the homologation, is to consider that everything that was done before is input data for a canonical design procedure (with risk management proc in parallel).
To explain it quickly, I "finish" the design with an "official" waterfall step that lasts roughly between 3 to 6 months. From the point of view of the developer, this adds a few constraints but he continues to work like before. From the point of view of the project manager, however, it changes his life, he has to monitor thouroughly the procedure and the documentation which is being produced to prove the good design.
The configuration management is very important. The version of the medical device is insulated in one branch, the research can continue on other branches. A porosity can exist and nice features in research branch (if they don't change the intended use!) can be manually comitted in the "official" branch. An update of documents produced in early steps of waterfall like SRS is done accordingly if necessary.
I've never seen any project which begins from scratch and this is the best way I've found to cope with this situation.
Hello
I like your lightbulb because this is what I already experienced.
FDA and CE NB's are not always software specialists and they feel more cmfortable with the canonical waterfall model. I already had seen prototypes/demonstrators developed outside any constrained frame.
My policy, when people eventually think to get the homologation, is to consider that everything that was done before is input data for a canonical design procedure (with risk management proc in parallel).
To explain it quickly, I "finish" the design with an "official" waterfall step that lasts roughly between 3 to 6 months. From the point of view of the developer, this adds a few constraints but he continues to work like before. From the point of view of the project manager, however, it changes his life, he has to monitor thouroughly the procedure and the documentation which is being produced to prove the good design.
The configuration management is very important. The version of the medical device is insulated in one branch, the research can continue on other branches. A porosity can exist and nice features in research branch (if they don't change the intended use!) can be manually comitted in the "official" branch. An update of documents produced in early steps of waterfall like SRS is done accordingly if necessary.
I've never seen any project which begins from scratch and this is the best way I've found to cope with this situation.
U
ujain82
Re: Update on IEC 62304 revision - 4 May 2012
Thanks for the update.
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.
Thanks in advance.
Thanks for the update.
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.
Thanks in advance.
M
Mondo 22
Re: Update on IEC 62304 revision - 4 May 2012
All,
How would/ are you managing legacy code against the requirements of 62304?
Any advice would be welcome.
Thanks,
Ray
All,
How would/ are you managing legacy code against the requirements of 62304?
Any advice would be welcome.
Thanks,
Ray
Similar threads
