Regulatory Open Forum

 View Only
  • 1.  IEC 62304 software safety classification

    This message was posted by a user wishing to remain anonymous
    Posted 13-Jul-2020 11:19
    This message was posted by a user wishing to remain anonymous

    On IEC 62304:2015, given that only risk control measures not implemented within (external to) the software system shall be considered, how could a standalone software reduce its software safety classification?


  • 2.  RE: IEC 62304 software safety classification

    Posted 14-Jul-2020 03:49
    Hello Anon,

    The question you are asking is probably well beyond a simple post within this forum as there is quite a few considerations you would have to review and understand from an overall risk management perspective.  Plus fundamentally I am not sure how you are relating using risk control measures to reduce the overall software safety classification.  If you are talking about safety classification such as A, B, or C, these classifications are related to the overall intended purpose of the device, not necessarily to the risk control being applied.  Meaning you can not really implement 'x' amount of risk controls to reduce the overall safety classification from C to B.  When looking at risk management concepts the use of risk control is to reduce the risks and hazards associated with a medical device including stand alone software.  This is using design characteristics or information supplied to the user to reduce occurrence or instances of hazards.  This might be what your question is posing, though probably need to clarify - but again this is a fairly broad question with alot of considerations in risk management.

    ------------------------------
    Richard Vincins RAC
    Vice President Global Regulatory Affairs
    ------------------------------



  • 3.  RE: IEC 62304 software safety classification

    This message was posted by a user wishing to remain anonymous
    Posted 15-Jul-2020 16:24
    This message was posted by a user wishing to remain anonymous

    I am not the original poster, but have had a similar question before.

    Richard, you wrote that you were "not sure how you are relating using risk control measures to reduce the overall software safety classification."

    I believe this draws from the 2015 amendment to IEC 62304 which states:

    • For a SOFTWARE SYSTEM initially classified as software safety class B or C, the MANUFACTURER may implement additional RISK CONTROL measures external to the SOFTWARE SYSTEM (including revising the system architecture containing the SOFTWARE SYSTEM) and subsequently assign a new software safety classification to the SOFTWARE SYSTEM.


    I'd be interested in your thoughts on the applicability of that section.


  • 4.  RE: IEC 62304 software safety classification

    Posted 16-Jul-2020 04:52
    Hello,

    Yes, I know that section of the standard which can be applied, but I guess for me was taking from a different perspective.  The statement about assigning a new software safety classification would be something occurring through the initial design and development activities.  Meaning when considering the safety classification of a software (and again this can be any software in a device or system to SaMD) it can start with Class C.  Then if the proper risk controls are applied, activities like checks in the software, internal validations of calculations, information being conveyed to the user, then the software toward verification or validation stages in development may be able to re-assign to Class B.  This being after all the risk controls have been applied.

    Personally, living in the US FDA world for a while and some other regulated country expectations, an assignment of a Level of Concern or Safety Classification is applied based on the intended purpose/intended use of the device.  This is where IEC 62304 from a life cycle approach may differ from a regulatory requirements perspective.  When a regulatory submission is made for a software the classification would already be known and established.  Through the design and development activities the software safety classification could be re-assigned based on the risk controls applied quite early in the development stream.  When the software system/component is ready for a type of pre-market submission, this has already been well established for the safety classification.  So in fact, the regulatory agency would never seen any of the internal activities occurring through the development process, i.e. they would only see being submitted as Class B.

    Then a final comment, the software classification may only change later in the life cycle of the device if again linking back to the intended use/intended purpose changes, where the risks and hazards are controlled in a manner for patient (and user) safety.  Personally, I think it would be not be possible or at least very rare a software safety classification would change later in the life cycle of the device by applying some new or different risk controls, because the intended use of the product may not change.

    ------------------------------
    Richard Vincins RAC
    Vice President Global Regulatory Affairs
    ------------------------------