Software as control or protection will lead to different Software Safety Class?

VinceTech

Involved In Discussions
#1
Hi,

There are two design:
1. A control system is hardware and its protection system is software. Without software protection system, the control hardware failure will lead to serious harm.
2. A control system is software and its protection system is hardware. Without hardware protection system, the control software failure will lead to serious harm.

Would the software be classified to the same Safety Class B according to IEC 62304?

Thanks,

Best regards,
 
Elsmar Forum Sponsor

Peter Selvey

Staff member
Super Moderator
#2
Depends on whether amendment 1 is included. The original publication in 2006 specifically refers to a hardware risk control, but the amendment in 2015 changed to "additional RISK CONTROL measures external to the SOFTWARE SYSTEM".

Although we often refer to independent control and protection, what the real target is two identifiable, independent means of protection similar to electrical safety. It does not matter what form they take (hardware, software, mechanical etc). The control system can be one of the means of protection.
 

VinceTech

Involved In Discussions
#3
Hi Peter

In IEC 62304:2014 Figure 3, there is a note: "A SOFTWARE SYSTEM which implements RISK CONTROL measure may fail, and this may contribute to a HAZARDOUS SITUATION. The resulting HARM may include the HARM which the RISK CONTROL measure is designed to prevent (see 7.2.2b)"

To the design 1 (Hardware Control + Software Protection), for assigning a class to the SOFTWARE based on Figure 3, is it reasonable to consider the Hardware Control is the RISK CONTROL measures external to the software? In this case, I treat Hardware Control is one means of protection while Software Protection as another means of protection fails with probability =1.

Thanks,
 

Peter Selvey

Staff member
Super Moderator
#4
To be clear, the classification method in 62304 is flawed because it tries to take a simplistic approach to a complex situation.

Most regulations have three or four "Classes" for devices: low, medium high; A, B, C; I, IIa, IIb, III etc. To determine these classes there are two options: #1 (USA, Japan, Canada, China?) - make lists with the classification pre-determined by people with experience; or #2 try to make some rule based approach (EU, and those that copied the EU), and, somewhat conspicuously, IEC 62304.

The EU's rule based approach deserves a lot of respect, they have done a pretty good job but it requires many rules with over 2000 words of text in the regulation, plus a 51 page MEDDEV guidance to help explain the nuances. In other words - not as simple as A, B, C. Brexiters might complain but I think their kudos is well deserved. Complexity does not mean "too hard" or "impossible", it just means a little more detail is required.

IEC 62304 tries to make 3 classes in roughly 200 words. Sorry, but that's an abject failure of the standards committee to appreciate the complexity of the situation. It is possible to classify software, but my guess is at least 1000 words of text would be needed to handle all the different situations, plus 2000-3000 words in guidance to flesh out the nuances.

Anyway ... the point is that you need to apply some common sense in determining the classification. Don't read the literal words in the standard.
 
Last edited:

VinceTech

Involved In Discussions
#5
Hi Peter,

We do feel the process of defining Software Class is a bit odd. Our engineers may not read the literal words but using common sense. The concern is if Regulatory bodies will read literal words in the standard.

I have another question regarding the process defined in IEC 62304:2015 Figure 3. The second step in the process is 'Evaluate effectiveness of RISK CONTROL measures external to the software.' Could you please comments if the 'effectiveness includes the consideration in the probability of RISK CONTROL measure failure occurrence?

Thanks,

Best regards,
 

Peter Selvey

