IEC 62304 : Risk control for SaMD

#1
Hi,

I am a young design quality engineer with no software experience and I am updating the hazard analysis of a SaMD.
My main interrogation is how to define Software Risk Control measures.
For instance one risk of our software is that the user interface does not show the medical warnings when launching the software.

What could be a Risk Control for this ? Testing the software code may seem like an option but this does not enter the 3 categories of risk controls defined by ISO 14971 (design, protection, information for safety). Plus, according to ISO 62304, testing the software is part of the verification campaign so it can not be both risk mitigating control AND part of the verification of the SaMD.

To summarize, how do you implement a software risk control by design?

For info the SaMD is class B.

Thank you very much for your help.
Best regards,
Tom
 
Elsmar Forum Sponsor

mihzago

Trusted Information Resource
#2
I would look at it a little different way.
Why do medical warnings have to be displayed when launching the software?
It probably is a control measure for another risk, and if that's the case, then instead of creating another risk control, you demonstrate though verification and/or validation that the medical warnings were implemented and effective.
 

yodon

Staff member
Super Moderator
#3
I am a young design quality engineer with no software experience and I am updating the hazard analysis of a SaMD.
Houston, we have a problem! How will you define software risk controls without any software experience? Many of the causes of failure required to be considered under 62304 will require software experience to address.

Next: testing should NEVER be a risk control. Testing can only verify a risk control.

Agree with @mihzago in that it sounds like what you're talking about is a risk control for something else.

To answer your question about what is a software risk control by design (albeit not in this case), things like a watchdog timer, validating inputs before using, etc. would all be examples. And do note that controls external to the software (other software systems or hardware) can also be controls.
 

Tidge

Trusted Information Resource
#4
To first order, specifically to software in a medical device, you can likely treat (some) of the software requirements as risk control measures.

The code to implement the requirements is verification of implementation; the software requirement testing is the verification of effectiveness.
 

yodon

Staff member
Super Moderator
#5
software requirement testing is the verification of effectiveness
We've been going around on this internally. While verification *may* show effectiveness (e.g., the device shuts down if the software detects some error), there are certainly cases where verification cannot show effectiveness. Take an example where, say, the system illuminates an LED to alert the user to some situation. If this is in a busy OR or situation where the user isn't always watching the device, verification that the LED lights up may well be quite ineffective (at alerting the user). I think you need to consider the context of the control. Some controls will need user studies (validation) to assess effectiveness.
 

Tidge

Trusted Information Resource
#6
We've been going around on this internally. While verification *may* show effectiveness (e.g., the device shuts down if the software detects some error), there are certainly cases where verification cannot show effectiveness. Take an example where, say, the system illuminates an LED to alert the user to some situation. If this is in a busy OR or situation where the user isn't always watching the device, verification that the LED lights up may well be quite ineffective (at alerting the user). I think you need to consider the context of the control. Some controls will need user studies (validation) to assess effectiveness.
I understand your point, but this is not a different situation (in so far as actually mitigating a risk) than having the LED called out in a DFMEA.
 
#7
Thank you very much for all your replies. Very insightful.
I think my struggles in defining risk controls is due to my difficulties in defining sotware risks.
The current state of the hazard analysis is that we take one software item and we determine what could go wrong.
So if I go back to my warnings, we have this software code responsible for presenting the warnings : what could go wrong --> this software code does not function and we have this "risk" of not showing the warning.
@mihzago and you're completely right ! we do have a risk where the warnings are a risk control.

We do this for each software item (almost for each low level software unit).

Another example, software code responsible for the button to change languages --> risk : software code does not function and we can not change languages. Failure in sound manager --> risk : no sound emmited.. etc

Therefore our risk analysis is extremely "heavy" and I feel this is not the right way.
Could I also have your opinion on that ?

Thank you very much again, highly grateful.
 

Tidge

Trusted Information Resource
#9
In all cases in which medical device software is written to for the purpose of presenting information to be processed by a human, I encourage the parties responsible for the risk management file to first filter the functions through the context of alarm conditions:
  • technical alarm conditions
  • physiological alarm conditions
If the software (primarily active code) isn't for either of these two categories, than the only other area where the software will (to first order) need to show up in the risk management files are for the software functions explicitly allocated for essential performance of the device, per the regulatory categorization/registration of the device. This is quite important, but these functions are all about meeting specific needs for the device to meet its intended use, it is NOT about the ancillary functions the software performs. It is of course possible that software is implemented specifically as a risk control for some non-software failure mode, but I consider such features to be a second order risk control. That is not to say that such software functions would need to work in a particular single fault condition, but I digress.

Some technical information presented at startup strikes me as being completely commensurate with having some information printed in the user manual, or on a device label. I wouldn't overthink this, nor would I overestimate how much risk such a feature is mitigating.

Software occupies a peculiar place in the headspace of medical device teams, partially because it is treated as some mystical device component for which have total control over and can completely specify and test. To some extent this is true, but it is also true of things like batteries and threaded fasteners. Teams that invest heavily in the specification and testing of batteries enjoy far more success than those that do not; there have been plenty of issues with medical devices because of poor choices in fasteners.
 
