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

Marcelo

Inactive Registered Visitor
#11
Re: Update on IEC 62304 revision - 4 May 2012

When do you anticipate the draft being available to purchase for the rest of industry?
It will take some time. Right now only final drafts can be obtained for purchase prior to publication. And it will take more than a year for this document to reach FDIS (almost two years, in fact).
 
Elsmar Forum Sponsor
M

Marc_G

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

It will take some time. Right now only final drafts can be obtained for purchase prior to publication. And it will take more than a year for this document to reach FDIS (almost two years, in fact).
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
 

Marcelo

Inactive Registered Visitor
#13
Re: Update on IEC 62304 revision - 4 May 2012

Hi

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.
Here is the list of ISO members - http://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:

Peter Selvey

Staff member
Moderator
#14
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.
 

Gert Sorensen

Forum Moderator
Moderator
#15
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.

:bigwave:
 

Marcelo

Inactive Registered Visitor
#16
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.
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
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.
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).
 

Peter Selvey

Staff member
Moderator
#17
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:
[The] 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 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:

c.mitch

Quite Involved in Discussions
#18
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.
 
#19
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.
 
M

Mondo 22

#20
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
 
Thread starter Similar threads Forum Replies Date
B IEC 62304 - Update Checklist IEC 62304 - Medical Device Software Life Cycle Processes 2
Hershal Update from MSC........ ISO/IEC 17025 - Challenges and Solutions ISO 17025 related Discussions 1
mike10 QMS Update - Rev. up or start over? Document Control Systems, Procedures, Forms and Templates 2
M Do we need to create a new CER or can we just update the existing CER EU Medical Device Regulations 3
dgrainger Informational MHRA guidance update on withdrawal of Notified Bodies Medical Device and FDA Regulations and Standards News 0
F Software development plan for SW update IEC 62304 - Medical Device Software Life Cycle Processes 2
M Informational Update on ISO TC 210 JWG 1 activities Medical Device and FDA Regulations and Standards News 0
M Informational EU – October 2019 update – State-of-play of joint assessments of Notified Bodies in the medical device sector Medical Device and FDA Regulations and Standards News 2
M Informational US FDA Final and update guidances – Software Medical Device and FDA Regulations and Standards News 0
M Informational From Medtech Insight – QSR/ISO 13485 Harmonization Update: FDA Enforcement Discretion Likely When New Rule Stands Up; Draft Reg Coming By Year’s End; Medical Device and FDA Regulations and Standards News 0
M Informational Update from GOV.UK – Regulating medical devices in the event of a no-deal Brexit – UK Responsible Person Medical Device and FDA Regulations and Standards News 0
M Informational Device Shortages Update – The US FDA Announces Two New Innovation Challenges on Device Sterilization Medical Device and FDA Regulations and Standards News 0
J Where can I find the latest update to Reach and ROHS? REACH and RoHS Conversations 5
M Informational Update – MDR and IVDR implementing measures rolling plan – 2 more NBs designated under the new regulations Medical Device and FDA Regulations and Standards News 0
M Informational US FDA – Digital Health Update: Mid-Year Update on Software Precertification Program Medical Device and FDA Regulations and Standards News 0
M Informational US FDA – Device Shortages Update: Challenges to encourage the development of new approaches to device sterilization Medical Device and FDA Regulations and Standards News 0
M Informational MHRA update – Medical devices: guidance for manufacturers on vigilance - June 2019 Medical Device and FDA Regulations and Standards News 0
M Is it compulsory to update the obsolete GMDN codes in ARTG? Other Medical Device Regulations World-Wide 4
M Informational USFDA – Digital Health Update: The FDA Announces an Opportunity for Test Case Volunteers for the Test Plan for the Software Precertification Program Medical Device and FDA Regulations and Standards News 0
M Informational US FDA Guidance update – Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program Medical Device and FDA Regulations and Standards News 0
M Informational TGA – Webinar: An update on the consultation for the Regulation of Software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 0
M Informational EU – Update on state-of-play of joint assessments of Notified Bodies in the medical device sector Medical Device and FDA Regulations and Standards News 1
E Gamma Sterilization Product Update Manufacturing and Related Processes 2
M Informational EU – April 2019 update of the MDR and IVDR implementing measures rolling plan Medical Device and FDA Regulations and Standards News 0
M Informational ISO 14971 / ISO TR 24971 revision update – atualizações sobre a revisão Medical Device and FDA Regulations and Standards News 1
M Informational IMDRF – Proposed update to Clinical Evaluation documents Medical Device and FDA Regulations and Standards News 0
M Informational USFDA Draft Guidance – Review and Update of Device Establishment Inspection Processes and Standards Medical Device and FDA Regulations and Standards News 0
C Do we need to make a new OFI (Opportunity for Improvement) for each document/form we update? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 23
M Medical Device News Last update of the MDR and IVDR implementing measures rolling plan – December 2018 Medical Device and FDA Regulations and Standards News 0
M FDA News USFDA Digital Health Update – New actions and documents Medical Device and FDA Regulations and Standards News 0
M FDA News Digital Health Update: USFDA Report on Non-Device Software Functions Now Available Medical Device and FDA Regulations and Standards News 0
M Medical Device News Letter to the health and care sector: update on preparations for a potential no-deal Brexit Medical Device and FDA Regulations and Standards News 0
Marc Software Update 23 November 2018 Forum News and General Information 1
M Medical Device News Joint Action On Market Surveillance Of Medical Devices (JAMS) Releases Progress Update EU Medical Device Regulations 0
Marc Attachment List Update - 2018-11-16 Forum News and General Information 0
K Medical Device Software Update in Field of AIMD IEC 62304 - Medical Device Software Life Cycle Processes 1
M Medical Device News Health Canada update - Applications for Medical Device Investigational Testing Authorizations Canada Medical Device Regulations 0
M Medical Device News IMDRF update - 26-09-18 - Cybersecurity, Premarket Reviews, Personalized Devices Other Medical Device Regulations World-Wide 0
M Medical Device News TGA update 26-09-18 - Medical Devices Safety Update, Volume 6 September 2018 Other Medical Device Regulations World-Wide 0
M Medical Device News Health Canada Update - 05-09-18 - Pilot Device Advice Canada Medical Device Regulations 0
S How to enforce my colleagues to update SOPs? Document Control Systems, Procedures, Forms and Templates 4
M Medical Device News Health Canada update 28-08-18 - Licensing Requirements for 3D-Printed Devices Canada Medical Device Regulations 0
Marc 2018 Software update - Donations Appreciated Forum News and General Information 21
J Update Technical File for EU Class IIa Medical Software Products EU Medical Device Regulations 3
L Re-calibrate after software update? Calibration Frequency (Interval) 3
W EU GDPR General Data Protection Regulation - What we need to update for our QMS EU Medical Device Regulations 10
Paul Simpson Informational The role of Annex SL - High Level Structure of ISO MSS's - Revision Update February 2019 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 26
R ISO 9001:2015 Transition Quality Manual Update - Redundant Content ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 12
F India Medical Device Regulations - Update - 2017 Other Medical Device Regulations World-Wide 11
T External Standard Update Notification AS9100, IAQG 9100, Nadcap and related Aerospace Standards and Requirements 5
Similar threads


















































Top Bottom