High Integrity Components Definition according to clause 4.9 of IEC60601-1 3rd ED

R

robertjbeck

#31
the only problem with this scheme is that the diagram in ISO 14971 clearly shows that the hazard precedes the hazardous situation, which precedes the harm, and the diagram shows that the sequence of events are between the hazard and the hazardous situation. for software, the only way I know how to assess its risk is to include things that start with the software not operating the way designers think it's supposed to. some of these are design flaws, some are coding errors, and some are system integration problems, but they are all collectively referred to as bugs, or software defects. the word defect is a bit misleading, because it comes from a testing and SQA viewpoint, but if ISO 14971 is to be applied, this seems like a compliant way to do it.

You called the burn the hazard and the harm. this is what confuses people. the harm is definitely the burn, if one occurs. the hazard is that the software makes a bad calculation. another hazard is the user enters data incorrectly. both of these hazards should be in the risk assessment. the first one is pure software defect, the second has to do with training, IFU, and usability of the user interface.
 
Last edited by a moderator:
Elsmar Forum Sponsor

Marcelo

Inactive Registered Visitor
#32
the only problem with this scheme is that the diagram in ISO 14971 clearly shows that the hazard precedes the hazardous situation, which precedes the harm, and the diagram shows that the sequence of events are between the hazard and the hazardous situation. for software, the only way I know how to assess its risk is to include things that start with the software not operating the way designers think it's supposed to. some of these are design flaws, some are coding errors, and some are system integration problems, but they are all collectively referred to as bugs, or software defects. the word defect is a bit misleading, because it comes from a testing and SQA viewpoint, but if ISO 14971 is to be applied, this seems like a compliant way to do it.
Again, there?s no risk in software. Risk are related to hazards that happen to the patient. If you take a look at the example list of hazards from table e.1 of ISO 14971, you will see that those are things related to the patient/user.

You do not necessarily need to begin with the hazard, but you do need to define is sometime because, otherwise, there?s no hazardous situation and thus no risk.

From my experience, and it seems what you are saying, you can begin with the software defect/bug/failure/whatever as the initiating cause in the sequence of events, but then you have to conclude what the hazardous situation is, and in this case you should define the hazard based on that hazardous situation. What means you always need to check if what you did is according with figure E.1.

A lot of times, is see the hazard defined in a risk management file having nothing to to with the hazardous situation (and remember the hazardous situation is the exposure to the hazard), so, even with the sequence of events being correct, the rest is wrong from the perspective of IS 14971.

The real problem with these types of standards is that people think it?s only a table, and as such, you can write anything on it (but it does not mean it?s correct :p)).
 

Marcelo

Inactive Registered Visitor
#34
You called the burn the hazard and the harm. this is what confuses people. the harm is definitely the burn, if one occurs. the hazard is that the software makes a bad calculation. another hazard is the user enters data incorrectly. both of these hazards should be in the risk assessment. the first one is pure software defect, the second has to do with training, IFU, and usability of the user interface.
No, the hazard would be Thermal energy/High temperature (again, using table E.1). As I mentioned, I put burn in the example, to make things more easy to see, but your are correct that this confuses a lot of people sometimes.

Bad calculation, user entering incorrectly data, they are not hazards, they are part of the sequence of events leading to a hazardous situation.
 

Marcelo

Inactive Registered Visitor
#35
Well, at least following ISO 14971 which has clear definitions for those terms (although the definition of hazard is still a bit unclear in my opinion :)).

People confuses the terms a lot - hazards, risk ,etc. This is also part of the problem.
 

Marcelo

Inactive Registered Visitor
#36
And in the previous example with the projector, the hazard would be Mechanical energy-Gravity-Falling (again, using table E.1 of ISO 14971 as reference).
 

Roland chung

Trusted Information Resource
#37
Hi Marcelo,

You did make some good points here. Thank you!

But from the example given, I do think the standard is wrong to set probability of software failure to 100% just for simplification.

One software example (I?m using "burn" for everything for simplicity):

- Hazard - Thermal energy - High temperature
- Sequence of events for a device controlled by software (US for example):
1 - user enter US treatment data
2 - software bug calculates the wrong amount of output
3 - user applies US transducer to patient leading to unwanted high output in patient
- Hazardous situation - patient is burned by unwanted output
Harm - Burn
It is expected that both P1-1 and P1-3 are 100% (certain to happen) because of there are too many patients and pregnant women need to use ultrasonic scanners every day (1 per device per day). Since P1-2 is also 100%, then P1 = 1. This is unpractically high and lead to unnecessarily additional protection.
 

Marcelo

Inactive Registered Visitor
#38
It is expected that both P1-1 and P1-3 are 100% (certain to happen) because of there are too many patients and pregnant women need to use ultrasonic scanners every day (1 per device per day). Since P1-2 is also 100%, then P1 = 1.
Not necessarily. This is only a generic fixed and simple example. If you have a hardware control measure after the software bug, P1 would not be 100% (in fact, the risk might not even exist).
 

Roland chung

Trusted Information Resource
#39
That is the question. At the end of the day, you will find everything ends up with the hardware protection if you set the probability of software failure to 100% (I can imagine that the sequence of events is not so help in many cases). This may only make sense for high risk product as mentioned by Peter.
 

Marcelo

Inactive Registered Visitor
#40
That is the question. At the end of the day, you will find everything ends up with the hardware protection if you set the probability of software failure to 100% (I can imagine that the sequence of events is not so help in many cases). This may only make sense for high risk product as mentioned by Peter.
Again, not necessarily. As the example from 80002-1 that I quoted above, a checksum to prevent memory corruption could be assumed to lower the probability, even if not possible to numerically estimate the risk.