Thread starter Similar threads Forum Replies Date
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
D IEC 62304 Risk Classification - With and without hardware control IEC 62304 - Medical Device Software Life Cycle Processes 2
P Risk acceptability alignment between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 6
D Software as risk control - Confused on one aspect of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 20
K Risk Reduction by Risk Control: IEC:62304-Class C ISO 14971 - Medical Device Risk Management 15
W IEC 62304 vs. IMDRF SaMD Guideline Risk Class IEC 62304 - Medical Device Software Life Cycle Processes 5
F IEC 62304 agile development EU Medical Device Regulations 1
shimonv Working with a software developer who is not setup for IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 9
P Examples of quality plans in IEC 62304 US Food and Drug Administration (FDA) 2
E Test report to certify compliance with IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
E Any sample of a full software life cycle IEC 62304 report ( any class )? IEC 62304 - Medical Device Software Life Cycle Processes 4
G Adopting old product - compliance with IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 12
A IEC 62304 safety classification, External Controls and off-label use related risks IEC 62304 - Medical Device Software Life Cycle Processes 5
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 3
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3
K IEC 62304 - Testing Independance IEC 62304 - Medical Device Software Life Cycle Processes 5
K IEC 62304 - Functional and performance requirements for SOUP items IEC 62304 - Medical Device Software Life Cycle Processes 2
K IEC 62304 compliance - Code reviews as part of verification strategy IEC 62304 - Medical Device Software Life Cycle Processes 5
M IEC 62304 Class A Project IEC 62304 - Medical Device Software Life Cycle Processes 15
B Clause 5.1.12 of Technical Standard IEC 62304/A1 IEC 62304 - Medical Device Software Life Cycle Processes 5
P SOUP anomaly evaluation for MMA (Mobile Medical Application) IEC 62304 clause 7.1.3 IEC 62304 - Medical Device Software Life Cycle Processes 6
P IEC 62304 - evaluation of integration and system testing IEC 62304 - Medical Device Software Life Cycle Processes 4
D Required Checklist Showing Compliance to IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 11
P Proposed revision of IEC 62304 - 2019 IEC 62304 - Medical Device Software Life Cycle Processes 6
S Relationship between IEC 62304 problem resolution and ISO 13485 IEC 62304 - Medical Device Software Life Cycle Processes 8
P IEC 62304:2006 A1:2015 - Software from the early 1990s IEC 62304 - Medical Device Software Life Cycle Processes 4
B IEC 62304:2015 vs IEC 62304:2006 + AMD1 IEC 62304 - Medical Device Software Life Cycle Processes 4
F IEC 62304 - Segregation and communication between software items IEC 62304 - Medical Device Software Life Cycle Processes 1
B Class IIB Device - IEC 62304 Software Classification IEC 62304 - Medical Device Software Life Cycle Processes 13
B IEC 62304 - Update Checklist IEC 62304 - Medical Device Software Life Cycle Processes 2
L Connection between IEC 62304 and Chapter 14 of IEC 60601-1 IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
M IEC 62304 - Develop an Architecture for the Interfaces of Software Items IEC 62304 - Medical Device Software Life Cycle Processes 8
S Does IEC 62304 require documenting unresolved anomalies for all safety classes? IEC 62304 - Medical Device Software Life Cycle Processes 4
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
T I need to make test reports according IEC 62304 & IEC 62366 IEC 62366 - Medical Device Usability Engineering 2
D Changing software classification via software - IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 3
K Trying to figure out what satisfies a few aspects of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 2
Y IEC 62304 Section 4.3(a) - 100% probability of failure IEC 62304 - Medical Device Software Life Cycle Processes 3
Y Application of IEC/EN 62304 at an advanced stage of software development IEC 62304 - Medical Device Software Life Cycle Processes 4
T Is there any requirement to be compliant with IEC 62304 while implementing ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 5
L Documentation Planning - IEC 62304 Clause 5.1.8 IEC 62304 - Medical Device Software Life Cycle Processes 2
C Software for Medical Devices - Requirements Content for compliance with IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 1
W CPU BIST IEC 62304 - Embedded code has CPU instruction tests IEC 62304 - Medical Device Software Life Cycle Processes 2
K IEC 62304 Amd 1 2015 - Figure 3 – Assigning Software Safety Classification IEC 62304 - Medical Device Software Life Cycle Processes 11
C Per IEC 62304, are DHF documents Configuration Items? IEC 62304 - Medical Device Software Life Cycle Processes 8
P IEC 62304 AMD1:2015: What's new vs.the 2006 Edition? IEC 62304 - Medical Device Software Life Cycle Processes 4
F FDA PMK 510(k) - IEC 62304 Software Components Segregation Other US Medical Device Regulations 3
M IEC 62304 Applicability - GUI Control Software IEC 62304 - Medical Device Software Life Cycle Processes 3

Similar threads

Top Bottom