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
------------------------------
Original Message:
Sent: 15-Jul-2020 15:14
From: Anonymous Member
Subject: IEC 62304 software safety classification
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.
Original Message:
Sent: 13-Jul-2020 10:03
From: Anonymous Member
Subject: IEC 62304 software safety classification
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?