Also, please note that the standard is created for software in general, and for low and high risk devices. Obviously the solutions might not fit all, and in some cases, yes, only a hardware risk control measure would be acceptable.

Also note that Amendment one more clearly specify and accept this.
 
Thread starter Similar threads Forum Replies Date
R What is meant by Use of COMPONENTS WITH HIGH-INTEGRITY CHARACTERISTICS in ME EQUIPMENT (clause no 4.9) IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
Marc NIST 'High Integrity Software Systems Assurance' resource (site semi-abandoned) Software Quality Assurance 2
D High level understanding of EUDAMED EU Medical Device Regulations 3
S Complexity Rating - CB adding another audit day for "high complexity" AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 6
D Supplier Quality level category help - high level ISO 13485:2016 - Medical Device Quality Management Systems 6
R DFMEA/PFMEA mitigation of high severity (9-10) in low volume products IATF 16949 - Automotive Quality Systems Standard 1
T How to justify this High %Tolerance Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 3
J Production Line Test Brasil - High Voltage Dielectric Strenght Test Other Medical Device Regulations World-Wide 5
S High voltage testing - ISO 17025 - 7.2.2 Validation of methods and 7.3 Sampling ISO 17025 related Discussions 3
D Performance of high shear mixer (or rapid mixing granulator Qualification and Validation (including 21 CFR Part 11) 4
Q % Study variation low, % tolerance high - GR&R Interpretation help Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 3
N Heavy tare to simulate high load in a routine sensitivity test of a floor scale? General Measurement Device and Calibration Topics 3
B HIGH QA Software - Auto ballooning software Quality Assurance and Compliance Software Tools and Solutions 2
F 5520A High Performance Multi-Product Calibrators General Measurement Device and Calibration Topics 0
N Use part of high risk device for establishing low risk device EU Medical Device Regulations 0
M Informational EU – Candidate List of substances of very high concern for Authorisation Medical Device and FDA Regulations and Standards News 0
M Informational From RAPS – Another Notified Body Bows Out Ahead of EU MDR: ‘Investment Too High’ Medical Device and FDA Regulations and Standards News 2
M Sampling Plan for Alumin High Pressure Die Castings Manufacturing and Related Processes 0
M Informational EU – Draft Functional specifications for the European Database on Medical Devices (Eudamed) – First release (High(1)) to be audited Medical Device and FDA Regulations and Standards News 0
I DOE: High variance and small effects in Minitab Using Minitab Software 1
S High warpage and negative shrinking in PPO + PS blend Design and Development of Products and Processes 0
Sidney Vianna High number of certificate suspensions in the IAQG OASIS database AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 14
Paul Simpson Informational The role of Annex SL - High Level Structure of ISO MSS's - Revision Update February 2019 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 26
E High level structure - Planning and operation control Occupational Health & Safety Management Standards 2
M Process Capability in a High Precision Environment Capability, Accuracy and Stability - Processes, Machines, etc. 7
S Opinions on the "Best" CMM for High Accuracy Machining General Measurement Device and Calibration Topics 9
O Is the Quality Objective for Company-wide Training as >90% too high? Training - Internal, External, Online and Distance Learning 4
N Definition Needed: High Level Acronym Buzzword Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 9
N Timing for Closing High FMEA RPN Items FMEA and Control Plans 4
M ISO 13485 and the High Level Structure (HLS) ISO 13485:2016 - Medical Device Quality Management Systems 0
P Is the next revision of ISO 15378 following the High Level Structure? Other ISO and International Standards and European Regulations 5
P Accounting for Variability on High Side of Specification Reliability Analysis - Predictions, Testing and Standards 1
J Uncertainty budget for IR thermometry at high T - 1000 - 1500?C Measurement Uncertainty (MU) 1
G Stable, Predictable, Control - High Volume Mfg Statistical Analysis Tools, Techniques and SPC 9
N Microsoft Word - How to make high-light go away after text is put in Excel .xls Spreadsheet Templates and Tools 5
J Meeting Feasibility Requirement - High number of part quotes IATF 16949 - Automotive Quality Systems Standard 6
C Is there a standard for HALT (High Accelerated Life Testing)? Reliability Analysis - Predictions, Testing and Standards 15
Hershal This week in the High Desert Coffee Break and Water Cooler Discussions 14
B Determing Machine Capability in a High Mix, Low Volume Sheet Metal Shop Manufacturing and Related Processes 4
Y How to cut off Extremely High and Low Data Statistical Analysis Tools, Techniques and SPC 2
C Suggestions on Sample Plans for High Volume/Low Cost/Low Risk Components Inspection, Prints (Drawings), Testing, Sampling and Related Topics 2
F High Level Disinfection Risk - Neonatal CPAP Device EU Medical Device Regulations 1
M Viscometer MSA / GR&R failure - High Variability Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 11
2 High-tech medical equipment to reduce medication errors Medical Information Technology, Medical Software and Health Informatics 5
M Differences between High, Medium, Low Risk Suppliers Supplier Quality Assurance and other Supplier Issues 5
K Probability of Occurrence Ranking for Low Volume Manufacturing vs High Volume FMEA and Control Plans 11
M Quality issues in a manufacturing plant - High-pressured solvent spray cans Quality Manager and Management Related Issues 2
T Mercury is covered under RoHS but is not a substance of very high concern (SVHC) ? RoHS, REACH, ELV, IMDS and Restricted Substances 2
F Statistical Comparison of Product: High Average vs. Low Range Capability, Accuracy and Stability - Processes, Machines, etc. 13
C AS 9102 Form 0 "Additional Information for High Risk Characteristics" AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3

Similar threads

Top Bottom