Staff member
Super Moderator
#6
Yes, probability of failure of the risk control is a factor. But you need to consider the whole sequence, including failure of the software and even factors external to the device (some devices, the probability of harm from device failure is high, other cases the doctor or user would normally notice and intervene, or some other reason why device failure doesn't always lead to high severity harm).

There are times when even two means of protection are not enough. In those cases, the solution usually involves some adding some periodic checks for the protection system, such as an automated start up test or inter-comparison of the data from sensors used for control and protection. It's rare to see three means of protection in a medical device.
 

VinceTech

Involved In Discussions
#7
Hi Peter,

As process in Fig 3 assumes Software Failure is 1. This will normally lead to a high reliable protection external to the software (such as high reliable independent hardware protection). However, as most hardware protection with more than 10 components will have a level of 1/1000 failure/year based on Military handbook. This is not sufficient for the serious harm if the hazardous situation is not obvious to the operator or patient. Also, most the self initial check is done by software. This means the selfcheck will not be effective in the software classification process.

Could you please advise.

Thanks,
 

Peter Selvey

Staff member
Super Moderator
#8
The assumption of 100% failure is just for classification, not risk evaluation. It just determines the parts of the standard that apply (A, B, C requirements).

Once you get into the actual risk analysis there is no normative requirement to assume 100% failure for software. There may be some poorly worded guidance floating around but usually the context is in determining if a risk control is required, it simply cannot work to continue to assume 100% failure rate in the the final residual risk evaluation.

I understand the original thinking behind the "100% failure of software" logic but I don't agree because it is too easy to misconstrue.
 

VinceTech

Involved In Discussions
#9
Hi Peter,

Process in Fig 3 does confuse me. The 3rd step is "Does failure of the software result in unacceptable RISK." This step sounds I will need to conduct the proper risk analysis under assumption of Software Failure 100% and hardware protection failure 1/1000/year. This leads to total 1/1000 failure in total. for a serious harm, the risk is unacceptable. This means all medical device with 2 means protection will be ended up with Software Class C if the harm is serious.

Thanks,

Best regards,
 

Peter Selvey

Staff member
Super Moderator
#10
Hmm, I never looked at it that closely. There seems to be a more fundamental mistake than I had thought. Weird that it has not been challenged.

You would expect that a high risk medical device (e.g. infusion pump, dialysis, incubator etc) would start out as Class C, and then drop to B once an external risk control is applied. Class B is still important to keep the overall probability low. Class A controls are too weak.

However, the flow chart indicates that for a high risk device, the only possibility is either Class A or Class C. No middle ground solution. And, as you point out the external risk control would have to have a failure rate of ~0.000001/year in order to justify A, otherwise, the software has to stay at Class C.

Wrong. Wrong. Wrong.

Marcelo, any insight?
 
Thread starter Similar threads Forum Replies Date
I Document Control Software Document Control Systems, Procedures, Forms and Templates 2
N ISO 13485 7.3.9 Change control in medical device software ISO 13485:2016 - Medical Device Quality Management Systems 6
GreatNate Master Control QMS software Quality Tools, Improvement and Analysis 0
N What are the software audit and control steps Reliability Analysis - Predictions, Testing and Standards 2
C 8.5.1.1 Control of Equipment, Tools, and Software Programs - Questions about the extent of control of NC programs AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
R Software change control process and defect tracking ISO 13485:2016 - Medical Device Quality Management Systems 1
J Document Control Software Needed ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
R SaMD - Software as a Medical Device - Software change control form ISO 13485:2016 - Medical Device Quality Management Systems 3
R Changing Document Control software. Must I transfer EVERYTHING? Document Control Systems, Procedures, Forms and Templates 3
JoCam Medical Device Software - Apps which can control medical devices EU Medical Device Regulations 13
D Software as risk control - Confused on one aspect of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 20
D Software for advancing with Document Control Quality Assurance and Compliance Software Tools and Solutions 4
A CAQ Software - Implementation of a Software for FMEA's and Control Plans FMEA and Control Plans 0
Y Risk Control Implemented in Software IEC 60601 - Medical Electrical Equipment Safety Standards Series 6
M IEC 62304 Applicability - GUI Control Software IEC 62304 - Medical Device Software Life Cycle Processes 3
A 5.5.3 - Software Unit Acceptance Criteria (Risk Control Measures) IEC 62304 - Medical Device Software Life Cycle Processes 3
T Software for linking Process Flow Diagram, Process FMEA and Control Plan APQP and PPAP 9
A Non-Conforming Material Control and Inventory Software System Recommendations Quality Assurance and Compliance Software Tools and Solutions 5
I Any recommendations on software for managing the APQP, PPAP, PFMEA, Control Plan etc? Quality Assurance and Compliance Software Tools and Solutions 2
M Is explicit revision control needed if handled automatically by software? Document Control Systems, Procedures, Forms and Templates 6
H ISO 9001:2008 Clause 7.6 Control of Monitoring and Measurement (Computer Software) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
O Camio Output Control - Programming on Camio 4.6 CMM Software Inspection, Prints (Drawings), Testing, Sampling and Related Topics 1
D Documentation Control Software for small companies on a Budget Quality Assurance and Compliance Software Tools and Solutions 10
C Change Control Forms Post Software Validation Medical Information Technology, Medical Software and Health Informatics 2
L OpenDocMan Document Control Software Question Document Control Systems, Procedures, Forms and Templates 2
R A simple electronic (software) document control question ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
J Implementing "Gage Control Software" Is anyone using this program? Calibration and Metrology Software and Hardware 12
D Drawing Revision Control Software Document Control Systems, Procedures, Forms and Templates 3
K Change Control for Software System that Controls Aspects of GMP Quality Assurance and Compliance Software Tools and Solutions 5
E Help with ECR/DCR Document Change Control Software Validation Qualification and Validation (including 21 CFR Part 11) 6
M How to Choose the Best Document Control Software Quality Assurance and Compliance Software Tools and Solutions 14
Z Floppy Disk Software Control - Floppy Disk with Software for Testing Document Control Systems, Procedures, Forms and Templates 4
M Has anyone used "Paradigm 3" software to Control their Quality or Management System? Quality Tools, Improvement and Analysis 2
C Process Mapping Electronic Document Control Software Recommendations Quality Tools, Improvement and Analysis 5
L Engineering Change Control Software Systems - Recommendations? Document Control Systems, Procedures, Forms and Templates 2
B Work Instruction Application (Software for Document Control) Quality Assurance and Compliance Software Tools and Solutions 2
V Electronic Document Control Software suggestions wanted Document Control Systems, Procedures, Forms and Templates 14
L Data Management and Web based Document Control Software Document Control Systems, Procedures, Forms and Templates 18
J Design Control & Rapid Prototyping - Medical Device Software 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
A Choosing Document Control Software Document Control Systems, Procedures, Forms and Templates 13
D How to Control Software Program based Forms - Document Control Document Control Systems, Procedures, Forms and Templates 1
A ISO 13485, Document Control and Software Validation ISO 13485:2016 - Medical Device Quality Management Systems 9
C Document Control Software Pricing Document Control Systems, Procedures, Forms and Templates 1
M Commercially available software solution for the control of our CNC programs. Records and Data - Quality, Legal and Other Evidence 3
T Document Control of ERP Report Format from Software Document Control Systems, Procedures, Forms and Templates 13
T Control of Medical Device Software Subcontractor ISO 13485:2016 - Medical Device Quality Management Systems 1
M Document Control Software Program with Revision Tracking Recommendations Document Control Systems, Procedures, Forms and Templates 7
Casana Control ES vs. Compliant Pro Document Control Software - Recommendations please Document Control Systems, Procedures, Forms and Templates 1
J What SPC (Statistical Process Control) software is your company using? Statistical Analysis Tools, Techniques and SPC 15
M Do you use Software to Control Preventative & Corrective Actions? Quality Assurance and Compliance Software Tools and Solutions 1

Similar threads

Top Bottom