Proposed revision of IEC 62304 - 2019

Peter Pringle

Registered
To all

Dear fellow members would you like to read the attached document and put forward your views as there is much discussion as to the direction of IEC 62304 in the future.

The Netherlands is of the opinion that the current project to revise IEC 62304 needs reconsideration by the responsible committees, IEC/TC 62 (the lead committee) and ISO/TC 215.
The following arguments substantiate this opinion; each argument is elaborated on the following pages.
1. The current standard (Ed1.1) contains a fundamental flaw regarding risk management. This flaw hinders application in the regulatory domain and is
not addressed in the revision;
2. The material submitted to IEC and ISO for distribution as CDV/DIS does not represent state of the art;
3. The material submitted to IEC and ISO for distribution as CDV/DIS is not following the main principle to be “agnostic” to regulatory terminology;
4. The key part of the revision, broadening of the scope of the standard from “medical device software” to “health software”, is done in a manner that
precludes full use of the standard;
5. The risk classification imposed by the standard is not in line with regulatory classification of software products, including the IMDRF Risk Categorization
concepts;
6. The material submitted to IEC and ISO for distribution as CDV/DIS has elements of a product standard, whereas IEC 62304 is a process standard.
This makes implementation of the standard unnecessarily cumbersome and complicates referencing from true product standards;
7. The revision project team refused to address serious comments, even when submitted repeatedly.

If you have any contacts in Europe or elsewhere with voting rights on IEC 62304, I suggest you inform them of the dutch position (attached) and suggest that they kindly support it through their national organisation.

BR
PRP
 

Attachments

  • NL position revision IEC 62304_September2019.pdf
    467.2 KB · Views: 757

Mark Meer

Trusted Information Resource
I notice that there is a draft revision of EN 62304:2019 available (for purchase :confused:).

Given the concerns expressed in the paper posted, I presume that the new revision is a ways from being finalized?

That being said, I am interested in getting a jump on the major changes. Can anyone kindly link-to/summarize what notable changes to expect in the 2019 edition?

Thanks.
MM
 

Ronen E

Problem Solver
Moderator
I notice that there is a draft revision of EN 62304:2019 available (for purchase :confused:).

Given the concerns expressed in the paper posted, I presume that the new revision is a ways from being finalized?

That being said, I am interested in getting a jump on the major changes. Can anyone kindly link-to/summarize what notable changes to expect in the 2019 edition?

Thanks.
MM
Apparently you can browse the draft on EVS for 24h at a cost of 2 Euro.
 

Matt Knyc

Registered
There's a nice post summarizing proposed changes to new revision called "IEC 62304:2019 or 2020 - Next Generation"
(sorry can't add links to posts, but you can find it through google on cm-dm blog).
 

Tidge

Trusted Information Resource
the mentioned blog said:
Several notes are added, two of which could retain your attention:
  • Note 3: Software failures are not only bugs, but also requirements failures, or failures in human factors,
  • Note 6: External risk control measures can be not only hardware or external system, but also healthcare procedures or other means.
Note 3 closes a possible discussion on the fact that foreseeable misuse of software isn't a software failure. Yes, wrong GUI, wrong man-machine interaction can be a software failure, which shall be undertaken in the assignment of a software safety class! This has all the more been present in clause 7.1.2 since the first version of the standard in 2006.

Note 6 closes another possible discussion on the fact that only tangible (hardware, external system) means are acceptable risk control measures. Yes, an intangible healthcare procedure can be a risk control measure!

My first reaction (to the text of the blog) is that note 6 doesn't align with the spirit of 14971, as this note feels very much like using IFU to reduce risk of individual harms in a medical device. To my way of thinking: if there exists a common, prevalent healthcare procedure then this is NOT a risk control that a manufacturer/developer can claim credit for, but instead would be a factor in a risk-benefit acceptability analysis after the device is fully developed.

Assuming that the required deliverables for different classifications of software of 62304 have not changed, I will still find it very peculiar that "intangible healthcare procedures" could eliminate some deliverables for software in medical devices.

from the same blog said:
Defects from software tools
In the same vein, the list of potential causes of contribution to a hazardous situation now contains 7.1.2 e) defects that may be introduced by the used software environment, including tools and libraries; defects that may be introduced by the software development environment.
This closes a third discussion on the fact that failure of software design tools shall be included in the identification of risks. Although they are not SOUP within a strict interpretation of the definition of SOUP found in IEC 62304, they are Off-The-Shelf Software (OTSS, FDA acronym) and they can contribue to a software failure. E.g. an error of compilation.

This comment strikes me as misguided. I don't dispute that misapplying a set of compiler flags can result in an executable that doesn't meet requirements, but it is typically the executable which is subjected to verification and validation and not the combination of "source code + libraries + compiler". Generally medical device manufacturers do not "assemble" executable code on a factory floor, so I struggle to see how such a comment is relevant.

This feels very much akin to asking that (hardware) risk management consider misuse of CAD packages as contributing factors to harms coming from electrical or mechanical hazards. In my way of thinking: The standard use of a CAD package (for hardware) or common libraries and compiler options (for software) could be cited as a reason for having improved detectability ratings prior to the implementation of risk controls (in an FMEA-like system of Risk Analysis) but they wouldn't be identified as potential causes in a risk file any more than "hiring unqualified programmers" would be an appropriate contributing factor.
 

Lorenzo

Starting to get Involved
Maybe I can share my experiences from the discussions with members on the different country committees and organizations.

There is a proposal from the German or DIN committee (I can't remember exactly) to split 62304 into two parts in order to get the problem solved with the reference to 14971.

The proposal will look like this:

IEC 62304-1 -> Medical Software with references to 14971
IEC 62304-2 -> Health SW for other use without reference to 14971

However, it is safe to assume that the current draft will not go through.
Thus, the Dutch criticism is also shared in Germany to a certain extent:

ISO 14971 (Medical devices - Application of risk management to medical devices) has in its scope "medical devices", even when the scope statement of the 2019 edition of ISO 14971 mentions that the "process described in this document can also be applied to products that are not necessarily medical devices in some jurisdictions".
 
Top Bottom